Asynchronous Activities Console

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > System maintenance and monitoring > Environment settings and administration >

Asynchronous Activities Console


When there are integration points in the processes where a Service-type task is used (to either invoke a Web or REST service or to use custom code for an advanced business rule -though the Component Library), Bizagi allows these types of tasks to be configured for asynchronous execution.


When defining a BPMN service task as an asynchronous activity, Bizagi allows setting a number of retry attempts (retries), in case the activity's integration actions fail to respond in a given threshold (usually, an invocation to an external service).

Whenever an asynchronous activity fails (i.e. an external application' service is not operational, there are connectivity issues, etc) and surpasses the number of predefined retries, Bizagi offers the possibility for an administrator to review, follow-up/diagnose and manually retry such operations.


Before you move on

Consider that such retries and asynchronous treatment, are all configured by you from the very definition of that BPMN shape (from the development environment and the process' design):




In the image above, we see the configuration parameters for an asynchronous activity, as it is defined while modeling the Process.


Within the administration options for any asynchronous activities, Bizagi will store a log having which process instances (cases) failed to complete specific activities and the corresponding reason (an error message).

Through this console, most importantly, the administrator will be able to manually retry these failed activities.


Asynchronous Activities Console.

To access this option, click on the Admin menu in Bizagi Work Portal.

Click on Asynchronous Activities Console in the displayed menu options.




This option allows the business administrator to decide which Items to retry, individually or grouped, and to view the retry log or choose to abort cases (should this be necessary).




Notice you will be presented with a table having all Failed Asynchronous Activities with overall following information such as: A log with execution's detail (error message), the case number to which the Activity belongs, the Activity's name, the number of retries so far, the date in which the Activity was first created (attempted), and the latest retry date.


Retry an Item

To manually retry an Asynchronous Activity, select the Asynchronous Activities tab and click the icon under Retry now column for the corresponding row.




Retry Specific Items

To retry more than one item at once, select the items to be retried in the Asynchronous Activities tab and then click the Enable Asynchronous Activities button.

These items will be marked for automatic retry, which is carried out by the Scheduler (the service installed for each Bizagi project which performs certain jobs at a given interval).




Retry Items in Group

Bizagi allows the user to retry all the items that have failed grouping by Process or Activity.

This retry is not performed immediately, it is executed by the Scheduler (see the detail in the above option).


For this, select the Grouped by Activity tab.

Click on Enable  at the Delegate retry to Scheduler column, for the Scheduler to retry in batch those grouped activities.




Notice you may enabled grouped Activities per Process.


See Retry Log

To see the retry log which has execution detail (the error message causing the failed Asynchronous Activity), click on the icon under the Log column.


On the Asynchronous Activities Log, you will find the history for the retried attempts' date and specific error message.