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?
Yes, I (personally) agree to. File a jira issue for this and have as many people vote for it. It could be made configurable with an attribute like 'evaluate="always"' or 'evaluate="once"'
Post your patch with the bug, since that might speed up implementation.
I'll post a patch when I implement the "real" solution. Currently we want this to happen always, so we made a quick modification to TaskMgtInstance only. To impl the patch fully there will be a bit (just a little) more effort.
I'm waiting to hear from any of the jBPM devs on the general concept of the feature before we do a lot more work than what is required for the current implementation.
I already forwarded the link of the jira issue to Tom. I hope he responds soon (he's kind of busy).
I don't think Tom will be against this (I certainly am not)
Thanks anyway for wanting to contribute
Hello! I remember reading this months ago and thinking "what would that be used for?" Well, now I need it. I'll hack a patch myself unless anything has anything handy...?
No, nothing at hand afaik.
i made it work last night. ish. a few questions so I can submit a patch:
- i added it to the Assignment element, not the swimlane element. thoughts?
- I dont know how to update the XML Schema. is it somewhere in SVN? what is the proper way to do that as a patch, etc?
also, i'm not quite clear on how i should best persist the change. should i add a column to the db? for JBPM_DELEGATION? or use JBPM_DELEGATION.CONFIGURATION_ somehow?
I have it working locally for what i need but i'm hardcoding some things until I sort this out and can submit the patch. The only files i've modified so far are:
Delegation, TaskMgmtInstance, and TaskInstance.
I'll give this a thought over the weekend. One important thing is backwards compatibility. So if needed an update/upgrate script for the db is needed.