XPDL 2.

1
Integrating Process Interchange
& BPMN
Robert M. Shapiro
Chairman: WfMC Working Group One

TABLE OF CONTENTS
History .................................................................................2
Basics ..................................................................................3
January 2008 Activities ..............................................................................4
Tasks and Applications ........................................................5
White Paper Compound Activities ............................................................5
Swim Lanes .........................................................................7
Message Flow .....................................................................7
Artifacts................................................................................8
Process Definition and Reporting ........................................9
Simulation ..........................................................................10
Process Interchange .........................................................10
BPMN Model Portability Conformance .............................. 11
Conclusion .........................................................................12
Appendix ...........................................................................13
Example: The BPMN Email Voting Process
The Main Process...........................................................13
Discussion Cycle Sub-process .......................................14
Collect Votes Sub-process .............................................15
Back to the main Process ...............................................16

Workflow Management Coalition 0/7%2 %$ " 9

99 Derby Street, Suite 200
Hingham, MA 02043 USA
+1-781-923-1411 (t)
+1-781-735-0491 (f)
wfmc@wfmc.org
www.wfmc.org
 XPDL 2.1 Integrating Process Interchange & BPMN

XPDL is used in nearly

HISTORY
70 BPM solutions, The basic concepts that underlie XPDL1 were formulated by individuals working
including all of the market together in the WfMC2 who were from companies developing workflow and
leaders identified by business process management tools. These concepts were embodied in a meta-
model and glossary which then guided the specification of interfaces for various
analysts such as
aspects of the overall problem. The interchange of process definitions between
Gartner and Forrester. different tools and also different vendors was regarded as an essential piece of
ActiveModeler this whole and the first version of a standard interchange language was WPDL,
Adobe published by the WfMC in November 1998.
ADVANTYS
Amazonas Workflow
Arachnea EverSuite The growing popularity of XML and its use for defining document formats for the
Appian Enterprise Internet, combined with some years of accumulated experience using WPDL
Ascentn in workflow and BPM tools, led to the creation of XPDL 1.0, which was officially
Aspose
BOC released in October 2002. XPDL retained the semantics of WPDL but defined
BEA Systems a new syntax using an XML schema. Neither WPDL nor XPDL 1.0 proposed a
Brein BV specific graphical representation, although the underlying meta-model for a process
Bonita was based on a directed graph structure consisting of activities as nodes and
ProEd Workflow
Canto CanFlow transitions as the edges or pathways between them.
CapeVisions
CARNOT BPMN3 was developed by individuals working together in BPMI4 to take the
CHALEX
ComActivity techniques employed in flowcharting tools, unify and extend the graphics to
Cordys express the semantics required in workflow and EAI processes. BPMN 1.0 was
COSA Designer released in May 2004.
Cubetto Toolset
Eclaire Group
EMC Documentum In addition to the graphical notation, BPMN incorporated a number of specific
Empresa Solutions mechanisms for process modeling that had not yet been included in XPDL; among
Enhydra Shark
Enhydra JaWE these in particular events and message passing between processes. XPDL 2.0
Finantix Studio FXS incorporated these mechanisms as well as the graphics and offered an extended
Fujitsu Interstage BPM meta-model that unified XPDL and BPMN. It was officially approved by the WfMC
Global 360 membership in October 2005.
GlobalSight
HOGA.PL
IBM FileNet In June 2007 the OMG5 published an updated version of BPMN: version 1.1. There
IDS Scheer were numerous changes to the graphics and semantics. WfMC has incorporated
iGrafx
Interwoven WorkRoute these changes, along with other improvements to XPDL 2.0 based on two years in
Infor (formerly SSA Global) the field, to create XPDL 2.1. This white paper has been updated to reflect these
ITP-Commerce Design changes. In the last section of the paper we describe BPMN Model Portability
jawFlow
Jenz & Partner’s BPEdit
Conformance which significantly facilitates the interchange of process models at
KAISHA-Tec the design level. An appendix provides a full example of BPMN, the E-Mail Voting
Metoda S.p.A Process.
Mono-sys
Nautica
Open Business Engine
OpenPages
Openwork
Oracle 9i Warehouse Builder
Pentaho
PB Polsoft
R-Data
Rodan Systems
Savvion
SIMPROCESS
Software AG
SpeechCycle
SSA Global
Tell-Eureka
TIBCO
Together
Transware
Unisys
Vignette
W4

