Overview
In Bizagi you can reuse business rules to accelerate your implementations and build and maintain processes more efficiently.
Reusability in Bizagi is promoted by having those business rules which are frequently used in a project, be created only once and then they are simply associated to the BPMN shapes of the processes, whenever required to be executed.
Types of business rules
There are two types of business rules: Boolean rules and Scripting rules.
Each type provides the flexibility and ease of use so their development is as powerful and yet as friendly as possible.
Depending on where you use business rules, Bizagi will suggest and support the use of one or the other.
•Boolean rules
These rules must only return True or False.
As hinted previously, Boolean rules are used to run the logic behind:
oRules associated with sequence flows (i.e., to route the Process).
oRules used as conditions for attributes (i.e., fields in the forms), so that it is determined if such fields are visible, editable or required (or not).
Notice the Reusable checkbox on the lower left corner. If the rule can be reused, tick the box.
•Scripting rules
These rules are the ones that perform calculations and validations.
In these rules you can write code (add scripts, as its name suggests), to carry out any type of task; and they do not have to return any type of data in particular.
These rules are used at:
oOn Enter, On Save, or On Exit actions
oValidations performed on Tables in Forms
oButtons on Forms
These rules are always reusable.
However, their reusability is available and depends on the context/scope of these have been created; meaning they could be reused by any Process in the whole project, by any Process within the same application, or just by a same Process.
Context/scope of business rules
Bizagi has four levels where Business rules as saved and according to that they can be accessed to be reused.
These levels represent the context/scope for which these are applicable.
These four levels can be categorized as:
•Global rules / Library rules:
These can be Boolean and Scripting rules. They are general rules that can be accessed and reused by all Processes in all applications, so they usually perform calculations that apply to several Processes, with no context. You can create families of rules to order them. If the rule is created as Function it will be used as library rule. This way, it can be called upon other rules to perform calculations.
|
Library rules work just as business rules, but they do not have a context associated to them since they can be invoked from anywhere on the project. This means that from Library rules there is no access to the Data Model, thus XPaths can't be used. Given this, avoid the use of any Xpath function or Me, such as Me.getXPath, or Me.newCollectionItem, or <count(XPath)>. |
For more information about this topic, visit the following article.
•Application rules:
These can be Boolean and Scripting rules. They can be accessed and reused by all Processes in a single application. They usually perform general calculations that can apply to Processes that share a context. You can create families of rules to order them.
•Entity rules: these can be boolean and scripting rules. They can be accessed by any Process in any application as long as the entity where the business rule is saved is part of the data model. The boolean rules in entities manage whether or not controls are visible, editable or required. Scripting rules are attached to buttons and validate Tables.
•Process rules: these can be Boolean and scripting expressions. They can be reused exclusively by the Process; any other Process will not be able to 'see them' to be reused. The Boolean rules are the ones related to the routing of the Process. Scripting rules are the ones related to On Enter, On Save and On Exit actions. When you create your rules to route the Process or On Enter, On Save and On Exit actions, through the fourth step of the Process wizard, these rules will be automatically created as Process rules.
Example of an Application rule
For the loan application, you need to provide some initial information about the applicant. Before the applicant is accepted as a client, the forms will need to show or hide some controls. Thus, you need a visibility rule that can be used in several forms of the same process.
Note that this rule has a context, because it relates to the applicant of the request. Thus, the context will be the Process Entity of the parent process. Thus, we create an application rule that returns True or False according to the customer evaluated.
In the Expert view go to Business Rules. Right-click Expressions in the Application where you wish to use your rule. Select New Expression.
You will be asked to decide between a Boolean and a Scripting rule. In this case we select Boolean.
Drag and drop the data to evaluate and select the condition.
Finally give your rule a name. If you have Families of rules created you can allocate this rule to a family in the Rule Family drop-down list, or leave it blank.
We can use this rule in the Forms Modeler for a Process in the chosen application.
Open the Forms Modeler, select the attributes that you wish to hide if the applicant exists as client.
Example of an Entity rule
In a Purchase Request Process there is a collection of products, where the end user enters all the products needed.
There is a one-to-many relationship between the Process Entity, Purchase Request, and Products Requested.
The end user enters each product specifying the unit price and the quantity. Then, when the record is saved, it is necessary to calculate and display the total price of the product, that is, the unit price times the quantity.
We calculate this amount using an Edit Validation Expression. These rules are related to the Forms modeler where they are automatically saved in the collection entity. Thus, they can be reused by any Process that also has the collection entity in its data model.
In the Forms modeler select the Table where the rule will be placed.
Select the Edit validation expression. This will open a scripting rule to write the code. Note that since we are working over a collection the context of the rule will be the collection entity, in this case Products Requested.
When the end user saves the new product, the total price will be calculated.
Example of a Process rule
Bizagi will store as Process rules the one created On enter, on exit, on save and the routing rules.
The following rule is a Boolean process rule that routes the Purchase Request process when the supervisor has requested changes, before it can continue to the Quotation Sub-Process.
How to reuse a rule
When a rule has been created and you want to reuse it, go to the sequence flow where you want to associate it and open the expression manager.
Select Based on the result of an expression.
This will display all rules available to be reused, in the expressions tab.
Select the one you want and click OK.
Last Updated 7/12/2023 3:18:50 PM