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
, andurl
sections - Call subworkflows
- Apply conditions
- Retry values, including
max_retries
andmultiplier
- 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 variableobject.field
: reference a value in an objectobject["field"]
: reference a value in an objectlist[index]
: reference an index in a list- Expression helpers
that can:
- Convert data such as
int
andstring
- Operate on lists, maps, and strings such as
in
andkeys
- Conditionally access data inline such as
default
andif
- Convert data such as
Function expressions
Functions such as len()
can be used in expressions, and the functions
defined in the standard library
are 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)