Error Management

In PRIMEUR Data Mover, no error management is required. The only exception is when the user explicitly wants the workflow template to behave in a different way according to a return code, or to intentionally ignore a potential service task exception.

Remote failures on transports and commands are treated forcefully failing the instance itself.

The instance can then be RESTARTED (the error instance becomes aborted and a new one will start from the beginning with the same set of variables and properties) or the single service task can be executed again with the RETRY option (in this case only the service task that failed is scheduled, anything preceding it will not be re-executed).

Anytime you are on an error boundary event branch, no variable defined in the service task that has just failed is available since... it has failed! In all ServiceTasks that are failing internally (and modeled with the Throw Exception variable enabled, only 2 process variables are guaranteed in the Error Boundary Event used to manage the exception:

• ${ExceptionMessage}: containing a descriptive message of the exception

• ${ExceptionStackTrace}: containing the full stack trace of the exception (for debugging purposes)

Don't forget to set conditions on every branch coming out of an exclusive gateway.

Remember that any triggerable service task that gets a schedule RC that is not 0 will throw an exception! This is because otherwise, it would wait for an event that will never come since the schedule has failed. Therefore, always mark your triggerable service tasks with a throw exception and an error boundary event for proper management.