Explore – exception handling verification

Motivation and scopeFrom all our Background, everything we know on BPMN and on business analyst needs, we need to pick our scope. So, let's sit down, make ourselves a nice hot cup of tea and reconsider the questions mentioned in the introduction. Ahaa! What if the kettle is malfunctioning? Did you stop and consider that?! (or what if you don’t have kettle since your wife prefers cauldron). And without a kettle how can you make tea? And without tea how can you read the problems you are reading at this very moment…

Seriously, such scenarios are our motivation to look into possible errors in the execution. There is no need for me to shout over rooftops that static analysis is important. We saw it saves huge amount of time and money. Is it the most important aspect in BPMN? Not necessarily. The Prosero prototype did not see 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 see, 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 man. Although, clearly, a machine won’t handle unknown condition as well as a human being, a manager will save time and money if his 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 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. There, we concluded that good static analysis is a huge time saver for instructive description – finding a problem in your process, at design time, 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 robust business process? The answer is that we want to be able to identify pitfalls in the process, which the business analyst missed, and inform him on the mistake. The most dangerous pitfall is reaching an unexpected condition in execution – causing an exception. In other words, the most dangerous pitfall is not handling an exception.

Static verification

Let's review an example of a problem the Prosero modeling tool does (!!) statically verify – type matching. If a certain Task returns an object of type Happy-Document, the process modeler must model a Happy-Document received from the Task. If the tool would not force the user (at design time) to receive a Happy-Document object, and the user mistakenly uses a different type of object, that could lead to serious problems at run-time. Moreover, knowing the type object makes it easier for the user to handle the object, since the object's attributes are also known.

Like a returned object, an exception is a possible outcome of a Task. For example, you call a Task to get a Happy-Document named "Transformers". And you prepared an object to receive the Happy-Document. But at execution time, the Task returned an Error Event – 'The document was not found'. In the above diagram (4.4) the Process does not "know" what to do with such a response so it simply stops and pass the error "upwards". While in the next diagram, (4.5) the Error is caught and handled.

Here begins our research – can static verification really identify unhandled exception the clever business analyst missed?

Verifying Error Handling in a BPMN Process is mainly: - For each Activity:

a. Identify possible Error Eventsb. Identify its Handlers c. Match these two lists. d. Error Events without matching Handlers are unhandled exceptions this

Process will throw, at run time.

We know that BPMN has an Error Intermediate Event that can catch an error and pass it to handling. So this gives the first problem to consider:

(1) How to force the user to use Error Intermediate Event for error-handling, when it is required?

Which leads to the obvious problem:(2) How to identify when error handling is required? I.e. identify unhandled Error

Event.And since we don’t believe in force (but do believe in "the force") we also consider the question:

(3) Instead of forcing the user, can the tool add the error-handling for him?And before we can even begin considering these questions, we must ask ourselves,

(4) Are there many types of errors? Do we handle all of them? Can they be handled?

Types of exceptionsWhat's in a name? That which we call an Exception By any other name would fail the execution.(ahmm… not quite Shakespeare)

First, we ask ourselves what exceptions we should identify. There are two unrelated categories of exceptions to consider: exception type and whether the exception was specified in the process or not.

We divide the exception types into two main classifications: Process Exceptions and Data Exceptions. The main difference is that Process Errors can happen to any Task and any Process and unless declared by the user, cannot be statically verified by the tool.

Process Exceptions 1. Failure

Generic infrastructure failure stemming from low levels that cannot be anticipated at BPMN level.

Analogous to "Work Item Failure" in [workflowpatterns].2. Timeout

An Activity is taking to long to finish, according to system settings.

Analogous to "Deadline Expiry" in [workflowpatterns]. Data Errors

1. Superficial data error Can be checked without special processing (e.g., wrong

argument type). "This is the wrong form. You need the red form!" the

administrator looked angrily through her thick glasses.2. Content level data error

Requires processing (e.g., incorrect URL). "This is the right form. But I can't understand a word!" the

administrator growled, pointing you to the door.3. Meta-data level error

Something wrong with meta-data, e.g., unknown sender, authorization, authentication, etc.

"Who are you and how did you pass security?!" the administrator tares her skirt and turns to combat position.

4. Commitment/precondition violation Correct data that violates some previous commitment in the

process or requires a missing commitment.

