Reserved words, also known as keywords, are predefined terms in a programming language that has special significance and cannot be used as variable names or user-defined identifiers. These words have specific syntax and functionality in the language and cannot be redefined or used for any other purpose. The use of reserved words helps to structure and define the syntax of a language and make the code easier to read and understand.

This means they can only be used for the relevant command defined in GLU reserved words below. They can not be used as variable names in the Public Static Collection, Authentication Parameter Control, Transaction Name, Flow code or Parameter Name.

In this context, attempting to use a reserved word will triggers an automatic removal mechanism within the Integration Builder. For example, trying to add the letter “n” to “join” is not allowed, as ‘join’ is recognized as a reserved word. This protective measure ensures that reserved words are appropriately utilised in the designated contexts.

The reserved word GLU_STATUS_CODE can be used to pass the last status code from a third party ( more details on the Response Manager page).

GLU Reserved Words

Transaction Names and Codes and API Selector

A transaction represents an API endpoint that will receive messages from an ‘Initiating System’. Each transaction is given a ‘common name’ (left box below) and within the Transaction Manager Panel a ‘Transaction Code’ (text field in the right box below):

• ‘Common Name’: is a free text description of the transaction being configured, its format can include spaces and special characters if desired since it’s not used within the GLU.Engine however the ‘Transaction Code’ format must not include any spaces or special characters.
• ‘Transaction Code’: is useful for log file analysis when troubleshooting.

The ‘API’ (drop-down list in the right box below) within the Transaction Manager panel is a drop-down list that will be populated with the pre-configured Inbound Connectors that have been associated with the GLU.Engine you are working on. This identifies the origin of the inbound transaction that is going to be configured.

If the Exclude from GLU.Engine Build checkbox is checked it will remove the transaction from the build process. This can be used if a new transaction is being built and it must not be included in the build process. If this option is selected the transaction in question will not be validated as part of the build validation process either.

The following fields including:

• Description fields should be used to describe the Transaction. The details within these fields will appear on the Swagger Specification for your APIs.
• Add an example of the URL used to call the API for this transaction in the Spec Request Sample field. Add an example of the response expected to be received for the API for this transaction in the Spec Response Sample field.
• Add and example of the expected response structure for an Error Spec Response Error Sample field.

For more on the Swagger Configuration see this page.

Log Filter

The Log Filter enables you to add any tag you like to the logs to help with log file analysis and filtering. If for example, you have integrations with 10 or 20 or more end-points, the logs can become difficult to follow and so by adding a log filter that identifies the Endpoint name for example, you will be able to search and read your logs easier. The Log filter value you add is pre-fixed to the transaction id in the logs.

If you had many MNOs you are integrating to, you could add an ‘MNO Name’ as a Static parameter, and then your log filter can pick that parameter up if it is set like this: MNO: ${mno_name}

The example below shows how the value myUniqueValue76235 passed into the API through the body parameter externalID, is reflected in the logs.

Postman shows how the parameter is passed in the body parameter.

Mask payload values in logs

This feature allows you to mask any values your GLU.Engine may receive.

Example 1:

In the log snippet below:

If you wanted to hide “authToken” value you can add into the Mask Payload field:

Your logs will then look as follows:

NOTE: the ‘,’ at the end of your mask setting indicates where the masking needs to end. Also you’ll notice that ‘GLU_MASK’ is a reserved work in GLU that will apply this masking logic.

Example 2:

If you’re handling XML you may have a payload with the following sort of format:

If you wanted to hide <a:CustomerPassword> value you can add into the Mask Payload field the following:

Your logs will then look as follows:

NOTE: the ‘<‘ at the end of your mask setting indicates where the masking needs to end.

Print Payload In Log on One Line: Use the tick box to force the incoming and outgoing payloads on the Transaction to present in the Logs on one line. Having the logs coming out on 1 line will partially speed up the performance of the GLU.Engine.

When the tick box is not ticked the Incoming Payload & Response Payload will wrap across multiple lines as can be seen below.

When the tick box is ticket the Incoming Payload & Response Payload will all stay on one line as can be seen below.

