<< Click to Display Table of Contents >> Navigation:  Low-code Process Automation > Studio Cloud - Authoring environment > Bizagi Studio > Process wizard > Model Process > Best Practices in process modeling > Managing parallelism in Bizagi

Overview

In Bizagi, there are instances where it is necessary to store information within the same Master entity (Bizagi table), entered or populated by different users (Performers) concurrently. This can occur in scenarios involving parallel activities or instances of parallel sub-processes.

 

For instance, consider an apparel company conducting regular evaluations of different vendors. In this specific process, two managers are required to concurrently record their evaluation scores and comments through parallel activities, as illustrated in the business process below.

 

 

 

Business scenario

Continuing with the previously outlined vendor evaluation process, it is crucial to store the evaluation scores and comments provided by each manager in the Master entity called mEvaluationResults. This implies the creation of only a single entity instance, underscoring the importance of handling the creation and persistence of this unique instance accurately within Bizagi's database. A solid understanding of the use of scopes in Bizagi is imperative to adopt this best practice approach in managing parallelism.

 

Within each manager's activity form, there are three mandatory fields from the Master entity mEvaluationResults. However, it's noteworthy that the XPaths for registering evaluation results differ for each manager, as outlined in the XPath tables below.

 

 

 

Once the requester has submitted the details of the product/service and the basic information of the vendor, two activities are triggered for each manager, each having its own scope. Since the evaluation fields pertain to the same entity (mEvaluationResults), the common XPath is mVendorSelection.kmVendorToEvaluate.kmVendorBasicInfo.kmEvaluationResults, as indicated in the process data model.

 

Without a default or initial value set and persisted in the Bizagi project's database within the mEvaluationResults table before the instantiation of the two Evaluate Vendor activities, Bizagi creates separate scopes for each activity. Consequently, the table contains two distinct instances created in each scope. Upon completion and submission of the vendor evaluation by the last manager, Bizagi overwrites the values of the first instance in mEvaluationResults, resulting in the loss of inputs provided by the initial manager.

 

Best practice

The recommended approach is to establish a business rule to be executed before the creation of the two activity instances. For instance, this rule could be set as an On Exit action in the activity Register Vendor Basic Info or as an On Enter action in the parallel gateway PG1.

By taking this step, Bizagi ensures the persistence of a unique instance in the mEvaluationResults table in the database. Consequently, no conflicts or issues arise when the two scopes for each Evaluate Vendor activity are created subsequently.

 

 

Alternatively, the workflow can be adjusted by eliminating the Register Vendor Basic Info activity. Instead, a start form can be implemented to prevent the creation of new cases (process instances) that may not be submitted from that initial activity. This is illustrated in the following workflow diagram:

 

 

Here, the business rule used to set a default value can be configured either as an On Exit action in the Start event or as an On Enter action in the parallel gateway PG1.

 

 

The following two lines of code set a default date for the Evaluation Date fields for each manager:

 

<mVendorSelection.kmVendorToEvaluate.kmVendorBasicInfo.kmEvaluationResults.dEvaluationDate1> = DateTime.Today;
 
<mVendorSelection.kmVendorToEvaluate.kmVendorBasicInfo.kmEvaluationResults.dEvaluationDate2> = DateTime.Today;

 

Upon execution of these lines of code and the successful completion of the transaction, Bizagi generates a unique instance in the Master entity mEvaluationResults. Specifically, this results in a distinctive value for <mVendorSelection.kmVendorToEvaluate.kmVendorBasicInfo.kmEvaluationResults.Id>.

 

Further recommendations

1. Avoid common fields in Parallel Activities

In scenarios where parallel activities are instantiated, such as in the vendor evaluation example, it is crucial to refrain from having common fields in the forms for each activity. This applies to both editable and non-editable fields. For instance, the Evaluate Vendor activity for Manager 1 should not include fields from the Evaluate Vendor activity for Manager 2.

 

2. Prevent data inconsistencies with shared Master entity records

Be careful when dealing with the same record from a Master entity in cases involving parallel instances. Data inconsistencies may arise, especially when two different cases (process instances) use the same record of a Master entity to edit or update values. For example, if two process instances are created by different case creators to update a vendor's basic info, only the values submitted by the last user completing the update action are persisted in the project’s database, leading to the overwrite of values entered by the first user.

Last Updated 1/16/2024 1:27:45 PM