Concept: Error Handler Components

Studio provides 3 different

Error Handlers

on the

Palette

Name	Function
send-error	Enables you to process the error using standard components and steps. A common pattern is to use send-error to report the error to the integration event by invoking the PutIntegrationMessage common component.
log-error	Logs the current error to the output log. Includes the error message and the stack trace of the Java exception. Use when there’s no need to individually expose errors on the integration event but you want to log the message at the time of the error. Avoid logging large messages as they can degrade performance and might be truncated, leading to loss of diagnostic data.
custom-error-handler	Enables you to supply a Spring bean that uses Java to process the error. Use when error handling requires complex Java code.

You can add an error handler as a child element of a mediation component or as an individual element on the assembly. Error handlers added to mediation components are local. Error handlers on the assembly are global.

When Workday encounters an error in a Studio integration, it stops normal processing and unwinds the chain of processed components, looking for an error handler to invoke. It always attempts to process errors locally first. If no local error handler is available, responsibility passes to the global error handler. Use local error handlers when you want fine control over what happens when errors occur or need to report the detailed context of what the integration was doing at the time of the error. Think of global error handlers as a failsafe.

If every error handler has fired and an error still isn't marked as handled, Workday processes the message, generates an error from the exception, and marks the assembly as terminated. It describes the integration as Completed with Errors.

Notable default behaviors:

Local error handlers only process errors that arise in their parent mediation component. However, they can also process errors in downstream components. To enable this behavior, set the

Handle Downstream Errors

property of the mediation component containing the error handler to

true

Workday marks errors as handled when an error handler is invoked. However, if you set an error handler's

Rethrow Error

property to

true

, Workday doesn’t clear the error. As a result, it’s handled by the next in-scope upstream error handler or global error handler. Use this pattern to report the detail of an error locally but to handle the overall failure or completion at a higher level in the assembly.

When Workday handles an error, it restarts message processing from the invoked error handler, continuing on the response path towards the element where the error was raised. However, you can specify that processing should instead resume at the element where the error was raised. To enable this behavior, set the

Continue After Error

property of the mediation component containing the error handler to

recover

. Use this behavior in situations where the code invoked by the error handler can correct the error condition, enabling a retry of the failed operation to succeed.

You can exercise greater control over error handlers by adding MVEL condition expressions on their

Properties

view. When condition expressions are present, Workday only invokes the error handler if they all evaluate to true.

You can force error raising using the

context.setError

context.SetException

methods in MVEL or Java code. When using the

setError

method, you can configure an error ID that can be detected by conditional expressions on the error handler. Use this technique when you’re handling an error locally but want to pass some detail of the error type to an upstream error handler for common handling.

You can also handle errors using

Route

components:

The

failover-strategy

attempts to use a route, and if an error occurs, executes the failover route, marking the error as handled.

The

custom-strategy

enables you to supply a Spring bean. Spring beans implement the

RoutingStrategy

interface, which has an

isHandleError

method. Use this method to specify that the strategy handles errors.