In scenarios where the GLU.Engine needs to call an HTTP service but this service is slow to respond and you do not want your GLU.Engine to be blocked, waiting for a response. You want your GLU.Engine to do other important computation while the slow response is happening. In such a case you can set your message to be Asynchronous so your GLU.Engine can handle other processing demands while the slow service is processing it’s long running requests.

In the Orchestration, the GLU.Engine can initiate outbound message exchanges with two main patterns: ‘Request only’ or ‘Request-Reply’:

• ‘Request only’ messaging: This involves sending a message without expecting a reply. It’s often referred to as fire and forget or event message.
• ‘Request-Reply’ messaging: This is when a caller sends a message and then waits for a reply. This is like the HTTP protocol that we use every day when we surf the web. We send a request to fetch a web page and wait until the reply message comes with the web content.

By default, messages in GLU are treated as ‘Request-Reply’, which is synchronous. To designate a message as ‘Request only’ or asynchronous, the ‘Asynch’ checkbox in the ‘Endpoint Manager Panel’ can be utilised.

This distinction allows the GLU.Engine to efficiently manage processing demands, ensuring smooth execution even when dealing with slow responses from external services.

Synchronous Transactions

A synchronous exchange is where the caller sends a message and waits for a response before continuing. A synchronous request blocks the calling thread until a response is received, meaning that it waits for the response before continuing to execute. Synchronous requests are typically used when the response time is short and the results of the request are immediately required for further processing.

Asynchronous Transactions

Asynchronous requests diverge from synchronous ones by not blocking the calling thread, allowing it to continue executing independently. The response to such requests is typically received at a later time, often facilitated through a callback or event handler. Asynchronous requests find utility in scenarios where the response time is protracted, and immediate processing of results is not imperative.

Asynchronous transactions processed by a GLU.Engine send a message to a receiving Endpoint which then returns immediately back to the GLU.Engine with an ACK/NACK response, this message, however, is processed in another thread within the GLU.Engine, the asynchronous thread. This enables the GLU.Engine to continue doing other work, and at the same time while the asynchronous thread is processing the message.

In networking terminology, ACK signifies “Acknowledgment,” confirming successful receipt of a transmitted data packet. Conversely, NACK, or “Negative Acknowledgment,” indicates either non-receipt or receipt with errors, prompting the need for retransmission of the data packet.

Asynchronous transactions do not implement any kind of persistence or recovery if the GLU.Engine terminates while messages are yet to be processed. If you need persistence, some form of queueing such as ActiveMQ or RabbitMQ, or a DB insert could be used.

Asynch-SEDA

To provide enhanced asynchronous transactions GLU provides the ability to deliver asynchronous transactions through the SEDA method. SEDA (Staged Event-Driven Architecture) is a software architecture that enables efficient and scalable processing of events, such as user requests or messages, in a multi-stage pipeline.

SEDA provides a framework for managing and coordinating the flow of events through the pipeline, with features such as flow control, back pressure, and dynamic stage scaling. Thus, SEDA adds a layer of orchestration and management to asynchronous messaging, making it more suited for complex, scalable event-driven systems.

In SEDA, events are processed through a series of stages, each of which performs a specific task. For example, a stage might be responsible for parsing incoming requests, while another stage might handle database access. Each stage runs as a separate thread and events are passed from stage to stage in a concurrent manner, allowing for high parallelism and low latency.

SEDA enables system designers to trade off between throughput, latency, and resource usage to meet specific system requirements.

The SEDA component provides asynchronous SEDA behaviour, so that messages are exchanged on a Blocking Queue and consumers are invoked in a separate thread from the producer. A Blocking Queue is a queue data structure that blocks or waits when attempting to dequeue from an empty queue, or to enqueue to a full queue. It allows for coordination between stages in the event processing pipeline, providing a mechanism for back pressure and flow control.

