Business Process Model and Notation BPMN Specification 2.0

1
Business Process Model and Notation (BPMN)
Specification 2.0
Initial Submission In response to Business
Process Model and Notation RFP (OMG Document
bmi/2007-06-05)
March 10, 2008
2
Agenda

• Overview
• Goals and Market Requirements
• Design Rationale
• Benefits of the Approach
• Notation and Diagrams
• Detailed Drill Down
• Metamodel Structure
• Choreography
• Human Interactions
• Events
• Execution Semantics Alignment
• Schema and Model Interchange
• Summary

3
Primary Goals and Market Requirements

• Satisfy OMG BPMN 2.0 RFP requirements
• Resolve BPMN 1.1 inconsistencies and ambiguities
• Formalize choreography as part of the BPMN
  specification
• A metamodel whose constructs are clearly
  recognizable as BPMN elements
• Formalize BPMN 1.1s implicit metamodel
• Correspondence of notional elements to metamodel
  constructs should be natural (minimize complex
  mappings)
• Refine and formalize BPMN execution semantics
• BPM scenarios are broader than any single
  execution environment
• Nonetheless want to enable straightforward
  deployment to WS-BPEL 2.0
• Create XML-based process model interchange
  formats
• Domain model and diagram layout
• XMI based format and a simpler, non-XMI based
  format
• Provide formal BPMN extensibility mechanisms
• Semantic extensions and visual extensions
• Enables coverage of or extensibility to all
  relevant process-related artifacts (e.g.,
  resources, simulation, etc.)

4
Other Goals and Market Requirements

• Formalization of human interactions as primary
  elements of the BPMN specification
• Enhance use of Data in BPMN by formalizing
• Data flow modeling
• How external type systems can be used for data
  description
• How external expression languages can be used for
  data manipulation
• E.g. XPath
• Refine event composition and event correlation
• Formalize the hooks to use external role and
  organization models in BPMN

5
Design Rationale

• BPMN 1.1 used as a base line
• Introduce Core and Extension Layers
• Core Includes the most fundamental modeling
  elements
• Extension Layers Includes Choreography, Data
  modeling, Events, Human Interactions
• BPMN Graphical Elements designed based on
  end-user modeling requirements and needs
  (Top-Down)
• BPMN, through a combination of Graphical and
  Supporting elements, must contain sufficient
  information to generate executable processes
• This does not restrict BPMN from having
  capabilities to model non-executable elements or
  processes.
• For each element in the diagram, there is a
  single element in the metamodel
• Reuse of and alignment with existing technologies
  and standards
• XML Schema, XPath, WS-BPEL, WSDL
• Provides both XMI based and simple non-XMI based
  exchange formats
• Support of MDA and non-MDA tools

6
Design Rationale (cont.)
BPDM?BPMN Relationship
BPMN (Notation)
BPMN (Notation)
Explicit Same scope as BPDM
Implicit Conceptual sub-set of BPDM
BPMN (Metamodel)
BPMN (Metamodel)
BPDM (Metamodel)
BPDM (Metamodel)
Current Standards Situation A metamodel-to-notatio
n mapping
Proposal for BPMN 2.0 A metamodel-to-metamodel
mapping
7
Benefits of the Approach

• BPMN 2.0 Metamodel is based on BPMN 1.1 The
  metamodel formalizes the implicit metamodel of
  BPMN 1.1
• Extends BPMN 1.1 Upward compatible extension of
  BPMN 1.1 so complications of upgrading to BPMN
  2.0 are minimized
• Reuse of adopted technologies Relies on widely
  adopted standards where possible, e.g XML Schema,
  XPath
• Portability of processes Achieved through
  exchange formats and execution semantics
• Modular design The BPMN specification is
  structured in layers, where each layer builds on
  top of and extends lower layers
• Extendable language for future innovations The
  language is extendable so that additional
  capabilities can be introduced on top of it

8
Agenda

• Overview
• Goals and Market Requirements
• Design Rationale
• Benefits of the Approach
• Notation and Diagrams
• Detailed Drill Down
• Metamodel Structure
• Choreography
• Human Interactions
• Events
• Execution Semantics Alignment
• Schema and Model Interchange
• Summary

9
Notation and Diagrams

• BPMN 2.0 contains three (3) views or diagrams
• Process (Orchestration)
• Choreography
• An additional Choreography view, a Participant
  Interaction View, is under development
• Collaboration combines Orchestration,
  Choreography, and Pools

10
The Process View (Orchestration)

• An Orchestration Process defines processes that
  are internal to a specific organization
