In this blog we will take a look at the way a dynamic process deals with a process that ends with an exception. We will implement this in our “Register Order” process.
We modeled the process as depicted below:
When saved, published and activated, we start a new dynamic process; of course through our famous form:
The expectation is that Register Order starts and that we can start executing the task. When we open the process and click the “Abort” button on the “Save in backend system”, the process ends with an error event. See the screenshot below:
So what do we expect our Dynamic Process to do? Will it recognize the error and re-activate the “Register Order” activity again? Let’s see.
Interesting to see is that the process is still running…Hmm…the “Error End” happens to not end the process, but instead just throw an error and end up in fault recovery. How do we know its still running? By having selected the filter in the activities list:
Lets try to end the process with a different callback.
Running this case and ending the human task with an abort action, the process at runtime looks like the following:
We can indeed see that the process came to an end, but far more interesting to see is that the Dynamic Process rules consider the process to be ended happily and activated two new activities: Process Payment and Prepare Pizza
So what have we learnt? The Dynamic Process can’t handle two different callbacks. So if you would like to model a scenario in which the process aborts and the case should act upon the abort, you should work with case data to indicate the process ended not successfully. This also means that you should think about making processes repeatable to ensure that an aborted process can start again. So, look before you leap and happy modelling!
Disclaimer: please note that the human tasks we used in the above screenshots is of the “Submit” type, whereas you should use the “Accept-Reject” pattern.
