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

Representing Process Instances

Workflow nets cover the model level in process modelling and—by tokens—
the process instance level as well. This means that for each business process
model represented by a workflow net there can be multiple process instances
following this model. Each process instance is represented by a set of tokens
in the workflow net.
The workflow net represents a business
process in which claims are processed; the details of this process are not relevant
to introducing how process instances are represented in workflow nets.
The tokens are coloured; they contain values. If we abstract from any application
data that might be represented by tokens, each token carries at least
a process instance identifier.
Case 5 is in the initial place; it is
not yet started. Case 4 is reflected by two tokens, because it is currently on a
parallel branch. The same holds for case 3, but for case 3 the Contact Client
transition has already been conducted.

Discussion

Workflow nets are a well-known technique to model business processes in an
abstract and formal way. In order to provide a formal background, especially
in the context of soundness properties which will be investigated in Chapter
6, several restrictions were introduced. Without these restrictions, formal
analysis of workflow nets would not be feasible.

Data and Conditions
Data is not explicitly represented in workflow nets. Data is only handled in
an abstract way, by denoting that tokens can be coloured, but the usage of
these data structures in the process is not investigated.
While the workflow net represents the structure of a set of similar process
instances (i.e., the process model), the individual cases are represented by tokens.
Each case is represented by at least one token. In general, when the case
starts, there is one token in the source place i, and when the case completes,
there is one token in the sink place o.
The workflow management system that controls the enactment of cases
requires differentiating between the tokens that belong to different cases. A
transition t with incoming edges from places p and p0 realizes an and join.
This means that t can only be enabled when there are tokens in p and p0, and
these tokens need to belong to the same case.
Therefore, tokens need to be typed. Tokens need (at least) to include a
process instance identifier, so that t can synchronize the branches represented by p and p0 only, if these places have tokens that belong to the same case. As
a simplification often made in the context of workflow nets, each workflow net
contains tokens that belong to a single case. In this case, the tokens do not
need to be typed.
Decision transitions that realize or splits and exclusive or splits require
expressions that are evaluated for each process instance to decide which branch
to take. These decision expressions are also disregarded in workflow nets.
Decisions are abstracted from in the following way: wherever there is a
decision transition, each of the alternative branches will be taken eventually.
This assumption mirrors the non-determination of firing in traditional Petri
nets: multiple enabled transitions that share a common input place will fire
in a non deterministic fashion.
The same assumption is now in place for decision nodes in workflow nets:
each expression in a decision transition will eventually evaluate to true. When
analyzing workflow nets, this assumption is in place to detect structural errors
in workflow nets. Errors that result from erroneous conditions associated with
decision transitions, however, are not considered.