• The Process elements include Activities, Events,
  Gateways, Sequence Flow, Data, Artifacts, and
  Associations

11
The Choreography View

• A Choreography Process depicts the interactions
  between two or more business entities
  (Participants)
• The Process elements include Activities, Events,
  Gateways, Sequence Flow, Artifacts, and
  Associations

12
The Collaboration View

• Collaboration involves two (2) or more Pools
• The Pools can be Black-Box while showing the
  Message Flow between them
• The Diagram elements include (in addition to
  Process elements) Pools and Message Flow

13
The Collaboration View (cont.)

• The Pools can show the Processes within them, and
  the Message Flow between the activities of the
  Pools

14
The Collaboration View (cont.)

• Choreographies can be shown in between the Pools
• The relationship between the Orchestration and
  Choreography can be shown

15
Agenda

• Overview
• Goals and Market Requirements
• Design Rationale
• Benefits of the Approach
• Notation and Diagrams
• Detailed Drill Down
• Metamodel Structure
• Choreography
• Human Interactions
• Events
• Execution Semantics Alignment
• Schema and Model Interchange
• Summary

16
BPMN 2.0 Metamodel Structure

• The proposed technical structuring of BPMN is
  based on the concept of extensibility layers on
  top of a basic series of simple elements
  identified as Core Elements of the specification.
  
• Layering is used to describe additional elements
  of the specification that extend and add new
  constructs to the specification and relies on
  clear dependency paths for resolution.
• The Serialization model for BPMN follows the
  structuring of the core and it is a direct
  representation of the BPMN core Metamodel.

17
BPMN 2.0 Core

• BPMN Core includes the most fundamental elements
  of required for modeling the flow of activities,
  events, messages, and how they are sequenced.
• The Core is simple, concise, and extendable, with
  well defined behavior
• The BPMN Core is organized in four packages
• Common includes the fundamental structuring
  elements that provide syntactic and semantic
  integrity to all BPMN Extensions (current and
  future)
• Process contains classes which are used for
  modeling the flow of activities, events,
  messages, and how they are sequenced within a
  Process
• Collaboration contains classes which are used
  for modeling Collaborations, which is a
  collection of Pools, their interactions as shown
  by Message Flow, and may include Processes and/or
  Choreographies .
• Service contains constructs necessary for
  modeling services, interfaces, and operations.

18
BPMN 2.0 Core Elements
Organization of the main set of BPMN core model
elements
19
BPMN 2.0 Extension Layers

• Layers are based on Core
• Layers follow well defined extensibility
  constraints that ensure specification integrity
• Layers included in BPMN 2.0
• Data for the specification of data flows.
• Gateways for the specification of control flow
  operational semantics.
• Events for the specification of even-driven
  process interactions.
• Compensation for the specification of
  operational compensation.
• Human Interactions for the specification of
  Human Activities
• Choreography for the specification of
  multi-process Choreographies
• Artifacts for the specification of annotations.

20
BPMN Elements
New Variations Added
New Elements
21
Choreography

• New in BPMN 2.0
• Can be used stand-alone or within a larger
  Collaboration view
• A Choreography Process is in between the Pools
• A Choreography Process depicts the interactions
  between two or more business entities
  (Participants)
• The Process elements include Activities, Events,
  Gateways, Sequence Flow, Artifacts, and
  Associations
• Choreography Activities are similar, but
  distinguishable from Orchestration Activities

22
Choreography Elements

• A Choreography is a type of Process, with the
  following elements
• Most are common to Orchestration elements
• Some have restrictions for use in Choreography
  (e.g., no data expressions)
• Events
• Start, Intermediate, and End
• Activities
• Choreography Task, Choreography Sub-Process, and
  Choreography Reference
• Gateways
• Exclusive, Event-Based, Inclusive, and Parallel
• Message
• Artifacts
• Group, Text Annotation

23
Choreography Model

• a Choreography is a type of Process, but
  fundamentally different from an Orchestration
• It is a definition of expected behavior, a
  procedural contract, between interacting
  Participants

24
Choreography Task

• A Choreography Task is an atomic activity in a
  Choreography Process. It represents a coherent
  set (1 or more) of Message exchanges
• The list of Participants (and Bands) is
  expandable

25
Message

• A Message is used to depict the content of a
  communication between two Participants
• It can be used with a Message Flow or Associated
  with a Choreography Activity

