1. Double quotes (“)
2. Backslash ()
3. Newline (\n)
4. Carriage return (\r)
5. Tab (\t)
6. Backspace (\b)
7. Form feed (\f)

Important to note: By default, the GLU.Engine will not make changes to any special characters within JSON payloads during the integration flow.

Unescape JSON Special Characters

GLU provides the capability to ‘unescape’ these characters – i.e. to remove the backslash ‘\’ characters from a JSON payload. The process of unescaping JSON characters is the reverse of the escaping process, and it involves converting the encoded special characters back into their original form. This allows special characters within JSON payloads to be properly interpreted and used by applications that receive them.

To perform the unescape operation, choose “Unescape JSON” from the Decoder dropdown menu in the Response Manager Panel.

Example 1

Original JSON payload:

Unescaped JSON payload:

Example 2

Original JSON payload:

Unescaped JSON payload:

Retain escaped JSON Special Characters

The GLU.Engine introduces the “Retain Escaped JSON” feature, providing users with the ability to preserve the integrity of JSON data containing escaped characters. This feature ensures that special characters remain intact during data transmission or storage, preventing misinterpretation and maintaining the accuracy of the original data structure.

The ability to retain escaped JSON characters can be utilised in both API requests and orchestration responses.

Clicking this tool opens up a pop-up box into which you can paste the template for the payload. The ‘Content Type’ that you have specified for the Request or Response in the ‘Request / Response Manager Control Panel’ will determine the template format that you will need to paste e.g. JSON or XML format.

Additional Options:

• The ‘Add Only New Parameters’ checkbox enables you to avoid duplicating auto-generated parameters when making updates to the template you are loading.
• The ‘Path Not Included’ checkbox informs GLU to ignore the missing path if it’s missing from the template.

When pasting your template, check it’s formatted correctly by clicking on the ‘Format’ button and make any corrections needed.

Thereafter by clicking on ‘Generate Parameters’, GLU will auto-create all parameters in the Template within the applicable Request / Response Parameter set. Additionally, the ‘collection path’ for each parameter is auto-populated. This is tremendously useful especially when the template has a ‘deep’ tree structure. If your variables JSON looks like this:

The beneficiaryType parameter will have the marshaling object/collection path set as input.beneficiary.bankAccount.

This will ensure that when the variables JSON is generated from the Outbound Request parameters, the beneficiaryType parameter will be generated in the JSON payload in the correct position.

For each parameter that is added through a template load, GLU parameters need to be mapped.

This feature provides the most efficient mechanism to quickly generate Request and Response payloads. We recommend that you use ‘working’ sample test message templates too (as often sample templates in API specifications are not 100% correct).

1. Inbound API Parameters (Request Parameters): These are parameters passed to APIs as part of the inbound request.
2. Response Parameters from Connectors in Orchestration (Response Parameters): These are parameters generated as responses from connectors within an orchestration.

Depending on the type of parameter, various types of validation are available.

Hash is described in the GLU Functions & Formulas article.

Min/Max Length

The min/max length validation applies to text parameters, specifying the acceptable character length, and to numeric parameters (integer or float), defining the allowable number of digits.

Here’s how it works:

• If the min length is left null, only the max length is enforced.
• If the max length is left null, only the min length is enforced.

Example:

Suppose we set Min = 2 and Max = 4:

• “hello world” would fail as it exceeds the max length of 4 characters.
• “h” would fail as it falls short of the min length of 2 characters.
• “hell” would pass as it falls within the range of 2 to 4 characters.
• Integer “232” would pass as it falls within the range of 2 to 4 digits.
• Integer “23” would pass as it matches the min length of 2 digits.
• Integer “2324” would pass as it matches the max length of 4 digits.

Example Use Case:

You could validate the length of an incoming parameter to route it to a specific action based on its length. To achieve this, you can create a Derived Parameter to calculate length then add a Handler to route based on the Derived Parameter value (i.e. length). In this case, the Derived Parameter formula might look like this: ${token_num}.length()

Min/Max Value

The min/max value validation applies to numeric parameters, specifying the acceptable range of values.

Here’s how it works:

• If the min value is left null, only the max value is enforced.
• If the max value is left null, only the min value is enforced.

Example:

Suppose we set Min = 2 and Max = 4:

• Integer “27” would fail as it exceeds the max value of 4.
• Integer “1” would fail as it falls short of the min value of 2.
• Integer “3” would pass as it falls within the range of 2 to 4.
• Integer “2” would pass as it matches the min value of 2.
• Integer “4” would pass as it matches the max value of 4.

Regex

Regex (regular expression) validation allows you to define complex patterns for parameter values using regular expressions.

Here’s how it works:

• Enter the regular expression pattern into the regex field.
• You can use online resources like regex cheat sheets or testers to build and test your regular expressions before configuring them in the validation.

Example:

Suppose we set RegEx (Alpha Only) as [a-zA-Z]*:

• String “hello_world” would fail as it contains a special character.
• String “hello2” would fail as it contains a number.
• String “helloWorld” would pass as it contains only letters (alpha only).

Date Format

The format field should be used to set the required date format for the parameter.

For instance, if the date format is set to dd-mm-yyyy:

• If “23-OCT-2019” is passed in as a date, it would not pass the validation, and an error would be raised.
• However, if “23-10-2019” is passed in as a date, it would pass validation.

Date formats adhere to the ISO 8601 standard. The recommended date format is “2012-04-23T18:25:43.511Z”.

It is recommended to ensure date formats used:

1. Human-readable yet succinct: Choose formats that are easy for humans to interpret at a glance but also compact to save space and improve readability.
2. Sorting order: Opt for formats that allow for correct sorting, ensuring that dates are arranged chronologically when sorted alphabetically.
3. Include fractional seconds: Incorporate fractional seconds whenever possible, as this can aid in accurately establishing the chronology of events, especially in high-frequency systems.
4. Compliance with ISO 8601: Ensure that the chosen date formats conform to the ISO 8601 standard, which provides a globally recognized and standardized format for representing dates and times.

For a more detailed view of date formatting please refer to GLU Formulas & Functions

Image

For an image parameter, setting a default value means that if no image base64 value is provided for the parameter, the default base64 value will be used instead.

This base64 image decoder can be used to extract a base64 image string.

All data types have a default value field, which can be set if the parameter is passed in without a value set.

Default

The default value needs to adhere to the data type it configures and needs to adhere to the validation rules applied.

Required

All validation rules include a Boolean option to indicate whether the field is required or not

If the Required checkbox is checked, default values cannot be entered. This means that if a parameter is marked as required and no value is provided for it, the validation will fail.

Parameters in your messages can sometimes contain sensitive information, and revealing these values in logs poses a security risk. GLU.Engines generate two types of logs where values may need to be controlled:

1. PAYLOAD Logs: These logs include parameters within the payload of a message.
2. PARAM Logs: These logs print parameters separately.

PAYLOAD masks

The PAYLOAD mask specifically targets parameters within the payload when they are printed in logs. However, it does not mask the value when it is unmarshalling. To mask values when unmarshalled, adds a mask for the full string as it prints in the logs. PARAM masks are used to mask the value in the logs when it is unmarshalled.

To mask PAYLOAD values:

1. Go to the ‘Transaction’ level within the Transaction Manager Panel.
2. Use the ‘Mask PAYLOAD Values in Logs’ field.
3. Define the ‘tags’ for any values that need to be masked along with the GLU reserved word “GLU_MASK” (e.g., “username”:”GLU_MASK”). This will replace the value for “username” with “**********”.

Since tags are used, any payload value can be masked, not just parameter values within the payload. Tags to be masked can be copied from your payload template configuration and will vary depending on the type of payload (XML, JSON, SQL call, etc.).

The GLU_MASK value masks the full line, so if you specify “username”: “GLU_MASK”, the value will also be included in the masking of “username” (e.g., “**********”).

PARAM Masking

Unchecking the ‘Mask PARAM Value in Logs’ checkbox (which is checked by default) ensures that parameters’ values are not masked in logs.

Any payload tag (PAYLOAD logs) or parameter name (PARAM logs) configured to be masked will be masked in all logs (INFO, WARN, DEBUG, etc.) associated with a particular transaction.

When using the ‘Generate Parameters from Template’ tool, or manually creating parameter names in the GLU Object Model, it’s possible to encounter situations where duplicate names are present. In such cases, the Console Validations will flag these duplicates as ‘Warnings,’ indicating that they need to be addressed and resolved.