• Concurrent Consumers: Concurrent consumers are parallel threads of execution that consume messages from a queue in the SEDA model. The idea is to increase the processing speed by allowing multiple consumers to process messages at the same time, thereby reducing the overall processing time. The number of concurrent consumers can be specified when setting up the SEDA system and can be tuned to achieve optimal performance. Use this field to sets the number of concurrent threads processing exchanges (the default value = 1).
• Size: Sets the default maximum capacity of the SEDA queue (i.e., the number of messages it can hold) (Default value = 1000). Queue size in SEDA messaging refers to the maximum number of messages that can be stored in the queue at any given time. This setting is used to manage memory usage and prevent the system from running out of memory due to a large number of messages being stored in the queue. The queue size can be set to an appropriate value based on the expected rate of message arrival and the processing time required for each message. If the queue size is set too low, messages may be lost if they cannot be processed quickly enough. If the queue size is set too high, memory usage may become a concern.

When NOT to use SEDA

When would you not use SEDA for an async connection or set of connections?

While SEDA can be a useful pattern for building scalable, high-performance systems, it may not be appropriate for all asynchronous connector integrations. Here are some of the reasons why you may not want to use SEDA for an async connection or set of connections:

• Complexity: SEDA can introduce complexity into your system, as you need to manage the different stages and ensure that data is properly processed through each one. If your integration is relatively simple and does not require a lot of processing, SEDA may not be necessary.
• Latency: SEDA can add latency to your system, as data must be passed from one stage to another. If your integration requires real-time processing, SEDA may not be the best choice.
• Debugging: Debugging a SEDA-based system can be more difficult, as you need to understand how data is being processed through each stage.
• Overhead: SEDA requires additional overhead in terms of system resources, as you need to manage the different stages and ensure that data is properly processed through each one. If your integration requires only a minimal amount of processing, SEDA may add unnecessary overhead.

So, it’s important to consider these factors when deciding whether or not to use SEDA for an async connection or set of connections. If the requirements of your integration are simple, low-latency, and easy to debug, you may want to consider an alternative pattern that is better suited to your needs.

Authentication Collections serve as a repository for defining reusable Authentication Parameters within an integration configuration. The Authentication Parameter Control Panel provides three essential configuration fields:  

• Code/Name 
• Key  
• Value 

The process involves assigning a unique and reusable ‘Auth Name’ through the Name field, which then becomes accessible in the Orchestration Request Manager Control Panel’s Authentication Name dropdown.

Key Components of Authentication Collections: 

1. Name: 

• Purpose: Assigns a distinctive ‘Auth Name’ to the defined Authentication Parameter. 
• Usage: Auth Names are accessible in the Orchestration Manager’s ‘Auth Name’ dropdown when creating a Request to a Receiving System requiring Authentication. 

2. Key + Value: 

• Definition: A key-value pair (KVP) representing linked data items. 
• Usage: Commonly employed in lookup tables, hash tables, and configuration files. 

Note: For signing Amazon AWS requests with Signature Version 4, you can build up the required headers and hashes in the Value as follows:

These values need to be specified in the Public Static Collection. The last value is the timestamp offset- in this case, the server is in UTC-2 so the required value is ‘-2’. See more here.

Static Parameters within the GLU.Engine are self-generated values not obtained from external systems but rather internally created. The Reusable and Static Parameters tool facilitates the creation of parameters for recurrent use across integration configurations. This tool allows for the establishment of an unlimited number of Static Parameters, each possessing a dedicated ‘Properties’ Tab within the ‘Parameter Control Panel’. 

Key Characteristics of Static Parameters: 

1. non-Nullable (A Static Parameter cannot be Null – Empty):

• Definition: A Static Parameter cannot be Null or Empty. 
• Implication: It must always hold a value and cannot exist without one. 

2. Immutable (A Static Parameter cannot be changed throughout the life of the transaction): 

• Definition: A Static Parameter remains constant throughout the lifespan of a transaction. 
• Implication: Its value, once set, does not change during the transaction.

Utilising Static Parameters provides a mechanism for the GLU.Engine to internally generate and manage values essential for the integration configuration. These parameters, once established, maintain a consistent state throughout the transaction, contributing to the stability and predictability of the integration process. 

Static Parameter Examples

In this instance, a http_status parameter is being configured as a Static Parameter:

Within the Parameter Manager Panel:

• The ‘Name’ field is required.
• Define the ‘Default’ field can be defined.
• Use checkboxes to indicate if the Parameter is a ‘timestamp’.
• Use the radio buttons to define the treatment of the Parameter value in the logs.

