Perform stateless execution of Bot Tasks
Definitions
Stateless Execution is a feature that allows the execution of Business Process Bot steps in memory without saving intermediate results to the database.
Business Cases
This feature is handy for the business processes of chatbot execution.
- Bot steps can be logically joined into one long transaction (Bot steps chain). Only input and output are essential for this transaction (this particular Bot steps chain). Intermediate results and analytics are not visualized as the intermediate data are not saved.
- Results data of the intermediate steps are confidential and should not be saved to the database.
Benefits
Performance: the transition records between steps are accelerated while the database load is decreased.
Confidentiality: results from the intermediate steps of the stateless execution chain are kept in memory only without storing in the database.
Multi-step transaction execution: a single logical transaction (for example, placing an order) can be split into multiple steps (log in, navigate to the order page, submit the order, and log out). Should a step fail, the transaction processing will start from the very beginning without retrying to complete the failed step.
How to use
In Business Process Designer, the step context menu has a new item called Stateless Execution, as shown in the image below.
To enable Stateless Execution, select the following option:
If a Bot step is selected for Stateless Execution, its border will be shown as the dashed line to distinguish it from the normal Bot task execution.
note
The stateless execution is aimed to be used in a chain of a few bot steps, rather than a single task.
Records transition between Step1 > Step2 and Step2 > Step3 occurs in memory.
Pipelined execution
You can create any number of stateless steps and arrange them into a single chain. As a result, you execute several Bot tasks as a single transaction on the same worker without queueing.
This pipelined execution should be applied only for the chain of stateless steps, for example:
The feature is enabled by default and automatically detects pipelines in the BP executions. Automation engineers only have to annotate the required Bot steps as stateless to use this capability. Your steps must satisfy the following conditions to be used in a pipeline:
- There must be a minimum of two linked stateless Bot steps.
- All steps in the pipeline must be of the ct-worker type only. No AutoML, OCR, or RPA steps are allowed in the pipeline.
- There must be no business rules between chained stateless steps.
- Steps must have no bot sources.
- Steps can have Bot Config Bundles.
Constraints
Only the first stateless Bot step will be created (and stored in the database). The next bot steps of the stateless execution chain will be made in memory only. No statistics on intermediate steps are available.
Results tab: Second column step is not created. All processed results are stored in One column step.
The WebHarvest context objects, such as AwsHitDto or RunDto, are created once in the first step of the stateless execution chain and reused in the next stateless steps.
See the details in the table:
DTOs type Created in the first step Created in an active step RunDto X AwsHitDto X SubmissionDto X AwsHitAssignmentDto X AutomationInfoDto X CampaignDto X ProxySettingsDto X End step of a sub-process is always in the Stateless Execution state. It prevents the chain from being broken when using sub-processes.
For a Stateless Execution step Split record and Split data are not supported
One record into several, and one record goes after rule to several branches (like split_rule Join_rule).
If the "Split Rule" composite rule has the SPLIT_DATA option, a user will see the following validation message when saving the process.
Record processing fails if it tries to go through more than one step after the "Split Rule" rule has been executed. The error message appears in "Events".
Threshold for streaming between stateless steps is always 1 Task
Release plugin is not supported in stateless bot tasks.
If the release plugin is used, results are not exported, and the minimum execution date is applied to the hit at the beginning of the chain. So it behaves similar to retry.All errors in the Event log are only related to the first stateless step. Each failed stateless step will be mentioned in the message.
In case of failure in the middle of the stateless execution chain, Repair/Retry starts from the first stateless step.
Start, End, Manual Tasks, and Rules cannot be marked as stateless.
Additional cases
A step can take part in the stateless execution chain and regular execution simultaneously.
Example: After the first step, five records go to the Yes outcome, and five records go to No:
Third column step does not have statistics from stateless execution, but only history about five records from the regular execution.
Single Stateless Execution step works like a regular step with statistics and stores the results in the database.
Troubleshooting
Performance analysis
To analyse performance gained from executing a step as "Stateless" you can use a jstack to identify the required step. The jstack contains the following information: run-{run_id}-hit-{hit_id}-step-{step_id} (if step_id is not presented, it's the first step).
Once the step has been identified, you can analyze how fast the step is executed as "Stateless" and as a regular. Additionally, you can check the information in the logs.
Business Process Example
The Business Process contains ~ 30 steps with several conditional rules, all of the steps are marked as stateless.
The execution time of each record is logged to Event Log and a Data Store (MonitorExecutionDataStore), so the execution time improvements can be measured by running this Business Process with or without the stateless option enabled for the steps.