Workflow Management in an Internet Environment

Martin Waardenburg
Maarten van Emmerik

Web-based systems for workplace and facility automation are rapidly gaining in
popularity because they enable organizations to share data and business processes with
customers, partners and suppliers. Typically data is stored in a relational database and
users can access information via an application server which includes rules and business
processes. Since business processes may change frequently they should not be statically
programmed on the server but instead users should be able to dynamically design and
modify workflows behind these processes. Many workflow management systems are
available today but they often lack true integration with a Web-based environment or do
not support complex workflow patterns. Axxerion is designed to address these limitations
by integrating high-end workflow technology based on Petri Nets with a fully web-based
graphical environment for workflow design and visualization.

Workflow Management Furthermore, the workflow definitions used

by many systems are often not formally
Tools for customizing business processes defined which makes it hard to predict the
are typically referred to as workflow behavior of these workflows.
management systems. A workflow When selecting a workflow management
management system assigns work, passes system, it makes sense to focus on
it on and tracks its progress. It can be a workflow management systems that are
standalone solution that interfaces with based on a formal foundation and provide
other products or can be embedded in an support for the workflow patterns.
enterprise application. Additionally, it should be required that the
Workflow management is still a relatively workflow system can be very tightly
new field in computing science. Despite the integrated with the rest of the enterprise
efforts of the Workflow Management system.
Coalition (WfMC, [1]), workflow
management systems use a large variety of
Requirements
languages and concepts based on different
paradigms. There is currently no generally Business processes include rules and
accepted standard for describing workflows business logic, for example 'if' the value of
[2]. To be able to compare various a purchase order is more than 1000 'then' it
workflow management systems, a needs additional approval. Some business
comprehensive set of workflow patterns has logic should be implemented by the vendor
been defined in [2]. The result of this of the platform and should never be
research reveals that the expressive power changed. For example, when a part is taken
of contemporary systems leaves much to be from an inventory the stock should always
desired, and that these systems support be decreased. Or if a document is locked for
very different sets of patterns. editing nobody should be able to change it.

Figure 1. Graphical workflow definition for a request.

Axxerion Workflow Management 1

Other business processes may be very Graphical visualization is not just helpful for
much dependent on how a specific designing a workflow but also for providing
organization works. For example, an feedback to users when the workflow is
organization may define various processes executed. A common complaint with many
for dealing with customer requests workflow systems is that users do not know
depending on the type of requests. Based what happens after they click on a button.
on feedback from customers these Or if a task has been assigned they cannot
processes may be changed over time. It is easily see the current state of the workflow.
therefore important that an enterprise Figure 2 shows how a graphical
system allows users to quickly define and environment can help here. If a user
modify processes without the need to receives a task 'Evaluate' the workflow
request a new software release from the diagram shows the current state in black
vendor. These are the kind of processes and previous and next states in grey. The
that should be defined with a workflow diagram shows that depending on whether
management system. the user accepts or rejects the request it
Because the business processes need to can be processed or archived.
closely cooperate with the business data, Because the workflow management system
the integration between processes and data should be integrated with a web-based
needs to be tight. A workflow should be enterprise application, it is important that
able to control the access rights of the data the graphical definition and feedback from
that it is managing. For instance, when a the workflow can be done in a web-browser
document goes from state 'draft' to state Drawing and editing diagrams cannot be
'approved', the document access right done in a standard web page and therefore
should go from 'full' to 'view'. To be able to a special browser plug-in or Java applet
have such behavior combined with good should be provided. A Java applet is
performance, the workflow system needs to probably preferable because it requires no
be very tightly integrated with the rest of installation and works on multiple
the system. platforms.
Since the business processes must be Workflow management systems should be
understandable for the users who are able to assign tasks to roles instead of
participating in the workflow, a good individual people. This avoids that the
graphical environment to present the workflow stalls when a specific person is
workflow is essential. Figure 1 shows an not available or has left the company. For
example of a graphical representation for a example, after an employee submits
request workflow. A graphical maintenance request a task is created for
representation is much easier to the role 'facility manager'. Depending on
understand for users than a program or a how the workflow is defined one or more
script. Therefore, it is desirable to have a persons who have been assigned to that
lot of expressive power in the graphical role will receive the task.
representation of the workflow, which Regarding the expressive power of the
leaves nothing or little to be defined in graphical representations, the workflow
additional scripting or programming. management system should be able to

