Functional blocks of the workflow scheme:
Initially, the empty scheme contains: the Start block, the workflow scheme scaling tool and the scroll bars.
Visually, the blocks are not connected in any way. When adding blocks to the scheme, you must add connections between the blocks manually, using the block
The Start block is the starting point of the workflow.
Its main purpose is to indicate the workflow start point and to set workflow parameters that can be used in any subsequent block in the workflow scheme.
The panel with workflow parameter properties opens to the right of the workspace of the Workflow Constructor and looks as follows:
Each workflow parameter has its own panel on which it is placed:
Example of a parameter setting:
String
The value of a parameter of this type can be specified using letters of any alphabet, numbers and symbols.
Boolean
This parameter can take only two values - True or False (in any case).
Number
The number can be positive, negative, floating point or fixed point.
With the Add Parameter + button, several workflow parameters can be added to the Start block. Each new parameter will be numbered in order:
A workflow parameter can be deleted from the parameter list using the trash can icon located in the upper right corner on the property bar of the specific parameter to be deleted.
The Finish block is used to indicate the process end point and, if necessary, to set the workflow result parameters. Any input and/or input parameters of the workflow/task/SF/subprocess can be used as result parameters.
The choice of process result parameters is left to the process designer: the designer sequentially adds result parameters to the Finish block, names them and links them to workflow/task/SF/subprocess parameters.
For the workflow, the scheme of which is shown in the figure below, the robot output parameter “Addition of 2 numbers” is chosen as the final result of the workflow, which adds 2 numbers: the degree of the first workflow parameter and the area of a circle with radius equal to the second workflow parameter.
The Robot block performs a robotic task. The block has 3 common properties:
To select a robot as the executor of the task, click on the Select a robot button.
When you click on the Select a robot button, a list of ready-made robots appears, in which you must select the one that will perform the task. The robot is selected using the left mouse button. As an example, we have selected the robot Increasing a number to a degree, which, as the name implies, increases a number to a degree:
If it is necessary to change the color of the block - it should be set using the Fill parameter.
The Performance conditions parameter - if the wait for all radio button is selected, the block waits for the execution of all guides included in it. If wait for one is selected - the block expects at least one guide to be executed.
Once the robot is selected, the Robot block property panel will display:
The remaining properties must be filled in by the workflow designer.
In a special launch, the designer is given the opportunity to choose:
This setting is also used to specify a specific machine to start the robot during operation. It is important in cases where access to information systems is restricted.
Fields for robot input parameters appear automatically based on the robot's internal specification. The designer only has to link them either to workflow parameters or to parameters of previous tasks.
In our example, we will bind the robot input parameters to the workflow parameters: x1 and n1, which are set in the Start block:
It is very easy to bind robot input parameters to workflow or task input parameters. To do this, in the field for each input parameter of the robot, you need to select the desired workflow or task parameter from the dropdown list. In our case we need to select the workflow input parameters x1 and n1:
This completes the work with the Robot block.
The Screen form block is used in the workflow as a user task.
The block has properties that are filled in or selected, depending on the purpose:
| Properties | Purpose | |
|---|---|---|
| 1. | Task name | Filled in automatically after selection of SF |
| 2. | Description of SF. | Filled in automatically after selection of SF |
| 3. | Block color | Filled in by the workflow designer |
| 4. | Responsible | Selected by the designer from the list, the default executor is Initiator |
To select an SF for a user task, click on the Select a screen form button.
When you click on the Select a screen form button, a modal window opens with a list of published screen forms, from which you should select the one that will be used as a step to perform a user task:
No. | Name |
|---|---|
1 | Header of the modal window |
2 | Number of screen forms in the list |
3 | Search bar for SF by its name |
4 | List of screen forms with fields |
5 | Screen form - the name of the SF |
6 | Version - SF version |
7 | Author - the workflow designer who created the SF |
8 | Date of publication - date and time of publication of the SF |
9 | Navigation bar for SF list pages with selection of the number of screen forms to be placed on the page |
10 | Choose button - when this button is clicked, the SF for the user task is selected |
11 | Cancel button - if you click on this button, the modal window is closed |
12 | Cross icon that closes the modal window when you click on it |
Suppose we want to select from a list of SFs named SF No.1.
Actions to be performed:
The remaining properties of the SF:
Performer
Block color
Priority
Deadline
Input parameters
are filled in by the workflow designer.
Performer is an individual, an employee of the company and at the same time a user with the role of Task performer, who will work with the SF.
By default, the task performer is the Initiator.
An initiator is a user who can initiate the start of a workflow, whereby they become the default executor of the workflow tasks where the executor is specified as Initiator.
If the workflow designer wants to assign one specific employee to a user task, he must select him from the list of users.
If the workflow designer wants to assign several employees from a specific group to a user task, he must select this group of users as executors. In this case, each user with the role Task Performer from this group will be given the right to take over the task and whoever takes over the task first will be the performer.
Each workflow is assigned a group of users with different roles who work with the workflow. The Task Performer must be a member of this group if there are user tasks in the workflow. So, when you click on the Performer dropdown list, the following should appear:
The user or group of users is also searched by the first characters entered.
Block color is a common optional property of any block. It is filled in the same way as for all other blocks.
The workflow designer can set the priority of a task to be used by its executor when selecting the next task, if several user tasks are in progress at the same time.
A task may have the following priorities:
The deadline is set in days, hours and minutes and is counted from the moment the task is available to a specific executor or group. If the deadline expires, the performer, workflow owner and workflow administrator will receive a notification that the deadline has expired, if they are all subscribed to this type of notification. Upon receiving such a notification, the workflow owner must find out the reason for the delay in execution and take the necessary measures to eliminate them as soon as possible.
The input parameter fields are created automatically based on the internal specification of the SF. The workflow designer only has to set the values of these parameters.
As with robots, the input parameters of the workflow at the Start block and the output parameters of the preceding task can be used as input parameter values.
For example, the workflow shown in the figure below has 2 input parameters a and b. The SF No. 1 also has 2 input parameters. We can link the values of the input parameters of the workflow to the input parameters of SF No.1:
In this case, the task performer will see 2 fields in SF No.1 during work with the workflow parameter values that were set either by default or at startup.
The logical gateway AND is designed to parallelize the workflow by branches. The number of parallel branches is unlimited and they must converge in one task (robotic or user).
The block has properties:
The logical gateway OR is intended for branching a workflow based on a condition. The condition can be one or several.
The condition is set only after creating a connector with the subsequent blocks of the scheme. The number of block conditions to be set is equal to the number of connectors (workflow branches) coming from the block.
In the scheme shown below, the OR block has two outgoing guides to the two Robot blocks:
Accordingly, such a block will have 2 conditions. The conditions are located under the general properties of the block in the Conditions panel. Conditions are set using the condition constructor. To set a condition, click on the Gear icon near the selected condition.
As a result, the following modal window of the condition constructor will appear:
In the condition constructor you can specify one or more conditions connected by the logical operator AND or OR. Each condition is defined by 2 operands (first and second parameters) and a logical operation between the operands.
Both workflow parameters and output parameters of other functional blocks preceding the OR block can be used as parameters of the condition.
The first parameter is always selected from the parameter list.
The second parameter can be selected either from the parameter list or set immediately with its own value.
The following logical operations on operands are available in the constructor:
Operands can be both numeric and string parameters.
As an example, let's set a condition for our OR block for the branch Condition 1 of the following form: x1 >= 0. This can be done using two conditions connected by the OR operation:
Save the condition by clicking on the Create button.
Similarly, create the second condition for the branch Condition 2 of the type: x1 < 0:
As a result, we get 2 conditions at the OR block:
Conditions can be edited at any time by clicking on the Gear. To delete a condition, click on the cross icon on the conditions panel or on the Bin in the condition builder.
The Workflow block is designed to use another workflow that has already been published to execute a business task. The configuration of this block is very similar to the work with the Robot block.
The block has properties:
To select a workflow as the executor of the task, click on the Select a workflow button.
When you click on the Select a workflow button, a list of published workflows appears, in which you should select the one that will perform the task. The workflow is selected with the help of the left mouse button.
As an example, the robot Addition of two numbers is selected, which, as is clear from the name, performs the addition of two numbers:
We used the search bar to select the workflow.
After selecting a workflow, the properties panel of the Workflow block will show:
The remaining properties must be filled in by the workflow designer.
Fields for subprocess input parameters appear automatically based on the internal specification of the subprocess. The designer only has to link them either to the main workflow parameters or to the parameters of previous tasks.
In our example, we will link the subprocess input parameters to the main workflow parameters a and b, which are set in the Start block:
It is very easy to link the input parameters of a subprocess to the input parameters of a workflow or task. To do this, in the field for each input parameter of a subprocess, you need to select the desired workflow or task parameter from the dropdown list.
In our case we need to select the workflow input parameters a and b:
The API block represents a link in the workflow to the REST API, which manages sending requests to an external server and processing responses from it.
The API block has the following parameters:
| Parameter | Description |
|---|---|
| Name | This is the name or identifier of the block that is used to designate a specific REST API action |
| Description | This is a brief explanation describing the block |
| Block color | Block color coding that can be used for visual differentiation |
| Performance conditions | If the wait for all radio button is selected, the block waits for the execution of all guides included in it. If wait for one is selected - the block expects at least one guide to be executed. |
| REST service URL | This is the address of the web service or API to which the request is directed. The URL points to the specific resource or endpoint to be processed. |
| Authorization | This field specifies the authorization method used to access the REST API. It can be basic authorization, authentication using tokens, or another method |
| Token | This field is for specifying an authentication token that is required for authorized access to the REST API resource. The token is used to verify access rights to protected data. |
| Method | Specifies the HTTP method to be used when sending the request. GET Used to retrieve data from the server POST Used to send data to the server, for example, to create a new resource PUT Used to update an existing resource on the server DELETE Used to delete a resource from the server |
Get file | Checkbox to indicate whether the file should be retrieved |
Disable SSL verification | Checkbox to disable SSL certificate validation |
Selecting a proxy server | Here you specify the proxy server that will be used to send requests |
Results | Response Status - HTTP status code returned by the server that indicates whether the request succeeded or failed Response Headers - HTTP header information returned by the server, such as content type, response time, and more. Response Body - The main content of the response, which may include data in JSON, XML, text, or other format. |
The Note block does not affect the workflow and is intended for the workflow designer - present or future - who will take it to them for revision or rework.
The note can include any considerations regarding the purpose of the workflow, the principles of the workflow design, and the specifics when executing the workflow.
A block has the following properties:
The designer enters the text of the note and changes the rest of the block's properties as needed to their liking.