8-,0ROCESS$ElNITION,ANGUAGE
WfMOpen

7ORKmOW-ANAGEMENT#OALITION
Workflow::Wfmc

"USINESS0ROCESS-ODELING.OTATION
Zynium

"USINESS0ROCESS-ANAGEMENT)NITIATIVE

/BJECT-ANAGEMENT'ROUP

wfmc.org/xpdl 2 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

BASICS
A Business Process Model consists of a collection of processes together with
the applications and
resources required
to perform all the
steps contained in the
processes. We start
with a discussion of the
elements in a single
process. To keep things
simple we focus first
on a minimal subset of
elements.
• Activities (the steps in the process)
• Transitions (or sequence flow)
For a complete description of the graphics, syntax and semantics refer to 6 and 7
In the diagram above. the four round rectangles are activities and the four arrows
are transitions which define possible paths between activities. The leftmost activity,
Receive Payment, is the first activity to be performed in the process since it has no
predecessor. Send Receipt is the last activity. Process Large Payment and Process
Small Payment are alternatives: a payment is routed to one or the other according
to the amount of the payment.
The Boolean expressions on the transitions determine which transition occurs, as
determined by a piece of data, amount, associated with the payment. This notation
is commonly employed in Petri Nets, a mathematical formalism that Influenced the
development of XPDL.
Flow charts often use specific graphical elements to indicate branching logic. To
support this XPDL offers routing activities (gateways). The diagram could then be
drawn as:

Here the diamond shaped nodes are routing activities and the X indicates
exclusive-or logic. The Exclusive Gateway on the left is a branch. Only one exit
transition has a condition expression; the other path is marked as the default gate,
to be taken only if the conditions on all other exit gates evaluate to false.
There are a number of gateway types. For The most commonly used are:

Exclusive (XOR) [Note that the ‘X’ symbol is optional]

Parallel (AND)

"0-)/-'"0-.
VERSIONn*UNE
7F-#80$,7&-# 4# 
VERSION!PRIL

wfmc.org/xpdl 3 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

The nodes and transitions can form arbitrarily complex graphs with
• Sequential Activities
• Parallel Activities
• Loops / Cycles
• Conditional Paths

In the above flow we have introduced a third type of activity node, an Event. An
event is something that “happens” during the course of a business process. These
events affect the flow of the process and usually have a cause (trigger) or an
impact (result). There are three types of Events, based on when they affect the
flow: Start, Intermediate, and End. There are numerous trigger and result types.
Some common combinations are:

Start Event triggered by a message.

Intermediate Event triggered by a Timer.

End Event with Error Result

ACTIVITIES
We have said nothing about the details of a basic activity. It is a step in the process,
but what happens at that step? Typically, to perform a step requires one or more
resources: e.g. a person with a particular skill set or a system resource. A task or
application may need to be executed to perform the step.
So basic activities have attributes which provide information about who can perform
the activity, what application or web services should be invoked, what properties of
the object being worked on are used and/or altered in this step, and so forth.
The participants (resources) and applications may be defined within a single
process or for the entire collection of processes in the Business Process Model.
The properties of work objects are likewise definable within a single process or for
the entire model.
Activities have other attributes which further define their specific role or how they
are implemented. Here we list a few:
• Loop Activity is repeated until condition is false.
• IsATransaction Transaction-based semantics.

wfmc.org/xpdl 4 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

TASKS AND APPLICATIONS

There are seven standard Tasks that can be specified for a basic Activity and are
used primarily for invoking Web Services and using WSDL8 meessaging.
An eighth task type is used for invoking Applications whose signatures have been
defined in the Business Process Model.
Applications that can be invoked by a process are defined at the Process or
Package (See Package meta-model) level. There are multiple types of applications:
• Traditional applications
• Components
• Web Services
• Business Rules
• Form
• Script

COMPOUND ACTIVITIES
A compound activity refers to another process (reusable or embedded). The
graphics for a compound activity include a special marker to designate this
Compound activities allow re-use of process definitions. If the
reference is to a reusable sub-process, a list of actual parameters
can be passed to the sub-process at the time of invocation.
An embedded sub-process shares the same data space so no
parameters are passed. (As a technical detail not shown in the
graphical representation, an embedded process is an XPDL activity set and the
compound activity is referred to as a Block Activity). A reusable sub-process may
be invoked asynchronously, in which case the exit transitions from the compound
activity immediately determine the routing of the work object to the successor of the
compound activity. Synchronous invocation requires that the sub-process complete
before the compound activity can continue. Embedded sub-processes are always
invoked synchronously.

