Background
The purpose of this Background section is to fulfill two roles: to lay out the ground
for our motivation – i.e., show BPMN and BPMN modeling tools and how they can
be enhanced – and [although the motivation to focus on exception handling
verification is not discussed here,] we elaborate on exception handling in BPMN and
in general.
We'll start with the concepts of BPM and SOA, to ease you into the world of business
processes. Then we'll discuss BPMN in detail. The first phase of BPMN will include
only the basic elements – a crash course of sorts – enough for you to be able to read
the diagrams throughout this work. We also need to elaborate on Exception Handling
in BPMN, but for that we first must understand Exceptions and Exception Handling
strategies. After coming to understand Exceptions we will elaborate on Exceptions in
BPMN, [and that will be all the immediate information needed on BPMN.] This will
be part of the answer to Q1 – how BPMN provides answers to the business analyst’s
needs. The other part of the needs involves good modeling tools to write BPMN
diagrams.
Therefore, we will next review BPMN modeling tools, what their capabilities are and
how much help they give the business analyst (compared to a whiteboard, for
example). This will answer Q2 regarding the tools the business analyst uses. But we
still haven’t finished with Q1. To consider what features the business analyst requires
from his tools, we will review different editing features from various disciplines,
focusing on exception handling in the software discipline.
Last, but not least, we will provide an elaborate review of one of the BPMN modeling
tools – Prosero’s modeling tool. Prosero [receives this royal treatment] as it is the
system with which [we will experiment our suggested enhancements.]
The Background includes the answers to our first two main questions and all the
information necessary to understand our reasoning in focusing on Exception
Handling, and in solving the problems the way we did. By the time you obtain all this
background knowledge you will probably identify many issues that can be improved
in BPMN modeling tools. Alas, we have only so much time and so many pages. And
we will use them to explore the issues of exception handling in the next chapter.
Background – Part 1
Business Process Models
Business processes are like complex recipes that indicate how to handle certain
business situations. For instance, a process used in a sales organization would
describe the steps involved in taking care of an order for a product by a customer.
Steps described in the process can be assigned to staff within the company to be
performed manually (e.g., “approve purchase order”) or they can be sent for
automatic execution to back-end servers of the company, or to third-party partners
and suppliers. The formal documentation of business processes allows companies to
improve their efficiency, monitor their operation and detect bottlenecks or
deficiencies.
1
BPM and SOA
In recent years, Service Oriented Architecture (SOA) has emerged as a powerful
methodology allowing business process analysts to specify business processes, and
Information Technology (IT) specialists to provide services in a form that is
immediately usable at the business strategy level. SOA organizes IT services as a set
of Web Services, which are software modules available on the Web through a
standard interface. For instance, in order to deliver a package, one can invoke such a
web service; once the request is sent through a regular Web browser interaction,
someone will pick up the order and deliver it to the requested destination.
BPMN, what is it good for?
BPMN, Business Process Model Notation, is a specification for writing BPMs. The
specification was detailed by the OMG. The first important piece of information
following that is the fact that the BPMN’s final specifications, for version 1.0, were
set as late as February 2006, just under three years ago. This is the first hint that this
standard may have room for improvements. The second hint is that even in version
1.1, emerging in 2008, all of the enhancements we suggest throughout this study were
not added.
Before
we
begin
our
review,
let's
examine
a
BPMN
example:
Figure 3.
"BPMN Sequence Flows. Reprinted with permission. Object Management Group, Inc. (C) OMG. 2008."
The first thing we notice about this diagram, prior to all the explanations, is that it is
clear. Even people outside the industry can follow the described process of handling
an order. The second thing one might notice is that no data is specified in the process,
only activities. More on these two will follow.
Now, how did BPMN come to be? Prior to BPMN there were:
1. Scores of process modeling tools and methodologies; i.e., all sorts of visual
business process flow-chart formats. We will not elaborate on these. We will
focus on BPMN's Business Process Diagram (BPD).
2. Web service-based XML execution languages, e.g., BPEL, for Business
Process Management systems. These languages are not discussed in this
section. Suffice it to say they can be handled very well by a software system,
but would be hard to understand by business analysts and managers.
That created some problems:
1. Business analysts are required to understand multiple representations of
business processes.
2
2. Business participants that don't share the same graphical notations might not
understand one another.
3. A technical gap between the format of the business process initial design and
the format of the languages that will execute these business processes.
BPMN solution:
1. BPMN provided a standard graphical notation. It follows traditional flowcharting.
2. To solve the technical gap:
1. BPMN provides BPD - to be used by people who model and manage
business processes.
2. BPMN provides formal mapping to an execution language of the BPM
system – to be used by IT (technical) people who design the process
(software) execution.
Though I like the notion of transforming BPMN to BPEL, this is not the major
advantage of the language, in my humble opinion. A language that describes a process
sequence flow in a clear and readable way has its own merit, even without automatic
execution, that is, even if all tasks are performed by humans.
Having said that, I must admit that exception handling is more important for
automatic execution than for human execution, for obvious reasons – humans can deal
with unexpected events much better than machines (at least for the time being).
BPMN for mummies
Most of the information here is taken directly from the OMG's BPMN technical
specification, version 1.0., specifically, the information on the attributes. For further
information on BPMN you can read the complete specifications. But for those who
prefer to "look and listen," I highly recommend Dr. Bruce Silver’s online course,
[XXX]. It is free, registration is required, and it takes less than two hours. It includes
all the information summarized in this background plus some useful tips. However,
the first forty minutes are enough to understand the basics.
Basic BPMN
Let's consider the BPMN graphical objects and their relationships. First, a list of BPD
core elements that will support the requirement of a simple notation.