Figure 2. Graphical feedback during execution of a request workflow.

Axxerion Workflow Management 2

model the workflow patterns as mentioned creates only one token, for example a
before. Further on in this paper we will request task produces a token for the state
explain the actual patterns in more detail. 'rejected' or for the state 'accepted'. An
Finally, it is important that the workflow and-split task creates tokens for all enabled
definition has a formal foundation. This outgoing connectors. For example, when
ensures that the behavior of the workflow is making a reservation a token is created for
well-defined and not dependent on a activating a task for reserving a room and
specific implementation. Furthermore, a another token for reserving equipment.
formal foundation provides a framework to
be able to prove certain properties of a Symbol Description
workflow and facilitates integration with
Place
analysis tools
Start Place
Petri Nets
Connector
Because of the requirements for a formal
foundation and graphical representation, it Task
makes sense to use Petri nets as a basis for
workflow definitions [3]. Petri nets were Or-split Task
devised in 1962 by Carl Adam Petri as a
mathematical tool for modeling and Or-join Task
analyzing processes. One of the strengths
And-split Task
of this tool is that it enables processes to be
defined graphically. Despite the fact that And-join Task
Petri nets are graphical, they have a strong
mathematical foundation. Unlike many Sub workflow Task
other schematic techniques, they are
entirely formalized.
Resource Task
A straightforward application of Petri nets
can model workflow processes to some
extent, but there are also some limitations Automatic Task
[4]. Therefore, a workflow language YAWL
(Yet Another Workflow Language) is
Trigger
proposed in [4] that solves most of these
limitations. Axxerion includes concepts from
Petri nets and YAWL as a basis for its Cancel Group
workflow management module.
Figure 3. Workflow symbols.
Definition
Outgoing connectors from a task can have
Figure 3 shows the symbols that are used conditions attached to them. An output
in the Axxerion workflow management token is only generated when these
module. Generally speaking, a workflow conditions are satisfied. Conditions attached
definition consists of places and tasks, to connectors are based on business data of
connected by connectors. the underlying object and can be easily
Each workflow has one start place. When specified in the user interface. For more
the workflow is executed, a token is put in complex conditions, it is possible to use
the start place. Subsequently, the token scripts.
can enable one or more tasks. If the task is It is also possible to attach commands to
an or-join task, only one token needs to be outgoing connectors. When executing the
present in its input places to make it workflow, such a command can be
enabled. If the task is an and-join task, all activated by the user. Execution of a
of its input places need to contain a token command can result in an output token
(there are exceptions however, as we will being created at the end of the connector.
see later). Optionally a command can update business
An enabled task can be executed, resulting data as well, directly or via scripts. In the
in input tokens being consumed and output user interface, commands and conditions
tokens being produced. An or-split task

Axxerion Workflow Management 3

can be displayed as labels to the carried out by the sales manager. The task
connectors. 'Cancel' is a task connected to a cancel
A resource task is a task that is assigned to group (depicted by the grey rectangle), and
users from specified user groups. When can be carried out by the creator or the
such a task is enabled during the execution sales manager.
of the workflow, tasks are generated for all
the members of these user groups. The
users can then pull the task from their task
list and execute it. It can be specified in the
outgoing connectors how many users
should complete the task. For instance, it
can be specified that two users from the
user group 'Reviewer' need to approve a
document before it can be published.
An automatic task is a task that is
automatically completed by the system
during execution of the workflow. One
useful application of an automatic task, in Figure 5. Token in start place, Submit task enabled.
combination with a trigger, is to define a
'time-out' task. After a specific time defined When the workflow is started, one token is
by a trigger, the time-out task will be put in the start place 'Draft'. Thus, task
automatically completed. For instance, if 'Submit' is enabled and assigned to the
the workflow is waiting on a form to be creator. This is shown in figure 5. Enabled
completed by a user, but the user has not places and tasks are drawn in black, the
reacted for a week, the workflow can rest is drawn in grey. When the submit task
automatically advance to the next step by is enabled, the user can enter data in the
executing the time-out task. In the screen displayed in figure 6. Most fields are
workflow of figure 1 and 2 an example is editable. The buttons at the bottom of the
shown of such an automatic time-out task. screen correspond to commands that are
specified with the outgoing connectors of
Workflow Execution Example the tasks that the current user has. In the
screen in figure 6, the 'Submit' button is
We will explain the execution of a workflow displayed, because this corresponds to the
in the Axxerion workflow management command that is attached to the outgoing
module according to a relatively simple connector from the 'Submit' task (the 'Back'
quotation workflow example (see figure 4). and 'Ok' buttons displayed in figure 6 are
standard system buttons, that are not
related to tasks).