Process MetaModel
The meta-model
depicts the
relationships
between all the
elements in a
Process. The
shaded elements
were not present
in XPDL 1.0 and
are now included in
XPDL 2.1 to support
BPMN constructs.
Gateway and Event
have already been
described. Pool and
Lane are elements
that support the
use of graphical
Swimlanes which we
discuss later in this
chapter.

7EB3ERVICES$ESCRIPTION,ANGUAGE


wfmc.org/xpdl 5 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

Package MetaModel
This meta-model describes the relationship between elements on the Package or
Business Process Diagram level. The shaded elements were not present in XPDL
1.0 and are now included in XPDL 2.1 to support BPMN constructs.

wfmc.org/xpdl 6 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

SWIM LANES
In the following diagram we depict a single pool containing the process Loan
Application. There are no lanes in the pool. The process can be either a reusable
sub-process or an embedded sub-process.

In the following diagram we depict a single pool containing the process Loan
Application. There are no lanes in the pool. The process can be either a reusable
sub-process or an embedded sub-process.

Notice that the transitions (sequence flow) may go across lanes in a pool.
Transitions may not go across pools.

MESSAGE FLOW
Message Flow is normally implemented by Web Services and Message Queues.

In the example we illustrate how message flow may go between activities in

different pools. This allows us to represent graphically aspects of the choreography
between processes. It should be noted that message flow cannot occur
between activities in the same pool. In other words, sequence flow is used to
connect activities in the same pool whereas message flow is used to represent
communication between activities in different pools.

In these examples pools have been drawn with a horizontal orientation and a width
that extends across the entire page. However, the specification supports vertical
pools as well, and also allows the width/height to be limited. This supports the use
of pools in the specification of abstract processes and their choreography.

wfmc.org/xpdl 7 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

ARTIFACTS
Artifacts provide documentation facilities with graphical representation.
Associations are used to connect the artifacts to flow objects such as activities. The
association is like a sequence or message flow, but allows optional arrows at either
or both ends of the pathway.
Data Object:

Text Annotation:

Group: Allows diverse objects to be labeled with the same name for reporting
purposes.

wfmc.org/xpdl 8 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

PROCESS DEFINITION AND REPORTING

An XPDL 2.1 document contains the process definitions for a collection (Package)
of processes. This XML document is used not only by modeling tools, simulation
tools and execution (enactment) engines; it also provides the basic information for
BAM9 reporting tools and in particular provides the dimensions and members for
OLAP10 cube reporting technologies.

Here we depict a Business Process Management System which uses the Admin
facility to send the XPDL process definitions to the analysis engine and transmits
a stream of log events which capture the details of execution. The Analysis Engine
structures the data base and OLAP cubes based on the process definitions,
participant and queue information. The events are processed by the Analysis
Engine to update the fact and dimension tables in the data base and cube
processing completes the preparation for interactive slice and dice viewing of the
data, using EXCEL and/or other proprietary Process and Business Intelligence
tools. Below is an EXCEL chart based on historical data.


"USINESS!CTIVITY-ONITORING
/NLINE!NALYTICAL0ROCESSING

wfmc.org/xpdl 9 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

An alternate approach to data presentation shows selected data in the visual

context of the process definition. This can be done for historical presentations as
well as animations of the executing system or a simulation run.

SIMULATION
Simulation engines based on the WfMC meta-model and the XPDL file format have
been available for a number of years. These engines are driven by XML scenario
files. The XPDL package is supplemented by a number of additional schemata that
provide information required for simulation, including details about the performance
of the activities (e.g. duration information), schedules for the arrival of work,
resource characteristics (skill sets, work schedules, cost etc.) and a variety of
simulation options. Some of this data can be acquired automatically from historical
information collected in the OLAP data base.

These simulators are able to generate log event streams identical to those
produced by the BPM execution engine. Hence the same Analysis engine can be
utilized to provide charts and reports that evaluate changes being tested using
simulation.

The simulation technology needs to be extended to include new constructs

incorporated in XPDL 2.1; in particular the BPMN events and message flow.

