Swimlanes are a very effective way to perform assignment, and we have 
implemented several that are nicely reusable.

A swimlane though, isn't always (to my mind) the same actor or actors 
throughout the life of a process instance.  In our case (and we've several use 
cases where this is applicable) a swimlane may represent an actor(s) that are 
related to a particular object or object in the process.  

The problem arises when the user(s) that are related to said object change in a 
long-running process. 

For example, a long running requisition process.  The manager of the user who 
made the requisition may wish to have notifications as the process goes along 
(we have integrated email functionality in a custom extension).  The most 
intuitive way to handle this as a process author is to use a swimlane that 
defines the relationship.  The current jBPM TaskMgtInstance will only perform 
the assignment once per swimlane though, assuming that the SAME actor(s) will 
be used for the life of the process.  Depending on what you're orchestrating, 
this may not be tenable.  

I think at the least there ought to be a way to allow a swimlane to configure a 
swimlane to perform its work every time it is referenced rather than using the 
previously determined actor(s).  

I've made a modification to jBPM to force swimlane instances to ALWAYS perform 
assignment, and while this fixes the issue in the short term, eventually I plan 
to modify either the global config for swimlanes, and better, add an attribute 
to the swimlane declaration that allows configurable behavior on a swimlane 
that will override the global default.  In this way you could have the current 
behavior or configure the global setting to behave as I've discussed and 
provide an override to the current behavior on a case by case basis.

You can get this behavior using nested assignment delegations, but there are 
reusability issues as well as the general cleanliness of the jPDL language to 
consider.  We think swimlanes are in many cases more intuitive, and make the 
process definition much more readable.

As we've discussed in internally, this seems reasonable, and seems to be 
required in a flexible environment supporting long running processes.

What do you think?

View the original post : 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967387#3967387

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967387
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to