Figure 4. Quotation workflow definition. Figure 6. Quotation screen in draft state.

The quotation can have 5 states: 'Draft', When the task 'Submit' is executed (i.e. the
'Submitted', 'Rework', 'Approved' and 'Submit' button is pressed), the token from
'Cancelled'. These states correspond to the place 'Draft' is consumed and a new token
5 places in the workflow. There are three is produced in place 'Submitted' (see figure
tasks: 'Submit', 'Review' and 'Cancel'. The 6). Now the task 'Review' is enabled and
task 'Submit' is an or-join task which is assigned to the sales manager. In addition
carried out by the creator of the quotation. the task 'Cancel' is enabled because there is
The 'Review' task is an or-split task, a token in the cancel group.

Axxerion Workflow Management 4

 Figure 9. Quotation needs more work.
Figure 7. Quotation submitted.
Now the quotation can be submitted again,
When the sales manager enters the system, and after another review it can be approved
the 'Review' task is displayed in the task (see figure 10). When the token is in the
list. When this task is opened, the place 'Approved', there are no more
quotation screen is displayed, see figure 8. enabled tasks. Completion of the workflow
The buttons at the bottom of the screen is implicit: if no more tasks are enabled,
correspond to the outgoing connectors of the workflow is completed.
the tasks for the sales manager. The
'Cancel' button corresponds to the outgoing
connector from the 'Cancel' task, and the
'Rework' and 'Approve' buttons correspond
to the outgoing connectors from the
'Review' task. Compared to figure 6, the
access rights for the fields have changed.
Access rights depend among others on user
group and workflow state. In the submitted
state, the sales manager can look at the
data, but can not modify the data.

Figure 10. Quotation approved, workflow completed.

This quotation workflow is a simple

example. The workflow in figure 1 and 2 is
more complicated because there are
parallel paths and there is a
synchronization point.

Implementation
Figure 8. Quotation screen in submitted state.
The Axxerion workflow management
In the task 'Review', the sales manager can module is implemented in Java in a J2EE
decide if the quotation can be approved or environment. The workflows can be
if it needs more work. If it is decided to designed and executed in a web browser,
rework the quotation (the 'Rework' button using html and a Java applet. This enables
is pressed), the token will go to the place dynamic placing and moving of the various
'Rework' and the 'Submit' task will be workflow items. The pictures in this paper
enabled again (see figure 9). Note that the are all generated from this applet, so this is
task 'Cancel' is still enabled because there also what users can see.
still is a token in the cancel group Because the workflow system is very tightly
rectangle. integrated with the rest of the Axxerion
workplace automation system, performance
of the application can be optimized to a
large extent. This is very important,
because the workflow is used for access
rights checking as well. To render a screen

Axxerion Workflow Management 5

in this system, potentially very many control which can be executed in parallel,
access rights checks have to be made. thus allowing tasks to be executed
All data required for the workflow definition simultaneously or in any order.
is stored in a relational database and can This pattern is supported in Axxerion by the
be changed dynamically without and-split task, as shown in figure 12. Task
recompiling the system. The applet for A and B are both executed, in any order.
workflow design and visualization is
downloaded automatically, which typically
takes less than 2 seconds. All
communication between the applet and the
server is handled via XML over HTTP(s) so
that no special network infrastructure is
required. On the server side, the workflow
definitions can be exported to XML and
imported on other servers running
Axxerion, regardless of the underlying
relational database.

