fbpx

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

Introduction: 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.

Project summary: 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.

Mule app

Figure.  Diagram showing work of the application with Webbing and the customer’s database

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

Ezwim Webbing Main Flow

Figure. Ezwim Webbing Main Flow

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

Call Webbing And Save Results

Figure. Call Webbing And Save Results

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.

Save Responce Data

Figure. Save Responce Data

Save Log MessageFigure. Save Log Message

4. Conversion to xml.

Write To Oracle

Figure. Write To Oracle

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:

  • After every commit a build of the project is started in the revision control system. If compilation is successful, Unit tests are run. If all tests are successful, then the build is considered successful.
  • From time to time Jenkins checks for a new successful build. If there is one, then it is published on the server.

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

Project technologies:

Stack: Mule ESB, Java, Apache Maven, XML, XSLT.
Infrastructure: Jenkins, Git, Anypoint Studio.
Test Automation Libraries: MUnit.
DB: Oracle.
Protocols: HTTPS, JDBC, SOAP.

Project features:

  • Multi-platform, heterogeneous project.
  • Dependence on the services of several providers/service providers simultaneously.
  • Optimization for large amounts of data. Work with load tests.
  • Need for CI/CD.

Project results

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

  • The concept of CI/CD was applied.
  • At the moment the system is successfully used.

Company’s achievements during the project:

  • We applied load testing to ensure the required performance parameters.
  • Profiling was used to optimize resource consumption.
  • The main features were covered by Unit tests.
  • Relevant exceptions handling strategies were implemented for every Mule thread.

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“.