IBM i Integration with Mule ESB

IBM i Integration with Mule ESB

Client Summary

  • Client is based out of Richmond, Virginia involved in full service freight transportation has 160000 employees, 30,000 trailers
  • Their annual turnover is US$ 5 billion and employees over 10,000 people

Executive Summary

  • This project is to streamline the multi-technology integration process and track the audit of data transfer.

Problem Statement

  • The IBM i applications are integrated with third-party applications. Those applications are rapidly integrated without the standards.
  • It increases the load in IBM i servers and applications to handle the user request.


  • The higher-level architecture for the IBM i - Mule interface consists of three parts:
  • IBM i application trigger event - The business flow present in the IBM i application would trigger the event to transform data through Mule into the third-party application.
  • Transaction interface - The interface with Mule would be at a transaction level with control data indicating the type of transaction
  • Data Queues indexed by the transaction number would act as a trigger to indicate a transaction is available for pickup/delivery.
  • Customized staging tables would store the data for each transaction type for Mule to refer.
  • Mule - Mule will act as a carrier to pick up transactions, send the data, receive the response and relay back the information to the triggering application.

Business Benefits

  • No business rules would be present in the Mule layer – the rules will be handled in the triggering and the receiving applications.
  • A sequential transaction number would be the key for all three systems involved – this enables the same Business logic to be re-triggered if required.
  • Intermediate staging tables and Data Queues will be used for Mule to refer to – thus not impacting the Master database and speeding up the time taken for a transaction to be completed
srinsoft mule