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

The ‘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.

The ‘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.

The Exclude from GLU.Engine Build checkbox if checked 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 the 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:

2020-09-15 10:09:28.849 [qtp1227903899-23] DEBUG – [ -TRX_ID : 7d731088-1126-4f3d-b0cd-0bacc1af9649] INCOMING PAYLOAD : {

"beneficiaryDisbursementId": "17702267",
 "disbursementReference": "200519",
 "expiryDate": "2020-09-28 23:59:59",
 "mobileNumber": "+27789999999",
 "authToken": "lbliu12giyego12",
 "value": 47500

}

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

Your logs will then look as follows:

“authToken”: *****************,

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:

<a:CustomerNumber>63288892</a:CustomerNumber> <a:CustomerPassword>56bnlwiju621</a:CustomerPassword> <a:CustomerSurname>MABAZA</a:CustomerSurname>

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

<a:CustomerPassword>GLU_MASK<

Your logs will then look as follows:

<a:CustomerPassword>*****************<

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.