Expressions (original) (raw)

Expressions are evaluated by the workflow engine and the output is used at the time of execution, such as assigning the result of an expression to a variable or returning the result of an expression.

There is a limit to the expression length.

All expressions must begin with a $ and be enclosed in curly brackets:

${EXPRESSION}

You can use expressions to:

• Assign values to variables
• Form call arguments, including all parameters in the body, header,query, and url sections
• Call subworkflows
• Apply conditions
• Retry values, including max_retries and multiplier
• Return values from a workflow step

Supported elements

The Workflows syntax supports the following elements in the definition of an expression:

• [0...9]: numbers
• "": strings
• - (minus sign): indicates negative numbers
• . (dot): indicates decimal place
• +: arithmetic addition and string concatenation
• -: arithmetic subtraction and negation
• *: arithmetic multiplication
• /: float division
• %: remainder division
• //: floor division
• (): parentheses
• Logical operators
• variableName: reference a variable
• object.field: reference a value in an object
• object["field"]: reference a value in an object
• list[index]: reference an index in a list
• Expression helpersthat can:
  • Convert data such as int and string
  • Operate on lists, maps, and strings such as in and keys
  • Conditionally access data inline such as default and if

Function expressions

Functions such as len() can be used in expressions, and the functions defined in the standard libraryare all supported (with the exception of blocking calls such as HTTP calls, sys.sleep, and sys.log). For example:

YAML

• initVariables: assign: - project: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}

JSON

[ { "initVariables": { "assign": [ { "project": "${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}" } ] } } ]

Multi-line expressions

You can extend an expression over multiple lines. For example, you might want to create a dynamic string for a SQL query. For multi-line expressions, follow these guidelines:

• String literals must be enclosed in double quotes.
• You can include colons within a string literal.
• Any required whitespace must be added inside the string literal.

For example, to generate "SELECT * from customers\nWHERE id=7", create a step like this:

YAML

• assign: assign: - table: customers - id: 7 - q: ${ "SELECT * from " + table + "\nWHERE id=" + string(id) }

JSON

[ { "assign": { "assign": [ { "table": "customers" }, { "id": 7 }, { "q": "${\n"SELECT * from " + table +\n"\nWHERE id=" + string(id)\n}" } ] } } ]

Blocking calls

Calls performed during a workflow can be either blocking or non-blocking.Blocking calls are calls that block a workflow's execution; they must be resolved before a workflow execution can complete.

Certain functions result in blocking calls if used inside an expression. Instead, they must be run from a call step (see Calls). For example,sys.sleep and http.get cannot be used inside an expression.

The following list contains all the functions that result in blocking calls in Workflows:

• events.await_callback (events.await_callback function)
• experimental.executions.map (executions.map function)
• experimental.executions.run (executions.run function)
• googleapis.* (for connector calls)
• http.* (HTTP functions)
• sys.log (see Send logs to Cloud Logging)
• sys.sleep (see Wait using polling)