1 of 1 people found this helpful
first of all thanks for giving a lot of details of your case, this certainly helps to understand what you do and what are the goals to achieve.
I would like to suggest to use throwing/catching events for your case. So when your sub process goes to aborted state it should trigger an error end event which will thrown an error and then use boundary (attached to your sub process) error catching event that will catch this error and execute alternative flow. It would look like this (very simplified case to illustrate usage of events):
If you make the boundary event interrupting (which is by default) it should cancel the regular flow and move though the sequence flow defined for boundary event. So that should suit your case, I think.
Thanks for the quick response.. Lets see if i understand what you are saying.
Here are three of the many process definitions that we have currently floating around.
The top-left process is our main process which calls (among others) the validation sub-process which is situated in the picture in the top-right position. The validation subprocess on his turn calls the process situated below. which does a specific validation task.
So here we have a chain of three (sub-)processes. the one below clearly shows the 'Reject' task which puts the process in an aborted state.
Please correct me if i'm wrong. what you are suggesting is putting an event catching node in the two processes above in order to catch the aborted state from the process below ? I must admit that i'm not very familiar with the boundary error event catching. I will surely look into that.
Any pointers to what that exactly means are very helpful I don't think i came across that term in my eclipse env.
Yes, pretty much this is what I meant. So you need to have in the last process (validation task) an end event that is throwing an error. Then the process should have catching event to handle the error, if your requirement is to propagate it further then it should thrown another error event, and so on...
Please note that I refer to BPMN2 processes.
Btw, have you tried to make the end event of the most nested process to be an error event instead of regular?! Or maybe it is already like that but the process image does not illustrate this...
Right. My processes are drools flow (DRF) processes. I guess that means i need a different approach then the one mentioned.. Is it advisable to move away from DRF processes and join the BPMN2 bandwagon ?
In my opinion it is worth to move to BPMN2 since that is the main process format that will be enhanced.
Don't know if rule flow is/will be under development but the most important is to make sure all requirements can be met be current BPMN2 implementation.
The exampe shown here uses an embeddable sub-process. How can I handle errors when I am using a reusable sub-process? Say for example, if I have a reusable subprocess (say sub1) which does some processing, and throws a fault on error. I now make a call to the sub-process from the main process (say proc1). Now during execution the subprocess throws the fault on error, how can I catch this fault in the main process? One approach I can think of is storing the exception in a sub-process variable, then map it to the process variable, and use a gateway to determine if there was a fault in the sub-process, and raise a fault in the main process, and use signals to handle the fault. however this is a lot of steps for handling sub-process errors, Is there a simpler way to handle faults thrown in reusable sub-processes?
If you use call activity then I would add a boundary error event to the call activity that in fact invokes sub process. So whenever sub process throws an error the boundary error event on call activity should handle it. I have not verified that it is supported by current version of jBPM.
Thanks for the response. I have implemented the call activity to throw the exception and the error handler as a boundary event in the main process. There are 2 issues I ran into
1. I have to redeclare the error code in my main process since the reference to the error code does not understand that its already defined in the subprocess (probably expected) but not sure if this would cause an issue
2. An error event is treated as a terminating event, and it stops the entire process. So the main process error handler is never fired.
Can you please verify that I have implemented the solution according to your suggestion.
Pretty much... I was even thinking to have the boundary event attached directly to the call activity, but after quick check it seems it is not supported at the moment.
Regarding the termination of the process on error end event, it should be ended but only the sub process and the main process should still run but seems like it does not work like this. Moreover error end event should throw an error event so other parts of the process could handle it, and I think it's not supported either
So, as an alternative you could use signal events instead of error events in quite the same approach.
Thanks Maciej. I was able to check the signal events and those work correctly. Do you think the error handling is an issue with the product that needs to be logged?
Yes, in my opinion errors should be thrown so they can be handled and not entire process stack should be ended but only this one that throws an error event. So, yes, I think it should be logged (for instance jira issue) at least for verification/confirmation from core developers.
Thanks Maciej, I have reported this via a JIRA.
A bit more detail here, as this is biting me as well right now. I don't believe that the end event is actually terminating the flow-- I think it's just not propogating the error back to the caller.
Using your examples (which are awsome, BTW), when I check the session state after execution, the session is marked as STATE_ACTIVE, not STATE_COMPLETED. This seems to indicate that the engine still thinks that the process is running, when clearly it is not. For a test I created an identical flow that put the steps into an embedded sub-process (rather than a called one), and the sequence of events is identical but the process state is STATE_COMPLETED.
Now, if I remove the boundaryEvent that handles the error, the embedded version of the flow returns STATE_ABORTED (which I would expect), but the call version still returns STATE_ACTIVE. It sure looks like the issue is that the error in the sub-flow is not getting passed back up, so the error handling in the caller never gets executed.