PROCESS INTERCHANGE
Common meta-model allows tools to exchange models
Type of tools:
• Simulation tools
• Monitoring tools
• Execution tools
• Modeling tools
• Repository tools

"USINESS!CTIVITY-ONITORING


/N,INE!NALYTICAL0ROCESSING


wfmc.org/xpdl 10 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

The following diagram illustrates the use of process interchange in a BPM suite.

BPMN MODEL PORTABILITY CONFORMANCE

BPMN can be used for both “abstract” activity flow modeling and for complete
executable design. Many tools, however, make use of BPMN for the abstract
modeling but add executable detail in tool-specific activity properties. One goal of
XPDL 2.1 is to promote portability of abstract activity flow models between tools.
This requires separating the elements and attributes of BPMN related to activity
flow modeling from those related to executable design. The BPMN spec does
not define this separation, but XPDL does, in the form of BPMN Model Portability
conformance classes.

In broad terms, the “abstract model” elements are those that represent BPMN
constructs that are printable in the business process diagram, such as those
defining the flow object type or subtype (e.g., looping User task, collapsed sub-
process, exclusive gateway, timer event), including only at-tributes specifying the
subtype, label (Name attribute), and unique identifiers for the object itself and
pointers to other identifiers in the diagram. Elements and attributes representing
data, messages, or other implementation detail are omitted from the abstract
process model. In other words, the model describes the “what” and the “when” of
process activity flow, but not the “how” of flow object implementation.

XPDL defines three Model Portability conformance classes, SIMPLE, STANDARD,

and COMPLETE. A modeling tool asserting compliance to one of these classes
means that the tool can import and understand all parts of a serialized BPMN
instance conformant to the class. All three classes exclude implementation-related
XPDL elements and attributes. All three classes exclude vendor specific extensions
via the use of Extended Attributes or user name spaces. They differ only in the set
of abstract modeling elements supported.

The SIMPLE class includes the following BPMN objects: task, collapsed sub-
process, gateway (exclusive data-based, inclusive, parallel), None start and None
end events, pool, lane, data object, text annotation, sequence flow (uncontrolled,
conditional, default), and association.

The STANDARD class includes the following BPMN objects: task (task type User,
Service, Send, Receive); collapsed and expanded sub-process, looping or multi-
instance activity, gateway (inclusive, exclusive data-based, exclusive event-based,
parallel), start events (None, message, timer), catching intermediate events in

wfmc.org/xpdl 11 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

sequence flow (timer, message), throwing intermediate events in sequence flow

(message), attached intermediate events (timer, message, error), end events
(None, error, message, terminate), pool, lane, data object, text annotation,
sequence flow (uncontrolled, conditional, de-fault), and association.

The COMPLETE class includes all task types, all event types, and all gate-way
types described by BPMN 1.1, message flow, transactional sub-process, and ad
hoc sub-process.

Each class is described by a filter transform (xslt) that can be applied to the XPDL
instance, leaving only the elements and attributes of the class. If the original XPDL
is schema-valid, the filtered XPDL will also be schema valid. A second transform
provides additional validation rules required for conformance. If the original XPDL
is identical to the filtered XPDL and has no validation errors, the original instance is
said to be conformant to the class. If the original XPDL is not identical to the filtered
XPDL, but the filtered XPDL has no validation errors, the filtered XPDL represents
the class-conformant portion of the original instance.

We will provide tools for validating BPMN abstract model portability conformance
levels. We envision other BPMN portability conformance classes, and other levels
of abstract model portability conformance may be introduced in the future.

CONCLUSION
XPDL 2.1 provides a standard graphical approach to Business Process Definition
based on BPMN graphics. XPDL 2.1 provides a standard file format for persisting
BPMN diagrams and interchanging Process definitions. The file format is based
on the WfMC meta-model which establishes a framework for defining, importing
and exporting process definitions for numerous products including execution
engines, simulators, BPA modeling tools, Business Activity Monitoring and reporting
tools. The schema defining the format is extensible and provides vendor and
user extension capabilities as well as a natural path for future versions of the
standard. Mappings to specific execution languages (e.g. BPEL) and other XML-
based specifications (e.g. ebXML) are possible. Finally, BPMN Model Portability
conformance classes greatly increase the likelihood of true portability at the design
level between a significant number of different vendor tools.

wfmc.org/xpdl 12 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

