Templating
For the YaWL specification fields that support templating, values can be generated dynamically using the data obtained from the workflow state. The templating language is jq. For more information, see the jq documentation
By default, templating is not used for string values of fields; use string interpolation
Input data for the templater
The templater input data will be different depending on the field.
| Field | Payload |
|---|---|
input |
Workflow state before starting the step. For example, if the step is a high-level one, it retains the full workflow state. In contrast, if it is inside a Parallel execution branch, the workflow state is filtered using the input parameter of the Parallel step and updated by prior steps in the branch. |
output |
Step output data |
| Other fields that do not support templating | JSON object filtered by input |
Templater usage examples
Full workflow state example:
{
"data": [
{
"some_property_0": "value_0"
},
{
"some_property_1": "value_1"
}
],
"a": {
"b": {
"c": "value_2"
}
}
}
| Field value | Templater interpretation |
|---|---|
this is just a string |
Non-templated string |
this is a value from workflow state \(.data[1].some_property_1) |
this is a value from workflow state value_1 |
\({x: 1, y: .a.b.c}) |
{“x”: 1, “y”: “value_2”} |
Templater extensions
Templater extensions allow you to call jq functions implementing non-standard logic.
$global variable
The $global variable returns the top-level state of the workflow before starting the current top-level step. For example, in the Foreach step, input data filtering is a required attribute, and the $global variable can be used within the sequence of steps in do to retrieve the workflow state as it was before Foreach started (top-level state).
$counter variable
The $counter variable returns the current operation index (indexing starts from zero). You can use the variable inside the input and condition fields of the While step.
Yandex Lockbox
A special lockboxPayload jq function allows you to get the value of the Yandex Lockbox secret by its ID, key and (optionally) version. For the extension to work correctly, the workflow settings must specify a service account that has permissions to view the secret contents, e.g., the one with the lockbox.payloadViewer role. You can employ this function in any integration step fields except for input.
Description of the lockboxPayload jq function arguments:
| Argument order | Type | Required | Description |
|---|---|---|---|
| 1 | string |
Yes | Secret ID. |
| 2 | string |
Yes | Secret key. |
| 3 | string |
No | Secret version ID. |
Examples of using the lockboxPayloadjq function
-
Getting the latest secret version:
\(lockboxPayload("<secret_ID>"; "<secret_key>")) -
Getting the specified secret version:
\(lockboxPayload("<secret_ID>"; "<secret_key>"; "<secret_version_ID>"))