execution transitions, data flow and other associations

[tom.baeyens]

currently, our model only has transition as the directed connection between nodes.

the BPDM (http://www.bpmn.org/BPDM_Documents.htm) defines multiple types of connections:
* sequence flow (for execution transitions)
* message flow (expressing how data flows in the process)
* association (just any association that a business user can draw between two graphical elements)

would it make sense to add multiple types of connections to the jbpm core library over time ?

how could these be used in jPDL ? what would a data connection mean exactly ? what are its possible sources and destinations ?

could data connections also influence the execution ? e.g. if execution arrives in a node that also is the destination of a data connection and that data is not available yet, should be process execution be halted till the data becomes avialable ?

more questions then answers. please add your opinions so that we can get closer to the answers :-)

[koen.aers]

Tom,

I think that message flow and associations are typical constructs that are used by a business analist. I am not sure they are that important to the execution. Of course if message flows are added to the GPD at some point in time and the GPD is to operate on the same model as the runtime engine, it would make sense to add these capabilities to the core model.
As for the question what a message flow would mean in jPDL, I think it could be used to somehow limit the visibility of the variables contained in this flow to all the nodes that are connected by the flow.

Regards,
Koen

[kukeltje]

page gives a 404, googlecache: http://64.233.183.104/search?q=cache:fDzgOi1k404J:www.bpmn.org/BPDM_Documents.htm+bpdm&hl=nl&gl=nl&ct=clnk&cd=1&client=firefox-a

[brittm]

Tom, a definite yes to more types of relationships.

My business (telecom) requires more complex relationships than jpdl provides. I need the ability to syncronize without merge on certain nodes across processes and sub-processes as well as tokens--and to synchronize various ways. I also need the ability to "multi-parent", or "share", a process.

I've already had to build the ability to multi-parent a process (orthagonal to jbpm) and am starting to work on doing the same thing for synchronization without merge. Here are two use cases:

Synchronization without merge.
A customer may buy several complex services from us, each of which has its own provisioning process. Each product can be billed when it reaches a particular state midway through its execution, but the customer cannot be billed until all products on a single order have become billable. Here, we need to synchronize across subprocesses, without merging.

Multi-Parented processes.
Again, a customer may buy several complex services from us, each of which has its own provisioning process. At some time, we'll want to schedule a technician to visit the customer's location and set up as much as possible in one visit. The scheduling and management of the technician's visit is its own process and becomes a loosely coupled 'subprocess' to several other product provisioning process.

The 'multi-parent' bit is probably outside the scope of your question, but these examples underscore a need to define node-to-node relationships that are both more complex than what we have now and that extend beyond the bounds of a single process instance.

Thanks,
Britt

[tom.baeyens]

Synchronization without merge

We had this once (i think it was called a milestone in jbpm 2). But probably it didn't make it to jbpm 3. I'll make sure this will re-enter in jbpm 4.

This is the same as the links in BPEL, right ?

Multi-Parented processes

Actually, what you need for this is variable colletion support :-) This requirement can be handled with 1 process variables e.g. called 'purposes' which is a collection of ProcessInstance's. jBPM is able to persist references to 'hibernatable' objects in the process variables. But jBPM doesn't yet handle collections. Meaning that if you put a collection of hibernatable objects as a process variable, this will be recognized as a serializable and the serialized value (a large one in case of a collection of process instances), will be stored in binary format in the db.

I'll try to add collection support in jbpm 4. Or do you think there is another (better) way of handling this requirement.?

[kukeltje]

You disappoint me Tom ;-) You probably did not speak to Vanderaalst for a long time

sync without merge != milestone

http://is.tm.tue.nl/research/patterns/mi_w__synchronization.htm
http://is.tm.tue.nl/research/patterns/milestone.htm

[tom.baeyens]

Afaict, the pattern that you reference (Multiple Instances without synchronization) doesn't have anything to do with the original topic. Namely, how to synchronize between two concurrent paths of execution without joining them.