26
Human Interactions
ltxsdelement name"userTask" type"tUserTask"
substitutionGroup"flowElement"/gt ltxsdcomplexTy
pe name"tUserTask"gt ltxsdcomplexContentgt
ltxsdextension base"tTask"gt
ltxsdsequencegt
ltxsdattribute name"implementationdefault"unsp
ecified"/gt ltxsdattribute
name"inMessageRef" use"optional"/gt
ltxsdattribute name"outMessageRef"
use"optional"/gt lt/xsdextensiongt
lt/xsdcomplexContentgt lt/xsdcomplexTypegt

• Tasks performed by human users
• Notation
• Types of Tasks with human involvement
• Manual Tasks Not managed by any business process
  engine
• User Tasks Managed by a business process engine

27
People Assignment for User Tasks
ltxsdelement name"humanPerformer"
substitutionGroup"performer"/gt ltxsdcomplexType
name"tHumanPerformer"gt ltxsdcomplexContentgt
ltxsdextension base"tPerformer"gt
ltxsdsequencegt ltxsdelement
ref"peopleAssignment" minOccurs"1"
maxOccurs"1"/gt lt/xsdsequencegt
lt/xsdextensiongt lt/xsdcomplexContentgt lt/xsdco
mplexTypegt
28
Example Procurement Process
ltbpmnuserTask id"ID7" name"Approve Order"
implementation"humanTaskWebService"gt
ltbpmnhumanPerformer id"ID8"gt
ltbpmnpeopleAssignmentPeopleGroup id"ID9"
definition"regionalManagers"gt
ltparameter id"ID10" parameter"ID2"gt
ltbpmnexpression id"ID11"gt /QuoteDataObject/namelt
/bpmnexpressiongt lt/parametergt
ltparameter id"ID12" parameter"ID3"gt
ltbpmnexpression id"ID13"gt /QuoteDataObject/addr
ess/countrylt/bpmnexpressiongt
lt/parametergt lt/bpmnpeopleAssignmentPeopleGr
oupgt lt/bpmnhumanPerformergt lt/bpmnuserTaskgt
29
Events

• Event is a noteworthy occurrence that affects
  the flow of the process
• Different event types
• Events explicitly thrown outside of the process
  Message
• Events based on time-base or status-based
  conditions Timer, Conditional
• Internal events Error, Cancel, Terminate,
  Compensation

30
Events Definition
31
Example Event Handlers
32
Execution Semantics Overview

• Purpose
• Describe a clear and precise understanding of the
  operation of the BPMN elements
• Approach
• The execution semantics are described informally
  as text
• The execution semantics is described using a
  token flow model
• (Based on prior research involving the
  formalization of execution semantics using
  mathematical formalisms)
• Semantics is described for
• Activities
• Basic state diagram
• Specific behavior of activity types (service
  task, human task, subprocess, event handler,
  ad-hoc activity, loop activity, multi instance
  activity)
• Gateways
• Token synchronization, consumption and production
  for each type of gateway
• Events
• Start, intermediate, boundary and end events
• Process Levels (TBD)
• Choreography (TBD)
• Multiple Processes (TBD)

33
Execution Semantics Activities

• Any activity is executed according to the state
  diagram
• Main path
• Inactive
• Running
• Completed
• Closed
• Special considerations for
• Event-based wait (Enabled, Withdrawn)
• Async handlers in case of a sub-process
  (Completing)
• Error handling (Failed)
• Compensation handling (Compensating, Compensated)
• Abnormal termination (Terminated)

34
Execution Semantics Gateways

• The execution semantics for gateways describes
• Which inbound token combinations are required to
  activate the gateway
• Which outbound sequence flows receive tokens
  after activation of the gateway
• Example 1 Parallel Gateway (Fork, Join)
• Activation At least one token present on
  eachincoming sequence flow
• Behavior Consumes one token from each
  incomingsequence flow, and produces exactly one
  token on eachoutgoing sequence flow
• Example 2 Exclusive Gateway (Decision, Merge)
• Activation At least one token present on
  anyincoming sequence flow
• Behavior Consumes exactly one token from
  oneincoming sequence flow, and passes it on to
  exactly oneoutgoing sequence flow which one is
  determined byconditions, including possible
  default sequence flow

35
Execution Semantics Events

• Throw events
• When a throw event is activated by an inbound
  token, it triggers the associated external event
  (such as a message) or internal event (such as a
  signal, termination or compensation trigger)
• Catch events
• When an external event (such as a message or a
  timer) or internal event (such as a signal,
  termination or compensation trigger) is received,
  a token is produced on the catch events outgoing
  sequence flow
• Triggering a start events first causes creation
  of a new process instance
