various questions

[tom.baeyens]

taking the liberty to post Fady's questions here so everyone can follow the conversation and join in.

"Fady" wrote:
Dear Tom,
I have been reviewing the code of JBPM in CVS and the code of the
web-console specifically.
And I believe a number of enhancements need to take place.

First of all, each workflow instance should be given a subject and a
priority. Those fields can be hidden for some users. The benefits of
them come when someone is dealing with a large number of tasks. The
priority fields highlights the criticality of the task while the
subject field provides with a quick way of identifying a task.

Moreover, is there any extra documentation outside the repository? For
instance I want to know what each JBPM tag is doing without having to
go into the actual code. An architecture document if available would
be very helpful.

Waiting for your feedback,

Best Regards,
Fady

[tom.baeyens]

"Fady" wrote:
First of all, each workflow instance should be given a subject
...
the
subject field provides with a quick way of identifying a task.

you mean as a variable ? what data should be filled in ? i don't think that it is a good idea to force the user to enter a subject. apart from that, the process definition contains a name and a description.

also the task definition has a name that is copied into the task instance as a kind of default value. after that, the task instance name is changeable. don't know if the UI allows this currently, though.

would the task instance name cover your requirements ? or how is your subject different ?

"Fady" wrote:
and a
priority.
...
The
priority fields highlights the criticality of the task

task definitions already have a priority. this priority is copied into a task instance when it is created. then the priority can be changed for that specific task instance. is that what you're looking for ?

"Fady" wrote:

Moreover, is there any extra documentation outside the repository? For
instance I want to know what each JBPM tag is doing without having to
go into the actual code. An architecture document if available would
be very helpful.

currently i'm the architecture document :-( feel free to use me for this purpose. maybe i should respond to all your questions in a wiki page so that can grow to become the architecture document...

[fady.matar]

Let's add the Wiki page to the JBPM web console wiki. Shall I create it?

[tom.baeyens]

yes. good idea.

[kukeltje]

Tom,

The subject could be the 'business' key Gavin also wants for seam (at least that is how I interpret it)

[tom.baeyens]

"kukeltje" wrote:
Tom,

The subject could be the 'business' key Gavin also wants for seam (at least that is how I interpret it)

i don't want to impose users with the task of specifying a business key.

i think that hibernate or JPA should solve the object identity problem :-)

regards, tom.

[estaub]

Hibernate/JPA can't solve the identity problem when the requirement is to apply a specific externally-generated identifier to the process and be able to reference the process by it later. This is a frequent business requirement.

In BPEL, all of the "Correlation Set" support addresses this - far more comprehensively than you/we perhaps have any need for.

-Ed Staub

[kukeltje]

I think that an externally generated businesskey on the process level, other than in a standard process variable, makes sense for jpdl as well, but that is my opinon. You should be able to pass it when starting a process.

[tom.baeyens]

"estaub" wrote:
Hibernate/JPA can't solve the identity problem when the requirement is to apply a specific externally-generated identifier to the process and be able to reference the process by it later. This is a frequent business requirement.

IMO, HB/JPA could do a better job of supporting the object identity versus object equality problem.

"estaub" wrote:
In BPEL, all of the "Correlation Set" support addresses this - far more comprehensively than you/we perhaps have any need for.

correlation is related. but i don't see how this justifies the need for business keys. it could only show the opposite. namely that a single business key is not sufficient. to support correlation in bpel, we would need a set of correlations (set of set of primitive values) for each process instance.

regards, tom.

[tom.baeyens]

"kukeltje" wrote:
I think that an externally generated businesskey on the process level, other than in a standard process variable, makes sense for jpdl as well, but that is my opinon. You should be able to pass it when starting a process.

i don't yet see the use cases.

first of all. technically, i think we could most easily implement a business key as a specially identified variable. (i don't think an extra join in the query is a big problem. even if that would be the case, it boils down to a performance issue and not a conceptual one)

second, while i can see the value of business keys for a number of use cases. making it mandatory is something else. i still see many use cases that would not require a business key. would they need to start inventing one ? that is still not clear to me. and just posing the invention of business key onto the user is unacceptable to me as i think this will increase the learning curve for a lot of people that don't need this feature.

[estaub]

Tom,

You didn't have to put names on process definitions, nodes, etc., but you did. Why? - because people have external handles on these things (in these definition cases, mostly concepts in their brains) by which they want/need to refer to the definition elements.

In the process instance case, the "business key" frequently is some key value that also is externally held (either mentally or by another system) by which folks need to prioritize their tasks, monitor, or intervene in. Usually it refers to some variable that is the "subject" of the workflow. In my experience, folks nearly always want this in some form. If you are concerned about requiring folks to invent a key, you could defaullt it to a combination of definition and date/time.

I have a feeling there's some much deeper divergence in intent here... this is so obvious that it would have to be obvious to you unless we were starting from very different places. I don't know what the deeper difference is, though...

Thanks,
-Ed Staub

[dmlloyd]

Why not do the same thing that has been done with names/descriptions - add a business key column for tokens/tasks/whatever, index it by default, but initialize it to null. This way if the user doesn't want to use it, they don't have to. I don't see it as a "mandatory or forbidden" kind of situation.

[tom.baeyens]

"estaub" wrote:
Tom,

You didn't have to put names on process definitions, nodes, etc., but you did. Why? - because people have external handles on these things (in these definition cases, mostly concepts in their brains) by which they want/need to refer to the definition elements.

i think i understand the concept.

but i have a hard time finding proper use cases for it. can you give examples ?

how would that differ from using the process variables ? just convenience methods ? or would it be conceptually difference.

[tom.baeyens]

Why not do the same thing that has been done with names/descriptions - add a business key column for tokens/tasks/whatever, index it by default, but initialize it to null. This way if the user doesn't want to use it, they don't have to. I don't see it as a "mandatory or forbidden" kind of situation.

again, this would be equivalient to marking one variable as being special, right ?

also here my main point is in finding the set of use cases that could guide me in finding the right methods that need to be implemented for this.

regards, tom.

[dmlloyd]

Yes, that's exactly it - a specialized process variable. Having this sort of special process variable could be very handy in many cases - an account number, or request ID, or ticket number... for every use case I can think of, I can see how a business key would be useful. And by providing a common place for it, we can include it in the web console by default, and that's one less customization a user would have to do.