Mule application for the collection and processing of information about calls and data transfer from Webbing

If you often travel (for business or personal purposes) to different countries and corners of the world, then you probably faced such a problem as the need to constantly control which mobile provider network your phone was connected to. And you either need to manually select the appropriate roaming provider or buy SIM cards for each country. Each of these options is inconvenient.

To get rid of using multiple SIM cards, Webbing devices (specific SIM cards) were specially developed. These cards are installed into the phone and no additional settings are required. Such a SIM card can be used as a single corporate SIM card of an employee. These SIM cards work in the mobile networks of most world mobile providers and allow users not to think about changing SIM cards when moving between countries, but simply to make calls and use mobile Internet.

Webbing maps are especially relevant for international companies, which employees regularly move between offices. One of our customers provides digital cost accounting services for the telecommunications industry. Moreover, such services are provided to one of the largest international agencies with more than a hundred offices around the world. Agency employees actively use Webbing SIM cards. It was required to add Webbing card cost accounting to the existing customer’s services.

This task was to be solved by our team. One of the customer’s requirements was to develop a solution based on Mule, since it already had Mule applications in its infrastructure. It is impossible to extract calls information from raw data of mobile phone operator centers (and there are many of them), so it was required to obtain data from Webbing web services. We proposed a solution, the essence of which is to transform extracted information about calls from Webbing services to the required format and save it in the database, so that the client can work with this data in the future. The integration diagram of the solution with the existing infrastructure of the customer is shown in Figure 1.

The developed solution is a Mule application that works as follows:

1. Requests are sent to Webbing every nn seconds (via Quartz).

2. XML responses from Webbing services are deserialized into Mule internal representation.

3. The data is filtered: the data that has already been processed is rejected, the remaining data is filtered again by the given prefix.

4. Conversion to xml.

5. The data and log are saved in the customer’s system.

After that the customer’s departments, for example, the accounting department, can access cost data in any form that is convenient for them. So, now employees do not need to process large amounts of data manually and enter them into the accounting software.

The application interacts with Webbing web services through SOAP requests, which makes it possible to implement any client side in the future.

In addition, in order to reduce time for deployment and testing and ensure that developers will focus on the development of the software product, the customer set one additional task: to implement Continuous Integration, Continuous Delivery (CI/CD) process (to be used in this and future projects), which would allow maximally automate the building, testing and deployment process. So, it was implemented by us.

For this purpose we deployed and configured Jenkins, with the help of which the following tasks are performed:

So, with Jenkins deployment we reduced the time the developers spent for new versions building, testing, and deployment manually.

Stack: Mule ESB, Java, Apache Maven, XML, XSLT.

Infrastructure: Jenkins, Git, Anypoint Studio.

Test Automation Libraries: MUnit.

DB: Oracle.

Protocols: HTTPS, JDBC, SOAP.

The implemented system allows to automatically collect and process detailed information about calls for every Webbing device:

Company’s achievements during the project:

Many of our best practices used to implement Mule solutions during this project were described in “Best Practices in Mule ESB”. This document later served as the basis for the creation of the article “Best Practices for Using Mule ESB“.