Skip to main content

Overview

This section describes the high-level architecture of the Compliance Platform. The platform was designed to be scalable and integrate with novel systems in future, and so it was designed around a flexible architecture consisting of three sections:

  • Core Test Platform
  • Simulators
  • Systems Under Test (SUTs)

Core Test Platform​

The core test platform presents a frontend interface to manage users, sessions and test cases. In addition, it presents a proxy layer which is capable of intercepting and validating every message between simulators and SUTs. The platform uses Laravel, a web application framework built with PHP.

Frontend​

The frontend is responsible for rendering the user interface and uses two main technologies: Vue.js and Tabler.

  • Vue.js: Used to build a single page application, rendered through Inertia.js.
  • Tabler: Provides the admin and dashboard layout to build the UI, using Bootstrap internally.

Test Manager​

The core of the test platform is the test manager. Test cases define the execution flow of tests, as well as defining schema validation and business rule validations. Schema validation is performed automatically bsed on an OpenAPI Specification (powered by OpenAPI PSR-7 Message Validator), while business rule validations are controlled by custom logic defined inside the test case definition.

Simulator Plugins​

If you are testing your own API on the Compliance Platform, you might run into some issues if you have additional parameters which are not part of the GSMA Mobile Money's API Specification.

To fix this problem you can use a Simulator Plugin. A Simulator Plugin is a JavaScript file you can upload to the platform to make adjustments to the request & responses that go through the platform. What this means is you can essentially manipulate the headers and the body to fit any requirements you might have.

More information can be found here.

Proxy​

In order to provide an end-to-end test, the platform must be able to follow all messages exchanged between entities. All messages within the system pass through a proxy layer, allowing the platform to store and validate messages before forwarding them to the correct recipient. When the receiver sends an HTTP response, that too will be validated before forwarding back to the original sender.

This diagram illustrates communication through the proxy layer.

Loading...

Simulators​

Every component in the system may be either a simulated component, or a real component known as a SUT. The behaviour of simulated components is entirely defined within the test case file. Within the file, a series of test steps is defined, with each step including a sample request and response. By playing back these requests and responses in sequence, a full system flow can be simulated.

System Under Test​

Any of the simulated requests and responses can be replaced by a real message generated by a live system. This live system is known as a "System Under Test" (SUT). When creating a test session, any component can be selected to be a SUT for the duration of this session. Once it is selected, it replaces the simulator representing that component for the duration of the test, and becomes responsible for generating all requests and responses from that component.