Blocks
Workflow logic is defined by one or more operations that are represented by blocks. Each block is a single operation that has a type and parameters. The execution of a workflow always begins with an input block. Some block types request a user interaction and pause the entire workflow process until a response is received. When the execution of a block is completed, the workflow looks for the next block.
Function blocks can have a return value. After a block is executed, the result of the invocation is stored in the environment variable with the name of the block. So every block can retrieve values of all previously executed blocks by referring to the environment variables. If the block is not yet evaluated then environment variable equals null. Also, the result of the previous block execution is available as the environment variable with the name value. If there is no previous block execution value, null is returned. This environmental variable is nullable.
Control flow blocks manage execution of workflow steps based on conditional logic, directing execution flow down different paths depending on specific conditions or criteria.
Each block is represented in the workflow builder with a graphical component.
Block Groups
There are three main types of block:
Connecting Blocks
Each block has pin points for connecting with other blocks by connectors. The incoming pin points are always on the left of the component, the outgoing pin points are at the right. An incoming pin point can receive connections from several connectors. An outgoing pin point can connect to only one connector.
Expressions and Bindings Resolution Environment
The behavior of each step is managed by Parameters. Expressions that can appear as the block parameters, as well as parameter bindings described below share the same environment. After a block is processed, the result of its invocation is stored as an environment variable with the name of the block.
Parameter Expressions and Binding Expressions Resolution Environment:
A Workflow context itself.
The table is passed as input parameter when the workflow is started. The table is not shared between tasks. A table is cloned for each task.
Variables for each result of the functional blocks and previously evaluated block of the workflow. These variables are local and have different values for each task.
Parameter Bindings
If it is required to have a dynamic behavior of a block then its parameter bindings should be used. These bindings will be evaluated before each step execution, and parameters specified as binding targets will be overridden by binding expression results.
 | Example: An operator is required to enter an explanation text, then show the explanation on monitor. With the UI procedure block "Edit Text", we prompt the operator to enter a text message, then pass this text as the parameter to the “Show Message” block. So the following parameter binding should be added in the block which calls the UI procedure "Show Message":
Where  |
Was this page helpful?