Transaction Manager Panel

Common Name

Each inbound transaction received from an ‘Initiating System’ is given a ‘common name’ (red box below) and within the Transaction Manager panel a ‘Transaction Code’ (blue box below). These values effectively ‘anchor’ the transaction being configured. 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 logfile analysis when troubleshooting. It is different to a ‘Flow Code’ which is used within the ‘Orchestration Manager’ for transaction routing.

API

The ‘API’ (green box below) within the Transaction Manager panel is a drop-down list that will be populated with the pre-configured Initiating System APIs using the API Tool. This identifies the origin of the inbound transaction that is going to be configured.

Exclude from GLU.Engine Build

The checkbox marked by “Exclude from GLU.Engine Build” can be used to 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 is selected then it will not be validated as part of the build validation process either.

Description

The following fields including the Description fields should be used to describe the Transaction. The details within these fields will appear on the Dev Portal and in the Specification

Spec Request Sample Example of the URL used to call the API for this transaction.

Spec Response Sample Example of the response expected to be received for the API for this transaction.

Spec Response Error Sample Example of the expected response structure for an Error.

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 read your logs more 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 INCOMING PAYLOAD & RESPONSE PAYLOAD will wrap across multiple lines as can be seen below.

When the tick box is ticket INCOMING PAYLOAD & RESPONSE PAYLOAD will all stay on one line as can be seen below.

Was this article helpful?

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Need Support?

Can't find the answer you're looking for?
Contact Support
Fill the form and we’ll contact you shortly

    I agree with

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