Variables

A variable is an integration element that holds and transports data between the tasks, triggers, and edges of an integration.

• Variables can be statically defined at design time or dynamically passed to the integration at runtime.
• Variables can reference other variables in an integration.
• Variables can be globally accessible to all tasks, or locally accessible to a specific task.

Variables

In Application Integration, variables are set or initialized in various places:

• Config variables: Set at design time to store the configuration data of the integration. For example, you can use this to set a target email address for notification, rather than hard-coding that email address in the integration.
• System variables: Automatically generated by the system to store the configuration data of the integration. For example, the ExecutionId variable stores the execution ID of the integration.
• Integration variables: Set explicitly in your integration to keep track of data throughout the course of an entire integration execution. For example, you can set a variable to store the result of a task and use it in a subsequent task.
• Task variables: Set implicitly by executing specific tasks to store the output of the task. For example, the Call REST Endpoint task sets the responseBody variable to store the response body of the REST endpoint. Task variables are also known as auto-generated variables. Auto-generated variables have a special naming convention of using backticks around the variable name.

Integration variables

Integration variables, which include input and output variables, are similar to variables used in a programming language. Data in the variables can be read and written throughout the execution of the integration.

Integration variables can be used in the following ways:

• Taken in as inputs to the integration, also known as input variables.
• Returned as outputs of the integration, also known as output variables.
• Used to hold temporary state during the execution of an integration.

Note: The variable roles listed above are not mutually exclusive. Any given variable can be an input variable, an output variable, both, or neither.

When you mark a variable as an input variable, you indicate that the variable's value is expected to be provided when the integration is triggered. The value of an input variable can be modified during the execution of the integration.

When you mark a variable as an output variable, you indicate that the variable's final value should be returned as part of the integration's response.

The value of a variable does not have to be statically defined in the integration. Variable values can be passed into an integration through the use of a trigger. However, if a variable is statically defined in the integration, and the same variable is supplied dynamically with trigger, the dynamic value assignment will overwrite the static assignment.

Supported data types

The following data types are supported for integration variables:

• String and String array
• Integer and Integer array
• Double and Double array
• Boolean and Boolean array
• JSON

Task variables

Task variables are pre-defined auto-generated variables of a task. If a task has an output, all such outputs are available in a task variable. You cannot delete or edit a task variable. Task variables are also known as auto-generated variables.

The unique name of a task variable follows a special naming convention: it uses backticks around the variable name and includes the Task ID. The format is `<Task ID>_<Variable Name>`.

For example, the Call REST Endpoint task has an output for the response body. If this task has an ID of Task_5, the unique task variable name for the response body is `Task_5_responseBody`.

In the Variables pane, task variables might be listed by a common output name, for example, responseBody, without the Task ID or backticks. To see the full, unique variable name required for reference, click on the variable in the pane and view its details in the right-hand panel.

Config variables

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

Config variables enable you to externalize configuration for integration. With config variables, you can configure aspects of your integration such as connector details, authentication details, or URL endpoints that are based on the development environment, such as QA, staging, or production. You don't need to update your integration manually before you upload the integration to a new environment. Application Integration lets you enter values for the config variables when you publish the integration.

To view and edit the config variables defined in your integration, click the variable_add Integration config variable in the Variables pane. To learn how to create config variables and use them, see the tutorial Build CICD for your integration.

System variables

System variables are automatically generated when you create an integration. You can use these variables in your integration tasks and to handle errors. The integration contains the following system generated variables:

• ErrorInfo: When your execution fails, you can access the error details with the ErrorInfo variable:

  {
    "ErrorInfo": {
    "message": String,
    "code": Number
    }
  }
  

  You can access the error messages by creating an integration variable named ErrorMessage. However, we recommend you to use the system-generated ErrorInfo.message variable to access error messages.

• ExecutionMode: The mode of execution based on the trigger. Valid values are SYNC and ASYNC.
• ExecutionId: The execution ID of the integration.
• IntegrationName: The name of the integration.
• Region: The region of the integration.
• ProjectId: The project ID that contains the integration.

View variables

You can use the Variables pane to create, edit, view, duplicate, and delete variables in your integration. The Variables pane also displays a count of the total variable references within the integration.

To view the Variables pane, click the , the Toggle panel, in the designer navigation bar.

The following image shows a sample layout of the Variables pane:

View and edit config variables

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

To view the config variables defined in your integration, click the variable_add Integration config variable in the Variables pane. This brings up the Config variables pane displaying all the config variables defined in your integration. You can simply click the Value field to edit the value of the config variable.