"I've been waiting for over an hour!" screams the administrator at the delivery guy. "I ordered at 3:21, as you can see in the receipt. I am not paying for this Pizza."

One way to handle a received exception, at run-time, is to try calling the Activity again. There are solutions that do so automatically and even try various implementations of the Task. E.g. [On optimal service selection]. So there is no need to bother the user, at design time, with this type of a solution. This solution is adequate for the Process Errors. In most cases the business analyst won't know how to handle such technical error anyway. And most likely there is not much to be done for such a failure. "Although it is useful to specify, at design time, what should be done if deadline has been reached." [workflowpatterns]. To conclude on Process Error, the user can catch and handle any error he/she likes, but there is no point for the system to go around issuing warnings "this can fail", "that can fail", "they might fail!" Of course any Activity can fail for technical reasons. Regardless if it will be executed by human or a machine Service.

As for the Data Errors, the superficial data errors, such as type matching, are already handled by existing tools. So, we are left with the real "meat" of the data – the meaning of its content fields and its meta-data attributes. Unfortunately, a truly intelligent solution for this problem will only be considered in "Future Work", since verifying correct content is a serious and challenging Domain-Specific-Knowledge in Natural-Language-Process problem. Until that future, we leave it to the intelligence of the business analyst to specify how to verify the content of the data using BPMN Gateway. And the Gateway may result in a sequence flow that throws a business-level exception – an Error Event. This is a true high-level exception, unlike the low-level exceptions caused by technical failures. And we call it a specified/declared/thrown Intermediate Error Event. It makes sense that an Error Event thrown by the business process, as result of a business decision, will be more crucial than the other types of Error Events.For example, in figure 6.6, let's say we either have access to the Customer's business process, or that the Customer publish possible Error Events for its business process.

Let us also say that "Accept Payment" Task might throw a 'Payment Denied' Error Event. This information is declared by the Customer, while the fact "Send Invoice" might throw 'Invoice Rejected' is not declared by the Customer. We'll consider 'Payment Denied' as a business level exception and should handle it. And we won't know and won't consider the 'Invoice Rejected' exception.

This concludes the answer to question number 4 (q4) – our research scope includes only specified Error Events. We assume that specified Error Events represent business level exceptions.

Message from the future: we said identifying unspecified Error Events, which represent lower level exceptions, is not in our scope. Nevertheless, there are systems where the thrown Error Events are hidden from us – we don't have access to the information. Identifying specified Error Events in such systems is basically identifying unspecified Error Events; since what use is the specified information if we don't have access to it.

The discussion now moves to the level of handling specified Error Events. Before we can touch how to force the user (q1), or how to help the user (q3), handle an Error Event, we investigate how to identify unhandled specified Error Events at design time (q2). The investigation is in a Top-Down manner.

Identifying unhandled specified Error EventsLet's consider the attributes required to verify Exception Handling. Add to BPMN Activity two attributes:

Errors - A list of Intermediate Error Events' Error-names that may be thrown by this Activity.

Handlers - A list of Intermediate Error Events that are (graphically) attached to this Activity i.e. will catch exceptions.

And add to BPMN Process one attribute: Errors - A list of Intermediate Error Events' Error-names that

may be thrown by this Process.Consistency rules:

Attributes of a Process and a Sub-Process referencing that Process must match. Attributes like Id and Errors.

Activity's Handlers attribute must match the Error Events attached to the Activity.

Process Errors must include all declared Errors in the sequence flow and any unhandled Error of any of the Activities.

The verifying procedure now has an easy job – statically verify that any error-name listed in the Activity Errors is addressed. Meaning: it either has a matching handler in the Handlers list, or a matching error in the container Process Error list. Otherwise, the tool will raise a warning notification that will force the user fix this situation. A fix is obviously either to remove an Activity Error, add an Activity Handler or add a Process Error.

This simple verification procedure, and the three attributes it requires to do its job, are the heart of the research and a gateway to a world of problems. Why? Because there are two possibilities to implement the attributes:

Static attributes vs. dynamic attributesEach implementation possibility effects the method to populate the attributes:

Automatically, semi-automatically or manually

Attribute implementation also effects the verification procedure implementation requirements:

Local vs. remote Immediate vs. daily Keep consistency vs. allow some inconsistencies

Lastly, there is the matter of system functionally to consider, when reviewing the performance of each requirement:

files accessibility – fast or slow file format – can we add static attributes to legacy data:

o Activity, inside a BPDo Process and Task, in repository

With combination limitation we have twenty-five use-cases for applying the static verification of unhandled specified Error Events. Let’s dive in.

(1) Dynamic attribute vs. Static attributesThe Error and Handlers lists can either be dynamic – temporarily created and populated by the verifier – or static – Activity meta-data is extended to include these lists. In the case of dynamic attributes, they will be populated by analyzing related Processes or by reading configuration files with information on referenced Activities. And the attributes will be discarded once the static verification is over.In the case of static attributes, the verifier does not populate the attribute, it just reads them. These attributes are populated by the user or by a separate procedure.

A short pros and cons – although it is understandable that many systems will prefer not to extend BPMN, keeping their element structure as is, it is quite safe to say that extending BPMN, with the static attributes, is better in the long run. Otherwise, a lot of machine power and memory will be wasted on building the dynamic attributes. But until the “long run”, add attributes to Legacy data might be inconsistent – more on that later in the inconsistency section.

A possible compromise, which can still lead to inconsistencies, is to have some attributes static and some dynamic. This is useful if, for example, you want to specify exceptions for a Task in a Process but without adding static attributes to Tasks in your repository.

A way to use static attribute without changing the BPMN format of existing diagrams is to use configuration file to map a shared Activity, to its Error list. Although we did not change the internal structure of an existing file, we did change relationship and dependencies between files in the system, by adding the configuration file.

Solution #1.1: Dynamic attributes. Discarded after verification.

Solution #1.2a: Static attributes – BPMN meta-data has extended.

Solution #1.2b: Dynamic attributes with static external files – attributes populated from configuration.

Solution #1.3: Some dynamic attributes and some static.

(2) Populating the attributes

Identifying specified Error Events in an ActivityHow do you specify exceptions?

1. If you are a Process, then, as we mentioned, you declare an exception by putting an Intermediate Error Event in a sequence flow.

2. If you are a Task then you must specify the exception in a new attribute of some sort.

How do identify the specified Error Events? Meaning, when you have an Activity element which references an existing, shared, Activity, how do you identify if the shared Activity declared an Error Event?

In the case the Activity is a Sub-Process, referencing an existing Process, you can access to the referenced Process, analyze and recursively dig into the Process' diagram and look for an Error Event being thrown. Note this information is not mentioned in any of the Process attributes. This is a very intuitive, automatic population technique.

But Task has no diagram to investigate. This line of thought leads us to the major problem with BPMN – we do not know whether a certain Task can throw an Error Event or not. This information is not specified in the Task attributes. One could think that since Task is an atomic Activity it will produce only Process Exceptions. That is not necessarily true. For example, If we knew the Task's implementation supports an authentication protocol then we would assume a possible authentication exception. In software, in type-safe languages, functions/methods signatures have returned type, argument types and exception types. Task "signature" attributes contains only the first two. So, we will extend BPMN Activity, affecting both Task and Sub-Process, and add the attribute Errors. When referencing a shared Activity we will have a list of declared Errors this Activity might throw. This is obviously only possible in the case of static attributes. And the probable population technique is manual – when adding a Task to a repository, or to a diagram, the business analyst can also specify possible exceptions.

A semi-automatic solution is assisting the business analyst to specify possible exceptions. For example, all Tasks which contains the word "Bank" can throw "Request rejected" Error. Or, a more likely example, a Task of type "Send" can throw "Incorrect format" Error.

Solution #2.1a: Automatic - recursively analyze referenced Process, looking for thrown Error Events.

Solution #2.1b: Automatic – read from the Activity's static attribute of Process Errors.

Solution #2.2: Manual – the user enters Errors according to his experience.

Solution #2.3: Semi – the tool suggests which Errors might fit the Activity.

We note that Solutions #2.1b, #2.2 and #2.3 will work for both Sub-Processes and Tasks. Solution #2.1a works only for Sub-Processes. However, Solution #2.1a can be accomplished with or without extending BPMN specification.

Combinations: #1.1 + #2.1 (dynamic + automatic) #1.2 + #2.1 (static + automatic) #1.2 + #2.2 (static + manual) #1.2 + #2.3 (static + semi-automatic) #1.3 + #2.3 (static/dynamic + semi-automatic)