• If a Default value is set, it acts as a preset for the Static Parameter when set to null.
• It’s not possible to set a default value when the type is Timestamp.
• Setting the type to Timestamp results in the value being a DateTime structure.
• The DateTime value is assigned when Requests are received.

Choosing the timestamp type will assign the value of this Static Parameter to a DateTime structure, and this DateTime value is allocated upon the reception of Requests.

• Timestamps are saved as a ‘LONG’ format with no inherent formatting.
• To format the timestamp:
  1. In the Parameter Control Panel under the Un/marshaling tab, set the Date Format (default is dd/MM/yyyy).
  2. Derived Parameters have a function called DATEFORMAT(${yourtimestamp}.

The timestamp is set to the time when the transaction is first initiated and it is kept static throughout the flow through the application. This means if the flow moves to other transactions in the application, even though the flow is in another transaction the timestamp value will still be the same.

The diagram illustrates how it is possible to navigate between transactions, and when doing so, note that the timestamp will always stay the same:

In the Orchestration, if a Connector is called, the flow moves out of the application. When the flow returns the timestamp value will still be the same. This is the case for synchronous and asynchronous connections.

Timestamps vs NOW Variable:

• Timestamp values are static throughout the entire transaction in the application.
• In contrast, variables defined as ${NOW} only reflect the time at the point they are used; they are not static throughout the transaction flow.

At the top of the Integration Builder configuration screen, you’ll see various tools that enable the rapid re-use of configurations within the Integration Builder. These tools help to radically speed up the process of configuring integration components that have similarities but that are not necessarily identical.

Copy – Paste

At a more ‘granular’ level you are able to Copy any level of a configuration within the hierarchical tree.

1. Open the Integration Builder configuration screen.
2. Locate Copy-Paste Tools at the top of the screen. (as indicated in the screenshot above)
3. Select the configuration section you want to copy within the hierarchical tree.
4. Paste the copied section of the configuration into your flow at the desired location
   • Note: Handler Configurations must be checked as the Flowcodes will change when pasted so the routing to the required Flowcodes needs to be set, to do so re-select the required destination Flowcode for each routing handler.
5. If pasting within a new transaction, double-check Handlers using or updating parameters, as the parameter to update might not exist in the new transaction.

Cross-Application Copy-Paste, is another option, you can also exit the Application you copied from and paste it into a different Application.

Export-Import

1. Open the Integration Builder configuration screen.
2. Locate Export-Import Tools at the top of the screen.
3. Export the entire configuration as a ‘flows.json’ file.
4. Import the ‘flows.json’ file into a new GLU.Engine Application to seed the new configuration.
5. After importing, add connector mappings for the new configuration. Check if Connector IDs that match may automatically map, but verify these mappings.
6. After import, click on the ‘spanner’ icon at the top right of the Integration Builder panel to ‘Repair’ your integrations. This re-indexes the configuration.

Note: These tools drastically speed up the configuration process by facilitating the re-use of configurations. Always ensure that Handler configurations are checked and, if necessary, reconfigured, especially when pasting into new transactions or applications. Additionally, after import, make sure to repair integrations to maintain a well-indexed configuration.

Use the XML JSON Converter tool (top right of your Integration Builder screen) to format and convert payloads from XML to JSON or visa versa. Simply copy and paste your sample message payload in the field, and click to convert.

The Format XML / Format JSON option will correct any formatting issues:

• Recommended Usage: It is highly advised to use this tool as a JSON Formatter because certain ‘invisible’ issues within a payload can potentially disrupt your integration.
• Example: If you are configuring on a Macbook, the ‘Double Quotation’ marks style may not be valid in a JSON file. Adjusting the style on a Macbook for these quotation marks can be done to ensure compatibility (instructions here).

The. Arrows Between XML and JSON Panels can be used to process the conversion each way:

• Usage: You can use these arrows to initiate the conversion in both directions, allowing flexibility in handling XML-to-JSON or JSON-to-XML transformations.

Once you have you converted and formatted the payload, you can copy and paste it into the Generate Parameters tool or to your Postman test pack as needed.