The following image shows a sample layout of the Config variables pane:

Create a variable

To create a variable, perform the following steps:

1. In the integration editor navigation bar, click the , the Toggle panel, to bring up the Variables pane.
2. Click +Create.
3. Do the following in the Create Variable pane:
   1. Name: Enter the name of the variable.
   2. Variable Type: Choose the type of the variable.

   Data type	Description
   None	A local variable in an integration.
   Config variable for Integration	A config variable in an integration.
   Input to Integration	During execution the variable will be provided as an input to the executed trigger.
   Output from Integration	Variable's final value at the end of execution should be output to the integration's caller.
   Input and Output of Integration	At execution the variable will be provided as an input to the executed trigger and its final value will be output to the integration's caller.

   3. Data Type: Choose the data type of the variable. You can identify the data type of a variable by using the icon next to the variable name.

      Data type	Example
      String	Alex
      Integer	30
      Double	30.5
      Boolean	true
      JSON	{ "employee":{"name":"Alex", "age":30, "city":"Mountain View"} }
      String array	Alex, Kai, Raha
      Integer array	30, 25, 22
      Double array	30.5, 25.34, 22.134
      Boolean array	true, false, false

      For information about the supported data types, see Supported data types.

   4. Default Value: Enter the default value for the variable. This is an optional field.
   5. Schema: Select the JSON schema for the variable.
      • Infer from a sample JSON payload: Generates a JSON schema from a sample JSON payload. The sample payload is discarded after the schema is generated. Only the generated schema will be saved.
      • Enter a JSON schema: Manually enter an entire JSON schema.
      • Infer from the default value: Generates a JSON schema using the provided default value.
      • None: No JSON schema.
      Note: This field is displayed only for JSON data type variables.
   6. Mask the variable in logs (preview): Select this option to enable masking for the variable in the integration execution logs. To enable masking for the variable, you must enable masking variables for your integration and region. For information about how to enable masking for the integration and the region, see Edit an integration and Edit regions.

      For information about masking, see Mask sensitive data in logs.

4. Click Create.

How variables work in integrations

During the execution of an integration, run-time data is passed in as variables that are declared for the integration or task. Once execution begins, input data is converted into an in-memory object called an Event.

After the Event object is created, an in-memory graph of tasks is built by using the integration definition. Incoming variable values are passed to tasks based on your configuration. As the integration executes, the tasks read and write data back into the Event object,to be used by subsequent tasks or to form the output data of the integration.

The following table summarizes the different types of variables and their behavior:

Variable type	Description	Behavior	Example
Config variable	Stores the configuration data of the integration.	Set at design time and can be edited when you publish the integration.	A target email address for notification.
System variable	Automatically generated by the system.	Read-only and cannot be edited.	The ExecutionId variable.
Integration variable	Keeps track of data throughout the course of an entire integration execution.	Set explicitly in your integration and can be edited during the integration execution.	A variable to store the result of a task.
Task variable	Stores the output of a specific task.	Set implicitly by executing a task and cannot be edited.	The responseBody variable of the Call REST Endpoint task.

Variable references

The tasks, triggers, and edges in an integration read and write to variables by using variable references. A variable reference takes the form $paramKey$ where paramKey is the name of the variable.

$isNameUnique$ = true AND $numAccounts$ >= 1

For example:

• An edge conditional could look like this:

  $isNameUnique$ = true AND $numAccounts$ >= 1

  In this example, isNameUnique is a variable of data type boolean and numAccounts is a parameter of data type integer.

• You can create an email notification for a new user registration within an Application Integration workflow. Suppose you have two variables:
  • $userName$: Holds the new user's name (e.g., "Alex").
  • $orderID$: Holds a unique order identifier (e.g., "ORD-12345").

  The template for the email body could be:

  Hello $userName$, thank you for your order! Your order ID is $orderID$.

  When this message is sent, the system replaces the variable references with their corresponding values. The final message will be:

  Hello Alex, thank you for your order! Your order ID is ORD-12345.

You can use variable references in the following places:

• Task parameters
• Trigger parameters
• Edge conditions

When you refer to an auto-generated or task variable, you must use its full, unique name, which includes backticks and the Task ID, within the dollar sign delimiters. For example, to refer to the responseBody output of a Call REST Endpoint task with ID Task_5, you must use $`Task_5_responseBody`$.

Quotas and limits

For information about quotas and limits, see Quotas and limits.

What's next

• Learn how to build CI/CD for your integration.
• Learn how to mask sensitive data in logs.
• Add and configure a Data Mapping task