Variable Substitution in Workflow Engine Actions
In certain scenarios, you may want to use a variable or dynamic value as a function parameter in the Moogsoft Onprem Workflow Engine. For example, when setting the value for an alert class, you may not want to specify a single class for all alerts. Instead, you may want to dynamically set the class based on the value of an existing custom_info value.
Workflow Engine string and JSON object parameters accept macro syntax to allow for variable substitution. The Workflow Engine calculates the specific value for the parameter at runtime based upon the value of the in-scope object or the workflow context.
The workflow context is a JSON object where you can temporarily store data during workflow execution. It is useful for holding data that may be required to construct field values or pass to other workflows, without storing it in the in-scope object.
Number type parameters do not support variable substitution. The UI validation prevents macro syntax for number parameters.
Variable substitution and macro syntax
The syntax for substitution is as follows:
$MACRO(<object field>)
Example: $EXPAND(severity) substitutes the severity name for the current object as the value. For instance, "Critical for severity 5." See Macros Reference for syntax for specific macros.
When to use variable substitution
In general, consider using variable substitution when a function requires a “value”. For example, setClass or appendString.
If a parameter requires a field name, variable substitution is unlikely to be appropriate. For example, upperCase.
See the following examples that show the usage for variable substitution in different scenarios:
Field Names in Workflow Actions
Additionally, some action expect fields as arguments. Unless explicitly stated, these fields can similarly be generic paths to data held in either the in-scope CEvent object or workflow context. In either case, the following conventions are followed to access the required data:
Field Prefix | Example | Description |
|---|---|---|
|
| The “assignment_group” key in the workflow context. |
|
| The “assignment_group” key from |
|
| The “assignment_group” key from a payload stored in the workflow context. |
- |
| Anything else is treated as a core CEvent field from the in scope CEvent object. |
Note that the payload prefix is different from the other prefixes in that it refers to the structure in the workflow context created by one of the following actions:
This prefix enables access to payload data in workflows, allowing actions that accept generic field arguments or substitutions to be used on payload data.
Note
The payload created by the getPayloadFromInform action is stored in a different location to the CEvent payloads produced by the other actions. As a result, in resolving a payload field path, we first check for the existence on inform payload and then for a CEvent payload. In the unlikely event that both an inform and CEvent payload is used in the same workflow, the CEvent payload should be created and manipulated first before creating the inform payload.