[Design of JBoss jBPM] - Strongly type assignment and pooled tasks
by Johan.Parent
Hi all,
I'd like to ask for some clarification regarding some of the pooled task internals of jbpm.
I'm working for a large university hospital. We us jbpm-3.1.4 for 2 years already. We've got plently processes in the air thank to jbpm. Supporting clinical pathways with workflow comes with its sets of challenges. The task assignment in particalur is difficult since it needs combine what is essentially a patient-centric view on one hand with other nitty gritty details of the internal organization.
Fortunately jbpm allows using an alternative TaskInstance implementation. I used this to its fullest extent to introduce custom changes in the assignment code. For two reason (which I hope to (in)validate with this post):
1) inspection of the pooled actors entries revealed a large amount of duplicate values. In practice what is conceptually a many-to-many relation between taskinstances and pooled actors (cfr hibernate mapping) is reduced to a 1-to-many by the code. This relates with this post http://www.jboss.org/index.html?module=bb&op=viewtopic&t=146959
2) the engine uses a String value to represent an assignment. As hinted above our assignment scheme/logic is complex and the use of String values is bursting at it seams. Furthermore we found that the lack of distinction between direct assignments and pooled assignments can lead to 'lost' tasks. So I added types for each kind of assignment to the API. These started of as a simple wrapped String but became more to meet our needs. With the appropriate helper-class the use of these types turned out the be less unwieldy than it may sound.
The value of the seperate assignment types end up in a seperate table each. This in turns allowed me to address the 'problem' mentioned in (1). First, the pooled actor entries now refer to entries in the pooled assignment table. They now longer represent the assignment directly. The second step was to rewrite PooledActor.createPool() to check for duplicates. Overall this was fun to do. The join table used for the pooled actors is now used as it should be. We have fewer pooled actor entries and all our unit tests are still green too ;)
Why the long story then? I could make all these changes simply by pluging in the alternative TaskInstanceFactory and providing the necessary queries. All this thanks to the nice design of jbpm. The problem showed up when I looked at the swimlanes. The overall logic largerly duplicates that of the task assignments. No big worry either except for ONE thing: the relation between a pooled actor and a swimlane instance! I had to provide an alternative swimlane implementation as well, and that's not simply pluggable as far as the engine is concerned.
I may of course be completely wrong here, hence this post, but a pooled actor does not strictly need a swimlane field. I think this could be avoided by using a seperate many-to-many relation (just like for taskinstance-poolactor case) between a swimlane instance and pooled actors. Is this correct or am I forgetting something here? I'm about to go ahead and try this but as it goes I'm getting closer and closer to forking from the original jbpm code. And that's exactly what I want to avoid. So again, am I going about this in the right way?
I'm not sure whether I am getting the message across clearly. Based on my recent work I would to advocate for a design with more explicit task assignment types. I think this API can prevent mistakes in the implementation of the assignment handlers. While at the same time make it possible make the actual assignment type pluggable as well. Using a String based implementation the default allowing custom type where needed.
Much looking forward to your input in this matter.
Best regards,
Johan
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210679#4210679
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210679
17 years, 1 month
[Design the new POJO MicroContainer] - Re: Redeploy is done wrong
by adrian＠jboss.org
"alesj" wrote :
| "alesj" wrote :
| | This would mean we have to move all the maps that track failing deployments
| | from MainDeployerImpl into DeployersImpl.
| |
| | How does this relate with method signature changes?
| |
| This means I have to move everything (map, comparators, ...) to DeployersImpl.
| As there is no point in hacking again, to have some ugly callbacks to MainDeployersImpl.
|
| I'll keep MainDeployerImpls's interfaces, which will only delegate to DeployersImpl, OK?
|
| I guess this means we'll have to do Deployers 2.1?
Why can't you just change MainDeployersImpl.process() to be?
| Deployers.process(toUndeploy, Collections.emptyList());
| determineStructureForToDeploy();
| Deployers.process(Collection.emptyList(), toDeploy);
|
That doesn't involve any changes to the external api.
The thing that changes is that you can't get the DeploymentContext/Unit from the
MainDeployer until you've invoked process() whereas previously
you could get it after addDeployment().
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210657#4210657
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210657
17 years, 1 month