Parameters are an important aspect of Boomerang Flow, allowing for a powerful inheritance model, and can be set and represent the many different parts of the application. They are available throughout a Workflow or Task and are substituted at execution time.
You can reference parameters in a Task using the
There are a number of caveats with parameters.
- Must only contain alphanumeric characters, hyphens (-), and underscores (_).
- Must begin with a letter or an underscore (_).
The following table lists the parameters and when they are available to be substituted in an execution. Additionally, parameters have an inheritance order based on the layering order indicated below. For example, defining a parameter with the same name at the Team and Workflow level will lead the Workflow parameter to override and replace the value for the Team parameter, unless referenced directly using scope.
The substitution is performed by the Workflow service when a Workflow is executed.
|Parameter Scope||Available When?||Syntax||Example|
|Global||Throughout the Workflow lifecycle. These are defined in Boomerang Flow by Administrators.||
|Team||Throughout the Workflow lifecycle. These are defined in Boomerang Flow by teams.||
|Workflow||Throughout the Workflow lifecycle. Created and set by a user through Editor inputs.||
|System||Specific reserved parameters available at the execution of a Workflow.||
|Params||The flattened parameters with all inheritance and substitution resolved.||
|Task Results||At completion of a Task execution, these parameters can be referenced by other Tasks during the same Workflow execution.||
Although Tasks themselves have input parameters, these are defined as part of the Task template and are only able to be referenced within the Task template or by the Task code itself.
The following are the reserved parameters provided by Boomerang Flow.
||This is the user-specified name of the executing Task. It is unique to a Workflow.|
||This is the unique identifier for the established Task in this particular Workflow.|
||This is the categorization of a particular Task. Options are
||This is the unique identifier for this Workflow.|
||This is the user-specified name for the Workflow.|
||This is the revision or version of the Workflow currently being executed.|
||This is the unique identifier for the particular execution of the Workflow.|
||This is the user ID of the initiator of this activity.|
||This is the trigger that created this Workflow activity or execution.|
||This is the URL including domain name and context for the webhook endpoint. It is useful if you programmatically want to provide a callback URL from an endpoint triggered by your Workflow.|
||This is the URL, including domain name and context, for the wait for event endpoint.|
||This is the URL, including domain name and context, for the event endpoint.|
A subset of System parameters are tokens, which allow you to dynamically reference a token programmatically in your Workflow. This can be useful if you are sending a wait for event endpoint in an email body and need to dynamically provide the token that will be used to authenticate.
||The specific token using the token label (set at creation time) to retrieve the token.|
All Tasks can have result parameters, which as mentioned above, can be used by other Tasks in the Workflow. They are also available at the completion of a Workflow using the execution status API.
Some Standard Tasks will output result parameters.
See Custom Task architecture for more information.
As this Task is a bring-your-own container, we have provided two mechanisms for setting result parameters.
||Any key value pair in the format of an environment variable can be placed in this file. At the termination of the worker, these will be turned into result parameters.|
||Any file in the
Boomerang Flow parameters are very similar to what you will find in Tekton® parameters and will be familiar to some of our users.