Next step - once we have the Activity Error list, each Error Event must have either a matching Activity Handler entry or a matching Process Error entry.

Identifying Handlers for an ActivityFinally, something easy. Error Events graphically attached to an Activity have their "Target" attribute reference that Activity. So, Activity Handler list can be automatically populated by collecting all Error Events which "target" that Activity. Easy indeed. However… how these Error Events got attached to the Activity? The user manually put them there. So is that automatic or manual? We'll consider it an automatic part of the static verification, especially in the case of dynamic attributes. We will also consider two manual options for the user to add Handlers to the list. The first is like we mentioned above – instead of adding an Error Event to the diagram, add it to the Handler and it will be "automatically" added to the diagram. The other option is to manually add to the Handler list the attached Error Events. There is no good reason for this option other than lack of development resource (guess how I know…). Again, manual solutions are only possible with static attributes.

Solution #2.4: Automatic – collect Error Events with "Target" attribute referring the Activity.

Solution #2.5a: Manual – adding to the list will create and attach the Error Event.

Solution #2.5b: Manual – adding to the list the attached Error Event.

Now we come to the semi-automatic solution, which the Activity Handlers share with the Process Errors, regardless to how Activity Errors are populated. The tool can give a window which shows the three attributes, like in figure 99:

As we can see, Error Event "Not Found" is not handled and the user can put it in either Activity Handlers or in Process Errors. Like in solution #2.4a, adding to the Handler list must create and attach the Error Event – to keep with the consistency rules.

Solution #2.6: Semi – the user can choose whether to pass an exception to higher scope or to catch it.

Identifying Errors in a ProcessSolution #2.5 is also applied here. There is also the simple automatic solution – all unhandled Error Events from internal Activities, plus all thrown Error Events, i.e. specified in the sequence flow, are collected as the Process Errors. Oops! Pay attention! Collecting all unhandled Error Events means there is no need to statically verify unhandled Error Events. This automatic solution is too powerful - the user never receives a warning since the static verifier fixes everything for him. It reminds me of Word Processor's auto-correction – can be very helpful or very annoying. But in the case of an executable process, this can be dangerous. Software developer, for example, will not trust their tool to correct exception handling without asking them. Asking is part of the semi-automatic option, #2.6.

Solution #2.7: automatic – collect unhandled Error Events and thrown Error Events

Solution #2.8: manual – the user enters Errors as he see fit

Options for using the automated solution:- Define a top-level Business Processes. This level will not have a Process

Errors attribute. Processes at this level are not allowed to throw an Error Event. It is a top level scope and must handle all exceptions. This option is fairly simply, but requires a further static extension of BPMN and an investigation whether a top-level concepts correlates with BPMN methodology. We'll return to it later on, in ______.

- Processes are not allowed to throw an Error Event. At least, are not allowed to declare they throw an Error Event. Meaning, the attribute is kept empty. This isn't really "population". But this is our current choice when going for "automatic". In which case it might as well be a dynamic empty attribute rather than a static empty attribute.

Activity ErrorsTimeoutSend FailedNot Found

Process ErrorsTimeout

Activity HandlersSend Failed

Possible combination cases:The initial combination set for three attributes, either static or dynamic nature, and which are populated either automatically, semi-automatically or manually, includes 216 combinations. As we have shown, dynamic attribute can only be populated automatically. This leaves us with 59 feasible implementation combinations. These are displayed in the next table, parted to three clusters: automated population of Process Errors, partially manual population and partially semi-automatic population.

Attributes Consistency Populating AttributesActivity Errors

Activity Handlers

Process Errors

Activity Errors

Activity Handlers

Process Errors

Dynamic Dynamic Dynamic Auto Auto AutoDynamic Dynamic Static Auto Auto AutoDynamic Static Dynamic Auto Auto AutoDynamic Static Static Auto Auto AutoStatic Dynamic Dynamic Auto Auto AutoStatic Dynamic Static Auto Auto AutoStatic Static Dynamic Auto Auto AutoStatic Static Static Auto Auto AutoStatic Static Static Semi Semi AutoDynamic Static Dynamic Auto Semi AutoDynamic Static Static Auto Semi AutoStatic Dynamic Dynamic Semi Auto AutoStatic Dynamic Static Semi Auto AutoStatic Static Dynamic Auto Semi AutoStatic Static Dynamic Semi Auto AutoStatic Static Dynamic Semi Semi AutoStatic Static Static Auto Semi AutoStatic Static Static Semi Auto Auto