Workflow Patterns Figure 12. Parallel split and synchronization.

Different perspectives can be taken to
The parallel split can also be seen in figure
evaluate a workflow system. The control
1. The initial single thread for the request
flow perspective is the main perspective
splits in two threads: one to send a form,
and deals with the workflow structure, the
and one to evaluate the request.
tasks and their execution. Other
perspectives such as the data or
Pattern 3: Synchronization
organizational perspectives rest on it.
The synchronization pattern is a point in
The workflow patterns [2] mainly consider
the workflow where multiple parallel
the control flow perspective of the
threads converge into one single thread of
workflow system. To assess the capabilities
control, thus synchronizing multiple
of the Axxerion workflow management
threads.
module we will evaluate it according to
This pattern is supported in Axxerion by the
these workflow patterns. The patterns
and-join task. An example can again be
range from fairly simple constructs to
seen in figure 12 and figure 1. At the end of
complex routing primitives.
the workflow in figure 1, the 'Archive' task
is executed, which synchronizes the two
Pattern 1: Sequence
input threads and produces one output
In the sequence pattern, a task B in the
token.
workflow is enabled after completion of
another task A in the same process.
Pattern 4: Exclusive Choice
This pattern can be modelled in Axxerion as
The exclusive choice pattern is defined as a
shown in figure 11.
point in the workflow where, based on a
decision, one of several branches is chosen.

Figure 11. Sequence.

This pattern can also be seen in the

quotation example we showed: Task
'Review' is enabled after task 'Submit' has
been completed.

Pattern 2: Parallel Split

The parallel split pattern is defined as a
point in the workflow where a single thread
of control splits into multiple threads of Figure 13. Exclusive choice and simple merge.

Axxerion Workflow Management 6

This pattern is supported in Axxerion by the conditions on the outgoing connectors.
or-split task, as shown in figure 13. Either Suppose that a flight and a hotel booking
Task A or Task B will be executed have been selected, then the workflow
depending on the choice that the user execution looks like figure 15.
makes.
Another example of this pattern can be
found in figure 4 in the 'Review' task.
Depending on the sales manager's decision,
the 'Approved' or the 'Rework' branch is
chosen.

Pattern 5: Simple Merge

The simple merge pattern is defined as a
point in the workflow where two or more
alternative branches come together without
synchronization. It is an assumption of this
pattern that the incoming branches are not Figure 15. Multi choice, taking two branches.
executed in parallel.
This pattern is supported in Axxerion by the The book flight and book hotel branches
or-join task, see figure 13. have been chosen, and there is no token in
the book car branch.
Branching and Synchronization
Pattern 7: Synchronizing Merge
The following patterns are more advanced The synchronizing merge is defined as a
patterns for branching and synchronization. point in the workflow where multiple paths
As opposed to the previous patterns, these converge into one single thread. If more
patterns do not have straightforward than one path is taken, synchronization of
support in most workflow engines. the active threads needs to take place. If
only one path is taken, the alternative
Pattern 6: Multi Choice branches should reconverge without
The multi choice pattern is defined as a synchronization.
point in the workflow where, based on The synchronizing merge is implemented in
decisions, a number of branches is chosen. Axxerion with the and-join task. An and-
In Axxerion, this pattern is implemented as join task can optionally be linked to a
an and-split task with conditions on the corresponding and-split task. At runtime,
connectors. The user can select in the form the and-join task can query the
belonging to the workflow which branches corresponding and-split task that was
should be taken. In figure 14, an example executed about the branches that were
is shown. When the user carries out the taken. Using this information, it is possible
task 'Submit', any combination of a flight, that the and-join task is enabled without all
hotel and car booking can be selected. its input places containing tokens. Instead
When 'Submit' is executed, the workflow it can be enabled by just the branches that
engine can determine the branches that were taken. It is possible that the whole
should be taken by examining the

