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

Milestone

The milestone pattern can be used to define that an activity is only enabled
if a certain milestone has been reached that has not expired yet.
This pattern is illustrated by an example. Consider a process model with
activity models A,B, and C. With a milestone pattern, the process designer
can determine that activity instance a is enabled only if b has been executed
and c has not been completed. As a result a is not enabled before the execution
of b and after the execution of c.
Since the informal process modelling
notation that served well in presenting the patterns so far does not
provide an explicit notation for state, Petri nets are used to express the milestone
pattern (Petri nets will be introduced in the next section in detail).
The milestone indicates that the execution of an activity a is possible only
after activity b is executed and before activity c is started. There can also be
multiple instances a1, a2, . . . of activity model A, as long as c has not started.

Run Time Patterns

In addition to the patterns introduced above, there are run time patterns
defined that are—strictly speaking—not part of a process model. They, rather,
characterize the functionality provided by a business process management
system.
The first of these patterns is the cancel activity pattern. When an activity
instance is cancelled, it enters the cancelled state.
The second run time pattern is the cancel case pattern, in which all activity
instances of a process instance are cancelled so that the process instance
comes to a halt. To cancel an activity instance, there are different options that
depend on the environment in which the activity instance is being executed.
If it is a manual activity, then the knowledge worker needs to be informed
about the cancellation, so that the person ceases working on the case. She
could also perform some cleanup activities, if need be.
If the functionality to execute the activity instance is provided by an information
system, then the realization of the cancel activity pattern depends
on the type of information system used. If the information system is realized
by a database application, then terminating the application is a valid option.
If the database application runs—at least the parts that realize the activity
instance to be cancelled—in a single database transaction, then cancellation
can be realized by aborting the transaction. The database management system
guarantees that the database is restored to the state before the execution of
the activity instance.
If on the other hand the information system is not based on a transactional
information system, cancelling an activity can be much harder. There might
be certain parts that are already stored in some kind of non-transactional
data store. Identifying these parts and manually undoing the effects of the
partial activity instance is a cumbersome and in some cases infeasible task.
Also in manual activities, actions might already have been performed that
cannot be undone easily, such as sending an email message. In this case, the cancellation of an activity instance involves manual activities, such as sending
another email message withdrawing the former, or making a phone call.
To summarize, it is easy to indicate the behaviour of the cancel activity
and cancel case patterns; however, the realization of these patterns in realworld
business process management systems is far from that.