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.
All GLU HTTP connectors uses the HTTP4 component, which is a newer version of the Hypertext Transfer Protocol designed to enhance the performance, security, and scalability of web applications. It is built on the QUIC protocol, utilising UDP instead of TCP and supporting multiplexing, encryption, and congestion control.
HTTP Cross-Origin Resource Sharing
HTTP Cross-Origin Resource Sharing (CORS) is a mechanism in HTTP headers that enables a server to specify which origins, including domains, schemes, or ports, are allowed to access its resources. This is particularly important for web applications that need to interact with resources hosted on different domains.
In the context of GLU, where HTTP connectors are used, CORS support can be enabled to facilitate cross-origin requests. Here’s how you can configure CORS support in GLU:
Host Settings: Host settings represent the generic parts of the URL path, such as http://localhost:9088/services.
Context Names: Context names, configured in the Integration Builder, form the basis of outbound connector requests. These names typically include the host, port, and context name, resulting in a URL structure like {host}{port}/{contextName}.
Enabling CORS: To enable CORS support in GLU, add ?enableCORS along with allowed headers to the context name in the Integration Builder. This informs the server that cross-origin requests should be permitted from specified origins. There are two common configurations for CORS support:
Allow All Headers: Use ?enableCORS=true&filterInit.allowedHeaders=* to allow all headers from any origin.
Allow Specific Headers: Alternatively, specify specific headers to be allowed using ?enableCORS=true&filterInit.allowedHeaders= followed by a comma-separated list of header names.
By configuring CORS support in GLU, you ensure that your HTTP connectors can effectively handle cross-origin requests, thereby enabling seamless interaction between different domains and resources.
Properties
The Properties Tab is where Protocol specific Properties are defined. There are no HTTP or REST specific properties so these options are not applicable for such Connector types. For other types such for a SOAP Connector, the SOAP Properties such as WSDL Location, SOAP Context Service name etc. will be presented.
OpenAPI 3.0 is the latest name given to the previous Swagger standard, the market however is still widely familiar with and using the term ‘Swagger’ to refer to OpenAPI 3.0 – as such GLU refers to the GLU.Ware OpenAPI 3.0 as ‘Swagger’. Swagger Specification and API document are used interchangeably. Details on the OpenAPI 3.0 Standard are available here.
GLU.Ware has the ability to generate a Swagger standard based API document to describe the APIs in the GLU.Engine. The API document is compiled in the build process. GLU uses the API configuration (as defined in the GLU.Console) to define the method, schema and structure of the API, and it pulls in the associated API descriptions configured by the analyst in the Integration Builder. The API document is included in the GLU.Engine build such that when the JVM is run a web service will also run to host the Swagger web page to render the API document.
The GLU.Engine Swagger File can be accessed through {Engine_URL}:{Server Port}/swagger. For example: http://mybankapi:9195/swagger
This will display the Open API 3.0 (Swagger) definition for the GLU.Engine APIs.
Download JSON for Swagger Specification
Included in the Swagger specification is a URL which can be used to download the full JSON for the swagger specification.
This JSON can be used to render the swagger definition in the GLU.Control API Manager and/or other swagger management tools.
Console API Control panel
The output of the API document generated by GLU will resemble the following sample.
The GLU.Console API Control Panel is used to configure the API document that will be generated.
The subsequent sections pertain to each of the labeled fields showcased in the API Control Panel screenshot provided above.
A – Swagger API Title
This is the title for the Swagger specification.
B – Swagger API description
This is the description of the API which should provide a description for all the API’s displayed on the Swagger specification and accessed in the GLU.Engine.
The format of this description is HTML.
See below for an example of the API description:
C – Swagger Contact email
This pertains to the contact details for the person responsible to support the exposed API, specifically the email address. Upon selecting this option on the screen, the associated email application will be triggered, and a new email will be created addressed to the provided email address.
D – Swagger API Terms of service URL
The URL to the terms of service for the API.
i.e. www.myorg.legalblurb.com
E – Swagger API Licence URL
The license information for the exposed API.
i.e. www.myorg.termsandSLA.com
F – Swagger Groups
On the Swagger specification it is possible to group API transactions into sections. To do this use the ‘Manage Swagger Groups’ tool.
In the screenshot below you can see how APIs are grouped based on their Swagger Group associations.
G – Manage Swagger Servers
It is possible to configure URL settings to point at the GLU.Engine which contains the API transactions defined in the Swagger specification, this provides the ability to use the web service hosted swagger specification to test each API transaction.
Request Parameters
If samples have not been included in the API transactions configuration, then GLU will generate a schema for the API Request and Response parameters based on the configuration API “body” Request and Response parameters.
The schema is based on Parameter Types.
The table below shows how the parameters are mapped to the Swagger specification.
GLU.Console Parameter Type
GLU.Console Parameter definition
Swagger definition
Generated in swagger
Text
minLength
string
Yes
Text
maxLength
string
Yes
Date
includes extra date format definition
string
Yes
Text
regex
string
Yes
Text
DEFAULT
string
No – default value isn’t included
Hash
string
Yes
Integer
integer
Yes
Image
image
Yes
Float
float
Yes
See below example from the Swagger specification with the mapping.
Show in Swagger Doc: For each transaction there is a tick box which can be used to indicate if a section in the swagger specification should be generated. Tick the box to include in swagger specification, un-tick the box to leave out from swagger specification.
Sample messages for the Request payload as well as Success and Failure Samples for the Response payload can be defined. These where provided will be included into the API Document. When the samples sections are filled in, then these will override the definition of the schema from the request parameters. Instead the value defined in the sample field will be pushed to the swagger specification.
In the Integration Builder, the process of adding transactions is facilitated through the ‘Transactions Panel.’ When you select ‘Add Transaction,’ the Integration Builder generates a standardized transaction ‘Pattern’ that is universally applicable to all transactions.
All GLU.Ware transactions adhere to this consistent and repeating ‘Pattern.’ Each transaction is structured or ‘anchored’ by the API definition, encompassing the Inbound API Request received from an Initiating System, followed by the API Response that the GLU.Engine sends back to that Initiating System.
The next step involves the use of the Orchestration Manager to specify the actions that the GLU.Engine should perform with the API Request payload upon reception. To enhance the orchestration configuration, the ‘Add Endpoint’ button can be utilized to incorporate different ‘legs’ into the configuration.
Note: This orchestrates the outgoing request in the applicable format expected by the third party being integrated to.
When you click the ‘Add Endpoint’, the configuration pattern for Outbound Connectors is automatically pre-populated. This approach guides users through the orchestration configuration by streamlining the input of necessary configurations for each Outbound Request and Response to the Endpoints that are included in the configuration.
At the bottom of all GLU.Console login screen the current version of the GLU.Console and the latest release date as shown. The history of GLU.Ware Release Notes since major Release 3.0 is provided below. The full history of Release Notes is available on request from GLU.Support.
We have introduced validation mechanisms to prevent the use of problematic characters, such as question marks, in Context Names. This enhancement ensures that such characters do not cause issues during the execution of GLU.Engine.
Example:
The character “?” is now disallowed in Context Names to maintain system integrity and prevent errors.
GLUW-4438 Enhancement: Multi-Client Access within a Group
We have implemented several key enhancements to allow users to manage multiple Clients within a Group using the same email address. This includes the ability to create distinct ‘Sandbox’ or ‘Training’ Clients, separate from those used for ‘real’ configurations.
Bug Fixes
GLUW-4449 FINCA UG – Addressed error in GLU.Engines with Handlers working from XML connectors and added a retry handler to the transaction with a STOP PROCESS.
GLUW-4465 Addressed issue created in Release 4.0.0 with swagger generation.
GLUW-4542 Addressed an error in build manager where under certain scenarios when Managing the SDLC adding an environment would fail.
GLUW-4543 Addressed error in build manager when adding a build without an Integration version did not highlight that version is Mandatory.
GLUW-4544 Addressed an error in build manager where under certain scenarios when deleting a build an error occurred.
GLUW-4260 Address issue when a connector in an orchestration is excluded it was still be included in the validation and affecting the running of the GLU.Engine.
GLUW-4418 In the Build Manager we have made hot links to the integration from the build manager screen and the download screen. See below.
GLU.Ware – Release 4.0.1 – Released: 01 May 2024
GLUW-4433 – Provide the ability to view Health Checks on an inbound connectors for a GLU.Engine and for all Outbound Connectors the GLU.Engine orchestrates.
The above Release was reversed due to issues with inbound connectors not working.
GLU.Ware – Release 4.0.0 – Released: 02 April 2024
Major Feature Enhancements
GLUW-2561 Java Upgrade from Java 8 to the Latest Long Term Support Version- 17 Java 17 Long Term Support introduces:
Enhanced Performance
Improved Security
Up to date Community and Resources
Choose between versions in the Build Manager:
Both Java 8 and Java 17 GLU.Engines can be built in the Console.
Java 8 will continue to be supported until the end of June 2024.
From July 2024 the option to build for Java 8 will be removed from the Console.
GLUW-4291 We added the ability to Load Swagger (Open API 2/3) into the integration to Generate Inbound APIs and Outbound Connector. This feature can generate individual inbound APIs or multiple APIs, if all the transactions defined in the Swagger file are consumed.
Generate Inbound API
Generate Connector
Minor Feature Enhancements
GLUW-4464 We have added a function to add dynamic URL within an array. This can be used within a handler through the `CHANGE_PARAMS_VALUE_IN_ARRAY` function, which will allow a parameter values in an array.
GLUW-4444 We corrected an error where when ContentType format is text/xml arrays are passed as JSON rather then XML.
GLUW-4450 We enhanced the functionality to allow for the creation of a request body with a dynamic structure for an orchestration with optional parameters.
GLUW-4461 We identified an anomaly where throttle type 2 would not apply. For more information on throttle type 2 please refer to throttle type 2
GLU.Ware – Release 3.5.0 – Released: 13 December 2023
Minor Feature Enhancements
GLUW-4291 In Integration Builder in BETA state we have added the functionality to load a swagger OPenAPI 2.0 file and from this generate the outbound connectors
GLUW-4318 We have introduced the ability to accommodate invalidate JSON structured if they follow this format. Where line values which are repeated will go into an array of line.
GLUW-4286 In the integration builder we have made a change to cater for two response templates in the response back.
GLUW-4308 In the integration builder we have added a search box for Integration Builder drop down.
GLUW-4344 In the GLU.Engine we have added a new feature to ignore unescape json payloads.
Bug Fixes
GLUW-2833 We corrected an issue introduced in the GLU.Engine in Release 3.0.1 where requests for Route to Many based On Param Handler were failing intermittently.
GLUW-4304 We corrected an issue with USSD Menu Builder where the handlers were not visible.
GLUW-4320 We corrected an issue where the GLU.Engine was not handling the response correctly.
GLUW-4366 We corrected an issue where in the integration builder Handlers and Parameters were unset or changed between configurations.
GLUW-4372 In the GLU.Engines we corrected an issue with Handlers which under certain circumstances were not triggering when using the EQUAL Condition.
GLUW-4378 Further update fixes in integration builder to xml to json conversion feature.
GLU.Ware – Release 3.4.0– Released: 1 December 2023
Bug Fixes
GLUW-3921 In Integration builder we corrected an issue where it was not possible to format/generate parameters from XML payload in Console.
GLUW-2048 In GLU.Engine we corrected an issue where the value returned for a date/time was formatted differently based on where in a template they positioned. It meant you could get either of these formats “2020-11-30T10:05:30” or “27/11/2020“, now it is always “2020-11-30T10:05:30“.
GLUW-3594 We addressed an issue with the XML to Json converter in the integration builder.
GLUW-4305 We fixed an issue with USSD where with Menu handler routing from one menu set into another the menu set was going directly into a prompt.
GLUW-4149 In Integration builder we identified missing functions in the predefined functions list and corrected them.
GLU.Ware – Release 3.3.0 – Released: 13 November 2023
Minor Feature Enhancements
GLUW-2613 In the GLU Engine Settings in Build manager we made the labels more descriptive. i.e. we indicated Max history value needs to be in days.
GLUW-3351 We have enriched the Build Error Messages.
GLUW-3884 Refined GLU.Engine meta data in logs to make more meaning full.
GLUW-4007 Added a New Function to Calculate ISO Field length and length of length to create described ISO Field.
GLUW-4243 Expanded documentation in GLU.Guide on ISO8583 – JPOS ignoreISOExceptions.
Bug Fixes
GLUW-4254 ISO issue with Compilation errors on q2 logs
GLUW-2373 Static Parameters: Action Cannot be empty
GLUW-3321 Errors in the logs – [array[]] is an ARRAY and Source: [trxArray[]] is a CLASS
GLUW-4063 What’s the char limit for Release Note? | RN special char | RN overwriting
GLUW-4163 If in full screen mode (button to right of XML JSON Converter) no popups show at all.
GLUW-4178 Build Manager: GLU.Engine Name missing from Download popup
GLUW-4251 Fixed a problem where a GE doesn’t start when its has 2 trx and each has scheduler
GLUW-4258 Addressed minot issue with the UX for Derived Parameter Management | Add Parameter Prompt
GLU.Ware – Release 3.2.0– Released: 1 November 2023
Minor Feature Enhancements
GLUW-4227 We created a new vendor specific application/json content type (PRAGMA)
GLUW-4175 We added the ability to in Global Variables to be able to specify if Global Variable is a String or Numeric value.
GLUW-4130 In the Scheduled function in the Integration builder, we have completed work on the Cron function. It is now possible to Schedule an API to trigger based on a Cron function We have moved the C switched on the Cron feature in the Schedule.
GLUW-4143 We have introduced a new feature to allow for a variable retry count in a response handler.
Bug Fixes
GLUW-4224 Setting the Password for a Redis connector needed to be fixed.
GLUW-4100 In Integration Builder we have optimised the screen responsiveness.
GLUW-4180 Getting error when we Build changes | No error in Repair for missing route To FlowCode
GLU.Ware – Release 3.1.0– Released: 1 October 2023
Major Feature Enhancements
GLUW-2077 GLU.Engine Configuration Control Multi-Environment support
We have introduced a new feature in the GLU.Engine aimed at addressing a potential risk associated with testing and deploying the engine in production environments. This release focuses on providing a solution that allows for direct changes to the GLU.Engine without requiring a complete rebuild, reducing the possibility of introducing untested modifications.
Key Changes and Enhancements:
Exposed a set of configuration files within the GLU.Engine system. Configuration files can be found in the “../engine/config/” directory.
List of Exposed Configuration Files:
application.yml
camel-context.xml
flows.json
iso8583
loggingSetting.xml
menu.json
By exposing these configuration files, system administrators and developers gain direct access to the GLU.Engine’s core settings. This enables them to make necessary adjustments without the need for rebuilding the engine, mitigating the risk of introducing untested changes during production.
We believe that this enhancement will significantly improve the flexibility and efficiency of managing the GLU.Engine system. Users can now make targeted modifications to the engine’s configuration files as needed, ensuring a streamlined development and deployment process.
Please note that any modifications made to these configuration files should be carefully tested and reviewed before deploying them in a production environment.
For more information on how to utilise and modify the exposed configuration files, please refer to our support team.
Minor Feature Enhancements
GLUW-3888 We have added a timestamp on the dialogue box for the application settings, so it is possible to see when the last change to these settings was made.
GLUW-3308 Further enhancements to the automatic generation of Swagger exposed on the SERVER PORT under the URL /swagger. Please note that the Swagger documentation remains compliant with the OpenAPI 2.0 specification. For more information on this please refer to Swagger – OpenAPI 3.0
GLU.Ware – Release 3.0.3 – Released: 22 February 2023
Major Feature Enhancements
GLUW-3019 We have refreshed the GLU.Guide and removed the requirement to access the GLU.Guide through a username and password so that it is available publicly to view. We have also enhanced the GLU.Console to provide a small window in the bottom corner which allows for a quick Guide assistance ‘in Console’. The old version of the GLU.Guide will be shutdown. The new Guider can be accessed on this link.
Minor Feature Enhancements
GLUW-3019 We have refreshed the GLU.Guide and removed the requirement to access the GLU.Guide through a username and password so that it is available publicly to view. We have also enhanced the GLU.Console to provide a small window in the bottom corner which allows for a quick Guide assistance ‘in Console’. The old version of the GLU.Guide will be shutdown.
GLUW-3869 We have added a new function CURRENT_NANO_TIME that returns the current time in nanoseconds.
GLUW-3870 We have standardise GLU Functions to be capital letters. However old lowercase syntax will also be supported.
GLUW-3878 We have updated the standard GLU Function formats to align the formats. Old formats will still be supported.
GLUW-3928 We have updated the ThrottleType 2 feature to support calling other APIs in the Integration, in addition to the existing functionality to call an orchestration Flowcode.
GLUW-3932 We have created a new function which will create a new GUID called GENERATE_GUID.
Bug Fixes
GLUW-3391 We have updated the DB Connector responses to make the Content-Type default to JSON.
GLUW-3502 We have removed the old ISO8583 Version from the GLU.Console.
GLUW-3775 We have addressed an anomaly related to deleting environments and how this is presented in the Build Manager.
GLUW-3821 We addressed a problem with copying Handlers from one transaction orchestration to another.
GLUW-3905 We fixed a problem where a large orchestration took a long time to delete.
GLU.Ware – Release 3.0.2 – Released: 19 January 2023
Minor Feature Enhancements
GLUW-3823 We have improved the response time to respond on an error, when a Docker container is pushed to a remote Docker repository.
Bug Fixes
GLUW-3814 Fixed the Context Name which didn’t allow a forward slash (/).
GLUW-3821 We fixed a copy/paste issue in the Integration Builder which was not working correctly for some fringe case scenarios.
GLUW-3871 We fixed the Paste button which was not being set correctly after a Derived Parameter was deleted.
GLUW-3875 Corrected an issue identified with Throttle Type 2 controls. Please contact support for more information if required on this fix.
GLU.Ware – Release 3.0.1 – Released: 7 December 2022
Major Feature Enhancements
GLUW-3639 We have added support for a new connector type. We now support GraphQL for outbound connections, for more information on this new connector type please refer to GraphQL Connectors.
GLUW-3764 We have also added the ability to generate automatically a Swagger (OpenAPI 3.0) Specification for the APIs in the GLU.Engine. For more details on how to configure your APIs so the descriptions, sample messages, and other ‘meta data’ about your APIs appear on the Swagger document please refer to Generate OpenAPI 3.0 (Swagger).
Minor Feature Enhancements
GLUW-1267 We in the process of enhancing our functionality related to the GLU.Engine’s ability to schedule (‘self-invoke’) API calls. This is the first ‘BETA’ release of this functional enhancement journey. The GLU.Guide will be updated to reflect these exciting new capabilities when they are fully released – no long ‘BETA’.
GLUW-1693 We have updated the GLU.Console to allow a single user to login multiple times. We believe this will help address the issue experienced by some users when a user’s session gets locked. In the roadmap we plan to add the ability to integrate the GLU.Console with 3rd party single sign-on services.
Bug Fixes
GLUW-3786 In the integration manager we fixed a problem with the description of a transactions where it looked like it was being duplicated across from one transaction to the next.
GLUW-3790 Fixed a problem with the ‘Search’ tool in the Integration manager, where it wasn’t truly accurate with what it found.
GLUW-3793 Fixed a problem in the integration manager in the orchestration connectors where the ‘Context Name’ would disappear when one deleted a character from the field.
GLU.Ware – Release 3.0.0 – Released: 20 October 2022
Major Feature Enhancements
GLUW-3316 We have updated all areas of the GLU.Console with a new look and feel. In some areas we have optimised positioning and utilisation of menus and buttons which we believe will improve the speed of creating integrations and USSD menus.
GLUW-3607 We have added a landing page from where you can quickly access latest integrations which have been worked on by every user in your organisation. It also provides quick access to key areas of GLU.Ware.
Minor Feature Enhancements
GLUW-3549 We have ratified AWS Elastic container register (ECR) for storing docker containers, See AWS ECR configuration.
GLUW-3551 Updated the Docker Settings as Password was limited to 255, we changed to support length ion 5000 characters. Specifically for AWS Elastic container service.
GLUW-2860 We have removed the “Jolokia Config Debug” from the GLU.Engine Settings Dialogue box.
Bug Fixes
GLUW-3631 Fixed ISO8583 issue caused when Connected state=false when trx is working. Should show =true if it’s connected.
GLUW-3630 Fixed issue when the ISO8583 log only shows request if there’s a response. Updated to always show both and print in order.
GLUW-3627 Connector Screen loads all Connectors.
GLUW-3591 Fixed issue with Invalid Node Description which is needed for ISO8583 field settings.
GLUW-3584 Fixed issue with generate parameters resulting in an invalid template warning & invisible template gets used.
GLUW-1614 Fixed an issue where repairing integration was breaking the Handler Routes None >> Many Request Handler.
GLUW-1140 Updated Request as Error messages was needed for mandatory ISO8583 fields (MTI etc.).
GLU.Ware – Release 3.0.0.1 Fixes
GLUW-3720 We found that the GLu Console had a bug in it which was stopping the USSD Simulator from connecting the test USSD GLU.Engines in clients environments.
GLUW-3719 We found an issue with the latest release in respect to Throttle Type 2: Concurrent Requests using Thread Pools GLU.Engine would error when “Max Queue Size” was passed as 0. This has been corrected.
What is GLU’s recommended approach to Integration Projects?
The GLU team has collectively over 100+ years of Enterprise Level integration experience, the GLU methodology summaries our best practice recommendations to Integration Projects.
What is the GLU V-Model of Testing?
Since GLU.Ware is a no code system, there is no need for developers. Thus the ‘traditional’ V-Model of testing is ‘truncated’ as it is the Analyst who will configure and build the integration Engines. This means that there is no need to wait for a typical 2-week sprint cycle before the Analyst can test the integration. Rather, with the GLU V-Model, Analysts can iterate through the Configure, Build, Deploy, Test cycle within minutes. This is what enables GLU.Ware users to Innovate at Speed.
What is the GLU Configuration Cycle?
The process an Analyst using GLU.Ware will follow entails cycling through the Configure, Build, Deploy, Test cycle as depicted below. This process can be conducted multiple times a day, some cycles can be as short as a few minutes. This is what drives the ability to Innovate at Speed.
GLU Support
How do I log a GLU Support ticket?
Log GLU Support tickets here: GLU Support Desk … other guidance on the GLU Support process can be found here.
How do I log a GLU.Engine Performance related Support Ticket.
To help GLU.Support to resolve issues expediently, the more detail you can share about your issue or question the better. This applies particularly to throughput / performance related Support Tickets. Details on how to log such tickets are provided here.
What is the purpose of logging tickets through the GLU.Ware Support Desk?
The purpose is for formal tracking of Support Tickets from logging to resolution for management and SLA compliance.
Can all users access the GLU.Ware Service Desk?
GLU.Ware Trained Users have been registered on the GLU.Ware Service Desk. Additional Users can be registered on request.
How can I register additional users to the GLU.Ware Service Desk?
Raise a Technical Support ticket to have additional users registered.
What type of ticket should I log for new GLU.Ware feature requests or suggestions?
Log a Suggest a Feature ticket for new GLU.Ware feature requests or suggestions.
What type of ticket should I log for broader suggestions to improve the way of working?
Log a Suggest Improvement ticket for broader suggestions to improve the way of working.
GLU.Ware Updates
Where can I find the Release Notes for GLU.Ware?
See the Release Notes page, this is updated with a new Release Note every time there is any update to GLU.Ware. Where updates impact the User Experience, those are also documented in the GLU.Guide.
ACK stands for “Acknowledgment” and is a signal used to indicate that a packet of data has been received successfully and can be used to confirm the receipt of a transmission. See the converse of ACK which is NACK
ACL
An ACL (Access Control List) is a list of permissions that define who or what is allowed to access specific resources within a system, such as files, directories, or network services. It is used to enforce security policies and prevent unauthorized access.
AML
AML (Anti-Money Laundering) refers to a set of laws, regulations, and procedures aimed at preventing money laundering, which is the process of disguising illegal proceeds as legitimate funds. AML systems monitor financial transactions for suspicious activity and help identify and prevent money laundering.
API
An API (Application Programming Interface) is a set of rules and protocols for building software applications that allows for communication between different systems. APIs allow different systems to exchange data and information, enabling integration and automation of processes.
AWS
Amazon Web Services
B
BI
Business Intelligence
C
CLI
Command Line Interface
D
DES
Data Encryption Standard
DMZ
A DMZ (Demilitarized Zone) is a network security concept where a small, secure network segment is placed between a secure internal network and an insecure external network (e.g. the internet). The DMZ acts as a buffer zone, allowing for secure communication between the internal and external networks while isolating and protecting sensitive internal systems from external threats.
DNS
Domain Name System
F
FTP
File Transfer Protocol is a standard network protocol used for transferring files between computers over the Internet or a local network.
H
HA
High Availability
HTTP
Hyper Text Transport Protocol
HTTPS
Hyper Text Transport Protocol Secure
I
IP
Internet Protocol
IPSec
Internet Protocol Security
iPaaS
iPaaS (Integration Platform as a Service) is a cloud-based platform that provides tools and infrastructure for connecting and integrating applications, data, and processes across multiple systems. iPaaS enables organisations to easily integrate their systems without the need for complex and costly on-premise integration solutions.
J
JAR
A .JAR (Java ARchive) is a package file format typically used to aggregate many Java class files and associated metadata and resources (text, images, etc.) into one file for distribution.
JSON
SON (JavaScript Object Notation) is a lightweight data-interchange format used for exchanging structured data between systems. It is easy to read and write, making it a popular choice for integration between systems, particularly in web-based applications. JSON supports multiple data types, such as numbers, strings, arrays, and objects, making it a versatile format for exchanging data between systems.
L
LAN
Local Area Network
M
MNO
Mobile Network Operator
MSISDN
Mobile Station International Subscriber Directory Number – this is simply a technical term for a mobile phone number.
N
NACK
NACK stands for “Negative Acknowledgment”. In computer networking, NACK is a signal used to indicate that a packet of data has not been received or has been received with errors and needs to be retransmitted. See the converse of NACK being ACK,
O
OWASP
OWASP (Open Web Application Security Project) is a non-profit organization dedicated to improving web application security. It provides guidelines, tools, and resources for developers and security professionals to help prevent and mitigate common web application security threats, such as SQL injection, cross-site scripting, and other security vulnerabilities.
P
PA-DSS
Payment Application – Data Security Standard
PCI-DSS
Payment Card Industry – Data Security Standard
POC
A POC (Proof of Concept) is a demonstration of the feasibility and potential value of a system integration project. GLU will often use a POC exercise to demonstrate how GLU.Ware will meet a potential customer’s requirements and solve their business problems. POCs are often used in the early stages of the GLU sales process to help secure customer buy-in and can help to de-risk a project before full implementation.
R
RDS
Relational Database Service
REST
REST (Representational State Transfer) is an architectural style for building web services that allow for the exchange of information between systems. REST uses standard HTTP methods, such as GET, POST, PUT, and DELETE, and uses a URL to identify resources and actions. REST is a popular choice for system integration due to its simplicity, scalability, and compatibility with a wide range of programming languages and platforms.
S
SAML
Security Assertion Markup Language
SFTP
SSH File Transfer Protocol
SIT
System Integration Test – typically a stage in the SDLC when all Test End Points are available and the full Test cycle covering all Test Cases can be tested.
SMTP
Simple Mail Transfer Protocol
SOAP
SOAP (Simple Object Access Protocol) is a messaging protocol used for exchanging structured data in the implementation of web services. It defines a set of rules for encoding messages in a format that can be transmitted over a network, allowing systems to communicate and exchange information in a standardized way.
SSH
Secure Shell
SSL
Secure Socket Layer – in system integration, SSL is used to encrypt sensitive information during transmission, protecting it from eavesdropping and tampering. SSL has been replaced by its successor, TLS (Transport Layer Security), which provides equivalent security and is widely used to secure web communications and other networked applications.
SSO
SSO (Single Sign-On) is a security mechanism that allows users to access multiple systems using a single set of credentials. In system integration, SSO can simplify the user experience and improve security by eliminating the need for multiple usernames and passwords, reducing the risk of forgotten or weak passwords, and centralising the management of user accounts. SSO can be achieved through various methods, such as federation, smart card authentication, or shared session cookies.
T
TCP
Transmission Control Protocol
TLS
Transport Layer Security
TPS
Transactions per second
TPS
TPS (Transactions Per Second) is a measure of the number of transactions processed by a system in a given second. It is a commonly used metric for evaluating the performance and capacity of a system, particularly in the context of database systems, payment systems, and other systems that process a large number of transactions.
TTL
TTL (Time-to-Live) is a value used in computer networking to limit the lifespan of data in a network. It helps prevent data from circulating indefinitely by setting a maximum number of hops that a data packet can traverse before being discarded. This is important in system integration to ensure the reliability and efficiency of data transmission in a network.
V
VM
A VM (Virtual Machine) is an abstraction layer that enables multiple operating systems to run on a single physical machine. In DevOps, VMs are commonly used to create isolated, reproducible environments for software development, testing, and deployment, allowing teams to develop, test, and deploy applications without affecting each other’s work. VMs also provide scalability, flexibility, and ease of management, enabling teams to quickly spin up new environments, scale resources on demand, and automate the deployment and configuration of infrastructure.
VPN
Virtual Private Network
W
WAR
A .WAR file (Web Application Resource or Web application ARchive) is a file used to distribute a collection of JAR-files, JavaServer Pages, Java Servlets, Java classes, XML files, tag libraries, static web pages (HTML and related files) and other resources that together constitute a web application.
X
XML
XML (eXtensible Markup Language) is a markup language used for encoding structured data for storage and exchange between systems. It provides a flexible and human-readable way of representing data that can be processed by computers, enabling systems to exchange information in a standardized way.
XSS
XSS (Cross-Site Scripting) is a type of web security vulnerability that allows attackers to inject malicious code into a website, compromising the security of users who visit the site. In system integration, XSS can occur when data from one system is integrated into another system without proper input validation or sanitization, allowing an attacker to inject malicious scripts into the integrated data. XSS attacks can steal sensitive information, such as cookies or login credentials, or perform malicious actions, such as injecting malware or redirecting users to phishing sites.
Y
YAML
The application.yml file is a configuration file used in the GLU.Engine to define settings and parameters for the application. It typically contains information such as database connections, environment-specific configuration, and settings for components and routes that have been configured into the GLU.Engine. The file is written in YAML format, which is a human-readable, data-serialization format. The settings in the application.yml file provide the necessary information for it to run correctly.
An API Gateway points to backend APIs and services and abstracts them in a layer that can be managed by the API Manager agent. Consumer applications that invoke your services and APIs are routed to the endpoints exposed by the gateway, enforcing runtime policies while collecting and tracking analytics data. The API Gateway separates management from implementation concerns for all your backend services and APIs. It also allows you to take advantage of the governance capabilities of the GLU.Engine APIs, such as applying policies, enforcing security, and managing contracts.
API Manager
An API Manager is a software platform that provides centralised management and governance for APIs (Application Programming Interfaces). An API Manager typically provides functionalities such as: API documentation and discovery, API security and access control, API versioning and lifecycle management, API analytics and monitoring, API monetisation and billing. GLU’s API Manager component is part of GLU.Control.
Audit History
The activities of users of the GLU.Console are logged so as to generate an Audit History on each GLU.Engine.
Authentication
Authentication is the process of verifying the identity of a user or entity. In other words, it is the process of proving that a user is who they claim to be. Authentication can be done using various methods, such as passwords, biometrics (e.g., fingerprint, face recognition), or smart cards. The purpose of authentication is to ensure that only authenticated users have access to sensitive resources.
Authorisation
Authorisation, on the other hand, is the process of granting or denying access to resources or services. Authorisation is based on the identity and permissions of the user or entity. Once a user has been authenticated, the system checks their permissions to determine whether they are authorised to access the requested resource or perform the requested action. For example, a user may be authenticated but only authorised to view certain files or perform certain tasks.
B
Build Manager
The tool used to manage the build process associated with your GLU configuration. The Build Manager produces the GLU.Engine.
C
Citizen Integrators
A domain specialist without a programming background, who can use tools (and not code) to integrate and extend business software applications. The complexity of such integrations is typically limited. With GLU.Ware the Enterprise Innovator is empowered to handle the more complex integration scenarios.
Connector
Any interface (inbound or outbound) attached to a GLU.Engine. Inbound Connectors are APIs.
D
Data Silo
A data silo is a situation wherein only one group in an organisation can access a set or source of data. An in-person example would be when several departments or groups within that organisation do not want to share information or knowledge with other individuals they work with.
DevOps
The combination of cultural philosophies, practices, and tools increases an organisation’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organisations using traditional software development and infrastructure management processes.
Docker Container
A Docker Container is a lightweight, stand-alone, and executable software package that includes everything needed to run a piece of software, including the code, runtime, system tools, libraries, and settings. Docker Containers can be used to package and distribute GLU.Engines, allowing teams to consistently deploy the same GLU.Engine across multiple environments, providing consistency and reproducibility in the development pipeline. Docker Containers also provide isolation, making it easier to manage dependencies and reduce the risk of conflicts, and ease of management, making it easier to automate the deployment and scaling of applications.
E
ERP System
Enterprise resource planning systems refer to a type of software that organisations use to manage day-to-day business activities such as accounting, procurement, project management, risk management and compliance, and supply chain operations. Examples being Microsoft Dynamics, SAGE, Oracle e-Business Suite
ETL
Extract, transform, load type of data integration that refers to the three steps (extract, transform, load) used to blend data from multiple sources.
End Point
Any system that talks to the GLU.Engine be it a Source system or a Target system or where the GLU.Engines handle the exchange of messages between these systems. End Points interface with GLU.Engines via an Inbound Connector exposed on a GLU.Engine and any downstream system that is uniquely identified by it’s host details (unique IP Address and Port combination or URL) to which a GLU.Engine connects
Enrichment
The ability for a GLU.Engine to itself add to a message payload being handled for example to create a timestamp upon receipt of a message that can then be used later on in the flow.
Enterprise Innovator
A persona ‘coined’ by GLU that describes GLU.Ware users. With GLU.Ware, users are empowered to bring the ability to drive Enterprise grade innovation programs that are founded on complex integration scenarios and orchestrations. The Enterprise Innovator is the next generation beyond the realms of the ‘Citizen Integrator’ (the persona coined by Gartner in ~2018 that puts the ability to integrate systems into the hands of the ‘Citizen’ – in GLU’s view, these integration scenario’s however are typically simple in nature).
Enterprise Service Bus
An Enterprise Service Bus (ESB) is a software architecture model with a set of rules and principles for integrating applications. In Service Oriented Architecture (SOA), an ESB replaces point-to-point integration, and ESB products enable users to build this type of architecture.
Enterprise System / Software
A software solution that provides business logic and tools to model entire business processes for organisations to improve productivity and efficiency. Examples include billing systems, customer relationship management systems and supplier relationship management systems.
F
Flowcode
Unique label used in the GLU.Console Integration Builder to identify each step in a Transaction flow. Flowcode’s are used by Handlers to identify orchestration endpoints and redirect the flow of a transactions.
G
GEAR
Refers to GLU.GEARs – an acronym for GLU Ecosystem AcceleRators – being value add business solutions that are build on top of the GLU.Ware integration framework.
GLU.Console
The Configuration User Interface used to configure GLU.Engines – their Connectors, Orchestrations, and to manage the SDLC and Build Process. It is also used to access the Configuration UI for GLU Value Added Services such as GLU.USSD
GLU.Engine
Configured in the GLU.Console, then downloaded and used by the Customer for the provision of the required Integration or associated VAS services.
GraphQL
GraphQL is a query language and runtime for APIs. It was developed as an alternative to REST and SOAP, two of the most commonly used API protocols. Unlike REST, which exposes a large number of endpoints for each resource, GraphQL exposes a single endpoint and allows clients to specify exactly what data they need.
H
Handler
Used to define routing rules within the flow of each transaction. Handlers can be attached to any received API Request or received Response from an outbound connector. There is no limit to the number of Handlers one can attached to any such received payload. Handler logic runs sequentially i.e. in the order that the Handlers are configured unless a Handler rule is processed to change the route.
I
IaaS
Infrastructure as a service is a cloud-based service, pay-as-you-go for services such as storage, networking and virtualisation. Examples being – DigitalOcean, Linode, Rackspace, Amazon Web Services (AWS), Cisco Metapod, Microsoft Azure and Google Compute Engine (GCE).
Integration Builder
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. More detail here.
J
JSON
JavaScript Object Notation is a standard text-based format for representing structured data based on JavaScript object syntax. Used for transmitting data in web applications for example sending some data from the server to the client so it can be displayed on a web page.
Jmeter
Apache JMeter is a popular open-source tool used for performance testing. It is primarily used to test the performance and scalability of web applications, but it can also be used to test other types of applications, such as databases, FTP servers, and more. It is a is a tool that allows testers to simulate a high number of users accessing an application and to measure the application’s performance and scalability under load.
K
Key Management
Key Management is the process of generating, distributing, and securely storing cryptographic keys used for encrypting and decrypting sensitive data. It is a critical component of system security, ensuring that sensitive information is protected during transmission and storage. Effective key management helps to prevent unauthorized access and ensures the confidentiality, integrity, and authenticity of sensitive information.
Keycloak
GLU.Control uses Keycloak, it is an open-source identity and access management (IAM) system, developed by Red Hat. It provides a centralised solution for managing user authentication, authorisation, and security policies across multiple GLU.Engine API’s that are managed within GLU.Control. Keycloak supports various identity protocols, including OpenID Connect, OAuth 2.0, and SAML 2.0. It provides a web-based administration console for managing users, roles, permissions, and security policies, and also supports features like single sign-on (SSO), social login, two-factor authentication, and user federation. With Keycloak, GLU Analysts can add authentication and authorisation capabilities to their GLU API’s without having to implement these features themselves. This can help save time and reduce security risks, as the GLU.Engine can rely on Keycloak’s proven security mechanisms. Keycloak is available under the Apache License 2.0, which means it can be used and modified freely without any licensing fees. It has a large and active community of users and contributors, who provide support and contribute to the ongoing development of the project.
L
Legacy Systems
In the context of computing, legacy systems are outdated computer systems, methods, technologies, or applications that are still used.
M
Mainframe
A high-performance computer, employed mainly in large organizations, capable of supporting high-volume, bulk data processing operations.
Marshalling
Marshalling refers to the process of transforming the representation of an object or data into a specific format that is suitable for storage, transmission, or communication between different parts of a computer program or between different systems. In a GLU.Engine, the transformed data is stored as a “marshalled” object in a ‘GLU object model’ and can be later transformed back into its original format (unmarshalled) for use or further processing.
Microservice End Point
Means an internal End Point / host, within the Client’s security domain (so no SSL or other security related handling required) that only serves one function or service and that is singular of purpose or ‘micro-service’ like, i.e. a single Request / Response message pair is involved and it uses JSON payloads only. For example a micro-service accessed via a JSON/REST API to verify the registration status of a MSISDN.
N
No Code
A no-code platform is a development platform that uses a visual development environment that allows anyone to create something. When it comes to TeamDynamix, our iPaaS solution uses a codeless visual flow builder with drag and drop functionality to create automated workflows.
O
OAuth 2.0
OAuth 2.0 is primarily used for authorisation, allowing an application to access a user’s resources on a resource server, without the user having to share their credentials (e.g., username and password) with the application. It provides a way for users to grant access to their data to third-party applications, such as social media platforms or productivity apps, without giving them full access to their accounts.
OAuth 2.0 is what OpenID Connect runs on, the difference is that OpenID Connect is just OAuth 2.0 with additional ‘Scopes’. Scopes are like permissions e.g. to make your email address or avatar or contacts available to the application.
OpenID Connect / OIDC
OpenID Connect, is built on top of OAuth 2.0 and provides an authentication layer on top of the authorisation protocol. It allows users to authenticate with a third-party application using their existing identity, such as a Google or Facebook account. This means that users don’t have to create new credentials for each application they use, and they can log in with a single click.
OAuth 2.0 is primarily used for authorisation, while OpenID Connect provides an authentication layer on top of OAuth 2.0.
Orchestration Manager
Within the Integration Builder use the Orchestration Manager section in ‘Green’ of the Transaction pattern to define the downstream Receiving System transaction step or steps for each transaction being configured. There is no limit to the number of receiving systems that can be addressed within the definition of a single transaction. More detail here.
P
Packager
Typically reference to a ‘Package’ refers to an ISO 8583 packager which is software or library that helps encode and decode data according to the ISO 8583 specification. ISO 8583 messages are structured into fields, with each field having a unique identifier and length. The packager is responsible for packing or unpacking these fields into a binary message format, which can be transmitted between systems over various communication channels.
The packager typically handles tasks such as validating input data, formatting the message according to the ISO 8583 specification, and handling any error conditions that may arise during the message processing. Overall, the packager provides a standardized way to encode and decode ISO 8583 messages, ensuring compatibility between different financial systems and networks.
Protocol Converter
A GLU.Engine is at it’s heart a Protocol Converter, it is a software component that is used to translate data between different communication protocols. It enables communication between systems that use different protocols, allowing them to exchange information and integrate their processes. Protocol converters play a crucial role in system integration by facilitating interoperability between different systems.
Q
Queue
A data structure that holds a collection of messages or requests that are waiting to be processed. In integration, queues are often used to buffer messages between different systems to ensure that data is processed in an orderly and controlled manner.
R
REST
Representation State Transfer (REST) is an architectural style that specifies constraints that if applied to a web service, induce desirable properties, such as performance, scalability, and modifiability, that enable services to work on the Web.
Roadmap
A technology roadmap is a flexible planning technique to support strategic and long-range planning, by matching short-term and long-term goals with specific technology solutions. Create roadmaps to plan out strategic technology initiatives in the future, for instance migrating to different software systems or rolling out software updates.DevOps RoadmapInfrastructure RoadmapSoftware Roadmap
S
SDLC Context Awareness
SDLC Context Awareness describes the ability for a GLU.Engine to embed within it all SDLC Environment specific details for each End Point / system being connected. Host details (IP/Port) and SSL credentials will often change when moving for example from a Test to a Production environment. The GLU.Engine Environments Tool along with the Connectors tool are used to define the GLU.Engine specific SDCL and all associated Connectors settings.
SOAP
Simple Object Access Protocol (SOAP) is a lightweight XML-based messaging protocol that specifies the exchange of information in the implementation of web services. SOAP messages are independent of any operating system or protocol.
Sandbox
An isolated environment on a network that mimics end-user operating environments. Used to safely execute suspicious code without risking harm to the host device or network.
Service Oriented Architecture
Service Oriented Architecture (SOA) is software architecture based on the creation of a repository of standardized and reusable services which can be composed into an aggregate service to automate a business process. This is known as service-orientation.
Software as a Service
Software as a Service (SaaS) is a way of delivering applications via the Internet as a web-based service. Access over the Internet means there is no need to download or maintain any software.
Spaghetti Code
Often referred to as “point-to-point integration”, spaghetticode is source code written without a coherent structure. Often custom integrations, these connections have no central way to monitor or troubleshoot. This is not effective for scaling given the tight dependency between applications.
Swagger
A set of tools for creating, implementing and describing a standardised RESTful API specification, known as Open API.
T
Transformation
The process of converting data from one format to another, typically from a source format to a target format, in order to facilitate data exchange and integration between different systems.
Transport Layer Protocol
A communication protocol that provides a standardised mechanism for transmitting data between systems, including features such as error checking, flow control, and data compression. Examples of transport layer protocols include TCP and UDP.
U
Unmarshalling
The process of transforming a data representation from a storage or transmission format back into an object in memory, typically as part of a system integration process. This is the reverse of the marshalling process.
V
Validation
Validation is the process of verifying that data meets certain requirements, such as accuracy, completeness, and consistency, before it is processed or stored in a system. This helps to ensure that the data is of high quality, reducing the risk of errors or inconsistencies in data processing and analysis. There are a varied of data validation rules that can be defined within the GLU.Console for each parameter being handled.
W
Web Services
A standardised way of facilitating communication between electronic devices and integrating Web-based applications over a network.
Webhook
One of the few ways web applications can communicate with each other and allows you to send real-time data from one application to another whenever a given event occurs. Anytime someone check-ins in, you’d be able to run any processes that you had in your application once this event is triggered. Use a webhook to connect a payment gateway with your email marketing software so that a user gets an email whenever a payment bounces.
X
XML
XML (Extensible Markup Language): A markup language used for encoding and exchanging structured data between systems. XML is often used as a data format for data integration and data exchange between different systems.
Y
YAML
YAML (Yet Another Markup Language): A human-readable data serialisation format used for data configuration and data exchange between systems.
Z
Zero-Code Integration
Zero-Code Integration – analogous to No-Code Integration, an integration approach enabled by GLU.Ware that allows users to connect and integrate different systems and applications without writing any code, using a visual interface and pre-built connectors.
SOAP (Simple Object Access Protocol) is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. It uses XML for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP). SOAP allows developers to invoke processes running on different operating systems to authenticate, authorise, and communicate using Extensible Markup Language (XML). Since Web protocols like HTTP are installed and running on practically all operating systems, SOAP allows clients to invoke web services and receive responses independent of language and platforms.
SOAP Properties
When configuring a SOAP Connector using the Connector tool, at Step 2, use the Properties Tab to specify the SOAP Properties for your Connnector:
SOAP Context Service: The Context Service uses context to express basic information about the activity. The context is identified using a URI.
NameSpace: From the WSDL – the targetNamespace
Service Name: From the WSDL – the wsdl:service
Port Name: From the WSDL – the wsdl:port
WSDL Location: Location of WSDL if not the same as the Host Environment. This could be put in a specific folder where the GLU.Engine will run. See note on ‘Use Host Environment’ below.
Use Host Environment: This is an important checkbox. Since the accessibility of the WSDL file is verified at GLU.Engine startup time, in the event of the WSDL file location not being accessible (e.g. due to a network / connection problem), the GLU.Engine will fail to startup. In order to avoid this issue, GLU recommends that the End-Point WSDL file is copied and saved locally within the /home/GLU/… folder on the GLU.Engine server. This path along with the filename should then be entered in the ‘WSDL Location’ field which can be edited when this ‘Use Host Environment’ box is unchecked. See screenshot below for an example.
If the wsdl requires the presence of xsd files, these xsd files should be placed in the GLU.Engine root/home folder e.g. GLU/endpointAServices-1.0/
If the End Point WSDL file is updated or changed, the local WSDL file will need to likewise be updated.
Integration Builder Usage
For a SOAP connector there is no option to change the Content Type. You can setup your template and use the parameter names and GLU placeholders for the parameters as for any other content type/connector i.e. using the GLU standard notation, “${parameterValue}”:
Note how the ‘msisdn’ value is being sent as the ‘phoneNumber’ parameter.
Give a unique Connector Name, this is the name you will see in the connector drop-down list in the Integration builder. Choose Connection Direction, for this example we will configure an OUTBOUND Connector. Select the required Protocol / Connector type from the Protocol list. Provide a Description about the end point which will be connected to.
Choose the Applications (GLU.Engines) that the connector you are creating will be made available to. In the interests of configuration efficiency, in this way as single Connector configuration can be used across any number of GLU.Engines. If you are working on a GLU.Engine that does not have this Connector associated with it, the Connector name will not appear in the Connector drop-down list in the Integration Builder.
Same Env. Host: This setting enables you to indicate that the SOAP WSDL is located in the same Environment as the Host (which is defined at Step 1). Ticking this will ‘grey-out’ the WSDL Location fields. Step 2.3 – SSL: This is where SSL Configuration properties are set for this Connector on the specified Environment. See *SSL Configuration for further detail.
Step 2: Connector Environment Settings
Here for each Environment (selected using the Environments Drop-down list) you need to define the Host Settings, Properties and if applicable the SSL configurations for the Connector. This is where the concept of SDLC Context Awareness comes to the fore. By specifying the Host Details for each Connector and for each Environment (as defined in your SDLC in the Environments Tool), you are ensuring that when you build a GLU.Engine for a specific Environment, it will embed within it all the Host details for the Endpoints applicable only to that stage of your SDLC.
Host Settings
To invoke ‘Step 2’ – click on the Step 2 – Connector Environments Settings button. Select the Environments, that the GLU.Engine will be running in and for each apply the Environment Specific Host Settings within the Host Settings Tab. Enter the URL or IP address for the Connector in the host field. If a Port is required, enter the port in the port field.
The port field defines the API port, which is used to provide access to an the API being configured, it is used to allow initiating systems to interact with the API. Note that this is different to the Server Port which is configured in the GLU.Engine Settings (General Tab) within the Build Manager tool (more detail on it here). The Server Port along with the IP address of the server or Virtual Machine the GLU.Engine is running on it used to access the actual GLU.Engine itself, this may be to access the JMX metrics or to access the GLU.Engine Management API’s.
These details will be embedded in the GLU.Engine at build time. Since these Host Settings are environment specific, when the GLU.Engine is set to a specific Environment e.g. ‘PRE-PROD’ in the example below, the GLU.Engine will direct outbound traffic routed through your connectors to the destinations defined by these Host Settings for the PRE-PROD stage of your SDLC.
For Inbound Connectors, specify the URL / Host internal IP and Port of the server that the GLU.Engine will run on for the specified Environment. For the Inbound connectors both host and port are required. Note that if you set this Host to IP address ‘0.0.0.0’ your GLU.Engine will be able to run on any machine, to tighten control of your GLU.Engines though it is recommended that you specify the INTERNAL IP address that the GLU.Engine will be running on in the Host field, doing so means that the GLU.Engine cannot start on any machine that does not use that specified internal IP address. For testing purposes, one can also use ‘localhost’ as the Host which will enable the GLU.Engine to run on your local machine.
For Outbound Connectors, the URL / Host IP and Port will be where the GLU.Engine sends Request messages to.
Read TimeOut: The read timeout is the timeout on waiting to read data. Specifically, if the server fails to send a byte <timeout> seconds after the last byte, a read timeout error will be raised. Read timeouts may occur if the received data payload is huge.
Connection TimeOut: The connection timeout is the timeout in making the initial connection i.e. completing the TCP connection handshake.
Once the connector has been configured, click Submit to complete the Connector configuration. The Connector will thereafter be available on the Connector lists for the GLU.Engines it has been attached to.
Properties
This is where Protocol specific Properties are defined – in the example below, since this Connector is configured as a SOAP Connector, the SOAP Properties of relevance are presented. Other Protocols will render the properties applicable in this panel. See the Protocol specific GLU.Guide articles for details on Properties applicable to the specific protocol you are working with.
SSL Configuration
SSL, or Secure Sockets Layer, is a widely-used security protocol that ensures the confidentiality and integrity of sensitive data transmitted over the internet. It uses encryption algorithms to encrypt data in transit, making it unreadable to unauthorized parties, including hackers.
In the context of back-end integration, SSL is often used between a GLU.Engine and an external endpoint system to secure data transmission and protect sensitive information.
TLS (Transport Layer Security) is the updated, more secure version of SSL. Despite this, many SSL certificate providers still refer to their certificates as SSL, but these certificates typically include the most up-to-date TLS encryption standards, including options for ECC, RSA, and DSA encryption.
When integrating systems in the back-end, the use of an SSL certificate indicates the secure transmission of data and protects sensitive information from unauthorized access.
The SSL Tab provides the fields one should populate to configure your Connector SSL settings. These are also environment specific.
2-Way SSL
An SSL Keystore holds the identity key for the server and the SSL Truststore serves as the repository for trusted certificates. The SSL Truststore is used for trusting or authenticating client certificates (for two-way SSL).
2-Way SSL (also known as Mutual SSL or Two-Way Authentication) is a type of SSL/TLS encryption that provides a secure communication channel between two systems by establishing trust in both directions. In a 2-Way SSL scenario, both the client and server must present a certificate to each other during the SSL/TLS handshake. This ensures that both parties are who they claim to be and helps to prevent man-in-the-middle attacks. n this scenario, both the client and server have a unique digital certificate, and the SSL/TLS protocol is used to establish a secure connection between the two systems. The certificates are verified and authenticated by a trusted certificate authority, and the encrypted data is transmitted over the secure connection.
The SSL Keystore is a store of digital certificates used by a client or server to identify itself to the other party during an SSL/TLS handshake. In a 2-Way SSL scenario, both the client and server will have their own SSL Keystore, containing a unique digital certificate. When a client or server connects to the other party, it presents its certificate from the SSL Keystore, allowing the other party to verify its identity.
The SSL Truststore, on the other hand, is a store of trusted digital certificates used to verify the identity of other parties. When a client or server connects to another party, it checks the other party’s certificate against the certificates stored in its SSL Truststore. If the certificate is not present in the SSL Truststore, or if the certificate has been revoked, the connection will be rejected. The SSL Keystore and SSL Truststore work together to establish a secure communication channel in 2-Way SSL.
Use the applicable Keystore and Truststore fields in the SSL Tab on the Connector Environment Settings window to define the Location, Path and Type of each.
In a 2-Way SSL scenario, the SSL certificate that a client or server receives from the other party’s SSL Keystore is the same certificate that the receiving party should have in its SSL Truststore.
When a client or server connects to another party, it presents its certificate from the SSL Keystore. The other party then verifies the certificate against the certificates stored in its SSL Truststore. If the certificate is present and has not been revoked, the connection is established, and the parties can communicate securely over an encrypted channel.
For the connection to be established, it’s important that both parties have each other’s certificates stored in their respective SSL Truststores. This ensures that both parties are who they claim to be and helps to prevent man-in-the-middle attacks.
SSL Config Tools
For SSL configuration the following types of files can be handled by GLU in SSL connections
.p12 / .crt / .pem and .ppk
If these files need to be switched to .jks then the following commands can be used:
This command uses the Java keytool utility to import a PKCS12 keystore (example.p12) into a JKS (Java KeyStore) keystore (example.jks). It converts the keystore format from PKCS12 to JKS.
This command also uses the Java keytool utility to import a PKCS12 keystore (example.p12) into a JKS keystore (exampleCert.jks). It specifies an alias (tomcat) for the source keystore and destination keystore, and sets a destination keystore password.
Similar to the previous commands, this command imports a PKCS12 keystore (example.p12) into a JKS keystore (exampleCert.jks). It does not specify an alias or a destination keystore password, so it might prompt you to enter them interactively.
This command uses OpenSSL to initiate an SSL/TLS connection to the specified server (testapi.example.pl) on port 443 (default HTTPS port) and displays the server’s certificate information. It does not import or manipulate keystore files; instead, it inspects certificates during a secure connection handshake.
The following is as an example of the feedback from a third-party entity regarding a GLU SSL request. In cases where our server require a certificate, the absence of one in the request results in an an SSL error occurs due to the server denying the request. This issue pertains specifically to requests directed to our production environment:
exampletest == is CN from client cert in logs[11/May/2020:13:06:02 +0200] testapi.example.pl exampletest 196.44.38.170 – – [11/May/2020:13:06:02 +0200] “POST /api HTTP/1.1” 200 674 “-” “Apache-CXF/3.3.5”
Java includes the keytool utility in its releases. Keytool can be used to manage keys and certificates and store them in a keystore. The keytoolcommands allows one to create self-signed certificates and show information about the keystore.
A keytool command follows the following structure:
In addition to keytool, GLU provides an SSL Tool which can validate your generated .jks vs the intended endpoint. The GLU SSL Tool .jar file is available here:
Receiving System Server generates a certificate request (.csr) using the -certreq command
Initiating System gets this CSR signed (by relevant CSA) and provide a signed certificate (.crt)
Receiving System imports that CRT into their keystore (Java Key Store) (this replaces the self-signed original certificate with a proper signed one)
Receiving System then exports a public key using the -export command (usually .cer)
GLU Config then points to the public key location in the Path (see screenshot above)
Notes:
If the signing authority is not a standard signing authority (thawte, verisign etc) then you might need to import a root and possibly intermediate signing authority into your Truststore.
If it is a ‘self-signed’ certificate, then Initiating System generated certs need to be loaded into Receiving System Truststore, else you won’t trust the authority that signed the Receiving System cert.
It could be possible that your verisign/thawte/CA certs are outdated, you might need to get them from the CA (certificate authority) and load them into your truststore
The following articles provide guidance on troubleshooting different SSL Connection issues: