I'm having a problem with a workflow, containing a nested fork, getting
"stuck". This only happens when tasks are completed in a certain order.
I'm wondering if someone can have a look at this as we have several customers
blocked on this one - and I have reached a dead end with trying to find a fix.
Here is the process definition:
<?xml version="1.0" encoding="UTF-8"?>
|
| <process-definition xmlns="urn:jbpm.org:jpdl-3.1" name="wf:fundingrequest">
|
| <swimlane name="initiator" />
|
| <start-state name="start">
| <task name="wf:startFundingRequestTask" swimlane="initiator" />
| <transition name="startToStep1" to="step1" />
| </start-state>
|
| <task-node name="step1">
| <task name="wf:step1FundingRequestTask" swimlane="initiator" />
| <transition name="step1ToFork1" to="fork1" />
| </task-node>
|
| <fork name="fork1">
| <transition name="fork1ToDec1" to="dec1" />
| <transition name="fork1ToStep2c" to="step2c" />
| </fork>
|
| <decision name="dec1">
| <transition name="No" to="join2"></transition>
| <transition name="Yes" to="fork1a">
| <condition>#{2 > 1}</condition>
| </transition>
| </decision>
|
| <fork name="fork1a">
| <transition name="fork1aToStep2a" to="step2a" />
| <transition name="fork1aToStep2b" to="step2b" />
| </fork>
|
| <task-node name="step2a">
| <task name="wf:step2aFundingRequestTask" swimlane="initiator" />
| <transition name="step2aToJoin1" to="join1" />
| </task-node>
|
| <task-node name="step2b">
| <task name="wf:step2bFundingRequestTask" swimlane="initiator" />
| <transition name="step2bToJoin1" to="join1" />
| </task-node>
|
| <task-node name="step2c">
| <task name="wf:step2cFundingRequestTask" swimlane="initiator" />
| <transition name="step2cToJoin2" to="join2" />
| </task-node>
|
| <join name="join1">
| <transition name="join1ToJoin2" to="join2" />
| </join>
|
| <join name="join2">
| <transition name="join2ToStep3" to="step3" />
| </join>
|
| <task-node name="step3">
| <task name="wf:step3FundingRequestTask" swimlane="initiator" />
| <transition name="step3ToEnd" to="end" />
| </task-node>
|
| <end-state name="end" />
|
| </process-definition>
|
We have a custom Join class which extends the default jBPM Join class. We have
this custom Join class, because we have an Event.EVENTTYPE_NODE_LEAVE action
handler JoinEndForkedTokens class which needs to get called when the Join node
is "left".
The key thing is that the getting stuck problem only occurs when we have this
custom Join class "wired in" and the tasks are completed in a certain order
The task completion order that exibits the "getting stuck" problem is as
follows:
When task "step2c" is completed after tasks "step2a" and "step2b", then the
workflow path does not leave node "join2" - and thus task "step3" does not get
reached.
The following files are attached:
- The process definition for this nested fork workflow,
http://rapidshare.com/files/121903643/nestedfork-workflow-processdefinition.xml.html
- The hibernate config and jbpm config files we are using
http://rapidshare.com/files/121903641/hibernate-context.xml.html
http://rapidshare.com/files/121903642/jbpm.cfg.xml.html
- A ZIP file containing our own workflow processing classes. Our custom Join
class and JoinEndForkedTokens action handler are in the jBPM folder therein.
http://rapidshare.com/files/121903644/workflow.zip.html
- Two debug log files (with debug turned on for org.jbpm and
org.alfresco.repo.workflow - the package for our workflow processing classes)
-- alfresco.step3-not-reached.log - for the above getting stuck scenario
http://rapidshare.com/files/121903639/alfresco.step3-not-reached.log.html
-- alfresco.step3-reached.log - for when "step2c" is NOT completed after
"step2a" and "step2b", and "join2" is left and "step3" reached - and all is
fine.
http://rapidshare.com/files/121903640/alfresco.step3-reached.log.html
I can't find anything wrong with our custom Join and neither our action handler
JoinEndForkedTokens class (added as an action by the custom Join code), but
when I change the hibernate and jbpm config files to point back to the default
jBPM Join class, then the workflow does not get stuck.
What I have found so far is that when the workflow gets "stuck" it is because
jBPM has "forgotten" to call the Join.execute() method (on Join2) after step2c
has been completed - the problem only happening in the scenario when step2c is
completed after step2a & step2b. But Join.execute() on Join2 is indeed called
when both step2a and step2b have been completed, and Join1 is left.
... and for some reason, this weirdness only happens when we wire in our own
custom Join class (which extends the default jBPM one).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157651#4157651
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157651
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
