The Integration Builder is used to configure the APIs your GLU.Engine will expose, the Outbound Connectors and the Orchestration logic using Handlers that will direct the transaction flows.
When the GLU.Engine build is processed in the Build Manager tool, the Integration configurations are compiled using the Apache Camel Routes framework. This enables broad native support within GLU.Ware for the full spectrum of the Camel Route capabilities (e.g. Message Queues, Database connections, LDAP etc.).
Multiple integrations are supported. The GLU.Engine can be configured to connect to a multitude of systems, translating protocols between them as required. A single transaction might require data from multiple external systems in order to complete. GLU.Ware can validate a Request and collate the required data from different systems in order to complete the Request. Different outcomes of a transaction can be catered for with configurable ‘flows’ using ‘Handlers’.
All Integration flows start with an Inbound Connector (API) Request and end with a Response. Downstream of the Request/Response definition for a Transaction, the Integration Flow is defined in the Orchestration section. For each step in the Orchestration, calls can be passed to downstream systems via Outbound Connectors. The Outbound Connector options are created by configuration of the relevant Connectors using the ‘Connector Tool’. All Parameters (data) received for any End-Point are transformed or ‘un-marshalled’ into a GLU ‘Object-Model’ that is persisted for the duration of an individual transaction only. It’s from these un-marshalled parameters that subsequent Outbound Connector payloads (or the API Response) can be populated. These parameters can be converted to different protocol formats and / or simply reused at later steps in any flow.
Transaction Codes and Flow Codes
Each Transaction is identified by a Transaction Code which must be a unique ‘string’. It can be anything the Analyst desires, typically it will describe the API service being configured e.g. ‘BalanceEnquiry’.
Within the Orchestration each ‘leg’ is assigned a unique ‘Flow Code’ which similarly to the Transaction Code uniquely identifies each outbound call within the Orchestration Manager. These Flow Codes can be used to route transactions flows to specific steps in the flow i.e. Flows although defined chronologically do not necessarily follow the sequence in which they are defined.
A GUID is generated by the GLU.Engine for each Transaction processed by the GLU.Engine.
A GUID (Globally Unique Identifier) is a large, random number that is used to uniquely identify an transaction that the GLU.Engine processes. GUIDs are 128 bits long, which allows for a very large number of unique values. The GUID is labelled as the GLU_TXN_ID in the GLU.Engine logs. The GLU_TXN_ID’s are useful when one is tracing transactions in the logs. The use of GUIDs ensures that each transaction with it’s associate Transaction Code has a unique identifier.
The ‘Repair Integration’ Tool
The ‘Repair Integration’ tool at that top right of the Integration ‘tree’ is used to re-index the full tree structure of your integration. In the event that you have a configuration that has been imported or segments of integrations that have been cut or pasted into your tree, the indexing will need to be refreshed. This is simply done by clicking the ‘Repair Integration’ icon. In such situations where your config ‘index’ is mis-aligned, the configuration validations that run in the background and that flag config error warnings may flag warnings related to configuration issues that have been resolved. Using the ‘Repair Integration’ tool will clear such Warnings.
Search Integration Tool
The ‘Search’ tool at the top right of the Integration ‘tree’ is used to search and will retrieve matches from:
– The transaction code, the flow code.
– The parameter label, the parameter name, and the attribute name.
– The derived parameter label, the derived parameter name, and the derived parameter body.
– The static parameter label, the static parameter name, and the static parameter body.
– The handler label, and the condition value if applicable. e.g. when the parameter equals a <value>
– The value mapping.
– Any text in the request/response templates.
– Case is not considered, so if you search for something in capital letters both capital and lowercase will be found. As the font ‘case’ is not used for the search, the results will be displayed in Capital letters. For example, when searching for ‘response’ the results will be displayed as per the below screen
The search results appear as follows:
