I am trying to build a simple process in BAW that is supposed to work as follows:The process calls a service flow. When an error is detected in the service flow, the error is caught by the process, printed to the logs and then the process ends on an Error End Event so that the process instance status is set to 'Failed'. Here is how it looks like:Catching the error and printing it to the logs works as expected but when the process reaches the Error End Event and the process instance is set to failed, the instance error details shown in Process Inspector always say "No error message". Only the error code specified for the Error End Event is correctly reflected in the details:
No matter what data or data type I hand over as Error Data in the Error Mapping section of the Error End Event properties, the output in Process Inspector is always the same: "No error message".Can anyone tell me how I could get the error message contained in my Error Data object into the instance error details displayed in Process Inspector?If it is not possible at all, I would like to understand why. Thanks in advance for your help!
Hi Atanu,thanks for your reply.I think the reason why it seems to work in your scenario is that you do not really catch the thrown runtime error. As you can see, the custom error code you defined ('MyErrorCode') is not mentioned in the Process Inspector's error details.
The uncaught error will still lead to a failed process instance and in such scenarios (uncaught runtime errors), there is indeed an error message in Process Inspector. However, it never works for custom errors defined on an Error End Event in a process.Surprisingly, if I take my sample process and use it as a linked process within another process, the enclosing process can catch and consume the custom error code AND custom error message delivered by the linked process via the Error End Event. Only Process Inspector is apparently not capable of consuming the custom error message. I think this is a product deficiency.Best regardsGregor
Thanks for your comments, Mattias.If you are at the process layer, I think there are basically three options how you can deal with an exception thrown in an executed service:
Personally, I do not like option 1 because I am keen on taking a few more process steps before I let the exception kill the flow. Moving tokens can be helpful sometimes but it should be the last resort in my opinion.Option 2 leads to completed instances but I would like to have failed ones to get proper statistics, so I don't like this option, either.Option 3 is my favorite and it actually works as expected - well, except for Process Inspector's incapability of displaying the error message handed over via the final Error End Event.
As mentioned in my comments to Atanu, I do not understand why Process Inspector cannot consume the error message. Any other process can. I think the fact that Process Designer enables you to use Error End Events at the process layer means that it is supposed to work. That's why I believe this is nothing but a deficiency in Process Inspector.
I think I am ready to continue the discussion and must admit some statements came out of my long-term memory. It was a while since I last did these things until just recently. I think I remember using 1. for system tasks in processes that mostly contained human tasks. If data or network problems caused error the instance would fail and we could then retry-revive it. Skipping or terminating is generally not an option. My current application under development is like this.There are some strange behaviours when retrying failed steps.Catching and rethrowing in the service flow seems to make the error end event the new failed step or something. The same error occurs again even after correcting the root cause. Also, process inspector is not displaying the correct details.If I don't catch anything, retry works. However it reruns the whole task service (the topmost service flow) even when the error occured halfway in, say at the third step which is nested service. This is apparent from log entries in each step. I vaguely recall that retry, at least in 8.0.x, started after the last successful step or at least at the beginning of the affected service.Next strange things is that the product documentation states that retry does not work for system tasks:
But it does now and I am sure it did before. It would be unreasonable if one could not.I did these tests in BAW 20.0.2 Process Center, where I triggered the error by a script null pointer assignment. Upon error I commented it away, saved and retried failed steps.
My 2 cents:
If you re-throw error from service flow - default retry API (and button retry in Process Inspector) works as you described. It basically retries returning error from service to main process.
This is not what you probably expect :)
My workaround for that is to first reset token on last failed activity (place where you invoked service).
This needs 2 REST API calls:
Find token for failed activity (tokenId, flowObjectId – first children under root)
After that standard retry (e.g PUT /rest/bpm/wle/v1/process/<pid>?action=retry or pressing retry button in Process Inspector) will re-execute whole service (from the beginning of failed service).
To be honest I frequently re-implement functionality of Process Inspector to have more admins friendly tool. It requires some efforts but BAW API is much more powerful than UI of Process Inspector.
E.g. initial problem in this thread of getting (modeled) error can be easily solved using that call:
You will find there errorData attribute which contains (serialized as XML) error object.
It is not available in Process Inspector, though.
Retry functionality is mostly useful for system tasks – so documentation update done in this APAR https://www.ibm.com/support/pages/apar/JR61296 is indeed rather misleading.