Nevertheless, I do think that we can debate if our previous implementation of a milestone is really the milestone of vanderaalst.

What was implemented previously is a wait state based on the state of another concurrent path of execution. If the other concurrent path of execution has passed a certain point, the token in this milestone node just continues. If not, the token will wait in this milestone until the other concurrent path of execution reaches that point. When that happens, the original token will continue to execute from the milestone.

The milestone pattern is a bit different. There is says that the activity inside a node is executed depending on the state of a concurrent path of execution. So that doesn't involve wait states and recontinuation when the event is reached by the concurrent token.

I believe that was the argument that someone pulled once... Anyways, it's easy to see that because we manage the complete runtime data structure as an object graph, that we can indeed inspect the complete runtime execution state of the complete process instance when the process executes. That gives us the ability to do 'whatever we want' :-)

Have I rehabilitated myself ?

[brittm]

Actually, for Multi-parented processes (Shared Subprocess) I was thinking of something a little more integral. So many of the features that are needed are already being handled by the standard jBPM subprocess mechanism, such as variable passing, it would be a shame to not handle Shared Subprocesses the same way.

I built my solution with two action handlers, two peristable classes, and an access class:
ShareProcInstAH (on node-enter of the 'shared process node')
SharedProcess (hibernatable shared proc, contains: processInstance, groupLabel, startedByToken, sharedProcParentSet)
SharedProcessParent (hibernatable parent, contains: sharedProc, token, joinedDate)
SharedProcessSession (utility methods)
ShareProcNotifyParentsAH (on end state node-enter of the shared proc)

ShareProcInstAH configuration looks like this:

<state name='SHARED_PROC' >
 <event type='node-enter' >
 <!-- If this process is cancelled, or for some other reason must go on without
 the shared sub-process, it is this process's responsibility to break the
 relationship with the sub-process so that this process is not incorrectly
 signalled if and when the sub-process ends. -->
 <action class='com.talk.wf.pd.common.ah.ShareProcInstAH' config-type='bean'>
 <!-- The process instance type that this process will use as a shared
 sub-process. If an available shared sub-process instance already exists, this
 parent will register itself with that; otherwise, a new shared sub-process
 instance will be created. A shared process is avaialable if the shared process
 is of the specified type and the shared process has a 'sharedProcessGroup'
 variable who's value is equal to the value of this process's variable that is
 specified here under <shareGroupVar> -->
 <sharedProcDefName>Shared Proc</sharedProcDefName>
 <!-- The process instance variable that will be compared to the shared process's
 'sharedProcessGroup' variable. If a new shared process is being created,
 this is the variable who's value will be stored in the shared process's
 'sharedProcessGroup' variable. This defines the group of parents that will be
 sharing the single shared process. -->
 <shareGroupVar>orderNum</shareGroupVar>
 <!-- If a new shared process is created, which (if any) of the new shared process's
 parents can cancel the shared process. Valid values are 'initiating' and
 'last remaining'. Default is that no parent can cancel the shared process -->
 <parentCanCancel></parentCanCancel>
 <!-- This parent will only create an association with an existing shared sub-process
 if that shared process instance has not entered or exited the specified Node.
 Whether the limitation is entered or exited is determined by the
 <joinBeforeNodeEvent> setting. The default value is the name of the shared
 process instance's start-state -->
 <joinBeforeNode></joinBeforeNode>
 <!-- Valid values are 'enter' and 'exit'. Default value is 'exit'. -->
 <joinBeforeNodeEvent></joinBeforeNodeEvent>
 <passInVars>someVar as sharedProcVar, someVar2 as sharedProcVar2</passInVars>
 <passOutVars>sharedProcVar as someVar, sharedProcVar2 as someVar2</passOutVars>
 </action>
 </event>
 <transition name='done' to='END'/>
 <transition name='_sys_redoNode' to='SHARED_PROC'/>
 </state>

I'd love to see something like the above configuration incorporated into the process-state. The only data I'm persisting that wouldn't fit nicely into existing jBPM entities would be the sharedProcParentSet; that would properly need to be a new table associated with ProcessInstance.

