The context of a Process
Each Process has one main entity, the Process Entity. The Process Entity provides the starting point to access the rest of the Process data. The context of a Process is defined by the main Process Entity.
If the Process (or Sub-Process) is created through the Expert View, the Process Entity is not set. Therefore, you need to manually set the Process Entity of the Multiple Sub-Process in order to access its data.
Basic and Advanced settings
You can specify basic or advance settings for a Multiple Sub-Process.
The Basic configuration will apply Bizagi's default settings through a very simple wizard. Click for further information about Basic settings.
The Advanced settings allow you to configure specific business cases, through the complete Sub-Process wizard. Click for further information about Advanced settings.
XPath to Collection
The collection XPath is the XPath that relates the Parent entity with the Collection entity from which the instances of the Multiple Sub-Process will be created.
Number of Instances
The number of occurrences that the Multiple Sub-Process will create depends on the amount of objects found in the collection or the defined number in an Integer-type attribute.
•Items in Collection: Value determined by the number of items of a Collection (a 1-N relationship)
•Integer Constant: Value determined by a constant integer
•Items Attribute: Value determined an integer-type attribute that is part of the Data model
Clean Previous Instances
When selected, all instances of the Collection will be re-created in case the Process re-enters the Multiple Sub-Process.
That is, if for some reason a case in a Process enters more than once the same multiple Sub-Process, by default Bizagi ignores the instances of the collection that were already used to create a case of the multiple Sub-Process, they are not used again. Bizagi will create cases only for those records of the collection that haven't opened a case already.
The Clear Previous Instances functionality when selected, ignores the default behavior, and when a case re-enters the multiple Sub-Process re-creates ALL instances again, regardless if they have already opened a case. If the multiple Sub-Process created four instances the first time around, the next time it re-enters it will create another four, and the case will have 8 instances in total. Keep in mind that the records modified the first time persisted data. This data is not changed nor rolled back. New case instances will have the persisted information the second time around.
There are some cases in which multiple Sub-Process must be created grouping chosen attributes from the collection. The number of Sub-Processes launched will depend on the different values of those attributes.
In our Students Applications example, if the multiple Sub-Process needs to be grouped by girls and boys, two Sub-Process instances will be created: one for girls and other for boys.
The next image shows how the Sub-Processes related to a collection of three students are grouped in two cases, one for men and other for women.
Related Entity or Group in Collection
Usually, the Collection entity and the Process Entity of the Multiple Sub-Process are the same entity. But sometimes they are not. When the Sub-Process Process entity differs from the Collection entity, the Wizard will display one of these fields. Related Entity or Group in Collection.
Related Entity or Group in Collection are relationships between the Collection entity and the Sub-Process Process entity. These relationships are necessary to allow the user to navigate through the data from the Process to the collection.
The Related Entity will be shown if the Collection is not grouped (using the Group by option). If the Collection is grouped, the Group in Collection will be shown, because a one-to-many relationship is needed to group the Collection records in different sub-collections.
Think of a school that needs to plan the beginning of a new school year. The process, Back to school, has its Process Entity, Back to school. A new case will be created for each grade, but the Sub-Process, Grade planning, has a process entity called Planning. Thus, the collection entity that will create cases is different form the Sub-Process entity:
Collection entity: Grades
Sub-Process entity: Planning.
Note in the diagram below that there is no relationship between the Sub-Process entity and the Collection entity.
Bizagi needs a relationship in order to relate each case created for Planning, to the Grade planned.
Thus, when the Sub-Process is configured, Bizagi will automatically detect the situation and request the user to create a relationship.
A new relationship is created to relate the two entities. With this relationship you will be able to access the Parent process information, as well as the collection entity.
Multiple Sub-Process instances can be created in two ways: Parallel or Sequential
Parallel instances will be created simultaneously, while Sequential instances will be created one after another.
The shape of the Sub-Process will be displayed according to the mode selected:
•If the Sequential Mode is selected, there will be no Exit Mode. Only Parallel Mode will enable the Exit Mode.
•If the Group by option is selected, only Parallel Execution Mode will be available.
This Mode determines the behavior on exit of the Sub-Process regarding the parent Process.
•StandAlone: The parent Process continues with the next Activity of its Process as soon as the Sub-Process is created, without waiting for it to be completed. The sequence pattern does not apply and the Sub-Process will not depend on the parent Process; that is, if the parent Process ends, the Sub-Process can remain in effect.
IMPORTANT: This option will not be displayed if the Sequential Execution Mode has been selected. Only Parallel Execution Mode applies.
•Integrated: The execution of the Sub-Process is required before the parent Process continues with the next Activity of its Process. This behavior can be compared to the sequence pattern, where Activity B cannot be run until Activity A has ended. The Integrated mode has four options according to the business case needs.
oAll Tokens: All the tokens are synchronized and only after ALL the Sub-Processes that are opened have ended will the flow of the parent Process continue.
oEach Token: As soon as each Sub-Process created is finished, the flow of the parent Process continues. When the output mode is Each Token, the Activity that follows the multiple Sub-Process in the parent Process will be enabled as many times as there are finished Sub-Processes. We highly recommend to synchronize the tokens created. For further information about synchronizing tokens when using this option go to synchronize tokens with Each Token option.
oOne Token: The parent Process will continue to the next Activity after the first Sub-Process instance has finished. Take into account that this does not cancel the rest of the instances created. However, when these instances finish, they will not activate the element after the sub-process.
We strongly recommend to rely on the first four Exit mode options (StandAlone, Integrated - All Tokens, Integrated - Each Token, and Integrated - One Token) to determine how the Sub-Process continues with the flow.
oExpression defined: the parent Process will continue according to an expression.