Figure 14. Travel request workflow, showing multi choice and synchronizing merge.

Axxerion Workflow Management 7

“and-split-join-block” is carried out inside a This pattern is implemented in Axxerion
loop. using the or-join task. In figure 17 the
Note that in this approach it is not allowed effect of this pattern is visualized. At first
for tokens to “escape” or “enter” the paths there are two tokens active in parallel.
in between the and-split and the and-join. When the multi merge task is executed,
The same number of tokens that leaves the one token is put in the output place. Then
and-split task should arrive at the and-join. the multi merge task is still enabled,
For instance, it is not allowed that the 'Book because it consumed only one token. When
flight' task is an or-join task that takes it is again executed, a second token is put
tokens from another execution path. in the output place and the multi merge is
finished.

Pattern 9: Discriminator
The discriminator is a point in the workflow
that waits for one of the incoming branches
to complete before activating the
subsequent task. It then ignores all
remaining branches.

Figure 16. Synchronizing merge, enabled by 2 tokens.

An example is shown in figure 16. The flight

and hotel have been booked, and the
'Confirm' task (which is a synchronizing
merge) is enabled.

Pattern 8: Multi Merge

The multi merge is defined as a point in the
workflow where two or more branches
reconverge without synchronization. If
more than one branch gets activated,
possibly concurrently, the task following the
merge is started for every activation of
every incoming branch.

Figure 18. Discriminator execution.

The discriminator can be implemented in

Axxerion using the or-join task in
combination with a cancel group, see figure
18. The discriminator task is enabled when
either task A, B or C has been executed.
When the discriminator is executed, all
tokens in the cancel group are 'cleaned up'.

Pattern 10: Arbitrary Cycles

An arbitrary cycle is defined as a point in
the workflow where one or more tasks can
be done repeatedly.
Figure 17. Multi merge execution. An example of how this pattern is
supported in Axxerion is shown in figure 19.

Axxerion Workflow Management 8

The parallel split task splits into a branch to in the user group. These persons see the
create a delivery, and a branch to decide if task in their task list, and can then decide
another delivery is needed. If yes, the to handle the task. In addition, with every
parallel split is executed again, thus outgoing connector from a task, it can be
creating another delivery task. specified how many task instances should
be executed to advance on the branch.

Figure 19. Arbitrary cycles.

Pattern 11: Implicit Termination Figure 20. Document approval workflow.

A given subprocess should be terminated
when there is nothing else to be done. In For instance, in the document approval
other words, there are no tasks in the workflow of figure 20, the task 'Publish' is
workflow and no other tasks can be made assigned to the user group 'Reviewer'. To
active. go from state 'Review' to 'Approved', two
This is standard behavior in the Axxerion users from the reviewer user group need to
workflow management module. For approve the document. If only one of them
instance, in figure 17 the workflow has rejects the document, it is put back in the
ended when all tokens are in the final place state 'Draft'.
(the place that has no outgoing
connectors). Pattern 13: Multiple Instances With a Priori
Design Time Knowledge
Multiple Instances For one process instance a task is enabled
multiple times. The number of instances of
The following patterns involve tasks that a given task for a given process is known at
have multiple instances running during design time. Once all instances are
execution of the workflow. There are two completed some other task needs to be
types of requirements. The first started.
requirement is the ability to launch multiple This pattern can be implemented in
instances of a task or subprocess. The Axxerion in various ways. A first example is
second requirement is the ability to the document approval workflow in figure
synchronize these instances and continue 20. At design time, it can be specified that
after all instances have been handled. all reviewers should get the 'Publish' task.
It can also be specified how many reviewers
Pattern 12: Multiple Instances Without should approve before the document is
Synchronization approved.
Within the context of a single workflow
instance, multiple instances of a task can
be created. To see how this pattern can be
implemented, we can again look at figure
19. During execution of this workflow,
multiple instances of the task delivery can
be created.
Actually, multiple task instance support is
built-in in Axxerion at a lower level as well.
For any task, user groups can be specified Figure 21. Request for quotation workflow.
that should carry out the task. When the
task is instantiated during the course of the Another example is displayed in figure 21.
workflow, tasks are created for each person This is a request for quotation workflow. It

Axxerion Workflow Management 9

uses sub workflows for the actual Subsequently, one quotation can be
quotations. When the 'Quotations' sub selected by the purchase manager in the
workflow task is enabled, instances of the 'Select' task. In this task, the purchase
quotation workflow (see figure 4) are manager can also decide to cancel the
executed that are linked with the main request, see figure 23.
request workflow. From a data perspective, If there are no 2 approved quotations
the quotation objects are linked to the before the due date, the automatic time-out
request object, and the workflow instances task will be executed. This will result in all
are linked to the quotations and request. non-completed quotations to be cancelled,
When the request for quotation workflow is because the sub workflows are not enabled
started, first general information on the anymore. The purchase manager can then
request is entered, like a description, still decide what to do with the completed
needed items, the due date, etc. The and/or cancelled quotations.
request is then sent out to a number of
contractors, who will have to send back a Pattern 14: Multiple Instances With a Priori
quotation before the due date. This state of Runtime Knowledge
the workflow is displayed in figure 22. For one case a task is enabled multiple
times. The number of instances of a given
task for a given case varies, but is known at
some stage during runtime before the
instances of the task have to be created.
Once all instances are completed some
other task needs to be started.
This pattern is supported by Axxerion as
shown in figure 21. The number of
quotations can be specified at runtime.
Figure 22. Main workflow is waiting for quotations.

The system automatically creates a Pattern 15: Multiple Instances Without a

specified number of incoming quotations (in Priori Runtime Knowledge
this case 2), that are ready to be filled out For one case a task is enabled multiple
when the quotations from the contractors times. The number of instances of a given
come in. When more quotations come in, task for a given case is not known during
they can be added at runtime, and they design time, nor is it known at any stage
will be linked to the main request workflow during runtime before the instances of the
as well. When the incoming quotations task have to be created. Once all instances
have been approved or cancelled, they are completed some other task needs to be
signal the main workflow of the completion started. The difference with pattern 14 is
of a sub workflow. that even while some of the instances are
In the workflow definition, it has been being executed or already completed, new
specified that the connector going from the ones can be created.
'Quotations' subworkflow task to the This pattern is supported as well by
'Received' place is enabled when 2 Axxerion, as shown in figure 21. At
incoming quotations are approved. So when runtime, quotations can be added that
2 quotations have been approved, the main automatically link as a sub workflow to the
workflow will advance to the 'Received' main request workflow.
state.
State-based Patterns
In real workflows, most workflow instances
are in a state awaiting processing rather
than being processed. In many workflow
systems the notion of state is interpreted in
a narrower fashion and is essentially
reduced to the concept of data. As this
section will illustrate, there are scenarios
Figure 23. Sub workflows have finished.
where an explicit notion of state is required.

Axxerion Workflow Management 10

Pattern 16: Deferred Choice Pattern 17: Interleaved Parallel Routing
The deferred choice pattern is defined as a A set of tasks is executed in an arbitrary
point in the workflow process where one of order. Each task in the set is executed, the
several branches is chosen. In contrast to order is decided at runtime, and no two
pattern 4 (exclusive choice), the choice is tasks are executed at the same moment.
not made explicitly, but several choices are This pattern can be implemented directly in
offered to the environment. Once a branch Axxerion because states are supported.
is activated, the other alternative branches
are withdrawn. It is important to note that
the moment of choice is delayed until
processing in one of the alternative
branches is actually started. The moment of
choice is as late as possible.

Figure 25. Interleaved parallel routing.

