The Integration Builder is used to configure the APIs of 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. GLU.Ware can validate a Request and collate the required data from different systems to complete it. 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 Endpoint are transformed or ‘un-marshalled’ into a GLU ‘Object-Model’ that is persisted for the duration of an individual transaction only. It is 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 a transaction that the GLU.Engine processes. GUIDs are 128 bits long, allowing for many unique values. The GUID is labelled as the GLU_TXN_ID in the GLU.Engine logs. The GLU_TXN_IDs are useful when one is tracing transactions in the logs. The use of GUIDs ensures that each transaction with its associate Transaction Code has a unique identifier. 

The ‘Repair Integration’ Tool

The ‘Repair Integration’ tool at the top right of the Integration ‘tree’ is used to re-index the full tree structure of your integration. 

In the event 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 misaligned, 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 retrieve matches the flowing information: 

• Transaction Code and Flow Code: Transaction Code: Unique string identifying each transaction, often reflecting the configured API service (e.g., ‘BalanceEnquiry’). Flow Code: Unique identifier assigned to each leg within the orchestration, aiding in routing transaction flows to specific steps.  
• Parameter Label, Parameter Name, and Attribute Name: Parameter Label: Descriptive label for a parameter. Parameter Name: Unique identifier for the parameter. Attribute Name: Specific attribute associated with the parameter.  
•  Derived Parameter Label, Derived Parameter Name, and Derived Parameter Body: Derived Parameter Label: Descriptive label for a derived parameter. Derived Parameter Name: Unique identifier for the derived parameter. Derived Parameter Body: The content or value associated with the derived parameter.  
• Static Parameter Label, Static Parameter Name, and Static Parameter Body: Static Parameter Label: Descriptive label for a static parameter. Static Parameter Name: Unique identifier for the static parameter. Static Parameter Body: The fixed content or value associated with the static parameter.  
• Handler Label and Condition Value (if applicable): Handler Label: Descriptive label for a handler. Condition Value: Value used in conditions, for example, when the parameter equals a specified value.  
• Value Mapping: Mapping of values between different parameters or components.  
• Text in Request/Response Templates: Any textual content present in the request or response templates.  

Note: Case sensitivity is not considered during searches; results are displayed irrespective of the case used in the search. For instance, searching for ‘response’ will yield results displayed in capital letters as shown in the example screen.  

The search results appear as follows: