Error Handling

The generated root state machine of Designer service comes with an integrated error handling. In case an error occurs during a transaction, the following happens:

1. The error is caught.

2. The error handler is invoked.

3. The process switches into the error state at transaction end.

The process instance is displayed as erroneous. You can now

• Rectify the error and send a retry signal
  You can now look into the error and apply fixes if necessary. The last process step the process has reached is marked by a history state, so it is possible to trigger a retry from this very step.

• Abort the process instance
  Alternatively, you can abort the process instance by sending an abort signal.
  In this case, the process instance will be terminated as aborted (not done).

Refer to Error Handling of Root State Machine for more details.

Automated Retry

A best practice that works for most scenarios is to have an automated retry of error objects from error state to a history state.
This automatically fixes technically errors like network down, system temporarily down, etc.

The tasks must be atomic, i.e. all actions within this task can be executed again.
We recommend to use dedicated error types to mark retry-able errors.

Retry can be implemented by a timer that periodically polls for error objects and sends the history signal (retry timer).

• define a Timeout-Boundary at the error object

• With this approach you prevent that you have to manually handle a a large amount of error objects.

Errors in the model (e.g. mapping errors) can easily be solved using this approach. After fixing the error in the model and re-deployment of the service, it is sufficient to just trigger a retry and the erroneous transaction will be performed again with the rectified code.
Depending on the project requirements, this can be a simple mechanism valid for all kinds of errors!

Validation Tasks

Instead of having complicated error handling in the flow, implement dedicated validation task(s): Check if fields are filled or correctly formatted etc.

This prevents you from having to check values later in the process before using functions such as concat() operation, substring, etc.

Do not misuse exceptions for validation checks but use constraints for validation instead.

Reaction on Errors

Use the xUML Service Monitor for a dedicated reaction on errors.
Refer to Monitoring xUML Services for more information on this PAS component.