Derived Parameters

Derived Parameters are a feature that allows you to apply formulas or functions to existing parameters, both on inbound requests and outbound responses.

For example, let’s say we have a parameter called ‘interestRate’ with a value of ‘0.06’. We want to calculate a new parameter by multiplying this interest rate by 100 to get a percentage value. This is where derived parameters come into play.

In the derived parameter configuration, we specify the formula or function we want to apply, in this case, multiplying the ‘interestRate’ by 100. The result will be a new parameter with a different name, let’s say ‘multipliedInterestRate’, containing the calculated value of ‘6’.

It’s essential to assign a unique name to the newly calculated parameter to avoid confusion with the original parameter(s). The common name format for derived parameters allows for spaces and special characters if needed, as it’s not used within the GLU.Engine itself.

Time Parameters

Time Parameters serve to capture timestamps to mark the specific moments when requests or responses are sent or received by the GLU.Engine. You can achieve this by using either the ‘Response Time Parameter’ for inbound and outbound responses or the ‘Submit Time Parameter’ for outbound requests.

To create a Response Time Parameter, navigate to the response handler control panel. Here, you can define the parameter and specify its name. Once created, you can reference this parameter in the response template. Additionally, in the marshaling panel of this parameter, you can define the date and time format to suit your requirements.

Request Parameters

For each parameter being received, the ‘Parameter Manager Panel’ serves as the tool to define various characteristics and specify how each parameter should be handled by the GLU.Engine. To add parameters for the relevant request, simply use the ‘Add Parameters’ button located under the ‘Parameters Panel’.

See the next major section for details on Parameter Types and Validation Rules.

Validation

One can also define ‘Validation’ rules for each parameter, serving to safeguard downstream systems against inbound messages that do not adhere to the specified validation criteria. This capability of the GLU.Engine adds a layer of load and performance protection to downstream Receiving Systems.

When a parameter fails to meet the validation rules, an error message is generated, indicating the specific parameter and the rule it violated. For example, an error message might state “textLength less than Min length.” The types of parameter validation rules available depend on the parameter ‘Type’ being received:

• Min / Max Length: Specifies the minimum and maximum number of characters allowed for the parameter.
• Min / Max Value: Establishes the minimum and maximum allowed numerical values for the parameter.
• Regex: Provides the option to apply a Regular Expression validator, enabling custom pattern matching (resources such as regextester can assist in defining your Regex).
• Default: Allows the addition of a default value at the GLU.Engine layer if the parameter is not received from the ‘Initiating System’. If a parameter with that Parameter Name is received, the GLU.Engine will pass the received value; if not received, the GLU.Engine passes the default value.

Make visible in logs

Indicates that the Parameter will be included in the gluware.log. If un-checked, the Parameter will not be visible in the logs.

Parameter Types

Text

‘Text’ type parameters accept only simple alpha characters. The validation configuration options for such parameters include:

• Required: This indicates that the parameter must be received. If it is not received, the GLU.Engine halts the transaction and returns a ‘parameter required’ response to the initiating system. The logs will also reflect this condition.
• Make Visible in logs: This option determines whether the parameter will be included in the gluware.log. If unchecked, the parameter will not appear in the logs.

Image

Images can be received as parameters in the form of an encoded object, such as Base64. In such cases, you can specify the following configurations for the parameter:

• Required: This checkbox indicates whether the parameter must be received. If checked, the GLU.Engine expects the parameter, and if it’s not received, the transaction is affected accordingly.
• Default: This field allows you to assign a default value to the parameter. It is useful when the image is added at the GLU.Engine layer instead of being received from the ‘Initiating System’.

The encoded object representing the image can be passed regardless of the format (JSON or XML) being used.

Float

A ‘Float’ type Parameter is a numeral, potentially with decimals as might be the case for a monetary value. The validation configuration options are as follows:

• Required: Indicates that the Parameter must be received.

Integer

An ‘Integer’ type parameter represents a whole number without fractions or decimals. Here are the validation configuration options available for this parameter type:

• Required: This checkbox indicates whether the parameter must be received. If checked, the GLU.Engine expects the parameter, and if it’s not received, the transaction is affected accordingly.
• Make Visible in logs: This checkbox determines whether the parameter will be included in the gluware.log. If unchecked, the parameter will not appear in the logs.
• Min / Max Length: This option specifies the minimum and maximum number of characters allowed for the parameter.
• Min / Max Value: These options define the minimum and maximum numeric values allowed for the parameter.
• Regex: This field provides the option to add a Regular Expression validator. Resources such as RegexTester can assist in defining your Regex.
• Default: This field allows you to specify a default value for the parameter. It is used when the value is added at the GLU.Engine layer rather than being received from the ‘Initiating System’.

Hash

A ‘Hash’ type parameter is as a secure value, typically used for sensitive data like passwords. It employs a Secure Hash Algorithm (SHA), a cryptographic function designed to secure data by transforming it into a fixed-size string called a hash value. This process makes it extremely difficult to reverse-engineer the original data from the hash.

The purpose of using a SHA is twofold: firstly, to encrypt sensitive parameters like passwords so that only the hash values are stored on the server, not the actual passwords. Secondly, SHAs can detect data tampering, making them effective against “Man-in-the-Middle” attacks.

GLU.Ware supports various SHA options, including SHA-1, SHA-256, SHA-384, and SHA-512, as well as the older MD5 verification. However, MD5 and SHA-1 are considered compromised and should be avoided for security reasons.

The choice of SHA option impacts security and system processing load. Higher SHA options offer greater security but require more processing power.

When configuring a hash parameter, you specify the input data for the Hash Algorithm using a Hash Expression. For example, you can use specific parameters from a request, such as “accountID” and “amount”. Additionally, a Salt Key can be added to enhance security. The Salt Key introduces an external input to the hash process, not present in the original message.

The ‘Create Hash’ flag determines whether the GLU.Engine generates and passes the hash or simply passes what it receives from the Initiating System. If ‘Create Hash’ is unchecked, a ‘Default’ value can be set to be used if the Initiating System fails to send a value.

It’s crucial to share the Salt Key and Hash Type with the Receiving System to ensure consistency in hashing. The Salt Key can be any random value agreed upon by both systems.

If the ‘Create Hash’ is not checked, a ‘Default’ value can also be set such that if the ‘Initiating System’ fails to send a value, the ‘Default’ value will be used.

Date

The ‘Date’ parameter type is must be used when handling dates or times within the GLU engine. Functions like DIFFTIMESTAMP() necessitate parameters to be of a date type.

In order to save a value as a date type, you must specify the unmarshalling date format to ensure the engine interprets the date correctly.

Example: If you receive a date in the format of ‘2020-10-21 15:10:03’, you can configure the unmarshalling panel as follows:

• Date Format: YYYY-MM-DD HH24:MI:SS

Note: Epoch dates (timestamps), such as 1619520000 (which corresponds to 27th April 2021, 12:00:00 UTC), are processed in the same manner as standard dates.

This ensures that the engine correctly understands the date format and processes it accordingly.

Example with timezone:

20201021T13:25:04+0330 then the unmarshalling panel would have:

yyyyMMdd’T’HH:mm:ssZ

“ResponseAsTime1”: “2022-03-11 11:12:49:1249”, “RequestAsTime2 G-yy-MMMM-w-W-D-E-u-a-k-h-z-Z-X”: “AD-22-March-11-2-70-Fri-5-AM-11-11-GMT-+0000-Z”

The following table defined the syntax to use, with locale being set to match the language which the GLU.Engine was initiated with (see XX).

Also note the following additional Letters for Pattern

– ms gives microseconds to the thousands of a second. See example below:

“ResponseAsTime1”: “2022-03-11 11:12:49:1249”, “RequestAsTime2 G-yy-MMMM-w-W-D-E-u-a-k-h-ms”: “AD-22-March-11-2-70-Fri-5-AM-11-1249”

Example 1: format: E dd MMM yyyy HH:mm:ss z output: Thu 09 Jun 2022 10:10:06 CAT

Outbound Date Marshalling

When completing outbound marshalling, you can set a date parameter to hold a specific format by using the Date Format in the marshalling panel.

Example: 2020-10-21T13:25:04 then the marshalling date

format would be: yyyy-MM-dd’T’HH:mm:ss