At the beginning of our journey with the GSMA Interoperability Test Platform, during the exploration phase, we decided that the platform should support operators during their drive towards building an interoperable ecosystem. In order to achieve that, one of our primary requirements was to choose an architecture which will give us this flexibility and adaptability. This blog addresses how we used modular programming to develop the GSMA Interoperability Test Platform, and how its design gives industry players the tools needed to build a consistent and efficient testing environment. If you are not familiar with the platform, you can learn more on our last blog which details our journey building it.

When designing the software architecture of a product, there are many aspects to take into account to ensure that the product’s desired purpose is achieved with adaptability, scalability and ease of maintenance in mind. This can be accomplished in several ways. In our case, we utilised modular programming, which involves splitting up the core elements of an application into separate individual components to act as self-entities.

As our platform had the goal to be an end-to-end testing platform, it needed to integrate three main entities (Service Providers, Financial Service Providers (FSPs) and Switches) to interact with each other, and if a particular system is to be tested, it needed to easily switch places with the corresponding simulator.

Because of the platform’s requirements, we decided to split all the core elements up into 3 main components:

The three components

The Simulators

All of our simulators represent a different entity within the real-life scenario, so it is therefore essential they be interchangeable with real systems. In order to achieve this, we created 3 different types of simulators:

• Service Provider – simulates a service provider (such as a vendor or a utility company) in a transaction.
• Financial Services Provider 1 – acts as the initiating FSP (such as a mobile money provide or a bank) in a transaction.
• Financial Services Provider 2 – acts as the recipient FSP in a transaction.

In addition to this, our platform runs a real version of the Mojaloop software to connect the two FSPs and act as the interoperability hub.

The Core Test Platform

The core test platform acts as a linking point between all entities involved, providing an interface for users to manage their sessions, test cases and other users within their group.

Every message exchanged within the platform is first validated through a proxy layer, before being forwarded onto the appropriate simulator.

The System Under Test (SUT)

So far it is possible to test two different types of systems – Service Providers and Financial Service Providers. A system under test replaces the corresponding simulator, and once configured, can be tested against any of the valid test cases in a consistent environment.

Through the detachment of the program’s functionality from its architecture, more control is given to the user to select the parts of the platform they would like to test, and which parts the simulators should take care of.

Shaping the platform to the user’s needs

With the architecture ensuring we can scale and adapt efficiently, how can we allow our users to shape the platform according to their individual needs? There are 3 key ways to take advantage of the ITP’s features for whichever scenario you would like to test.

Creating new test cases

Test cases are specifically suited to run through each step of a given use case, validating every request and response against a list of business rules defined within the test case file, along with schema validation, which is handled automatically by the OpenAPI validator. Test cases are currently in the form of YAML files, an easy-to-read data-serialisation language. We chose the YAML format as it leaves room for a lot of flexibility, and reduces the complexity involved in creating additional tests. Our next blog delves into this topic in more detail.

Using our guide on creating new test cases, users can be granted permission to generate their own test cases and upload them onto our platform which they can then immediately use in their own sessions. We also have plans on adding a user interface to manage test cases, further simplifying the process.

“Plug in” an external simulator

As explained above all of our simulators are independently connected to the test platform. This means they can also be removed and replaced with an external system. The only requirements to having a valid system to test within our platform are that they; a) Are capable of sending and receiving JSON messages to and from our simulators, and b) have also incorporated the relevant APIs.

Currently we host two APIs in our system; the Mojaloop API, which is used for communication between the two FSPs, and the GSMA Mobile Money API, which is used for the communication between the Service Provider and the Financial Services Provider.

Upload any OpenAPI specification

Additional APIs can easily be introduced into the system by simply uploading the specification through our platform. However, some changes may need to made to our current simulators in order to accommodate them, or we may need to create a new simulator to support this new API. If you would like to introduce a new API into our platform feel free to reach out to us and we would be happy to assist.

Summing it up: Adaptability, Scalability and Ease of Maintenance

Our platform was designed to give operators a straightforward path into testing an interoperable ecosystem, and in this blog, we discussed how this was accomplished using modular programming.

Through our user-friendly method of creating new test cases, we provide non-technical users with the adaptability of creating new testing scenarios which better fit their requirements. Scalability is achieved through our expandable “plug-and-play” system for simulators, which can happily accommodate new types of simulators without difficulty. And lastly, once our support of OpenAPI specifications is in the platform, it doesn’t require anything additional on the developer’s part, providing ease of maintenance.

While our initial version has already been released, we are continuing to make improvements to our platform by adding new test cases and features as required. If you would like to request a new feature or get involved with our project please visit our GitHub page, where you can find documentation regarding the platform as well as our contribution guide. Lastly, we would like to invite all operators and service providers to reach out and joins us in our interoperability journey.