What is Error Handling in Mulesoft

What is Error Handling in Mulesoft In this article, we are going to discuss components of Mule error, Error types, categories of Mule error and components for handling Mule errors.

Components of Mule Error:

The Mule error is the result of the failure of the Mule exception to

the following components: • Description: This is an important component of the Mule error which will give a description of the problem. Its expression is as follows - #[error.description] • Type: The Mule Error “Type component” is used to characterize the problem. It also allows routing in an error handler. The expression is as follows- #[error.errorType] • Cause: The “Cause component” of the Mule error gives the underlying java disposable that is causing the failure. Its expression is as follows- #[error.cause] • Message: The Mule Error Message component displays an optional error message. Its expression is as follows- #[error.errorMessage] • Child Errors: The Child Errors component of the Mule error provides an optional collection of inner errors. These inner errors are mainly employed by elements like Scatter-Gather to supply aggregated route errors. Its expression is as follows - #[error.childErrors]

Example: If an HTTP request with status code 401 fails, the Mule errors are as follows Description: HTTP GET on resource ‘http://localhost:8181/TestApp’ failed: unauthorized (401) Type: HTTP:UNAUTHORIZED Cause: a ResponseValidatorTypedException instance Error Message: { "message" : "Could not authorize the user." }

Error Types: Let us understand the Error Types with the assistance of its characteristics – • The first characteristic of Mule Error Types is that it consists of both, a namespace and an identifier. this enables us to differentiate the kinds consistent with their domain. within the above example, the Error Type is HTTP: UNAUTHORIZED. • The second important characteristic is that the type of error can have a parent type. for instance, the Error Type HTTP: UNAUTHORIZED has MULE: CLIENT_SECURITY because the parent which successively also features a parent named MULE: SECURITY. This characteristic establishes the Error Type because of the specification of the more global items.

Kinds of Error Types: Following are the categories under which all the errors fall Any: The errors under this category are the errors that will occur during a Flow. They are not so severe and may be handled easily.

Critical: The errors under this category are the severe errors that can't be handled. Following is that the list of Error Types under this category • Overload: This Error Type indicates an error occurred due to the problem of overloading. In this case, the execution will be rejected.

• FATAL_JVM_ERROR: This kind of Error Type indicates the occurrence of a fatal error. for instance, stack overflow.

CUSTOM Error Type:

The CUSTOM Error Types are the errors that are defined by us. They will be defined when mapping or when raising errors. We must provide a specific custom name space to those Error Types for distinguishing them from the opposite existing Error Types within Mule application. For instance, in Mule application using HTTP, we cannot use HTTP as the custom error type.

Categories of Mule Error:

In a broad sense, the errors in Mule are often divided into two categories namely, Messaging Errors and System Errors.

• Messaging Error: This category of Mule error is said to the Mule flow. Whenever a drag occurs within a Mule flow, Mule throws a messaging error. we will found out the On Error component inside the error handler component to handle these Mule errors.

• System Error: System error indicates an exception occurring at the system level. If there's no Mule event, the instruction is handled by a instruction handler. The subsequent exceptions are handled by System Error handler – - The exception occurs during an application start-up.

- The exception occurs when a connection to an external system fails.

In case an instruction occurs, Mule sends a mistake notification to the registered listeners. It also logs the error. On the opposite hand, Mule executes a reconnection strategy if the error was caused by a connection failure.

Handling Mule Errors: Mule has the following 2 Error Handlers for handling the errors On-Error Error Handlers: The first Mule error handler is that the On-Error component, which defines the kinds of errors they will handle. Here we will configure On-Error components inside the scope-like Error Handler component. Each Mule flow contains just one error handler, but this error handler can contain as many On-Error scopes as we would have liked. The steps for handling the Mule error inside the flow, with the assistance of On-Error component, are as follows • First, whenever a Mule flow raises a mistake, the traditional flow execution stops.

• Next, the method is going to be transferred to the Error Handler Component that has already got On Error component to match the error types and expressions.

• At last, the Error Handler component routes the error to the primary On Error scope that matches the error.

Following are the 2 sorts of On-Error components supported by Mule

On-Error Propagate: The on-Error Propagate component executes but propagates the error to the subsequent level and breaks the owner’s execution. The transaction is going to be rolled back if it's handled by the On Error Propagate component.

On-Error Continue: Like the On-Error Propagate component, the On-Error Continue component also executes the transaction. the sole condition is, if the owner had completed the execution successfully then this component will use the results of the execution because of the results of its owner. The transaction is going to be committed if it's handled by the On-Error Continue component.

Try Scope Component: Try Scope is one among many new features available in Mule 4. It works almost like try block of JAVA during which we wont to enclose the code having the likelihood of being an exception in order that it are often handled without breaking the entire code. we will wrap one or more Mule event processors in Try Scope and thereafter, try scope will catch and handle any exception thrown by these event processors.

Example: Following is an example of the use of try scope

Configuring try scope for handling transactions:

A transaction may be a series of actions that ought to never be executed partially. All the operations within the scope of a transaction are executed within the same thread and if a mistake occurs, it should cause a rollback or a commit. we will configure the try scope, within the following manner, in order that it treats child operations as a transaction.

• INDIFFERENT [Default]: If we select this configuration on the try block, then the child's actions won't be treated as a transaction. During this case, the error causes neither rollback nor commits.

• ALWAYS_BEGIN: It indicates that a replacement transaction is going to be started whenever the scope is executed.

• BEGIN_OR_JOIN: It indicates that if the present processing of the flow has already started a transaction, join it. Otherwise, start a replacement one.

For More Information about Mulesoft Online Training Click Here Call: +919989971070