BackgroundThe 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 in 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 ModelsBusiness 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 SOAIn 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. Business participants that don't share the same graphical notations might not

understand one another.

2

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 flow-

charting. 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 BPMNLet'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.

Flow Objects - behavior of a Business Processo 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)

3

Complex Decision/Merge Parallel Fork/Join (AND)

Connecting Objects - connecting the Flow Objectso Sequence Flow  (order activities)o Message Flow   (cannot connect two objects within the same Pool)o Association       (Artifacts with Flow Objects)

Swim-lanes - groupingo Pools (Participant in the Process)o Lanes (organize and categorize activities)

Artifacts - additional informationo Data Objects (i.e., "Purchase Order [Complete]", "Purchase Order

[Approved]")o Groupo 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 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'.

4

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 ToolsAll of the following tools follow the BPMN specification to the letter. Some may add extensions that fit their users’ needs.

eBPMN Designer by soyatec.comThis tool is based on Eclipse platform. It has a free version with most of the features.Features:

Pool auto-layout managemento All pools are kept the same size.

Connectivity controlo Prevents wrong semantic connections.

Type conversiono Change element type after its creation.

Embedded sub-process designo Support collapse, restore and maximum-view.

Boundary attachmento 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.comThe free version does not provide any interesting features.Features:

6

Business process diagramo Note - Easy and intuitive usage.o Note - Collapsed SubProcess shows a small image of the SubProcess

Data flow diagramo 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 diagramo Relationship among diagramso 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 Round-Trip 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 ProseroAs 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 to - deployment of the process within a SOA based on concrete Web

Services by a software developer.

7

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 processingDocument writing assistance

Spelling and Grammar validation Automatic text (e.g., weekdays, greetings, etc.) Creating a document from a template. Creating new templates.

Programming environmentsCode writing assistance

Text auto completion – suggesting which reference to use (variable/method/type name).

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.

8

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 possibilityHuman intellectPlanning 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 needsConsidering 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 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].

9

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 scopeOur 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 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

10

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 2Previously, in Background… we discussed BPMN, BPMN modeling tools and features from various disciplines. And now, the continuation…

Exceptions and Exception HandlingAn 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:

1. Approach the keyboard.2. Type any number.3. If you typed "9" the keyboard will melt down. 4. Type any letter.

11

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).

Consider for a moment the BPMN example 1.19.

12

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 cookiesb. Walk on “Ever After” roadc. Cross the forestd. 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

Don’t handleo Strategy: don’t even attempt to catch a thrown exception.o Result: process aborts and control returns to caller.o Example: “go to grandma’s house” – no mention of an exception.

Ignore and continueo Strategy: catch but do nothing about it.o Result: Usually futile, since part of the process was not completedo 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.

Logo Strategy: write the details of the exception in a log. o Result: instead of keeping track of a process execution, you can later

read the log for any problemso 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.

Recovero Strategy: try to complete your goal even without completing the failed

action. There are various methods of doing this.o Result: the overall goal achievedo Example: “try to: go to grandma’s house. If you failed: ask the wood-

cutter to go to the muffin man. If you didn’t fail, go to the muffin man.”

Abort the processo Strategy: throw your own exceptiono Result: this process still fails, but you can make sure the reason is clearo 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 BPMNIn 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

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.

Flow Dimension - Intermediate (Error)

Intermediate Events occur between a Start Event and an End Event. It will affect the flow of the process but will not start or (directly) terminate the process.

  Intermediate

Type Dimension - Error (a.k.a. Exception)

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.

The "Error" trigger is used for error handling – 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).

  Error

Exception Flow

Exception Flow occurs outside the Normal Flow of the Process and is based upon an Intermediate 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 Mapping to BPEL4WSWithin the Normal Flow 

This will map to a throw element.

Attached to an Activity Boundary           

        

The mappings of the activity (to which the Event is attached) will be placed within a scope. This 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 BPMNThese 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 verificationThe 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 disciplinesWord processing

- Includes only language syntax verification.

Programming environmentsA 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 industryThe 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. remoteIn 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 less-common 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. dailyIn 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 BPMNWe 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