An example of this is if you want to change a Slack channel which messages are sent to depending on whether you are deploying on a development environment or a production environment. It is possible to have a single variable name such as “slackKeyValue” with the channel keys for development and production being different.

How to set this up:

1. Setup your Global Variables

Press the “Global Variables” button in the Environments tool, to access the Variable configuration screen.

The Global Variables screen shows the variables that exist. It is possible to “Add Variables”, and to modify and delete existing variables from this screen. Each Variable must have a unique name per Client, with a description of what the variable is used for.

If you add or modify a variable you will be presented with the ‘Edit Variable’ dialogue.

In this dialogue, you can define/modify the name of the variable and description. For each environment, you can set the value to be used. It is not necessary to enter values for Environments that are not used. If the value is left empty, then null will be present in the GLU.Engine when used in that environment. Once Variables have been set per environment, those variables will be used for each GLU.Engine Environment-specific build.

2. Use the variable in your integration

The variable that you have created is now available to be used in your integration. It will be added to the parameter dropdown box with the prefix “env_” .

Example of global variables that will be present in the pulldown box with the “env_” prefix:

Example of using a global variable in the context name:

/${header.env_slackKeyValue} … where the variable defined was slackKeyValue and the env_ is the prefix to identify the variable as a global variable and the /${header. represents part of the parameter being passed to the URI.

Masking Environment Variables in the logs

See how the values are masked in the logs

Note: avoid using variables in Header, Body, or query sections endpoint calls, as they will not be encrypted when presented in the logs.

Using an Environment Variable in a Handler

Where an Environment Variable needs to have a condition applied and Action taken, when in the Integration Builder, and configuring the Handler, select the Environment Variable from the Parameter Name drop-down.

See the example below.

In accordance with this SDLC, the following environments would be established:

1. Development (DEV)
2. System Integration Testing (SIT)
3. Quality Assurance (PRE-PROD)
4. Production (PROD)

Each environment will have different outbound connectors, typically with distinct endpoints such as hosts (IP/Port or URLs). Therefore, it’s necessary to define environment-specific host details for each outbound connector within the GLU.Console. This approach ensures that all host configurations are centralised within GLU, eliminating the need for SDLC-related configuration changes outside of GLU.Engines as they progress through the SDLC.

It’s worth noting that maintaining a “PRE-PROD” environment mirroring the production environment, including all production host details, is beneficial. This setup allows for building a PRE-PROD GLU.Engine identical to the PROD GLU.Engine, facilitating PROD smoke testing. Once the “cut over” to PROD is approved, the transition can be seamlessly executed.

Add Environment

Use the ‘Add Environment’ Tool to add Environments, where the following details need to be provided.

Manage SDLC Tool

Use this tool to define a particular SDLC to be used for the specified Application which you select from the first pop-up box as below.

Once selected, you can add your pre-defined ‘Environments’ to this SDLC using the drop-down list. If an SDLC is going to conclude with a ‘Production’ release, select one of the pre-defined Environments that you flagged as a ‘Production’ Environment when using the ‘Add Environment’ Tool.

There is no limit to the number of Environments you can add where the Production Checkbox has not been selected. You cannot add more than one ‘Prod’ Environment to an SDLC.

The ‘grab handles’ on the left of each ‘Environment Block’ can be used to ‘drag’ the Environments up or down, to adjust the SDLC sequence. The SDLC sequence is determined based on the top-down sequence of these Environment blocks.

The ‘Skip Test’ toggle allows the Release Manager to quickly adjust the SDLC sequence. This may be useful for example where there is a Production bug that is low risk and urgent, instead of the fix having to follow the full SDLC sequence, the Release Manager can ‘Skip Testing’ on any Environments (except if flagged as Production) to fast track the Production fix. The ‘red X’ can be used to de-activate the environment. It is not possible to delete environments once created and used for historic audit reasons.