Transactional Flow
A transaction is the entity that integrates the applications with clients' or Veritran’s back-end.
The transactional flow represents how a message travels from an app’s front-end, through the middleware and to the services' back-end. In the section below, you will find information about each component that takes part in the transactional flow and how they interact with each other within this process.
There are three main components that take part in the transactional flow:
The digital communication channels, such as the web and mobile app’s front-end.
The middleware, which allows the communication between apps and the back-end.
The back-end layer, made up of the APIs or interfaces provided by the client to connect with their services. This component also contains Veritran’s own services.
Read below to learn about the Middleware, the servers that conform it, and the role of every component in the transaction flow.
Middleware
Veritran’s Middleware is the main component that allows communication between the front-end or apps and third-party and clients’ services, and also between the front-end and Veritran’s platform services. It is a set of processes that run over VT-NET runtime system, and route, orchestrate and integrate client’s and third parties’ APIs to solve transactions incoming from both web and mobile apps.
Middleware enfolds the Communication Server (COMM) and the Core Server (CORE).
Communication Server
The Communication Server is the communication layer. It is the first component to interact with an incoming message in the transactional flow. It establishes sessions for the transaction's duration and forwards them to the corresponding processes within VT-NET. Additionally, it stores web and mobile apps configurations, and can store dynamic resources.
In the communication server, you can find VT-Gateway and Webfly.
VT-Gateway: PHP component that functions as a gateway between messages sent from mobile devices and VT-NET, Middleware’s orchestration system.
Webfly: Java application that interprets web metadata received through VT-NET to present the user with the desired web app.
Core Server
The Core Server is the orchestrating layer, which controls and manages communication between apps and the back-end through VT-NET, Middleware’s main component. VT-NET is a runtime that manages transactions and is divided into two sets of processes: system and application processes.
System processes are all those processes necessary to guarantee that VT-NET runs correctly. Those processes are the Kernel, Command Server, Model Server, Application Server and the Security Server. Application processes are those that manage the transaction’s route, which is the path that communicates apps with the back-end, and execute the necessary functions to implement business functionalities within the app. These processes are the Device Handler, the Authorizator and the Host Interface. Next section focuses on application processes, since they are deeply involved in the transactional flow.
Note
Read VT-NET's documentation to learn more in-depth information about the system, how to initialize it and a list of useful commands that can help you operate on the platform.
Services Integration and Orchestration
The Host Interface can invoke several services, of one or more external systems, in the same transaction. These integrations can be done using industry standard protocols, such as SOAP, REST, or JSON.
Here's an example of the path a transaction takes when the mobile app needs to connect to a service provided by a client or a third party, or to a service owned by Veritran. Once the message reaches the back-end, the response takes the same route back to the app.
Most of the time, apps need to obtain data from the back-end that require to invoke several services, depending on the business logic applied, in the same transaction. After the Device Handler has executed every service orchestrated in the transaction and received data, it sends a response back to the device.
The platform supports several orchestration modes which can be adopted depending on the transaction and service's characteristics. This way, a complex transaction can be decomposed in a series of steps that can be executed in different ways:
Sequential: Each step is executed one after the other. Each step must be successfully completed to execute the next step. An example of a sequential orchestration is a login, where the transaction first authenticates the user, sends an OTP validation, and lastly retrieves the account's details.
Parallel: Some steps can be executed simultaneously because there is no dependency between them, therefore reducing transaction's execution time. For example, a transaction can authenticate a user, verify accounts, and then, for each account, validate their movements in parallel.
Optional: The transaction can be completed even if the optional step is not. For example, after a user has been authenticated and accounts have been retrieved, the transaction can also verify accounts promotions. If this is configured as an optional step, the transaction can be completed successfully even if the promotions service is not responding.
