ExpressConnect - Systems Integration solution for TRIRIGA - Solution Components - Part 4

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 part 3, we went into the details of ExpressAPI Run-time Components.

In this part, we shall dive into more details of the ExpressAPI Tools components.

To recap, The ExpressAPI consists of two core groups of components:

1. The "Run-time Components" used during the API execution; and,

2. The "Tools" used to set up, configure and explore the APIs.

The Run-time Components and Tools include multiple underlying components dealing with specific capabilities.

Fig 1: ExpressAPI expanded solution with sub-components

The "Tools" Components include the following sub-components:

OpenAPI Explorer App:

Once the APIs are developed, socialising the API within the developer community is an additional challenge. The APIs have a lifecycle where they go through changes. Keeping up with the latest changes and maintaining the versions of the offline documents goes out of control, and we generally end up with multiple offline versions of the documentation for the same API.

With different team members involved, the documentation always takes a different shape and form. This presents another set of challenges for the Developers representing the Consumer side of the APIs. A hassle-free onboarding of the APIs requires consistent and latest documentation to be published in a central repository where the developers can explore the API, understand the usage patterns and use cases and test the potential data exchange scenarios before deciding on the consumption patterns.

The OpenAPI Explorer App provides these capabilities packaged as a neat UX App. The App is fully embedded in TRIRIGA and is developed using the ReactJS framework.

The App acts as a repository of the API and aids in the discovery and onboarding of the APIs. The App enables a true sense of self-discovery and takes away countless hours of workshops and assessments to onboard APIs in Consumer systems.

Click on the sections below for a further explanation of the OpenAPI Explorer App capabilities:

Version Management

The OpenAPI Explorer App allows a Developer to explore multiple versions of the APIs. Developers can easily switch between API versions within the App and assess the changes and would be able to plan for the development switchover to the latest versions seamlessly.

Each API version can work independently, allowing developers to adopt the changes gradually. The API versions provide a metadata wrapper around the underlying TRIRIGA data model; however, each API version will provide the same data.

Fig 2: Support for multiple versions of the same API

OpenAPI Specification

The OpenAPI Explorer App renders the APIs in compliance with the OpenAPI specifications. For further collaboration with other industry standard tools, the API specifications can be exported in an OpenAPI-compliant "yaml" file.

The OpenAPI specifications are auto-generated by the ExpressConnect platform during the publishing process. This removes any need to manually create the documentation and the requirement to keep the documents up to date.

Fig 3: OpenAPI document download option

Data Models and examples

Each API definition features a detailed Data model definition and specific examples. The OpenAPI Explorer App will dynamically keep the data model and the API definition up to date as and when changes are published for any APIs.

A future roadmap capability will enable the generation of examples utilising live data from the specific environment.

Fig 4: Data Example and Schema

Security schema

The OpenAPI Explorer details the various security schemas supported by the API for the specific TRIRIGA environment.

Developers can utilise the security schema to authenticate with the target environments in real time and utilise the connection for invoking the APIs for trial and testing purposes. Developers can use the "Try It" option to connect to a pre-defined server and explore actual data.

Fig 5: Security Options

Constructor for Operators

The OpenAPI Explorer App features a constructor for Query and Hint Operators. Developers can utilise the self-service option to explore the syntax of the operators.

Developers can use this feature to shorten the learning curve for the API query syntax.

Fig 6: Constructor for Query operator

Fig 7: Constructor for Hint operator

Client Code

Developers can construct the API use cases utilising the required operators and view the client code in the available languages detailing the selected use case; for example, any selected headers or query operators are dynamically embedded in the client code samples.

Fig 8: Client Code viewer

API Test Runs

Developers can test the APIs in real time. They can utilise the security schema, connect to the target server, test run the APIs, and explore the responses right from within the Explorer App.

Developers can simulate various exception use cases and preview the responses (including exceptions) to help configure the required handling in the client tools.

Fig 9: Online Request and Response option

There are exciting roadmap items planned for future releases. Some core enhancements include new UX Apps for Analytics Dashboard, API Administration, and API Builder.

ExpressAPI Native / Classic App

The ExpressAPI capability is embedded within the TRIRIGA tool. This capability is supported by multiple run-time and tooling sub-components, and these sub-components are configured and managed through various Apps within TRIRIGA.

These Apps collectively enable the overall ExpressAPI capabilities.

Click on the sections below for a further explanation of the capabilities:

Data Model Configuration

A module-level data configuration option allows a granular level of control over the data model definition for the APIs.

Fig 10: Data Model Configuration option.

The planned API Builder App will largely automate the generation of the Data Model configuration in future.

Cache Configuration

The in-built cache is one of the core components of the ExpressAPI run-time. The run-time behaviour of the cache can be configured and controlled through the TRIRIGA application.

The cache settings can be configured on the Global and the API Path Level.

The global settings for the cache deal with defining the size of the cache and default refresh policies. The cache size can be defined as the number of keys or the maximum size of the memory store.

Different cache eviction policies like LRU (Least Recently Used), LFU (Least Frequently Used) or FIFO (First In, First Out) could be applied.

Fig 11: Cache global settings

The cache setting feature options on the API Path Level define the cache loading policy. The Administrators can set up intervals for full and incremental loads and provide criteria for the incremental load fetch of data.

