External integrations subsystem
| 🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions. |
1. Overview
The subsystem provides standardized interaction interfaces based on REST and SOAP protocols, ensuring registry interoperability with external systems.
External integrations management subsystem supports the following options for the information exchange configuration:
-
Via Secure Exchange Gateway, as a protected transport.
-
Via the configuration of direct integrations with external systems that aren’t part of Secure Exchange Gateway information exchange.
-
Via the configuration of direct integrations with the Registries deployed on one Registry Platform instance.
-
Via public API.
Existing information systems, and Registries deployed on separate Registry Platform instances can act as external systems for integration.
2. Subsystem functions
-
Providing API for the initiation of automated and semi-automated Business Processes in a Registry by external systems.
-
Providing search API for Registry data to external systems.
-
Request routing during cross-Registry interaction on one Registry Platform instance.
3. Subsystem technical design
3.1. Cross-Registry interaction
The subsystem involves interaction between two Registries deployed on the same Platform, which creates a connection between the data source Registry and the data consumer Registry.
Data source Registry - is the data holder Registry that allows read operations with its data by using dedicated search requests.
Data consumer Registry - is the Registry that was give access to search requests to data source Registry.
The main aspect that enables this interaction is the creation of a service user in the data source Registry for the data consumer Registry, and using it for requests. The receiving of service user account data, and authentication are performed by cross-Registry interaction API-gateway deployed in the data consumer Registry. This cross-Registry interaction API-gateway is available for authenticated users of the data consumer Registry.
As a separate case, there is the provision of data access to external system data consumer. In this scenario a dedicated service user is created, and the account data is transferred by system administrator. This way, the authentication and token exchange must be performed by the external system.
4. Event audit and logging
Events of Registry manipulation via external systems are recorded in the audit log with full context. Along with Registry data management subsystem events, the following events are recorded:
| Event type | Service name | Description |
|---|---|---|
USER_EVENT |
SOAP request. Method: ${methodName} |
Data read request with method recording. |
USER_EVENT |
EXCEPTION |
Data reception error. |
|
You can finkd more information on the Registry audit events logging subsystem here. |
5. Subsystem components
| Component name | Representation in the Registry | Source | Repository | Function |
|---|---|---|---|---|
API-gateway for calling Business Processes by external systems |
|
origin |
API-gateway for the provision of access to Business Process calls by external systems via Secure Exchange Gateway, or directrly via external traffic management subsystem. |
|
Cross-Registry interaction API-gateway |
|
origin |
The service for request execution from service users to Platform Registries. |
|
API-gateway for Registry data reading by external systems |
|
origin |
The component that provides SOAP interface for data reading via the Secure Exchange Gateway. |
|
Synchronous Registry data management service for cross-Registry interaction |
|
origin |
A dedicated instance of the synchronous Registry data management service for the provision of data read access to other Registries on the Platform. |
|
Synchronous Registry data management service for public data access |
|
origin |
A dedicated instance of the synchronous Registry data management service for the provision of public data read access . |
6. Technology stack
During the design and development of the subsystem, the following technologies were used:
7. Subsystem quality attributes
7.1. Interoperability
The External integrations management subsystem supports compatibility with other systems by providing standardized interfaces for Registry interaction (REST, SOAP).
7.2. Scalability
The External integrations management subsystem supports horizontal and vertical scaling.
|
You can find more details on subsystems scaling in the corresponding sections: |
7.3. Observability
External integrations management subsystem supports logging and performance metrics gathering for further analysis via web-interfaces of the corresponding Platform subsystems.
|
You can find more details on subsystems design in the corresponding sections: |
7.4. Security
The External integrations management subsystem uses TLS asynchronous traffic encryption for all communication. All requests to services that perform the operations on Registry data require authentication. Requests between Registries within the Platform are performed by internal service names (internal network).