This documentation is for WSO2 Enterprise Integrator version 6.4.0 . View documentation for the latest release in the 6.x.x family and the latest release in the 7.x.x family.

All docs This doc

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

WSO2 Enterprise Integrator (WSO2 EI) is a comprehensive integration solution that enables communication among various, disparate applications. Instead of having your applications communicate directly with each other in all their various formats, each application simply communicates with WSO2 EI, which acts mainly as an ESB to handle message transformations, and routes the messages to their appropriate destinations. The WSO2 EI product can be used to manage short-running, stateless integration flows (using the ESB profile) as well as long-running, stateful business processes (using the Business Process profile). The product also includes a separate Analytics profile (which is an instance of WSO2 Stream Processor) for monitoring ESB statistics, a Message Broker profile (WSO2 MB ) that can be used for reliable messaging, a Micro Integrator profile that is container-friendly, as well as the WSO2 MSF4j profile, which you can use to run microservices for your integration flows.

The ESB profile in WSO2 EI provides its fundamental services through an event-driven and standards-based messaging engine (the bus), which allows integration architects to exploit the value of messaging without writing code. This ESB profile is a step ahead of the previous releases of WSO2 Enterprise Service Bus , as it provides data integration capabilities within the same runtime. This eliminates the need to use a separate data services server for your integration processes.


The Micro Integrator profile of WSO2 EI is architectured to designed to be container-friendly so that it allows you to perform advanced scenarios without sacrificing the speed required for a container-based architecture. Because its start-up time is faster than the ESB profile, microservices are designed to start up very quickly, perform a specific task, and then shut down. Also, you can use the Micro Integrator profile to orchestrate atomic microservices into composite microservices that address more complex, real-world scenarios. 


  1. An application(client) sends a message to the Business Process profile of WSO2 EI. Note that this request could be for a BPEL process, Human Task or a BPMN process. 
  2. The message is picked up by the transport layer, depending on whether it is intended for a  BPEL process, Human Task or a BPMN process as explained below.
    • Business processes defined using BPEL, as well as Human Tasks are exposed as SOAP services. Therefore, the transport layer is essentially an Axis2 web service (corresponding to the BPEL process or the Human Task), which can receive messages from Axis2-supported transports such as HTTP, HTTPS, JMS, etc.
    • Business processes defined using BPMN are exposed as a secured REST API, which is built as a web application and deployed in embedded tomcat. Therefore, the transport layer for BPMN is essentially a web application that can receive RESTful messages.
    • Human Tasks allows you to integrate human interactions into the business process workflows work flows
  3. The message will be forwarded to the relevant runtime: BPEL runtimeBPMN runtime or the Human Task runtime.

    • BPEL Runtime - The message will be processed against the compiled BPEL process definition. The Integration Layer sits between the ODE BPEL runtime and Axis2 for processing and forwarding received messages to ODE Runtime. If the message is received for a BPEL process, it goes through the Axis2 engine, where QoS (quality of service) requirements such as WS-Addressing and WS-Security will be processed using Axis2 modules such as rampart and addressing. 
    • BPMN Runtime - When REST requests are received by the BPMN REST API, it will perform relevant operations in the BPMN runtime against deployed BPMN processes. In addition to exposed REST service, admin services are provided for BPMN processes and instance management.
    • Human Task Runtime - The received message will be executed against the human tasks defined in the system. If the execution is successful, an instance of the task will be created and relevant task instance data will be persisted to the database. 
  4. The Data Access Objects Layer is used to interact with the database for persisting BPEL process definition/instance data and Human Tasks instance data.