Parameter Names must be unique in the GLU Object Model – i.e. when you unmarshal them. It doesn’t matter if two or more parameters reside in different places in a message payload e.g. at different levels of a tree of nested arrays. Thus when using the ‘Generate Parameters from Template’ tool it may be that the template has parameters that have the same names. In this case or if you manually create parameter names in the GLU Object Model that are duplicates, the Console Validations will show these duplicates as ‘Warnings’ which you will need to resolve.
Derived Parameters
A Derived Parameter can apply a Formula or a Function to another Parameter or Parameters. Derived Parameters can be defined on both Inbound Requests and Outbound Responses.
In the example screenshot below, the formula takes an existing Parameter ‘interestRate’ and multiplies it by 100.
This would take an input value of ‘0.06’ and work out a new value of ‘6’. The new calculated Parameter needs to be given a new, different name to the input parameter(s). In other words, the example could be called ‘multipliedInterestRate’ but not ‘interestRate’.
The ‘Common Name’ format can include spaces and special characters if desired since it’s not used within the GLU.Engine.
Time Parameters
You are able to capture the timestamp to record the specific point in time when a Request / Response messages are sent or received by the GLU.Engine – for this use the ‘Response Time Parameter’ (Inbound Response and Outbound Response) or the ‘Submit Time Parameter’ (Outbound Request).
The Response Time Parameter can be created on the response handler control panel. This parameter can then be referenced in the response template. The parameter can be added in the parameter list referencing the parameter name created and the date and time format of this can be defined in the marshaling panel of this parameter.
Request Parameters
For each Parameter being received, the ‘Parameter Manager Panel’ is used to define various characteristic of the Parameter as well has how each Parameter must be handled by the GLU.Engine. Use the ‘Add Parameters’ button under the ‘Parameters Panel’ to add Parameters for the applicable Request.
See the next major section for details on Parameter Types and Validation Rules.
Validation
One can also define ‘Validation’ rules for each Parameter that can be used to protect downstream systems from inbound messages that don’t pass the defined validation rules. Thus, the GLU.Engine can provide a layer of load/performance protection to downstream Receiving Systems.
When a Parameter doesn’t meet pass the Validation Rules, an error message is displayed citing the Parameter and the Rule broken. EG: textLength less than Min length Depending on the Parameter ‘Type’ being received there are different Parameter Validation Rules as described below.
‘Min / Max Length‘ – used to decline the number of characters allowed for that Parameter.
‘Min / Max Value‘ – used to define the min / max allowed.
‘Regex‘ – gives an option to add a Regular Expression validator (resources such as regextester that can help to define your Regex).
‘Default‘ – is used to add the value at the GLU.Engine layer rather than it being 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 are simple alpha characters only. The validation configuration options are as follows: ‘Required’ – Indicates that the Parameter must be received. If it is not received then the GLU.Engine responds by stopping the transaction from progressing and returning a ‘parameter required’ response to the initiating system, the logs likewise will reflect the same. ‘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. can help to define your Regex).
Image
Images can be received as Parameters in the form of an encoded object (e.g. Base64), in this case one can stipulate that the Parameter is ‘Required’ using the check-box or a ‘Default’ value can be assigned. The ‘Default’ value is used for situations where the Image is being added at the GLU.Engine layer rather than it being received from the ‘Initiating System’. The encoded object 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 is a whole number with no fractions or decimals. The validation configuration options are as follows: ‘Required’ – Indicates that the Parameter must be received. ‘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. ‘Min / Max Length’ – used to define the number of characters allowed for that Parameter. ‘Min / Max Value’ – used to define the min/max allowed. ‘Regex’ – gives an option to add a Regular Expression validator (resources such as https://www.regextester.com can help to define your Regex). ‘Default’ – is used to add the value at the GLU.Engine layer rather than it being received from the ‘Initiating System
Hash
A ‘Hash’ type Parameter is a secure value. A secure Hash Algorithm, also known as a SHA, is a cryptographic function designed to keep data secured. It works by transforming specified input data using a hash function. The hash function produces a fixed size string that looks nothing like the input. These algorithms are designed to be one-way functions, meaning that once they’re transformed into their respective hash values, it’s virtually impossible to transform them back into the original data. One can use a SHA to encrypt sensitive Parameters such as passwords, so the server only needs to keep the specific user’s hash value, not the actual password. Any breach of the database will find only the hashed values and not the actual passwords.
SHAs can also be used to detect the tampering of data by attackers, preventing “Man in the Middle” attacks.
GLU.Ware supports SHA-1, SHA-256, SHA-384 and SHA-512 as well as the older MD5 verification.
The higher the SHA option selected the more secure but also the higher the system processing load will be. This can be configured with select or all parameters in a request or a response to ensure its authenticity.
NOTE: MD5 and SHA-1 Hash Algorithms have both been compromised and should not be used.
GLU continues to support these Hash options as we understand that some systems do still use them and may not change. The risk of doing so is entirely for the Customer / User of GLU.Ware.
The SHA uses data from the message, which it validates as input to the Hash Algorithm. For example, a request with parameters “accountID”, “amount” and “reference” can be configured to use a single parameter or all parameters as input to the Hash Algorithm.
The input parameters are specified in the Hash Expression. To use “accountID” and “amount” from the example above, the expression should be set to: ${accountID}+${amount} A Salt Key can also be inserted for additional safeguarding. The salt value provides an external input to the Hash that isn’t present in the message being validated. The Salt Key and the Hash Type being used must be shared with the Receiving System to ensure that it has the same inputs to the SHA. The Salt Key can be any random value. The ‘Create Hash’ flag: If not checked, the GLU.Engine will pass what is received from the ‘Initiating System’. If checked, the GLU.Engine will generate then pass the hash (using expression).
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
‘Date’ parameter type must be used when you are handling dates or times in your GLU engine. Functions such as NOW() and DIFFTIMESTAMP() require the parameters to be of a date type.
In order to save the value into a date type, you need to set the unmarshalling date format to ensure the engine is able to read 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 below.
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 will be: yyyy-MM-dd’T’HH:mm:ss