Dynamic Dynamic Static Auto Auto ManualDynamic Static Dynamic Auto Manual AutoDynamic Static Static Auto Auto ManualDynamic Static Static Auto Manual AutoDynamic Static Static Auto Manual ManualStatic Dynamic Dynamic Manual Auto AutoStatic Dynamic Static Auto Auto ManualStatic Dynamic Static Auto Auto SemiStatic Dynamic Static Manual Auto AutoStatic Dynamic Static Manual Auto ManualStatic Dynamic Static Manual Auto SemiStatic Dynamic Static Semi Auto ManualStatic Static Dynamic Auto Manual AutoStatic Static Dynamic Auto Semi AutoStatic Static Dynamic Manual Auto AutoStatic Static Dynamic Manual Manual AutoStatic Static Dynamic Manual Semi Auto

Static Static Dynamic Semi Manual AutoStatic Static Static Auto Auto ManualStatic Static Static Auto Manual AutoStatic Static Static Auto Manual ManualStatic Static Static Auto Manual SemiStatic Static Static Auto Semi ManualStatic Static Static Manual Auto AutoStatic Static Static Manual Manual AutoStatic Static Static Manual Manual ManualStatic Static Static Manual Manual SemiStatic Static Static Manual Semi ManualStatic Static Static Semi Manual AutoStatic Static Static Semi Manual ManualStatic Static Static Semi Manual SemiStatic Static Static Semi Semi Manual

Dynamic Static Static Auto Semi SemiStatic Dynamic Static Semi Auto SemiStatic Static Static Auto Semi SemiStatic Static Static Semi Auto SemiStatic Static Static Semi Semi SemiDynamic Dynamic Static Auto Auto SemiDynamic Static Static Auto Auto SemiStatic Dynamic Static Auto Auto SemiStatic Static Static Auto Auto Semi

We have the following preference in regards to the three clusters:

We dislike Process Errors automated population since, in this branch of solution, it means an empty attribute. That is a great loss of information.

We dislike any combination that includes manual population. Why? Simple – it is not user-friendly. At least some help should be given to the user, to avoid strange scenarios where he might attempt to handle Error Events for an Activity which are not thrown by it.

We prefer one of the remaining nine cases. We will evaluate which of the cases will suite best considering the system requirements. For example: without considering the requirements, I would say that the best option is Dynamic Dynamic Static Auto Auto SemiSince the user won’t need to populate two attributes and since the programmer won’t need to add attributes to the Activity element. That’s worth the extended recursive analysis the verifier will run to populate the attributes.

I can tell you I was heart broken to find out that for the Prosero system the best case is not one of the preferred cases. The fun is just beginning.

(3) Static Verification Implementation RequirementsIn the background, we covered the same static verification implementation possibilities in the software discipline. The meaning of the requirements is the same in the business process world.

Local vs. RemoteLocal static verification means the verification will be done immediately by the modeling tool, on the local machine. The tool will run static verification either as the business analyst models the diagram, when he saves it, or when he clicks a verification button.Remote static verification takes place on the server side. Business processes are verified only when their files are sent to the repository on the server – committing prepared files.

Req. #3.1: local – static verification will take place on the local machineReq. #3.2: remote – static verification will take place on the server side

Immediate vs. DailyImmediate verification means the verification process is execute immediately after an action has been taken by the business analyst. An action can be: changing the diagram, saving the diagram, calling the verification – in the case of local static verification – or committing the diagram file – in the case of remote static verification. The option of immediate, remote static verification is important since it means the server will not accept the diagrams into the repository if they won’t pass verification.Daily verification is only relevant for remote static verification. It is like “nightly build” in software companies. Once a day, the server runs static verification on all the files in the repository and sends the results report to the managers. As oppose to immediate verifications, incorrect files can be committed to the repository and the problem will be announced in the next day report.

Req. #3.1a: immediate, local verification – receive warnings while you modelReq. #3.2a: immediate, remote verification – receive warnings when you commitReq. #3.2b: daily, remote verification – receive warnings in a daily report

It should be clear there is no contradiction between the three requirements. You can implement all of them in the same system – seven combinations. But we don’t care about the seven combinations. We care which of the cases we covered fits each of the requirements.

