A question that sometimes comes up is "Why aren't system exceptions caught by error boundary events in PCS?".
Just like in life, not everything can be predicted as process instances execute in PCS, and exceptions can and do occur. The purpose of this is to explain why some exceptions are not caught by the error boundary events shown below in PCS and why this is not necessarily a bad thing.
The ability for business users to handle exceptions and being able to continue work is one of the things I’ve liked most about PCS from the beginning. The five recoverable instances shown below were not able to be caught by error boundary events in the process.
Once “Recoverable Instances” is clicked, the user sees the list of instances that can then be handled by a business or technical user.
There are two types of exceptions that can be caught in PCS processes, business and system exceptions. Business exceptions occur due to things being outside the norm like when a fraud is detected or an item on an order has been discontinued. System exceptions on the other hand can occur unpredictably when a service invoked by a task in a PCS process is down, it times out, it is sent incorrect parameters, or a connection to it simply cannot be made. While it could be argued that PCS processes should be able to catch system exceptions (like it does business exceptions) using error boundary events, this explains how these are handled and something to guard against.
If you have used Oracle BPM or SOA on-premise products, you might already know that a fault policy can be defined that defines how exceptions are handled for the deployed composite. Similarly, when PCS applications are deployed, they automatically have a fault policy to handle system exceptions under the covers as well. This fault policy simply retries the service that failed three times and makes the instance available to be handled in the Recoverable Instances tab shown above.
What is causing some people problems is a new deployment option in PCS. If you have deployed a PCS application recently, you might have noticed that the 4th step where you specify the "Deployment Options" has a new "Use Fault Policies" for system exceptions checkbox.
Something to be aware of is that when error boundary events are added to Service Task activities, these events do not catch system exceptions by default.
Unless the new "Use Fault Policies" deployment checkbox is unchecked, instances with system exceptions ignore error boundary events. Instead of being routed via the intended boundary event's sequence flow path, the instances are instead retried 3 times and are then left in the service task for manual recovery.
By unchecking the "Use Fault Policies" checkbox during deployment, however, system exceptions are instead surfaced to the process and boundary error events have the potential of working for every process in the deployed PCS application. Do this with caution though because:
- If unchecked and the system exception is not caught in a boundary error event in the activity, the instance rolls back to the previous activity in the process. To keep the instance from rolling back to the previous activity, each of the service activities would need to have boundary error events attached to them.
- Error boundary events handle system exceptions differently for Subprocess and Service activities. Although boundary error events work for Service activities, system exceptions are not caught today in boundary error events for Subprocess activities.
Here is a matrix that describes how system exceptions are handled with and without the fault policy and with and without boundary error events.
Because PCS has no Error Event Subprocess activities that could catch all exceptions at the coarse grained process level, and because boundary error events do not catch system exceptions in Subprocess activities, during deployment leave the “Use Fault Policies” checkbox checked during PCS deployments and handle system exceptions in the “Recoverable Instances” tab.