3
Flow Objects - behavior of a Business Process
o Events
 Start
 Intermediate (we will focus on Error)
 End
o Activities
 Process (not a graphical element)
 Sub-Process
 Task (atomic activity)




Service | Receive | Send | User | Script | Manual |
Reference | None
o Gateways (control how Sequence Flow interact)
 Exclusive Decision/Merge (XOR)
 Inclusive Decision/Merge (OR)
 Complex Decision/Merge
 Parallel Fork/Join (AND)
Connecting Objects - connecting the Flow Objects
o Sequence Flow (order activities)
o Message Flow (cannot connect two objects within the same Pool)
o Association
(Artifacts with Flow Objects)
Swim-lanes - grouping
o Pools (Participant in the Process)
o Lanes (organize and categorize activities)
Artifacts - additional information
o Data Objects (i.e., "Purchase Order [Complete]", "Purchase Order
[Approved]")
o Group
o Annotation
The three most important and basic elements are the Activity, a rectangular shape, the
Gateway, a diamond shape, and the Event, a circular shape. As noted, they have
different sub-types, graphically depicted by an additional icon inside the basic shape.
But, we are not in any hurry to know everything. We'll touch some sub-types later.
First, understanding the three basic elements is winning half the battle. Let's look at
the BPMN example we saw:
[source xxxx]
Activity is a point of decision making. Some data is being prepared or reviewed. Or,
some action is being taken by a person or by a machine. For example, "Ship Order" is
a physical action, while "Send Invoice" can be performed by automated email.
A Gateway is either a conditional decision, splitting the sequence to several
continuations, or a point where several paths join together. The notation of the
Gateway and its outgoing flows should make it easy to understand. Here we see that
the "Accepted or Rejected?" Gateway is an exclusive decision with one path for each
scenario. And the other Gateway joins two parallel paths. Meaning, there is a
condition here – continue only after both paths have been completed.
Events are one of the innovations of BPMN. They mark a point where the process
sends a message, or a signal, to another process. Alternatively, they can mark a point
where the process is waiting for a message/signal. Here, the circle on the left is the
4
Start Event – a point where the process is initiated (signaled to start); the right circle is
the End Event – where the process signals its completion. The "Accept Payment"
Activity could be replaced by an Intermediate Event – waiting for the message
'payment was accepted'.
Now half the battle has been won; let us conquer one more outpost by explaining
how Pool and Lane would fit in the above example.
Pool is the chief participant body which provides the resources for executing the
process, usually, the company which manages the processes. Here we could say, the
company is "Big Happy Boxes," and that would also be the name of the Pool.
Inside the Pool there are the Lanes – categorizations of duties, usually departments in
the company. Here we would assign "Ship Order" to the 'Shipment' Lane and payment
related Activities to the 'Accounting' Lane.
Has it occurred to you from where our process, in example 1.2, receives the payment
message? Let's say it's from another process. That process would be called an external
process. We could draw an abstract estimation of that process, since it is not our
process, and show the message choreography between the two processes.
In this work we deal only with Private (internal) business processes - internal to a
specific organization. We will not discuss choreography.
BPMN is intended to be extensible by modelers and modeling tools – meaning:
adding attributes to existing elements and adding new element types. To satisfy
additional modeling concepts that are not part of the basic set of flow elements,
BPMN provides the concept of Artifacts that can be linked to the existing Flow
Objects through Associations. Thus, Artifacts do not affect the basic Sequence or
Message Flow, nor do they affect mappings to execution languages. The meaning and
the execution of the original "Handle Order" process, diagram 1.19, and of diagram
1.21 is exactly the same:
5
"Order" is an Artifact of type Data-Object, and it is associated (by an Association
link) as the output of the "Receive Order" Activity and as the input of the "Fill Order"
Activity. Although this information seems very relevant, BPMN does not emphasize
Data. It is, rightfully, more concerned with the sequence flow. However, we will see,
later on, that Data-Object information is useful for building the execution of the
process.
At this point you know enough about BPMN to start modeling diagrams of your own.
I cannot provide you with the entire three hundred pages of BPMN specifications. For
more information on BPMN, I suggest you consult [1], [2], or one of the many
resources on the web. After this crash course in BPMN, the next stop is the tools the
business analyst uses to model Business Process Diagrams. While examining the
tools, we will consider what might be missing.
BPMN Tools
All of the following tools follow the BPMN specification to the letter. Some may add
extensions that fit their users’ needs.
eBPMN Designer by soyatec.com
This tool is based on Eclipse platform. It has a free version with most of the features.
Features:








Pool auto-layout management
o All pools are kept the same size.
Connectivity control
o Prevents wrong semantic connections.
Type conversion
o Change element type after its creation.
Embedded sub-process design
o Support collapse, restore and maximum-view.
Boundary attachment
o Some Intermediate Events such as, Timer, Error and Compensation,
can be attached to the boundary of an activity.
o Note - from my experience, this feature worked well for Sub-Process.
Model explorer to show logical model view
Boundary attachment of Start/End event
Embedded Sub-Process refractory by grouping
Business Process Visual ARCHITECT by visual-paradigm.com
The free version does not provide any interesting features.
6
Features:







Business process diagram
o Note - Easy and intuitive usage.
o Note - Collapsed SubProcess shows a small image of the SubProcess
Data flow diagram
o Note - Interesting, but not part of the BPMN specifications. Thus, the
diagram cannot be automated.
Entity relationship diagram
Textual analysis
o Identify candidate classes from a problem statement (in natural
language).
Overview diagram
o Relationship among diagrams
o Note - like a BPD where all activities are referenced Sub-Processes.
Export business process diagram to BPEL
Identify candidate business process element by textual analysis
Business Process Modeler for Business Analysts by eClarus




Keep requirements and implementation in sync with BPMN-BPEL RoundTrip Engineering.
Generate ready-to-deploy BPEL 1.1 or 2.0 codes that can run on any BPEL
servers.
Help validate proposed process changes and identify hard-to-find bottlenecks
and potential optimizations with built-in simulation.
Model validation as BPMN compliant
BPMN Modeling Tool by Prosero project, DT Labs @ BGU



Support BPMN core elements
Suggest business process Activities and Data-Object from customer
repository.
Export business process diagram to BPEL, using a Natural Language
Processing procedure to match an appropriate Web-Service to each Task.
At first look, Prosero's modeling tool seems lame compared to other tools; from
BPMN aspects, it is. It doesn't even support the full spec of BPMN, and it only
supports the Referenced (Collapsed) Sub-Process and not the Expanded Sub-Process.
But, Prosero is a prototype system whose focus is the last feature we mentioned –
BPEL transformation. And in that department, it is a step above the rest. Since
Prosero is the tool in which we implemented our solutions, we'll give it a special
review.
More on Prosero
As part of the ongoing research project Prosero at Ben-Gurion University, we are
investigating ways to improve the workflow
 from - business process specification by a business analyst
7

to - deployment of the process within a SOA based on concrete Web
Services by a software developer.
The Prosero project relies on the analysis of gaps between the level of analysis used
by business analysts (at the business strategy level) and software developers (at the
technical level). To bridge this gap, the Prosero project introduces a set of reference
models which are semantically annotated and describe the activities and data objects
manipulated by typical business processes. Business analysts rely on these semantic
repositories to compose composite business processes that can be safely mapped to
executable SOA Web Service orchestrations.
A business analyst defines a process, for a customer, using a prepared reference
model repository (RMR). This repository includes predefined tasks and data-objects
to be used in building the business process. The defined process is entered into the
customer models repository (CMR). The analyst may then customize the business
process according to the customer’s specific mode of operation.
The Prosero system will then transform the customized business process, in BPMN
format, into a SOA process-sequence of web-services (implemented in BPEL). The
web-services are taken from a Web Service Repository (WSR) and are selected by the
Prosero Matcher to fit the functional and non-functional requirement of the overall
business process.
We will not detail the Matcher operation. That is for another thesis (in another time,
by another student – i.e. Shay). We will take a closer look at the functional
requirements the Matcher considers for each Task.
The functional requirements include:
- Task's input Data-Object
- Task's output Data-Object
- Task type: Service of Human
This is important information for the Matcher. It helps to filter out non relevant
Services which do not support the requirement.
User support in other disciplines
We saw what BPMN modeling tools offer the business analyst. Here I will compare
their capabilities to some basic features given by "environments" from other
professions (seemingly unrelated).
Word processing
Document writing assistance
 Spelling and Grammar validation
 Automatic text (e.g., weekdays, greetings, etc.)
 Creating a document from a template.
 Creating new templates.
Programming environments
Code writing assistance
 Text auto completion – suggesting which reference to use
(variable/method/type name).
8
 Code template – method format, loop format, etc.
Reflection – basically means to modify your code without changing its
meaning/behavior. For example, beautifying and improving re-usability.
 Renaming a variable and all references to it.
 Identifying code duplicities.
 Extracting code segment to another file.
Static validation (compilation)
 Type matching – e.g., you can't ask what is the minimum,
mathematically, of 4, 21 and Potato Salad.
 Unhandled exceptions – e.g., if you are told a function might
fail, you must deal with that possibility
Human intellect
Planning assistance




Identifying patterns
Identifying duplicities – e.g. repeating names
Identifying the right task for the goal
Thinking ahead and avoiding exceptions
Obviously this is only a limited list. But, when we think about writing experience,
developing experience and living experience and compare them with BPMN
modeling experience… Just a minute. Thinking is not part of a Background section.
Let us have a short intermission.
To be continued…
Intermission – find our bearings
Business analyst’s needs
Considering the short feature list of the different disciplines, what would we consider
to be a major requirement for the business analyst?
o Spelling is a definite plus, but it is only a "nice to have" and not much research
about it is needed.
o Auto-completion, the most addictive feature known to date, is already offered
by Visual-Paradigm, using "Identify candidate…", and by Prosero, using
"Suggest Tasks from repository".
o Refactoring is a great help. And even though Soyatec's tool already offers
refactoring, we could probably suggest enhancements.
o Static validation/verification is basically thinking ahead, checking a process
before executing it. It is extremely valuable and indeed BPMN syntax is
validated in many tools. But other than syntax, the only verification offered is
some optimization.
o Patterns and templates are needed by any person who deals with planning.
Instead of re-inventing the wheel a business analyst can use a well known
9
solution – a work pattern. A template is an abstract representation of the
pattern.
o If we could offer new insights on business process patterns - that
would be wonderful. But that has been covered through and through by
groups such as workflow-patterns [22].
o Nevertheless, not many modeling tools offer to their users patterns, in
the form of templates, for specific business goals. The way, for
example, Visual Studio IDE ** offers programming patterns: when the
user selects a pattern the tool automatically generates the appropriate
components, as an empty skeleton. Or a Calendar Wizard, which can
create a huge calendar document in a few steps.
Motivation and scope
Our initial scope was enhancing a modeling tool. Now we need to pick the
enhancement from one of the three topics: refactoring, static verification and
templates. So, let's sit down, make ourselves a nice hot cup of tea and consider the
matter. Aha! What if the kettle is malfunctioning? Did you stop to consider that?! (or,
what if you don’t have a kettle since your spouse prefers a cauldron?). Without a
kettle, how can you make tea? And without tea how can you engage in reading the
problems you are reading at this very moment…
Seriously, such scenarios are our motivation for looking into possible errors in the
execution. Identifying in advance possible errors in the execution – exceptions - is
part of the static verification. There is no need for me to shout over rooftops that static
analysis is important. Shortly, we will elaborate on it and show it saves huge amount
of time and money. Is it the most important aspect of BPMN? Not necessarily. The
Prosero prototype did not regard it as the top issue. Like Prosero, many feel that
BPMN to BPEL transformation is a much bigger issue. I could argue my own love for
languages and the importance of a coherent statement. But even without arguing, I
can tell you that many have researched the transformation issue and, as we’ve seen,
have left the static analysis to the level of syntax verification. And so there is much to
contribute on static verification – as part of the effort to help Business Process
Diagram modelers.
Still, the importance of BPEL does not elude us. We know that BPMN diagrams are
not meant just to be hung on walls. They are meant to be executed. And therefore we
want to contribute in making the execution as smooth as possible, meaning, to either
avoid exceptions or to handle exceptions. And I will make it clear time and time
again: I do not care if the one executing the process is a machine or a person.
Although, clearly, a machine won’t handle an unknown condition as well as a human
being, a manager will save time and money if his/her employees can follow a
sequence of instructions without stopping and calling for help in unexpected
scenarios.
That is the major responsibility of the business analyst when writing a business
process - to make it robust by avoiding or handling unexpected scenarios. This is part
of his responsibility to write coherent business processes. We will touch on other
10
aspects of coherent diagrams, such as clarity, much later. Currently we are focused on
exceptions.
To sum up the focus of our problem: our initial scope is improving modeling tools.
We concluded that good static analysis is a huge time saver for an instructive
description, i.e., finding a problem in your process during design time and before you
allocate resources for its execution, is very beneficial. Which leaves the question,
which aspects of static verification should we improve to help us model a robust
business process? The answer is that we want to be able to identify pitfalls in the
process, which the business analyst has missed, and inform him of the mistake. The
most dangerous pitfall is reaching an unexpected condition in execution, that is,
causing an exception. In other words, the most dangerous pitfall is not handling an
exception.
Now it is time to elaborate on exceptions and exception handling.
Background – Part 2
Previously, in Background… we discussed BPMN, BPMN modeling tools and
features from various disciplines.
And now, the continuation…
Exceptions and Exception Handling
An exception is an occurrence during an execution of a process. It can be viewed as a
status and as a message. An exception status for a system means the system has
aborted the current execution, namely, the execution stops at the current scope and the
execution control returns to the calling scope. We say that the system threw an
exception or raised an exception. The system usually informs the calling scope it has
aborted – that is the exception message – and might include in the message details on
the exception, such as, its reason and the particular action that caused it. The message
the system passes is also referred to as an exception event.
Reasons for an exception can be an unknown instruction, a limited resource or even
an instruction in the process raising the exception. In the next chapter, we will
research different types of exceptions. For now, it is important to distinguish a
specified exception – an instruction in the process specified as throwing an exception
– and an unspecified exception – the system throws an exception because of a fault.
These are also called declared and undeclared exceptions, respectively. For example,
in the instruction, “if they are late, cancel the meeting” we see a specified exception.
If “they” (you know… them…) do not come to the meeting, the specified exception
will be thrown and the meeting will be cancelled. Of course, there are numerous other
unspecified reasons for an exception – the cancellation of the meeting – such as,
termites in the building. The distinction is important for handling techniques which
we’ll discuss later on in the research.
Example – The mystery of the melting keyboard
Here we have an instructive sequence of events:
11
1.
2.
3.
4.
Approach the keyboard.
Type any number.
If you typed "9" the keyboard will melt down.
Type any letter.
In this case, the exception is expected but unspecified. You cannot type any
letter, at step 4, if you typed "9", since there is no keyboard; this is a failure!
An exception! Exceptions lead to frustration and frustration leads to the Dark
Side.
At the very least, we can view this failure as a cognitive exception of the
person following the instructions. There is an instruction he cannot execute.
For a tiny moment his brain is stuck. As we will soon discuss, the person can
simply disregard this failure and continue, in which case it remains at the
cognitive level. But, in compliance with modern systems, the person should do
something in response to this failure – handling it. Thus, the exception moves
from the cognitive level to a real, live event. For example, he can call his
supervisor and say "Hey! This step has failed!" He aborted the execution and
threw an exception at his supervisor. Or he can log the exception in a log-book
and either carry on or abort.
To understand exception handling we will review three types of execution paths. For
any instructive description, be it in a text, diagram or program, there are three paths:
1. Normal path, also known as normal flow, basic flow, sunny day scenario and
happy path. We will use “happy path”.
2. Alternate path, also known as alternate flow.
3. Exception path, also known as exception flow and exception handling flow.
The “happy path” is the sequence of events which can be considered the best scenario
to achieve the goal of the instructions. For example:
Bring cookies to grandma #1
(1) Take cookies
(2) Walk on “Ever After” road
(3) Cross the forest
(4) After 10 minutes you’ll reach grandma’s house
These instructions, use case #1, depict a happy path. Now, an Alternative flow is
when not everything is going well, but you can still achieve your goal.
Bring cookies to grandma #2
(1) Take cookies
(2) If it is raining, take an umbrella (in addition to your hood)
(3) Walk on “Ever After” road
(4) If the road is closed, go past Rapunzel’s tower instead
(5) Cross the forest
(6) After 10 minutes you’ll reach grandma’s house
The happy path is still 1,3,5 and 6, if we disregard the restrictions as an actual step.
And there are three alternative paths: rain (1,2,3,5,6), closed road (1,3,4,5,6) and both
(1,2,3,4,5,6).
12
Consider for a moment the BPMN example 1.19.
The ‘Accepted’ scenario is the Happy Path, while the ‘Rejected’ scenario is the
Alternate Path.
There are some disagreements about the distinction between an Alternate flow and an
Exception flow. Some say the Alternate flow must reach a successful completion of
the task, and that the Exception flow is any scenario in which the goal is not reached.
We claim that an Exception Flow is a type of an Alternate flow. The only difference
is that it includes an event tagged as Exception, regardless if the goal is reached or
not.
Bring cookies to grandma #3
(1) Take cookies
(2) If it is raining, take an umbrella (in addition to your hood)
(3) Try to:
a. Walk on “Ever After” road
(4) If failed (exception caught), go past Rapunzel’s tower instead
(5) Cross the forest
(6) After 10 minutes you’ll reach grandma’s house
In general, there is no distinction between use-case #2 and use-case #3, other than
calling the closed road scenario an Exception Flow. But the distinction is deeper:
- In use-case #2 we avoid an unknown condition – we consider the possibility of
a closed road. We attempt to avoid an exception.
- In use-case #3, instead of avoiding an exception, we handle the exception. In
the scope of “Try to” we did not consider what might prevent us from
completing the task. But any such unexpected event will be caught and
handled.
- Some would say it is not really unexpected, since we handle it, and so it can’t
be called an exception. But that’s just semantics.
The biggest advantage Exception Handling has over a situation with restrictions is the
fact it can cover more cases in less work. For example:
Bring cookies to grandma #4
(1) Try to:
a. Take cookies
b. Walk on “Ever After” road
c. Cross the forest
d. After 10 minutes you’ll reach grandma’s house
(2) If failed (exception caught): call grandma and say you won’t be coming
13
For this solution, of canceling the visit, we did not need to check the success of each
step. If one failed, we give up. Obviously that is just one strategy. Want to hear other
strategies?!
Exception handling strategies
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
 Don’t handle
Strategy: don’t even attempt to catch a thrown exception.
Result: process aborts and control returns to caller.
Example: “go to grandma’s house” – no mention of an exception.
 Ignore and continue
Strategy: catch but do nothing about it.
Result: Usually futile, since part of the process was not completed
Example: “try to: go to grandma’s house. Then go to the muffin man.”
– if you failed to reach grandma’s house, you’ll try the muffin man
even if you aborted in the middle of the forest.
 Log
Strategy: write the details of the exception in a log.
Result: instead of keeping track of a process execution, you can later
read the log for any problems
Example: “try to: go to grandma’s house. If you failed: tell mom. Go to
the muffin man.” – make a note of the failed attempt and, again,
continue to the next task and hope it does not rely on the failed one.
 Recover
Strategy: try to complete your goal even without completing the failed
action. There are various methods of doing this.
Result: the overall goal achieved
Example: “try to: go to grandma’s house. If you failed: ask the woodcutter to go to the muffin man. If you didn’t fail, go to the muffin
man.”
 Abort the process
Strategy: throw your own exception
Result: this process still fails, but you can make sure the reason is clear
Example: “try to: go to grandma’s house. If you failed: go home. If
you didn’t fail, go to the muffin man.” – (1) if you didn’t reach
grandma, you will not reach the muffin man; (2) when your caller
knows you but doesn’t know grandma, it makes sense to tell him “I’m
home” rather than “The visit to grandma was canceled”.
Now we know some basic BPMN and the idea behind exception handling. Seemingly,
this is a good place to start talking about more serious, more robust business
processes;. business processes that take into account exceptions during their
execution. We will review exception handling strategies in BPMN.
An example of a process that catches an exception and throws its own exception:
14
BPMN Error Events – Exceptions in BPMN
In BPMN, an exception event is called an Intermediate Error Event. We will call it an
Error Event. As you may guess, an Intermediate Event is a sub-type of Event, and an
Intermediate Error Event is a sub-type of an Intermediate Event.
Here we will elaborate only on the elements which are the focus of this paper, related
to error handling in BPMN:
Element
Description
Notation
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
Event
(trigger) or an impact (result). There are three types
of Events, based on when they affect the flow:
Start, Intermediate, and End.
Intermediate Events occur between a Start Event
Flow Dimension
and an End Event. It will affect the flow of the
- Intermediate
process but will not start or (directly) terminate the Intermediate
(Error)
process.
Intermediate Events have "Triggers" that define the
cause for the event. There are multiple ways in
which these events can be triggered. End Events
may define a "Result" that is a consequence of a
Sequence
Flow
ending.
Type Dimension
- Error (a.k.a. The "Error" trigger is used for error handling – Error
Exception)
both to set (throw) and to react to (catch) errors. It
sets (throws) an error if the Event is part of a
Normal Flow. It reacts to (catches) a named error,
or to any error, if a name is not specified, when
attached to the boundary of an activity (Task or
Sub-Process).
Exception Flow occurs outside the Normal Flow of
the Process and is based upon an Intermediate
Exception Flow Event that occurs during the performance of the
Process.
Exception Flow
A BPD is not designed to graphically convey all the information required to execute a
15
business process. Thus, BPD elements will include attributes that will hold
information about how these elements map to execution languages. Some relevant
examples of attributes:


ErrorCode o For
an
Intermediate
Event
within
Normal
Flow:
If the Trigger is an Error, then the ErrorCode MUST be entered. This
“throws” the error.
o For an Intermediate Event attached to the boundary of an Activity:
If the Trigger is an Error, then the error code MAY be entered. This
Event “catches” the error. If there is no error code, then any Error
SHALL trigger the Event. If there is an error code, then only an Error
that matches the error code SHALL trigger the Event.
Target o A Target MAY be included for the Intermediate Event. The Target
MUST be an activity (Sub-Process or Task). This means that the
Intermediate Event is attached to the boundary of the activity and is
used to signify an exception or compensation for that activity.
One or more Intermediate Events MAY be attached directly to the boundary of an
Activity.
You can only throw and catch events within a single pool.
Mapping BPMN to BPEL4WS:
The mappings from BPMN to BPEL4WS are derived by analyzing the BPMN objects
and the relationships between these objects. We will focus on errors and we will only
cover the mapping to BPEL4WS, even though other execution languages are
available.
This part is intended mainly to help understand some of the implementation
considerations. It is not relevant for the majority of the study since the execution
language is not directly part of our scope.
Mapping Error Intermediate Events
Intermediate Event
Within the Normal Flow
Attached
Boundary
to
an
Mapping to BPEL4WS
This will map to a throw element.
The mappings of the activity (to which the Event
is attached) will be placed within a scope. This
Activity Event will map to a catch element within a scope.
If the Error Event does not have an ErrorCode,
then a catchAll element will be added to the
faultHandlers element. If the Error Event does
have an ErrorCode, then a catch element will be
added to the faultHandlers element with the
ErrorCode mapping to the faultName attribute.
Table ## Error Intermediate Mappings to BPEL4WS
16
Exception handling strategies in BPMN
These are exceptions in the sense of exceptional scenarios, and not necessarily Error
Events – an exception message. The discussion on [44] does not make any distinction
between the two, but we will. Although these are all valuable patterns, we will focus
only on Error Events handling.
- Internal Business Exception Pattern: this is actually an Alternate path, using
conditions.
- Time out exception pattern: a Timeout Event is closely related to Error Event,
but is still a different type of event. The Timeout Event element is attached to
the Activity.
- System Fault Pattern: the basic exception flow we reviewed. The Error Event
element is attached to the Activity. The pattern refers to the case where no
exception is specified to be thrown during the Activity and so the only
exception will be a system fault.
- Business Exception Throw-Catch Pattern: here we are aware of a specified
thrown Error Event. We catch this specified Error Event and handle it.
- Unsolicited External Business Exception Pattern: we receive an external
Message (Event), not necessarily an Error Event, which stops the process. For
example: a call from grandma, “don’t come today”. Aborting the event.
- Solicited External Business Exception Pattern: waiting for an event, even an
Error Event, to decide how to continue. For example, waiting for a phone call,
but for no longer than 5 minutes.
- Transaction Compensation: this is another type of an Event and therefore is
not part of the scope of this work. In fact, this pattern is interesting enough to
do similar research on it. When a Sub-Process is aborted because of a Cancel
Event, before the control returns to the calling process, all of the Activities in
the Sub-Process which are attached with a Compensation Event run the
Compensation flow. The state returns and rolls back to its condition prior to
the execution of the Sub-Process.
The only two patterns that fit our scope are System Fault Pattern and Business
Exception Throw-Catch Pattern. We will realise that the problem of Business level
exceptions is much more appealing (and solvable) than System fault, which is a low
level exception.
Summary:
To sum up, we saw the basic specification of BPMN – its graphic elements and their
attributes. We perceived how a business process can throw an error and how it can
catch and handle an error thrown by a sub-process.
The clever reader already identifies one of the problems we will try to resolve – while
writing a BPD: how do we know whether a sub-process throws an Error Event or not?
And what type of an error, if any?
17
[[maybe this should be under Exception Handling in Software discipline]]
We have already noted that existing tools do not help the business analyst to identify
whether a sub-process throws an Error Event. This is a major difference between
BPMN modeling editors and a programming language, such as Java, editors. In most
Java-supported IDEs, calling a method which can throw an exception will force the
caller to handle the error. The IDE will highlight the calling statement pointing out
that it is an error, as in this example:
To fix this error the user has two options: catch and handle the error (figure 4) or pass
the error "upwards" (figure 5):
[figure 4]
[figure 5]
The Java example shows a specified exception handling.
Identifying thrown exceptions, and by that unhandled exceptions, is part of the static
verification procedure.
Static verification
The main feature Prosero lacks, compared to all the other tools, is static verification.
All the other tools verify that a diagram keeps up with the specifications. But even the
other tools can boost up their static verification. At this point, some of you might
wonder to yourselves: what is static verification?
- Verification is a procedure that checks a description for mistakes, usually, but
not necessarily, when the description involves instructions to be executed.
- To understand static, consider the instruction "Jump" compared to the action
of jump. We say ‘jump’ has a static form, which can be written down - a text,
a picture - and a dynamic form, which is an instance of the action taking place.
- Static verification is a procedure that checks a description for mistakes,
usually, but not necessarily, when the description involves instructions to be
executed.
- If you can identify and fix mistakes, before executing the instructions, you will
have less exception occurrences during the execution.
There are three categories of mistakes – syntactic, semantic and logical. We'll
consider identifying mistakes in the same manner we examine the world around us.
We see, hear, smell, taste and feel our environment. We perceive separate objects and
their interaction or relations with other objects. Psychology has shown that our
understanding of these perceptions is interlinked with our language. This line of
18
thought allows us to review our understanding as a text page (in a manner of
speaking).
A syntactic mistake is an object we don't know, equivalent to an unknown word or an
improper grammatical combination.
 Real world example: "this round, hairy, brown, thing… what is it? I don't
know it."
 English example: "I to go an yourki the lioriki."
 BPMN example: having a Lane outside a Pool, or outgoing sequence flow
from an End Event, or call the activity "Rest Now," which does not appear in
any business analyst dictionary.
A semantic mistake is a usage of an object in a way that does not meet with that
object's definitions. Meaning, the object is used in a way that should not be possible.
It is equivalent to a meaningless sentence that meets grammatical rules.
 Real world example, "It's a bird, it's a plane, no… it's a… tree. What are you
talking about, trees don't fly." Or, "This can’t be a Lemon, it is sweet."
 English example: "The king of France is bald."
 BPMN example: the "get-happy-document" activity returns "sad-document".
Now, semantic and logic are very close, both look at the meaning. We will consider
the difference that semantic focus on the meaning of a single state and that logic focus
on the meaning of a sequence of states. Meaning, even if each state on its own is
valid, the states’ sequence may not be valid.
 Real world example: "I open my shower door, get into the cab, my waitress
gives my cocktail and I wave goodbye to the penguin."
 English example: "If all butterflies are green and I see a butterfly then it must
be red."
 BPMN example: a "Check credit" sequence flow that does not deal with the
bad credit scenario. Or when "Ship Order" precedes "Fill Order" in a sequence
flow.
Note that for the BPMN, in addition to the naive example of an illogical sequence of
Activities – which cannot be identified by a machine – we focus on the notion it is
illogical to assume that things will always work out. You could even say that logic
includes common sense [to identify problems] in things like "Give a chainsaw to a six
years old." Of course this example is not as illogical as general English or general
world scenarios. But BPMN is a much more limited domain.
Even if you disagree with my choice of words, I am sure you understand what I am
talking about. In all of the above examples the human intellect will start ringing a bell
and shouting that something is wrong – "I don’t know this", "I don't understand this",
"This doesn't make any sense", "This could lead to a serious problem," or "I've been
drugged."
Many tools from different disciplines can identify syntax mistakes and even certain
semantic mistakes. Logical mistake, however, are very difficult to identify.
Identifying a missing Exception in a programming language, for example, is a
semantic mistake and not a logical mistake – since the Exception is part of the method
signature. But an unused variable or statements that will never be reached in
execution are logical mistakes that IDEs can report.
19
Unlike syntax and semantics, logical mistakes can only occur when a sequence of
events is described. It is crucially important for executable languages, though, I
wouldn't mind if my Word Processor picked up illogical sentences as well.
Static verification examples in other disciplines
Word processing
-
Includes only language syntax verification.
Programming environments
A must:
- Language syntax verification.
Highly recommended:
- Type matching
- Unhandled exceptions
Optional:
- Code duplicities.
- Unreachable lines of code.
Human intellect
-
Thinking ahead and avoiding exceptions
Static verification implementations in the software industry
The section is more technical than the other. It is important as background for
researching the best implementation for our static verification. How are software
editors able to identify unhandled Exceptions? And, would it be difficult to implement
in current BPMN editors?
Local vs. remote
In the case of software there is the common case and the less-common case. The
common case is when all the software code is on the user’s local machine. The lesscommon case is when some of the code is saved on the server with no immediate
access by the editor.
When the code is on the local machine it is relatively easy for the editor to access and
analyze all the files relevant to, i.e., referenced from, the viewed code. As result of
this static verification, the editor can highlight mistakes in the code, such as
unhandled exceptions. Though, if the relevant files include hundreds of files of a large
size, it would take some time even for a powerful machine. At this point I remind our
readers that good code design includes low coupling, meaning, a small group of
relevant files.
And another reminder, when the code is on the local machine, it is usually (and it had
better be) under the management of a version control system, a system that retrieves
the code from a shared repository and commits the finalized local changes to the
repository.
20
In the second case, when some of the relevant code is on a remote machine, it is not
the responsibility of the local editor to run complete static verification of the code. It
is the responsibility of the server, repository management, which receives the
finalized code. The server should run static verification on the code, with all the
relevant files at hand. And if the static verification fails, the server rejects the file and
informs the user why the file failed the static verification. Then the user must fix the
code and re-send the file. This is somewhat tedious and less user-friendly than the
first case, for programmers and business analysts alike. Still, we will evaluate this
possibility thoroughly since there are systems - Prosero among them - which don't use
local version control management. It also depends on the referencing of an Activity.
Id referenced data, again, as in Prosero, is much easier to retrieve from the database
on the server side than on a local file-system, which is path based.
Immediate vs. daily
In the case where the relevant code is on a remote machine we showed the option of
an immediate static verification of files currently being committed to the server. There
is another, non contradictory, option: a daily build. This means, every day, usually
every night, the server runs static verification on all the codes in the repository and
checks for mistakes. Obviously, all relevant files are accessible. At the end of the
daily verification the server sends a report of the results.
Summary - Exception Handling in BPMN
We now know how to read and write Business Process Models using BPMN. We
know how to read, write and model using different modeling tools. And we know how
to transform BPMN into BPEL, for execution, using these tools. We know how to
model Error Events in BPMN and how they are transformed to BPEL.
We are also aware of the power various Integrated Development Environments (IDE)
give their users, specifically, helping the user identify mistakes that stem from
possible exceptions in the future execution of the code.
This leaves us with the question - is it really important to handle the possible
exceptions? We saw business analysts can model Exception Handling in BPMN. Do
we need to force them to do so? This is the question that launches our research.
Knowing BPMN editors and knowing software editors, should we and can we
duplicate the Exception Handling validation from software to a business process?
21