Demand consistency vs. allow inconsistenciesThe consistency requirement is not related to the other two. It applies to our choice of static attributes – specifically Process Errors attribute. Consistency verification is not related to exception handling verification directly. It relates to the values in the attributes.

Consistency procedure requires a big portion of the implementation time and a great deal of CPU time in the verification process. That makes it a drawback when comparing static attributes to dynamic attribute, which are always consistent. We can focus on three drawbacks:

1. Companies with huge number of Processes probably will not transform all of their data to the new format. Especially when they don't have to, since the new format is backward compatible. And so, some Processes that do throw Errors will have them listed in the Errors attribute and some won't.

2. The first drawback is just a hint to the major problem of inconsistency. For example, we edit a Process by adding an Error Event. Let's say there are ten other Processes that call upon this Process. They will also need to be updated with this change. Crucial for local verification. But even for daily, remote verification this will demand much of the CPU time.

3. The third drawback is a next of keen. To solve the inconsistency problem, some system force their Process' attributes to be fixed, unchangeable once set. This means that all references to the Process will always be consistent. It also means you cannot change arguments, output or exceptions of the Process.

So, demeaning consistency between attributes content and the actual Process sequence flow calls for either automatic population of the attributes – in the current discussion means leave it empty – or for a hefty consistency verification prior to the error handling verification. Another option is to trust the user when he specifies Errors for a certain Sub-Process, even if the referenced Process doesn't seem to throw these Error Events. Of course, in an ideal world we would demand consistency without a second thought. But as we see from the three drawbacks, sometimes we must make concessions. And we will discuss these times, right after we review system functionality options.

Req. #3.3: consistent - static verification also verify attributes are consistent with the Process statusReq. #3.4: inconsistent - static verification does not verify attributes information

Req. #3.4 goes well with an empty Process Errors – i.e. automatic.

(4) System functionality

Fast access vs. slow accessNo one would require its system to give slow access to data. But this functionality is usually a result of a system requirement – the location of project files. As we mentioned in the background, usually, when referenced diagram files are on the local machine the tool will have fast access. When the diagrams are on a remote machine –a remote repository – the tool has slow access. Of course, this is not a must and we care more about the speed of the access than the location of the diagrams.This is relevant for two previous requirements.

(A) If you want to support the requirement of immediate and local static verification. It is a bad user experience if a verification warning comes minutes after the users made the mistake. If that is the case it will be better to

abandon the "immediate" requirement. Or that's what I thought… The other solution is to speed up the static verification by abandoning the consistency verification.

(B) Automatically populating Activity Errors attribute from a shared Activity's file should have fast access to the shared file. Though we can still automatically populate Activity Handlers and Process Errors which relay on present diagram information. But the work needed to populate these two attributes is negligible in comparison to recursive drill down for populating Activity Error.

Req. #4.1: the modeling tool has fast access to referenced Activities (Processes or Tasks)Req. #4.2: the modeling tool has slow access to referenced Activities (Processes or Tasks)

Possible verification combinations

Sys #1 Local Immediate Consistent Fast accessSys #2 Local Immediate Inconsistent Fast accessSys #3 Local Immediate Inconsistent Slow accessSys #4 Remote Immediate ConsistentSys #5 Remote Immediate InconsistentSys #6 Remote Daily Consistent

System #1 gives the ideal requirements. As the business analyst model the diagram he will receive warnings on mistakes he is making. Although I like system #6 concept of daily report, and the fact that remote static verification has an easy access to all relevant files, I must admit that individual warnings at design time are superior to a report which might contain dozen of problems in numerous business processes. To combine these six sets of system requirements and functionality with the nine implementations of static verification, one must consider:

- First, the file access protocol. The most fundamental aspect of work methodology. It is already set in most case.

- The second most influential decision is whether or not the company can extend the BPD structure and add the static attributes.

- Then, how much effort can be given in development of consistency verification.

As an example of making these considerations, we will show how they were made in Prosero (and now a note from our sponsors – "when you think BPMN, think Prosero" ;).

Prosero's requirementsIn Prosero, the business process files sit in a remote repository and the business analyst can work on a single file, on a local machine, by requesting to refine it. This

system allows only slow access to referenced files. From the six possibilities we can conclude that the best option is to develop a server side, remote, static verification. However, as software developers, we wanted to give a tool that can give warnings at design-time. Therefore, we had to choose system #3. Meaning:

