playing with jBPM 5.1Final i realized that i was not able to handle tha abortion of a work item inside the process definition.
I have tried unsuccessfully to usa an BoundaryEvent thet refer an Error Event Definition.
basically I want the process can take two different paths after the execution of a work item on the basis that it was aborted or carried out, there is a way to obtain this behavior?
The only solution that i found is to register a listener that check, for every ProcessNodeLeftEvent, the status of the work item and in case of an abortion it signal the process instance. But in this case in the process must be included a path that has an IntermediateCatchEvent for handle the abortion of a task (see the picture below). I think this solution isn't smart and i don't like it.
I also checked the chapter of BPMN2.0 spec about the execution semantics, but i have not found any useful information.
does any one know how to handle this situation?
In my opinion that should be managed by an Interrupting Boundary Event...something like that:
Now, I've clear how to do that with a sub-process...I don't know how to do that with a Task activity.
Indeed, if I want to signal an error or an escalation/compensation I didn't find any good way to do that...Am I missing something?????
Looking at the code, it seems that the way to "raise" an Error/Escalation, etc. from a boundary event is using the signalEvent with the correct "type".
The "type" seems to be specified as the first String part of the "type" parameter in the signalEvent method.
I mean: "Escalation-", "Error-", "Compensate-", etc...
Trying to test what I've written I meet this error (I'm using a generic task, with a userTask the error is similar).
java.lang.ClassCastException: org.jbpm.workflow.core.node.WorkItemNode cannot be cast to org.jbpm.workflow.core.node.CompositeContextNode
It seems that it's not yet supported to have a Boundary Event in a Task (even if it should be possible for BPMN2). Can you confirm that, or I'm missing something?
I don't know if JBPM-3319 will be fixed (it's a big issue form me, since I don't know how to manage a aborted workitem situations without a subprocess). Anyway, looking at the code, when a WorkItemManager.abortWorkItem is esecuted, an event is sent to the process instance:
So when (and if...) the boundary events for the task will be supported, it should work simply with a "catch" event from the task.
Am I wrong?
Funny, this just became important to me.
How would one learn of an aborted workitem?
I've been stepping through jBPM code watching what it does looking for a clue of how to detect this happened from the afterProcessCompleted call. From the org.jbpm.workflow.instance.node.WorkItemNodeInstance the workItemAborted and workItemCompleted methods are exactly alike. The data indicating that the work item has been aborted is tossed and triggerComplete is called on the work item exactly the same way if the work item completed successfuly or aborted. In fact the process instance appears to go about its' business like the work item has really completed normally.
Or for that matter, if something goes horribly wrong from a work-item, is there a way to get the process state set to aborted so I can detect it from a ProcessCompletedEvent? WorkitemManager is pretty limited in options: abortWorkItem, completeWorkItem, registerworkItemHandler,
Is there some tract of the work item having aborted on the NodeInstance or ProcessInstance?
I stumbled into a solution that works for me:
getWorkItemManager() on the statefuleknowledgesession really returns a DefaultWorkItemManager. That one allows you to pull up the WorkItem based on the id of the WorkItem. From there you can grab the process instance id. With that you can call abortProcessInstance on session with the process instance id from the WorkItem. That causes the state of the process instance to be set to WorkflowProcessInstance.STATE_ABORTED and afterProcessCompleted gets called.
There still seems to be no answer to this. When reading through the documentation and looking at the sample code, there isn't anything pointing out how to abort a workflow. In fact if you follow, what I regard as the straight forward solution (listed below) the flow isn't interrupted at all.
I have a flow with two tasks that each is mapped to a WorkItemHandler. If I in my first WorkItemHandler implementation call
I would assume that the second handler would not be called - but it does. Actually the whole flow is completed.
Can someone explain how to abort a workflow and when the above method call is useful, if not for exactly that?
Do I need to add other elements to my bpmn 2.0 flow? I have one start event, two tasks and one end event. All connected in a lineary fashion.
I have added a simple example - a workflow going from start, over two tasks to end. The first task is a custom workitemhandler that always fails. The executing flow does however, reach the second task that just prints "hello world". See attachment.
AbortingFlow.zip 5.3 K
I am just looking for how to define the task name with work item handler...Till now, i was not aware of that...............
Can you please clarify below questions?
- Any idea about JBPM scalability? Can i run jbpm in two servers? If, how do they share load?
- When i register a work item handler, will it execute the execute method immediately or Do i need to confihure anywhare when to invoke the handler?
No resolution on this I assume ? I'm running into the same issue as you, and seeing the same behavior as you ... would be nice to know if this was a bug that will be fixed, or if there is an alternative way to abort a work item; in my case, all I want to ensure is that the path for that work item isn't marked as complete, and that it can be rettied (I don't want the whole workflow process to abort).
If you found any workaround I'd appreciate hearing about it.