Using Common Error Handler within Mule Services

  • Written By Coforge-Salesforce BU
  • 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.

Using Common Error Handler within Mule Services

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

Latest Insights

Application Integration
Blogs

What is Application Integration?

Application integration helps close the gap between existing on-site systems and the ever-evolving cloud-based enterprise applications.

Coforge Salesforce High Velocity Sales
Blogs

Enabling sales with Salesforce High Velocity Sales

What exactly High Velocity Sales is, how it can benefit your business and how to enable it.

CRISP-DM : ANALYTICAL FRAMEWORK
Blogs

Using the CRISP-DM framework for data driven projects

Learn how CRISP-DM can facilitate the planning, organising, and implementing process of data-driven projects.