APPENDIX:
EXAMPLE – THE BPMN EMAIL VOTING PROCESS
The Main Process: EMailVotingProcess (see diagram below)

The Process has a point of view that is from the perspective of the manager of the
Issues List and the discussion around this list. From that point of view, the voting
members of the working group are considered as external Participants who will be
communicated with by messages (shown as Message Flow).

The Process starts with Timer Start Event that is set to trigger the Process every
Friday.

The Issue List Manager will review the list and determine if there are any issues
that are ready for going through the discussion and voting cycle. Then a Decision
must be made. If there are no issues ready, then the Process is over for that
week – to be taken up again the following week. If there are issues ready, then
the Process will continue with the discussion cycle. The “Discussion Cycle”
Sub-Process is the first activity after the “Any issues ready?” Decision and this
Sub-Process has two incoming Sequence Flows, one of which originates from a
downstream Decision and is thus part of a loop. It is one of a set of five complex
loops that exist in the Process. The contents of the “Discussion Cycle”
Sub-Process and the activities that follow will be described below.

wfmc.org/xpdl 13 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

Discussion Cycle Sub-process:

The Sub-Process starts off with a Task for the Issue List Manager to send an e-mail
to the working group that a set of Issues are now open for discussion through the
working group’s message board. Since this Task sends a message to an outside
Participant (the working group members), an outgoing Message Flow is sent from
the “Discussion Cycle” Sub-Process to the “Voting Members” Pool in the main
process. Basically, the working group will be discussing the issues for one week
and proposing additional solutions to the issues. After the first Task, three separate
parallel paths are followed, which are synchronized downstream. This is shown by
the three outgoing Sequence Flow for that activity.

The top parallel path in the figure starts with a long-running Task, “Moderate E-mail
Discussion,” that has a Timer Intermediate Event attached to its boundary. Although
the “Moderate E-Mail Discussion” Task will never actually be completed normally
in this model, there must be an outgoing Sequence Flow for the Task since Start
and End Events are being used within the Process. This Sequence Flow will
merge with the Sequence Flow that comes from the Timer Intermediate Event. A
merging Exclusive Gateway is used in this situation because the next object is a
joining Parallel Gateway (the diamond with the cross in the center) that is used to
synchronize the three parallel paths. If the merging Gateway was not used and
both Sequence Flows connected to the joining Gateway, the Process would have
been stuck at the joining Gateway that would wait for a Token to arrive from each of
the incoming Sequence Flows.

The middle parallel path of the fork contains an Intermediate Event and a Task.
A Timer Intermediate Event used in the middle of the Process flow (not attached
to the boundary of an activity) will cause a delay. This delay is set to 6 days. The
“E-Mail Discussion Deadline Warning” Task will follow. Again, since this Task sends
a message to an outside Participant, an out-going Message Flow is seen from the
“Discussion Cycle” Sub-Process to the “Voting Members” Pool in the main process.

The bottom parallel path of the fork contains more than one object, the first of
which is a Task where the issue list manager checks the calendar to see if there is
a conference call this week. The output of the Task will be an update to the variable
“ConCall,” which will be true or false. After the Task, an Exclusive Gateway with
its two Gates follows. The Gate for “default” flows directly to an merging Exclusive
Gateway, for the same reason as in the top parallel path. The Gate for the “Yes”
Sequence Flow will have a condition that checks the value of the “ConCall” variable
(set in the previous Task) to see if there will be a conference call during the coming
week. If so, the Timer Intermediate Event indicates delay, since all conference calls
for the working group start at 9am PDT on Thursdays. The Task for moderating the
conference call follows the delay, which is followed by the merging Gateway.

wfmc.org/xpdl 14 Copyright ©2008: The Workflow Management Coalition

 XPDL 2.1 Integrating Process Interchange & BPMN

The merging Gateways in the top and bottom paths and the “E-Mail Discussion
Deadline Warning” Task all flow into a joining Gateway. This Gateway waits for
all three paths to complete before the Process Flow to the next Task, “Evaluate
Discussion Progress.” The issue list manager will review the status of the issues
and the discussions during the past week and decide if the discussions are
over. The DiscussionOver variable will be set to TRUE or FALSE, depending
on this evaluation. If the variable is set to FALSE, then the whole Sub-Process
will be repeated, since it has looping set and the loop condition will test the
DiscussionOver variable.

Collect Votes Sub-process:

