Debug Integration Artifacts with WSO2 EI Tooling
For a bug free Integration Solution
Over the time the communication between enterprise applications is becoming more complex. More efficient protocols, message formats and messaging patterns are emerging everyday in the enterprise world. The requirement of cross communication between the systems hence is an increasing need. There is a number of integration solutions out there to cater that. However, every integration need is unique and developers need to figure out how integration should be and implement. When developing these integration artifacts, they need to see how would these behave when deployed on to the real servers. That is where need to “debug” requirement is surfaced.
WSO2 Enterprise Integrator is a complete integration solution provided by WSO2 for the purpose of integrating enterprise applications. To develop integration artifacts which are deployable to it, WSO2 EI Tooling is introduced.
Before we discuss about debugging, let us see what kind of artifacts are generated by WSO2 EI Tooling first.
Configuration driven artifacts
There are two main approaches integrator solutions facilitates to develop integration.
- Code driven : Some integrator solutions require developers to write code to do the integration. This brings the flexibility to making of the integration between the systems but takes out the agility and flexibility.
- Configuration driven : In contrary, some solutions provide configuration approach which is flexible enough to achieve any integration solution
WSO2 Enterprise Integrator falls under latter, hence the tooling solution allows developers to configure the integration using popular XML. The total integration solution is presented as a set of mediator units which developers can configure to construct the desired integration solution.
Graphical Support!!
WSO2 EI integration developers do not need to remember any xml syntax to configure the mediator units. All are supported graphically in WSO2 EI tooling. Citizen Integrators can use the tooling with a minimum knowledge about WSO2 Enterprise Integrator internals by drag and drop of mediator units on to the message flow and configuring them.
This increases the agility of building the integration solutions. At the same time, it is very easy!!
Why debugging is needed?
However, when the integration solution becomes complex, developers will need a way to execute and see at each step what happens to the message, how they get transformed along the message flow. By doing that, they can ensure when they ship a deployable artifact for the WSO2 EI runtime, everything works as expected.
No need to plug an external runtime
Artifacts developed using EI tooling are eventually get deployed to WSO2 EI runtime. Owing to that reason, we need the same runtime to debug the artifacts as well. WSO2 EI tooling is pre-equipped with WSO2 Micro EI runtime (yes, not the whole server — but a lightweight runtime environment) which is launched by default when you engage debugging. There is no need to configure anything additional.
How to launch debugging
With default internal micro EI runtime
- Click on run → debug and choose artifacts you want to deploy and debug
- Notice that internal micro EI is launched and logs are printed on console tab
- HTTP traffic is listened on 8290 port
With external WSO2 EI server
- First to configure an external server, click run → debug configurations
- Specify debug mode as remote and configure the ports to connect to an EI server. (default 9005/9006)
- Add the new configuration into debug menu
- Execute the following commands to start WSO2 EI server in the debug mode by passing a system variable at start up:
<EI_HOME>/bin/integrator.sh -Desb.debug=true(on Windows) <EI_HOME>\bin\integrator.bat — run -Desb.debug=true
- When server is listening on ports engage debug from the tooling
NOTE: To invoke the internal/external runtime APIs/Proxy services please use an external tool like SOAPUI, Postman or Curl.
Features of the debugger
1 Mediator level debug points
Right click on mediators and you can toggle break points as desired. Make sure to “Resend ESB debug points” every time you change the debug points so that the runtime knows about the change.
It is convenient to use “debug perspective” when on debug.
2. View payloads before and after
When a debug point is hit, if you mouse over the mediator, payload is displayed. This is payload after the mediator is executed. If you need to see the payload before, you need to check on the previous mediator on the flow.
3. View properties in different scopes
When a debug point is hit, you can see different properties on the message context that is passed through the integration flow. These properties are categorized to different scopes and they control the behaviour of mediators in the runtime. Learn more about WSO2 EI properties.
4. View Wire logs
When HTTP/HTTPs protocol messages are coming in and going out from WSO2 EI, developers can view them using wire logs. These are the message coming in and going out at the transport level. Proxy services, APIs, Send and Call mediators show request and responses.
This post highlighted the debugging features provided by new WSO2 EI tooling. It is time to wrap up. Happy integration development!!
