error handling framework in mule esb
TRANSCRIPT
Exception Handling Current Exception HandlingCustom Error ManagementSynchronous Exception HandlingNotifications Services
Contents
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
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
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
Synchronous Exception Handling
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
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
THANK YOU!!!