This part of the process starts out with a Task for the issue list manager to send out
an e-mail to announce to the working group, and the voting members in particular,
which lets them know that the issues are now ready for voting. Since this Task
sends a message to an outside Participant (the working group members), an
outgoing Message Flow is seen from the “Announce Issues” Task to the “Voting
Members” Pool in the main process. This Task is also a target for one of the
complex loops in the Process.

The “Collect Votes” Sub-Process follows the Task, and is also a target of one of the
looping Sequence Flow. This Sub- Process is basically a set of four parallel paths
that extend from the beginning to the end of the Sub-Process.

The first branch of the fork leads to a Decision that determines whether or not a
conference call will occur during the upcoming week, after the Working Group’s
schedule has been checked. Basically, if there was a call last week, then there will
not be a call this week and vice versa. The appropriate variable that was updated in
the “Discussion Cycle” Process will be used again.
The second and third branches work the same way as the similar activities in the
“Discussion Cycle” Sub-Process, except that the “Moderate E-Mail Discussion”
Task does not have a Timer Intermediate Event attached. This is not necessary

wfmc.org/xpdl 15 Copyright ©2008: The Workflow Management Coalition


Copyright ©2008
The Workflow
Management Coalition
All rights reserved. No part of this
publication may be reproduced,
stored in a retrieval system, or
transmitted in any form or by any
means, electronic, mechanical,
photocopying, recording or
otherwise, without the prior
written permission of the Workflow
Management Coalition except
that reproduction, storage or
transmission without permission
is permitted if all copies of the
publication (or portions thereof)
produced thereby contain a notice
that the Workflow Management
Coalition and its members are the
owners of the copyright therein.
since the whole Sub-Process is interrupted after 7 days through the Intermediate
Event attached to the Sub- Process boundary. The “E-Mail Vote Deadline Warning”
Task sends a message to an outside Participant (the working group members),
thus, an outgoing Message Flow is seen from the “Collect Votes” Sub-Process to
the “Voting Members” Pool in the main process.
The fourth branch of the fork is rather unique in that the Diagram uses a loop that
does not utilize a Decision. Thus, it is, as it is intended to be, an infinite loop. The
policy of the working group is that voting members can vote more than once on an
issue; that is, they can change their mind as many times as they want throughout
the entire week. The first Task in the loop receives a message from the outside
Participant (the working group members), thus, an incoming Message Flow is
seen from the “Voting Members” Pool to the “Collect Votes” Sub-Process in the
main process. The Timer Intermediate Event attached to the boundary of the Sub-
Process is the mechanism that will end the infinite loop, since all work inside the
Sub-Process will be ended when the time-out is triggered. All the remaining work of
the Process is conducted after the time-out and Flow from the Timer Intermediate
Event.
Back to the Main Process
Two Tasks follow the time-out. First, a Task will prepare all the voting results, then
a Task will send the results to the voting members. A Document Object, “Issue
Votes,” is shown in the Diagram to illustrate how one might be used, but it will not
map to anything in the execution languages.
The last segment of the main process contains four Decisions that interact with
each other and create loops to upstream activities.
The first Decision, “Did Enough Members Vote?,” is necessary since two-thirds
of the voting members are required to approve any solution to an is-sue. If less
than two-thirds of the voting members cast votes, which some-times happens,
the issues can’t be resolved. This Decision flows to another Decision for both
of its Alternatives. The “No” Alternative is followed by the “Have the Members
been Warned?” Decision. If voting members miss a vote, they are warned. If they
miss a second vote, they lose their status as a voting member and the voting
percentages are recalculate through a Task (“Reduce number of Voting Members
and Recalculate Vote”). If they haven’t yet been warned, then a warning is sent and
the voting week is repeated.
If all issues are resolved, then the Process is done. If not, then another Decision
is required. The voting is given two chances before it goes back to another cycle
of discussion. The first time will see a reduction of the number of solutions to the
two most popular based on the vote (more if there are ties). Some voting members
will have to change their votes just because their solution is no longer valid. The
process depicts these two activities as if they could be performed in parallel, but in
fact that is wrong, since the reduction to two solutions must take place first in order
to know which voters have to change their votes. After the pair of parallel activities,
the flow loops back to “Collect Votes” Sub-Process. If there already has been two
cycles of voting, then the process flows back to the “Decision Cycle” Sub-Process.
0 /7% 2% $ " 9