Launch Multiple instances asynchronously

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Process wizard > Model Process > Modeling for execution > Sub-Processes > Understanding Multiple Sub-Processes > Advanced configuration for Multiple Sub-Processes >

Launch Multiple instances asynchronously

Overview

Multiple sub-processes can be configured to be launched asynchronously with an advanced configuration in the process properties.

This is especially useful when the parent process launches hundreds or thousands of instances of the multiple sub-process.

When a process launches several instances of a multiple sub-process the recommendation in to set them asynchronous, otherwise the performance of the Work Portal can be highly compromised.

Multiple sub-processes that are launched asynchronously will be handled by the scheduler and not by the Web application. Thus, there will be no performance issues for end users.

 

Asynchronous configuration

To configure a multiple sub-process to be launched asynchronous go to the first step of the process wizard. Right click the multiple sub-process shape and select its properties.

 

 

AsynchMultiple1

 

 

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 the 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 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.

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 execution 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.

It is strongly recommended to use this property..

 

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.