Combining the full and incremental loads ensures the cache is always in sync. The incremental cache load can be adjusted to a low "minute" value for highly transactional objects, such as Service Requests or Tasks.

The cache management functions are exposed through APIs.

With the auto-loading enabled, the cache will load the records in the cache on the server start-up. The cache can also be loaded and managed manually or through scripted API calls.

The ExpressEvent capability planned for a later release will introduce real-time cache update capabilities through the event pub-sub feature.

Fig 12: Cache settings on API Path level

The cache, once loaded, can be validated online to confirm the integrity of the cache. The testing can be performed manually or through scripted API calls.

Fig 13: Cache test option

Authentication Provider Server

To enhance the Authentication capabilities of the underlying API platform, we have created a new Authentication Provider Server component to allow the Consumer systems to authenticate using the API Keys.

The API Key-based authentication is more significant while dealing with event-driven data exchange. (We will cover event-driven architecture in the "ExpressEvent" related articles).

With the recent focus on security, Organisations are unwilling to accept passing the username/password in plain text and are pushing to move away from Basic Auth. Most organisations are looking to separate the Authentication and Resource access concerns. The API Key authentication option over HTTPS provides an extra layer of security.

A feature to provide OAuth capabilities is in the future roadmap.

API License Manager

The API License Manager app allows an Administrator to control the usage of the API against the Organisations. License Manager will support targeted use for specific organisations and users in a multi-customer environment, i.e. any licenses applied to an organisation allow the Users belonging to the Organisation to use the API platform.

Fig 14: License Manager

API Users and Key Managers

The API Users allow Administrators to enable any Users for API Use. This will allow a detailed control on which Users can invoke API as only authorised users are allowed access through the ExpressAPI solution.

Fig 15: API Users

The API Keys Manager allows Administrators to generate API Keys for the API Users. The API Keys are an alternate authentication method and allow a secure login over a secure socket layer.

Fig 16: API Keys

Test Configuration and Execution

The ExpressAPI solution includes full-function automated test case generation and execution capabilities.

The Tests can be executed manually or through scripting. In addition, during the release cycles, these tests can be performed to validate the correctness of the APIs.

Two different types of tests are available through the ExpressAPI Platform - API Lifecycle Test and API Query Test.

The API Lifecycle tests will generate test scripts in real-time, including incorporating actual data as much as possible. Once the scripts are generated, the tests are executed, which cover the available API paths and different actions like POST, PUT, GET, and DELETE.

Fig 17: API Lifecycle Test

The API Query Test verifies all available operators across all the relevant fields. For example, it will validate "contains", "equals", "not equals", etc., and other operators against each attribute.

Fig 18: API Query Test

These scripted API Tests could be hooked up to any DevOps pipeline to perform an automated regression test during the release cycles. This automation process alone can reduce the effort required to perform API unit and regression tests by up to 80%.

To note here - Customers would still need to perform some Integration tests with external systems and, in some cases, end-to-end tests incorporating the business processes they manage; however, the tests defined above do help with the first step of technical validation and regression checks.

A future roadmap item will include the option to generate the API Tests scripts that can then be downloaded and hooked up to any automated testing or DevOps pipeline.

API Group Manager

The API Group Manager consists of various pre-built APIs related to a specific area of the TRIRIGA application. Customers can opt for only specific API packs relating to the TRIRIGA applications they use or have licenses for.

The API packs are packaged individually and can be deployed independently to a specific TRIRIGA environment.

The basic Portfolio API pack is included as part of the base deployment configuration for the ExpressConnect solution. This includes Organisation, Geography and Location hierarchy-specific APIs.

Fig 19: API Groups

The API Packs are quite a broad topic to cover in a short paragraph. We shall dive into the API packs in a dedicated article sometime in future.

OpenAPI Adaptor

The OpenAPI Adaptor dynamically generates the OpenAPI specifications and manages the APIs' versioning. When published, the APIs defined in TRIRIGA will utilise the OpenAPI Adaptor to publish the OpenAPI specifications ready for consumption.

The OpenAPI Adaptor also acts as a bridge between the API definitions and the OpenAPI Explorer.

The OpenAPI Adaptor is the foundation for future capabilities to enable a design-driven API generation.

Fig 20: OpenAPI Specification

API Builder App

The API Builder is conceived to allow Developers to define, generate and publish the APIs without any configuration or lines of code.

The API Builder App is a future capability and is subject to change. Therefore, we will explore this component further in future.

Metadata Explorer API

The Metadata Explorer APIs are conceived to extend TRIRIGA integration capabilities to allow external Integration middleware toolkits to discover the TRIRIGA APIs and Events and build metadata-aware connectors.

The Metadata Explorer APIs will be utilised as a part of the ExpressAdaptor capability, and a native connector for the AppConnect is planned for release towards the end of Q2 2023.

Fig 21: ExpressConnect extension to external Integration and data platforms

The Metadata Explorer is a future capability whose scope and timelines are subject to change. Therefore, we will explore this component further in future.

Forward-looking statements: Multiple areas in this blog article explore features currently under development or are part of the future roadmap. These features will be released in future; however, all delivery timelines and capabilities are subject to change.

In the next part, we will explore ExpressEvent, the event framework.

Meanwhile, if you need to discuss anything, don't hesitate to contact us through this link.

Please read our Privacy policy here.