[brittm]

For what it's worth, these are the methods of SharedProcessSession used in the solution listed above:

public void saveSharedProcess(SharedProcess sharedProcess)
public SharedProcess getSharedProcess(long sharedProcessId)
public SharedProcess loadSharedProcess(long sharedProcessId)
public SharedProcess getSharedProcess(ProcessInstance pi)
public SharedProcess getSharedProcess(Token parentToken, String groupLabel)
public Set getAvailableSharedProcesses(String processDefName, String groupLabel)
public void createSharedProcess(ProcessInstance pi, String groupLabel, Token startedByToken)
public SharedProcess attach(Token parentToken, String processDefName, String groupLabel, boolean createIfNoneAvailable)
public void detach(Token parentToken, String groupLabel)

[kukeltje]

yes rehabilitated and you are right, I should have mentioned http://is.tm.tue.nl/research/patterns/multiple_merge.htm instead... mea culpa

[brittm]

Tom, its my understanding that a Link in BPEL is simply a mechanism that sends a message and waits for a response. In other words, a wait state with a messaging structure defined. Of course, that can be used for synchronization purposes.

What we need for sync without merge is something much more defined. Something that allows processes to 'subscribe' a node to a 'sync group' based on some common variable (like an order number), and then react to various conditions of that group as each participating node is executed.

Configuration could allow participating nodes to react in different ways to various conditions within the sync group, such as:
* If I'm the first to arrive, take my transition a.
* If I'm not the first, take my transition b.
* If I'm the last to arrive, take my transition c.
* Or when the last participant has arrived, take my transition d.

Done properly, this would allow for dynamic processes in which the definition doesn't need to know ahead of time how many instances (or what type of instances) will be participating in a sync group. This kind of dynamic behavior is huge.

Probably within the next week or two I'll have something like this implemented orthagonally to jBPM, but of course, like Shared Subprocess, I'd love to see these concepts integrated into the project.

[tom.baeyens]

brittm: i'm not yet convinced about the shared processes as a general concept to pursue in jpdl. the implications are far reaching and i'm not yet sure this is a common use case.

one thing that might help you already a little bit is that in jbpm 4 we will be componentizing the node implementations. so that you can build complete node packages, including jPDL-parsing, hibernate persistence, actionHandler based implementation, designer form, icon, ... That way it will become more feasible to develop your own custom node and really integrate it into the current runtime and toolset.

maybe the shared subprocesses could become part of jbpm as a kind of advanced or add-on node package, not part of the default configuration.


About links: i think they are something different. Each link is a named boolean that connects two concurrent paths of execution. Then, the target activity has an boolean expression as a function of the arriving links. The activity will only be executed if the link expression resolves to true. But Alex will know better.

[tom.baeyens]

Koen,

I think that message flow and associations are typical constructs that are used by a business analist. I am not sure they are that important to the execution.

They are valuable modelling constructs. But we have to define wether they mean anything at runtime and if so, we have to create a logical story for those other link types.

Of course if message flows are added to the GPD at some point in time and the GPD is to operate on the same model as the runtime engine, it would make sense to add these capabilities to the core model.

The model used by the GPD is second to the real issue here. First we have to define if other link types make sense, second we have to get a crystal clear picture of what the other link types mean at design time and at runtime (if they have any runtime implications at all). Only after that story, we'll see if and how the GPD model is going to cope with this.

As for the question what a message flow would mean in jPDL, I think it could be used to somehow limit the visibility of the variables contained in this flow to all the nodes that are connected by the flow.

If you have a document that has to be passed from one node to another and the analyst wants to model this graphically, the main thing is that the document is produced (entered) in one activity and consumed (available) in the other activity. I don't think that we should be considering to limit the visibility of all other variables in the process.

The runtime impact of data-links then becomes quite thin. It only specifies that the data item is required input in the source activity... But the runtime is not why we would add this. We would add this for the business user to be able to create better models.

Would you think that such a construct is usefull for business users ?