Overview
Within the processes, Bizagi features the possibility to execute certain tasks asynchronously from the Work portal.
This allows end users to finish up their tasks, regardless of what the next step of the process is, and have Bizagi process that next step as a background task (without user interaction).
In Bizagi, such tasks are known as asynchronous Activities; and through them, you may also configure an asynchronous communication with an external system.
To indicate in the process that certain task needs to be executed asynchronously, you will need to first make sure you use a BPMN-standard Service Task (task of the service or automatic type), and that you set it up with the property that sets it as asynchronous.
Why use asynchronous Activities?
Asynchronous Activities have been especially designed to provide a special treatment where there is the need to integrate with external applications.
Either by means of web services, or direct invocations done through custom components (i.e, Component library), a special treatment is required when connecting to external applications so that these aspects are considered:
•Should the external application be offline (or temporarily off service), then Bizagi will queue up that execution and automatically retry it as an background task.
•Should the execution be delayed, then a timeout will take place, leaving that processing as pending and to be automatically retried as a background task.
•Should the execution be delayed, you can best manage the transaction with Bizagi to avoid potential locks in the database.
Given the nature of an integration point in the process, which has a high possibility of presenting a significantly extended execution time (due to external variables such as: the connection's state, the external application's processing capacity to respond, etc.), it is a best practice and ideal for the overall performance that this transaction is handled apart from other simultaneous activities or pending transactions in the Work portal fired by all end users.
|
Bizagi manages the access to data through its components (such as the Entity Manager), by implementing several measures to avoid locks and optimize persistence operations (i.e, writes to the database). The above allows Bizagi to commit transactions in the database upon users completing Activities in the Process workflow, and have the Work Portal automatically load up and manage next tasks.
Since these transactions are intended to be committed in a fast way, it is best to use the asynchronous treatment for connections with other applications because usually in this scenarios, the time employed for their completion varies greatly (may increase an uncertain amount of time), and you do not have any control over this. |
Asynchronous A2A communication
In addition to the above reasons, this type of task allows you to model in Bizagi an asynchronous communication approach with an external application, by relying also on a BPMN-standard intermediate Event.
In the figure below, notice that you may have Bizagi trigger processing at the external application through the Interface task, and receive an ACK (acknowledgment of receipt) right away from the external application.
The process moves on to a next task, but in the meantime, it also awaits for the completion of the intermediate Event below.
Once the external application finishes up its triggered processing, it can fire in return the Event in Bizagi, by making use of Bizagi's web services API (SOA layer).
Keep in mind that for this model, you would need to send through the initial Interface message all the relevant callback address and information for the external application to notify back to Bizagi (having the Event's id, and any additional metadata).
How do asynchronous Activities work?
Asynchronous Activities are a variant of the way in which a Service Task can execute (though, the preferred variant).
This feature works as described below:
When the process finds an asynchronous Activity, actions set at the On Enter timing of that activity (typically business rules) are immediately processed.
When the transaction associated to those actions at the On Enter timing ends, then the pending actions at the On Exit timing (business rules, web services, components, etc) will be executed in a separate, new transaction.
At this point the completion of that Activity will be represented as pending to the end users (or shown as "processing..." when using a Show feedback property).
This is different from activities not being asynchronous because on the default treatment, both on Enter and On Exit actions will rollback when an error is produced at the on Exit timing.
If the asynchronous Activity fails, then it will be handled in automatic retries by the Scheduler service (as a background task).
Once the execution is retried and successful, the Scheduler notifies to the Work Portal that the next Activity is available (end users will see this Activity as available by looking at their inbox, or by means of an e-mail notification if designed that way).
On the other hand, if the execution continuously failed until the predefined number of retries is exhausted, this activity will be shown under the asynchronous Activities console with a corresponding log (for an administrator to diagnose and review such repetitive errors' cause).
Even when within the process workflow, next steps are as well other asynchronous Activities (chained sequentially), then Bizagi will handle each asynchronous Activity in a separate transaction so that each will handle a rollback to that given point.
How to configure an asynchronous Activity?
Asynchronous Activities are defined when creating the Process model (in the first step of Process Wizard by using BPMN-standard Service Tasks).
From that point, you may configure each of the Service Tasks to work as asynchronous Activities.
To configure it, from the step #1 of the process wizard in Bizagi Studio (Modeling the process) carry out the following:
1. Right-click a Service Task and choose the Properties option.
2. Locate the set of properties for asynchronous treatment under the Runtime tab.
3. Enable the Is Asynchronous property.
Once enabled, enter the details for the asynchronous execution parameter which mainly consider how to handle errors that may occur during its execution.
Refer to the following table for detailed information on each parameter.
PARAMETER |
DESCRIPTION |
RECOMMENDATION |
|---|---|---|
Retries |
Determines the number of times that the asynchronous execution will attempt its actions automatically, should it fail. |
It is strongly recommended to use this property and set at least 1 automatic retry. Failed executions which are not successful even on retries, indicate that your external service is experiencing issues and should be addressed by an administrator. |
Retry Interval |
Holds an interval of time in minutes that Bizagi will await for, before retrying another execution (should it initially fail). |
It is strongly recommended to use this property. Set a retry interval that is sized according to your external service's SLA. |
Show Feedback |
This property is useful when you have actions which are likely to execute under a relatively, really fast time frame.
This is so because when this property is marked, Bizagi will immediately execute the Activity through its Work Portal (interactively), having a wait page displayed to the end user while the request is processed. Hence, once the invocation is successful, the Work Portal will load up automatically the next task of that user if he/she has any assigned in that same case. The advantage provided by using this property is that the end user will be able to see almost immediately that the task has been completed and that his/her next pending task is available (because otherwise when this property is disabled, the Work portal will just display to the user a message indicating that this execution has been scheduled and not load up the next task).
If the execution fails or is delayed, the end user will either see the summary form or be prompted about the error (at this point, users should contact the administrator). Still, failed executions will be processed by the Scheduler as background tasks. |
If you are using this option, it is really important that your timeout property is not defined as a large number (i.e does not exceed for instance 10 seconds). Otherwise using the Show feedback property is not adequate. |
Timeout |
Defines a time interval in seconds setting the maximum waiting time in which Bizagi will expect the execution's response. The external application needs to responds to in a timely fashion, in between that time interval, otherwise Bizagi will cancel that pending operation. |
It is strongly recommended to use this property. Set a timeout that is sized according to your external service's SLA. The default value is 0, and this means that the timeout for the Asynchronous Activity is 30 seconds. If the timeout is a very large number, then it is recommended that you evaluate using an asynchronous A2A communication.
If you are using the Show feedback option, it is really important that your timeout is not defined as a large number (i.e does not exceed for instance 10 seconds). Otherwise using the Show feedback property is not adequate.. |
Administration of asynchronous Activities and retries
Notice that a number of retries can be configured so that, should an asynchronous Activity fail, Bizagi can automatically retry it without user intervention.
The Activity will not be retried automatically when the number of retries is exhausted.
In these cases, the intervention of an administrator will be required, who will be able to use the asynchronous Activities console options in the Work Portal (to review and manually retry these exceptional cases).
To view more information about these Administration options, refer to Asynchronous Activities Administration.
Last Updated 1/23/2023 12:05:09 PM