1. We won’t attempt to uphold consistency – because of the slow access;2. Disregard Process Errors – since they are inconsistent;3. Use only semi-automatic Activity Errors population – since we can't populate

them from Process Errors;And in return we'll get immediate, local exception handling verification. Our implementation cases are:Activity Errors

Activity Handlers

Process Errors

Activity Errors

Activity Handlers

Process Errors

Static Dynamic Dynamic Semi Auto "Auto"Static Static Dynamic Semi Auto "Auto"Static Static Dynamic Semi Semi "Auto"

As you can see, we had to take cases from a non-preferred cluster.

In retrospect I see that Activity Errors attribute is the most difficult to populate. Difficult enough to give up the immediate verification requirement and to run verification on the server side. I'll touch that in the Conclusions section. On the other hand, attacking this difficulty proved to be very interesting and lead to adding Templates with pre-set Activity Errors. But that's jumping ahead.

After Activity Errors, Process Errors is the most difficult to populate. We already explained why fully automated population is not possible. So it would be preferable if it would be semi-automatically populated. Is ‘not verifying consistency’ good enough reason to deny this? If we could use static attribute it might be possible. However, the consistency issue is stronger in our case. At the time, Prosero did not allow changing Process attributes once they have been set. Meaning, adding or removing thrown Error Events would render Process Errors inconsistent. So, we could not choose the static attribute for Process Errors.

This left us with only three implantation cases. From which we would obviously prefer the first, with automatic Activity Handler population. You might recall I said there is only one reason why not to choose automatic Activity Handler population – lack of development time. And sure enough, we did not have time to spare in building the prototype. We had bigger fish to fry – how to provide valuable help, with semi-automatic Activity exceptions identification, when we don’t have access to the Process Errors? [question #___]

SummaryTo conclude – we have a Process. In it, sitting comfortably, are Error Events and Activities. When comparing a programming language, such as Java, to BPMN modeling language, we correlate method to Process, call statement to Activity and throw statement to Error Event.

The above 'getHappy' Process can be written in this manner as a Java method:HappyDocment getHappy (PersonDocument doc) { … Integer total; total = calcMethod(); … HappyDocument result = createHappyDocument(total, doc); return result;}

In Java, if a call statement can result in an Exception, either the statement is wrapped by an Exception Handler or the method declares it may throw this Exception. Similarly, if an Activity can result in an Error, it is either attached with an Error Handler or the containing Process declares it can result in this Error.

HappyDocment getHappy (PersonDocumet doc) throws HappyDocumentException{ … Integer total; try{ total = calcMethod(); } catch (CalcException) { total = -666; } … HappyDocument result = createHappyDocument(total, doc); return result;}

What we don't see in diagram 5.6 is where the "Process declares it can result in this Error" – i.e. throws HappyDocumentException. This is not graphical information. This is added to the attributes of the Process. For example:

- Author = Ziv- Creation Date = 08.08.2008- Name = Example Process- Errors = HappyDocumentException,- Root = false

A note for the future – what we do see in diagram 5.6 is things getting messy. The added handling flow sequence makes the diagram messier. Now imagine three more handling… why imagine?! Here is an example:

This is almost unreadable. Especially when you consider that the Process involves only two Activities. In "Future Work" we will discuss the possibilities of "filtering" perspectives when viewing a Process. A perspective for normal sequence flow and a perspective for error handling flow.

Even with its messiness, this process is much safer for execution. And if you would start building a system from scratch, we suggest you add these new attributes and plan for their automatic population. But there is yet another improvement we will now review. This comes as a solution to the previously mentioned problems in automatically population the attributes or even adding the Process attributes. So, we will now assume we have an existing system, full of "taking over the world" Processes. And since we don't want to deal with the inconsistencies issues, we will not add attributes to the Process and the Activity Error list will not change automatically, e.g. the Prosero system. We decided to add static meta-date to the Activity. When a business analyst adds an Activity - Task or Sub-Process - he can manually edit the Error and Handler lists. We assume the business analyst will use his knowledge of the Activity to edit the lists. Knowledge such as what are the Activity's resources, parameters, output and the likes. Can't we help the user make the most from that knowledge by supplying a semi-automatic method? [QUESTION #?]The answer to this and much more in the next chapter – Constructs and Patterns.