Figure 24. Difference explicit and implicit choice. In figure 25, an example of interleaved
parallel routing is shown. In this example,
Figure 24 illustrates the difficulty in the Navy requires every job applicant to
supporting this pattern when the workflow take two tests: a physical test and a mental
language does not support states directly. test. These tests can be conducted in any
The top workflow is made using only tasks, order but not at the same time. To realize
the bottom workflow also has states (the the desired behavior, a mutual exclusion
circles). The workflow is about a document place is added to synchronize tokens. As
approval. The approval can be made by the can be seen in figure 25, initially both tests
manager, or alternatively by two are enabled. After the physical test has
coordinators. In the top workflow, the only started, the mental test is not enabled.
way to make the distinction between the When the physical test has ended, the
branches is make a separate task to decide mental test will be enabled again.
which approval to take. In the bottom
workflow, this decision is made implicitly by Pattern 18: Milestone
executing an approval in one branch. The enabling of a task depends on the case
Since Axxerion has the notion of states, this being in a specified state. The task is only
pattern is straightforward to implement. enabled when a certain milestone has been
Another example can be seen in figure 21. reached, that is in another parallel thread
The choice between time-out or advancing of execution.
when 2 quotations are approved is only The milestone pattern can be implemented
made at the time one of these steps is directly in Axxerion. An example is shown
completed. Such a time-out is difficult to in figure 26. This example is a step further
model when the workflow language does in the execution than what is shown in
not support states. figure 2. The milestone is the state where
the two parallel paths are synchronized.

Axxerion Workflow Management 11

Figure 26. Milestone.

Cancellation Patterns Axxerion system or to create, delete or

update information. Scripting does require
The following patterns deal with the ability a good knowledge of programming and
to cancel tasks in a workflow. data structures and is typically only used by
advanced users and system integrators. A
Pattern 19: Cancel Activity detailed discussion on the Axxerion
An enabled task is cancelled, meaning that workflow scripting capabilities is beyond the
the thread waiting for the execution of the scope of this paper.
task is removed.The cancel activity or task
pattern can be implemented directly in
Conclusion
Axxerion. We have seen several examples
of this pattern related to the deferred We have given an overview of the workflow
choice pattern. For instance, in figure 2, functionality offered in the Axxerion
when the time out task is executed, the workplace automation system. The system
process form task is cancelled. was evaluated according to the workflow
patterns in [2]. It has been shown that
Pattern 20: Cancel Case Axxerion supports all workflow patterns in a
A workflow instance or case is removed direct way, without the need to resort to
completely. Even if parts of the workflow additional scripting or programming. It has
are instantiated multiple times, all also been demonstrated how advanced
descendants are removed. workflow capabilities can be integrated in a
For this pattern, the cancel group can be graphical web environment.The focus of
used. When a task connected to a cancel this paper has been mainly on the control
group is executed, all tokens in the cancel flow perspective of the Axxerion system.
group are removed. Also, all tasks related For an overview of the other aspects of the
to those tokens are cancelled. For instance system we refer to the Axxerion whitepaper
in figure 26, the workflow case can be [5].
cancelled at once by executing the cancel
task. Authors
Martin Waardenburg and Maarten van
Scripting Support
Emmerik each have over 15 years
All patterns described in this paper have experience in development of enterprise
been created graphically in a web browser systems for computer-aided design and
without the need for any programming. business process management. They
Axxerion does however offer scripting for founded Axxerion to develop a new
defining more complex decision rules and generation workplace and facility
business logic. The scripts are written in automation software. Workflow
Java and are compiled at run time. management, based on the concepts in this
Scripts can be used as conditions on paper, is a key element in this software.
connectors, for example an approval branch
is only enabled when the 'amount' data
field in an invoice exceeds '1000'. Scripts
can also be used to send messages to other
systems, call on internal APIs in the

Axxerion Workflow Management 12

References [3] Workflow Management, Models,
Methods and Systems – Wil van der Aalst
[1] Workflow Management Coalition, non- and Kees van Hee, MIT Press, 2002
profit organization (www.wfmc.org). [4] YAWL: Yet Another Workflow Language
[2] Workflow Patterns - W.M.P. van der – W.M.P. van der Aalst and A.H.M. ter
Aalst, A.H.M. ter Hofstede, B. Kiepuszewski Hofstede, 2003 (www.citi.qut.edu.au/yawl)
and A.P. Barros, 2002 [5] Workplace and Facility Automation via
(www.workflowpatterns.com) the Internet – Maarten van Emmerik and
Martin Waardenburg, 2004
(www.axxerion.com)

Axxerion Workflow Management 13