In part 1 of the series, we reviewed some gaps in the Systems Integration solutions and the need to act.
In part 2, we introduced the ExpressConnect Integration solution and its high-level components.
In this part, we shall dive into more details of the ExpressAPI components:
ExpressAPI
The ExpressAPI delivers the primary capability for API-driven data exchange. It exposes the APIs in an OpenAPI format and provides intuitive search and interaction capabilities.
The ExpressAPI consists of two core groups of components:
The “Run-time Components” used during the API execution; and,
The “Tools” used to set up, configure and explore the APIs.
Fig 1: ExpressAPI components
The Run-time Components and Tools include multiple underlying components dealing with specific capabilities. We will expand on the functions of these components as we go.
The Run-time Components include the following sub-components:
Fig 2: ExpressAPI expanded solution with sub-components
OpenAPI Gateway
The Gateway component exposes the API endpoints aligned with OpenAPI standards and manages the paths and the methods available for the API Paths. The exposed API paths are all contained within the TRIRIGA context path requiring no additional network configuration. Finally, the gateway component validates the request against the available API Paths and the Operators.
The Gateway component manages the API End Point-specific routing to route the request to the correct internal branches for further processing through the Request and Response Handler component. In addition, this component validates the combination of the API path and the requested “Method” of execution, for example, GET, POST, etc.
The responsibility for parsing the operators and constructing the search operation also lies within the Gateway. This component will check for syntax and build the search and control parameters based on the operators included in the request.
Towards the end of the request, the Gateway component will receive the response from the Request and Response Handler component and pass the response to the requester.
Schema validator
The Schema Validator component performs validation for the POST, PUT and PATCH methods. Once the Run-time component performs the path validation, it will perform the schema validation.
The validator component will validate the structure of the incoming payload and check if the required fields are available and in the correct format, for example, string vs numeric fields. It will also check for the mandatory fields and the required character lengths. In addition, it will validate the field value against the allowed values for specific fields. Additionally, it will also check the format of date fields and can identify any attempt to update the read-only fields.
The schema Validator component collates all the errors encountered during the schema validation. Then, it passes the errors to the Exception handling component. Worth noting that the validation component will report all the errors collectively to allow for seamless exception management.
For the next level of validation and handling, the Validator component will pass the ownership to the Request and Response Handler component.
Custom Auth Provider
The current authentication methods lack the support for modern authentication methods in systems integration, for example, OAuth or API Keys. Currently, the system supports only plain text or Basic Auth with Base64 encoding, and security mainly relies on communication on the HTTPS layer.
The Auth Provider component runs within the App Servers and provides additional authentication options. Currently, the Basic Auth with Base64 encoding and API Keys are supported. The support for OAuth and the ability to provide encrypted data transmission are under consideration for future releases.
An API Consumer can utilise API Keys to authenticate while connecting to TRIRIGA and will have the same underlying usability. However, the API Key is more secure and encrypted, hence, hard to decipher compared to the Base64 string.
Cache Provider
The performance of any API is a core concern and is an important KPI for any API Consumer. The response time for the search (GET) operations is fundamental to the usability of the APIs. The digitisation trends and the move to the microservices architecture require the underlying components to respond with the least latency possible. Any bottleneck in the whole lifecycle renders the use cases useless for the End users.
Traditionally, the TRIRIGA APIs are cached based on the request URIs. The data is in the cache for a limited period, as caching will clear the old data off the cache store. And because the rate for cache miss is high as different query string value generates a different URI, the underlying data store/database ends up serving most of the requests.
The modern requirements to cater to usage spikes, instant synchronisation of cache, and the required data availability in cache-store generally need heavy customisations. These requirements typically will lead to an external solution at a high cost.
The Cache provider component is dynamic, aware of the underlying data modal changes, and will auto-adjust the cache data model. Additionally, an Admin can adjust the cache size and other parameters through the ExpressAPI Native App.
We can pin certain data sets in memory through the settings app to prevent the data from being evicted from the cache-store.
The Cache store can auto-warm (pre-populate the data) on the server's start-up. It can be kept up to date through an “Event” subscription for real-time updates or through configured scheduled refreshes.
The cache also features a distributed caching capability. This capability means that in scenarios with more than one App Server, the same cache data is available in all those servers and synced.
Request and Response Handler
The Request and Response Handler is the leading orchestration component handling the requests. It will parse the request, execute the required actions, and prepare the response payload (success or exception) for return transmission by the Gateway component.
Once the schema validation is successful, the Request and Response Handler component will perform further validation steps.
During the next step in the validation process, the component will validate the referential integrity of any dynamic data fields containing Classification and Hierarchy data. After that, the Schema Validator component will ensure that the linked data fields have the data matching the ID and Path in the system before it can accept the data.
We refer to all these checks collectively as reference data validation.
The next step within the validation component is the Business Rules validation. This validation step is quite complex to achieve as the business rules can be quite complicated and could vary for each implementation. These validations generally cover the items that have related validations or multilevel validations. The approach we have taken is the component provides a framework for the business rules validation, and the Customer can look to provision specific validation through custom workflow steps.
The execution at this point will move over to the Data Access Layer. This component will manage the data exchange actions, such as getting the record data or updating any specific data.
Towards the end, it will pass the response back to the gateway component for further transmission. It will rely on the hint and display operator to adjust the response output in preparing the response.
Exception Handler
The Exception Handler is called upon when the API run-time encounters any exception. This component can be called upon at any point during the processing of the request. The exception handler component will collate all the exceptions and provide a structured error response.
The error response is after that passed to the Request and Response handler component.
Data Access Layer
The next step in the validation flow is validating the linked and child objects and their referential integrity. This validation is orchestrated at the Data Access Layer and performed by the underlying TRIRIGA platform.
In part 4, we cover the components within the Tools section of ExpressAPI.
Meanwhile, if you need to discuss anything, don't hesitate to contact us through this link.
Please read our Privacy policy here.