Scribd
Upload
307 views

What Is Error Handling in Mulesoft

This document discusses error handling in Mulesoft. It describes the components of Mule errors, types of errors, categories of errors, and components for handling errors. The key components of Mule errors are description, type, cause, message, and child errors. Error types have a namespace and identifier and can have a parent type. Errors are divided into messaging errors that occur in flows and system errors that occur at the system level. Mule has On-Error handlers and Try Scope components to handle errors. On-Error handlers match error types and routes errors, while Try Scope catches exceptions like a try-catch block.

Uploaded by

Krishna
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
307 views

What Is Error Handling in Mulesoft

This document discusses error handling in Mulesoft. It describes the components of Mule errors, types of errors, categories of errors, and components for handling errors. The key components of Mule errors are description, type, cause, message, and child errors. Error types have a namespace and identifier and can have a parent type. Errors are divided into messaging errors that occur in flows and system errors that occur at the system level. Mule has On-Error handlers and Try Scope components to handle errors. On-Error handlers match error types and routes errors, while Try Scope catches exceptions like a try-catch block.

Uploaded by

Krishna
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

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

You might also like