Using Common Error Handler within Mule Services

06.11.2015

Service Oriented Architecture (SOA) is all about service reuse and extendibility. If services are composed as reusable components, then it will be easy for projects to maintain the modularity and extensibility. Error handler should be conceived as a re-usable service and hence should be designed using SOA principles. This design approach helps in reducing the cost.

Plan your error handling strategy

All errors should be delegated to a common error handling service. Error handling service will take care of the errors and act upon them i.e. the error handler encapsulates the logic. In case of Mule, flows and sub flows can be created to handle various errors.

service oriented architecture.jpeg

Identify error types

During the analysis and design phase, plan the errors (in some cases exceptions) that would occur in these applications. There are two types of errors in any application integration:

  • Business Errors
  • Technical Errors

Derive the type of error from these requirements – typically errors pertaining to service availability, authentication, connection errors, etc. These are called as technical errors. Business errors are those which occur due to the failure of business data. For example, failure to validate a credit card or inability to process a loan request because of missing a mandatory document.

Using the above approach, errors should be identified and categorized based on the user requirements and design strategy. For example, if RESTful services are implemented, the error types would be different from the error types generated for a XML based Web Services.

Use Case Scenario

The above approach was used in one of the projects implemented for a client. The end points were Salesforce, Mobile application, On Premise applications such as legacy database, and multi-stage processing of requests.

Instead of having an error handler for each service integration layer, a separate error handler is put in place. When an error occurs, the common handler is called. The error handler encapsulates the logic to address the errors and hence knows what to do with that particular error and performs necessary action. For example, the following actions can be performed:

  • Retry
  • Enrich the error message
  • Route the enriched message to an error queue
  • Send an email to Operations Team
  • Integrate & Publish to Operations Dashboard Service (SolarWinds, Splunk etc)

Apart from re-usability, it  also saves 20-30% of the time. The services are kept modular and better architectural pattern can be enabled.

If you would like to find out more about how Systems Integration could help you make the most out of your current infrastructure while enabling you to open your digital horizons, do give us a call at +44 (0)203 475 7980 or email us at marketing@whishworks.com

Other useful links:

Mule 2 to Mule 3 Migration Case Study

APIs in the IoT

5 challenges with Systems Integration

Recent Posts