Parameters Types and Configurations

In the GLU Object Model, it is important for Parameter Names to be unique, i.e. when unmarshaling them. This uniqueness requirement applies regardless of whether the parameters are located in different parts of a message payload, such as within nested arrays or at different levels of a tree.

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.


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’ 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.


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.


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.


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’.


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.


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:


“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

Was this article helpful?

Related Articles

Fill the form and we’ll contact you shortly

    I agree with

    We uses cookies to make your experience on this website better. Learn more
    Accept cookies