We are proud to have a large and active developer community using MuleSoft. Some of those developers become Champions, developers who become an active part of our community. Champions grow their skills, help others, and network with the top MuleSoft developers and advocates around the world. Gennaro Spagnoli, a MuleSoft Champion who works at Accenture, wrote about his experience with Anypoint Platform, and his approach to a particular integration project.
I’ve been using Anypoint Platform on the project that I’m involved with at Accenture for about a year.
The project is about an insurance company; the need to introduce an ESB layer is born from the need to use a software layer capable of orchestrating the diversity present in the architecture of the platform systems and services.
The software architecture is composed of various internal and external systems that expose services in the form of web services and REST.
Through the use of Mule as an ESB it was possible to mask all existing services under uniform interfaces to the outside, making the appropriate transformation through the use of transformers made available by the platform.
One of the most interesting applications, in the first stage, was to proxy all the existing web services, making sure that all the request and response to and from these services would pass to the ESB.
In this way we were able to intercept calls and to provide the logging / tracing services of such services.
For this purpose it used the web-service-proxy pattern, as described in the official documentation:
All flows extend a single abstract flow, sharing the transformers LogDBTransformerRequest and LogDBTransformerResponse as follows:
You can notice the following things:
- The abstract attribute is equal to true, to express it is an abstract proxy;
- The request transformer is the LogDbTransformerRequest, as previously depicted, preceded by a byte array to string transformer able to parse the incoming xml to a readable String;
- The response transformer is the LogDbTransformerResponse, as previously depicted, preceded by a byte array to string transformer able to parse the incoming xml to a readable String;
- There’s a class implementing a custom exception strategy, able to catch the errors and log them in a database table;
The two transformers basically have the task of capturing the request and response xml SOAP respectively destined to the proxies that extend the abstract proxy, and logging them on a table on DB for further analysis and introspecting.
In the project, another approach is present which does not make use of proxies, but is able to perform the message log in and out through the various flows either on db table indicated above or on files .
In addition, the log file is able to distinguish the system from / to which the message is forwarded, and route the log towards the appropriate files associated with those systems.
Take a look at an image that describes a flow portion used for tracing:
In order to not to slow down the flow during the log, it was useful to implement an asynchronous writing logic on a jms queue, in order to allow the flow to continue its running, and only then retrieve messages queued to be logged and perform writing to a DB table.
Would you like to join the Champions program? You can. Take a look and sign up!
