Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec G -- By Mathias Weske

Multiple Instances With A Priori Design Time Knowledge

In the multiple instances with a priori design time knowledge pattern, the
number of activity instances of an activity model is known at design time.
These activity instances are synchronized, so that once all activity instances
have completed, the follow-up activity is enabled.
The follow-up activity c can only be enabled after the last activity instance
of B has completed, in this case b1. This property is shared by all multiple
instances patterns that are “synchronized.”
The specific property of the pattern at hand is that the number n = 2 of
activity instances of B is defined at design time, i.e., as part of the process
model. Depending on the process language used, there can be an attribute of
the activity model B that states, for instance, NrOfInstances = 2;.

Multiple Instances With A Priori Run Time Knowledge

In the multiple instances with a priori run time knowledge pattern, the number
of instances of a given activity model depends on the characteristics of the
case or the availability of resources. Therefore, it is only known at some stage
during run time of the process instance, but before the instances of the multiple
instances activity are created. This pattern also assumes synchronization
of the activity instances before the next activities can be enabled.
Rather than specifying the number of activity instances directly, we define
an expression. This expression is evaluated during run time to compute the number of activity instances for a specific process instance. This computation
occurs before the activity instances of the multiple instances activity are
created.
A process language might provide a functional representation of the number
of instances to create, so that, for instance,
NrOfInstances = GetNoOfLineitems(order);
might be a valid term. Here, the number of activity instances is computed by
a function that takes the current order and returns the number of line items
in it. An individual activity instance is then performed for each line item.

Multiple Instances Without A Priori Run Time Knowledge

In the multiple instances without a priori run time knowledge pattern, the
number of instances of a given activity is not known during design time; nor
is it known at any stage during run time before the instances of that activity
are enabled.
The difference with the previous pattern is that even while some of the
instances are being executed or have already completed, new activity instances
can still be created. During the
execution of these activity instances, new activity instances are created.When
all instances of B have terminated—in the example, b5 is the last activity
instance to complete—the next activity instance in the process can be enabled.
In order to realize this pattern in a process language and in a process
engine, there need to be additional assumptions in place. The main question in this context is, until what point in time is it possible to create new activity
instances of B?
One choice would be to indicate that while bs are running, new instances
of the multiple instances activity can be created. While this is a valid choice,
realization of this might not be practical, because it would assume that the
activity instances would include the creation of new instances, thereby intertwining
process management tasks (start new process instance) and doing the
actual work.
An alternative solution is to install a management activity related to the
multiple instances activity. This management activity explicitly defines the
end of the multiple instances activity. It is also responsible for creating new
instances of the multiple instances activity. It can even create new instances
after all instances have terminated. This is a valid approach, since in dynamic
settings, there might be an explicit decision about whether additional activity
instances are required to achieve the business goal related to the multiple
instances activity.
In the first alternative—if the follow-up activity is automatically enabled
after the current instances of the multiple instances activity have completed—
there are no options to create new instances of the multiple activity task once
all instances have completed.