All product information in wiki.bizagi.com is only valid for Bizagi BPM Suite 9.1.X.
For newer Bizagi BPM Suite versions (10.X and up) please visit the User Guide.
 

Context

From Business Process Management, BPM and Workflow Automation Wiki | BizAgi BPMS

Jump to: navigation, search

<keywords content="keywords">

context, identify context, identifying, context example, business rule context

</keywords>

Contents

Context

The context determines how the user navigates through the set of attributes and how the information is built. Thus, the context is strongly related to the data model. According to the context the user will be able to move from one entity to another and obtain the information needed to create Forms, Business Rules, and assign Persons in Charge.


The Context is determined by the process. That is to say, depending on the process, the information will be stored and presented differently. Therefore, it is a determining factor to know the context of the process in order to be able to create the forms and business rules, and allocate the resources of a process.


How to Identify the Context of a Process

The context of a process is defined by the Main Process Entity. The Process Entity is the principal entity through which a user accesses the rest of the data model entities.


Example: To discuss a process of a client’s request for a loan, the Main Process Entity would be the Request. The entire data model is accessed through Request. The request is received, the request has products, the request is approved or turned down, etc.


Therefore, the Main Process Entity is the context entity of the process.



The Process Entity is created and marked with a small star when the user creates the Data Model. It should be the first entity created.



The Forms and Expressions associated with each of the activities will be created in the Process Entity.

Therefore, the CONTEXT of a process always goes from the PROCESS ENTITY to the rest of the data model.


Example

In a Credit Request process the Main Process Entity is Request. Every Request has several Products and has one client as shown in the image above.

When a user is building the forms that will be displayed in the web application, the context changes, especially in the attributes that have a one - to -many relationships (in this case, Products).


The next form has attributes that are related directly to the Request Entity, like the Client's attributes. These are dragged and dropped without changing Context.


Image:Context1_Image003.jpg


However, the form has a table with the Requested Products. When the table is created in the form, the context doesn't change. But when the Add form or the Edit form is opened, the context changes to the Many entity. In this case, corresponds to Products.


Image:Context1_Image004.jpg


The user can notice the context change, by looking at the Data Binding box. In the Edit form, the user can only access attributes related to the Products. The Request entity is no longer the Context entity.


Image:Context1_Image005.jpg

How to Define the Context of a Business Rule

The user does not define the context of the Business Rules. This is selected automatically by Bizagi. However it is important to understand why the Data Model shows certain information from certain entities depending on where the business rules are built.

Business Rules are created with the context of the Business Main Entity when they are built from the Process Wizard or when defining shapes' actions: On enter, On save, on Exit action or transition conditions.


However, there are certain cases where the business rules have a different context. The following is a list of when we have to change the context of a rule.


Image:Bulletazul.gif When the rules are going to be used as rules of visibility, editing or the mandatory nature of the attributes that belong to the forms to edit or add to tables. In these cases, the context is the N entity (of the 1-N relationship) where the rule is evaluated. That is to say, the entity of the edit or add form.

In the image, as the example above, the Main Process Entity is Request. In Product's Edit form, a visibility rule has the Products context. That is, the conditions can navigate the Data Model starting from the Products entity.


Image:Context1_Image006.jpg



Image:Bulletazul.gif When the rules are going to be used as rules of visibility, editing or the mandatory nature of attributes, the context of the rule is the entity of the form.

Image:Bulletazul.gif When the rules are going to be used in a button that is in a form to edit or add to table entries. In these cases, the context of the rule must be the N entity of the relationship. In other words is the entity of the table.

Image:Bulletazul.gif When rules are going to be used in buttons that are in forms, the context is the entity where the button is being called on.

Image:Bulletazul.gif  When the rules are going to be used as rules to filter information from a combo or a search window. In these cases, the context of the rule must be the entity where the combo or the search window is located.

<comments />