This document discusses Mule's error handling framework. It describes the two types of errors that can occur - system exceptions with no message, and messaging exceptions within a flow. A global exception handler is used to provide uniform handling across applications. There are three types of exceptions it handles: fatal exceptions requiring abort, non-retryable requiring resubmission, and retryable using retries or replays. Current exception handling relies on custom error management rather than native message stores or channels. Synchronous exceptions require transaction rollback and HTTP status codes, while asynchronous use retries and replays. A notification service is proposed to independently handle different notification types including email.

1. MULE Error Handling Framework
GDS Sashidhar Rao
gdssrao@gmail.com

2. Exception Handling
Current Exception Handling
Custom Error Management
Synchronous Exception Handling
Notifications Services
Contents

3.  There are two different types of errors that can occur in Mule
 System Exceptions - This is when no message is involved. Ie; An error on
application startup
 Messaging Exceptions - This is when there is an error within a flow
 Global Exception Handler is a common component used across single / multiple Mule
Applications/Services to process exceptions.
 The primary objective is to provide a uniform exception handling across all available
Native and App Services
 Common Exception Message is a wrapper that defines properties of exception as well as
exception payload. There are three types of exceptions a Global Exception Handler is
expected to handle
 Fatal Exceptions – These are raised when some unexpected issue occurs in the
system that will require the process to be aborted.
 Non Retryable Exceptions – These are raised when some predefined issues occur
in the system that can’t be corrected. This requires the request to be submitted
again. Usually these exceptions occur in synchronous requests.
 Retryable Exceptions – These are raised when some predefined issues occur in the
system that can be automatically or manually corrected. Usually these exceptions
occur in asynchronous requests.
Exception Handling

4.  ESBs support the detection of errors (Dead Letter Channel) and anomalies
(Invalid Message Channel)
 There is no native Message Store on the way
Current Exception Handling

5.  The goal here is to tool up strictly with what is necessary for the errors management
strategy.
 Custom error management to reproduce more or less what traditional solutions provide
natively
 Auditing the state (Request, Response, Error) in Log file or DB is preferred
 Retry and Replay suits well with Async Messaging by using JMS/AMQP
 MMC Alerts
Custom Error Management

6. Synchronous Exception Handling

7.  The responsibility of identifying type of exception lies with individual service or
application invoking Global Exception Handler
 We need to set HTTP status codes and description to reflect internal error (500) for
REST requests.
 Relevant service/application admin needs to be notified.
 When the request is synchronous, we need to rollback transaction (if any) before
exception message is returned to the caller.
Synchronous Exception Handling

8.  Notification Service is just an email
service in the current context.
 Notification Service should be
implemented as an independent
application that should be capable of
processing different types of
notifications (email,tweet, sms etc.,).
 It can be extended it in future to
provide additional features to handle
other types of notifications.
 Notification Service should also log
message using “fatal” log level.
Notification Services

9. THANK YOU!!!