• Triggering a boundary event first causes
  termination of the associated activity
• Triggering a start event of a subprocess event
  handler causes creation of a new event handler
  instance (without terminating the subprocess)
• Compensation
• Compensation handlers of a subprocess can be
  realized as an event handler with access to the
  subprocess data, allowing for recursive
  compensation

36
Agenda

• Overview
• Goals and Market Requirements
• Design Rationale
• Benefits of the Approach
• Notation and Diagrams
• Detailed Drill Down
• Metamodel Structure
• Choreography
• Human Interactions
• Events
• Execution Semantics Alignment
• Schema and Model Interchange
• Summary

37
Model Interchange

• Goal Interoperability
• Two Interchange Formats
• MOF XMI
• XML Schema
• Plus an XSLT Transformation between them.
• Formats will be equivalent. Few differences,
  largely due to technology differences (e.g. XML
  provides first class support for choice, while
  XMI does not).

38
Model Interchange

• XML Schema
• Designed for extensibility
• Defines global elements and global types
• Use of anyAttribute and any element
• ltxsdelement name"baseElement"
  type"tBaseElement"/gt
• ltxsdcomplexType name"tBaseElement"
  abstract"true"gt
• ltxsdsequencegt
• ltxsdelement ref"documentation" minOccurs"0"
  maxOccurs"unbounded"/gt
• ltxsdany namespace"other" processContents"lax
  " minOccurs"0" maxOccurs"unbounded"/gt
• lt/xsdsequencegt
• ltxsdattribute name"id" type"xsdID"
  use"required"/gt
• ltxsdanyAttribute namespace"other"
  processContents"lax"/gt
• lt/xsdcomplexTypegt
• Supports mixed-content where appropriate.
• Designed to reduce the footprint and complexity
  of XML instances (use of substitutionGroups, for
  example).

39
Model Interchange

• XML Schema - Snippet
• ltxsdelement name"activity" type"tActivity"/gt
• ltxsdcomplexType name"tActivity"
  abstract"true"gt
• ltxsdcomplexContentgt
• ltxsdextension base"tFlowElement"gt
• ltxsdsequencegt
• ltxsdelement ref"performer" minOccurs"0"
  maxOccurs"unbounded"/gt
• ltxsdelement ref"loopCharacteristics"
  minOccurs"0"/gt
• lt/xsdsequencegt
• ltxsdattribute name"isForCompensation"
  type"xsdboolean" default"false"/gt
• lt/xsdextensiongt
• lt/xsdcomplexContentgt
• lt/xsdcomplexTypegt
• ltxsdelement name"task" type"tTask"
  substitutionGroup"flowElement"/gt
• ltxsdcomplexType name"tTask"gt
• ltxsdcomplexContentgt
• ltxsdextension base"tActivity"/gt

40
Summary

• BPMN 2.0 Metamodel is based on BPMN 1.1 The
  metamodel formalizes the implicit metamodel of
  BPMN 1.1
• Extends BPMN 1.1 Upward compatible extension of
  BPMN 1.1 so complications of upgrading to BPMN
  2.0 are minimized
• Reuse of adopted technologies Relies on widely
  adopted standards where possible, e.g XML Schema,
  XPath
• Portability of processes Achieved through
  exchange formats and execution semantics
• Modular design The BPMN specification is
  structured in layers, where each layer builds on
  top of and extends lower layers
• Extendable language for future innovations The
  language is extendable so that additional
  capabilities can be introduced on top of it

41
Major Changes Since BPMN 1.1

• Choreography View and new elements
• Participant Interaction View (Choreography
  variation TBD)
• Process View
• Inclusion of Choreography within Collaboration
  View
• Collaboration View is basically the BPMN 1.1 BPD
• Formalization of BPMN execution semantics (for
  Orchestration)
• Activity lifecycle
• Formalization of BPMN 1.1 implicit metamodel
• Derived XMI Schema
• XML Schema (in progress)
• Formal Extensibility mechanisms
• Diagram Interchange model and schema
• Separation of Data Object from Artifacts to a
  first class Data element
• Addition of Repository type of Data element
• Expanded Human Interaction definitions

42
Major Changes Since BPMN 1.1, Cont.

• Reorganization of embedded vs. called activities
• Defined interfaces for called activities
• Improved definition of Event Handling
• Addition of non-interrupting Events (TBD)
• Addition of optional Sub-Processes
• Icons for Task types (in progress)
• Definition of BPMN subset that can be mapped to
  BPEL
• Notation for Message