Attack What do we have so far? We have business analyst viewing a Business Process
Diagram by a modeling tool. The business process contains BPMN Activities – Tasks
and Sub-Processes – referencing Activities in a shared repository, the Customer
Model Repository. An Activity might result in an exception. But the modeling tool
can't tell what kind of an exception if any, since a referenced Activity is not accessible
and its shared meta-data does not contain an Errors list. And so the tool cannot warn
against unhandled Error Events.
To solve that we extended BPMN by adding two attributes to the local Activity's
meta-data, as opposed to the shared Activity. The attributes, Errors list and Handlers
list, give the static verification procedure possible exceptions information and so the
tool can warn against unhandled exceptions. This is a partial answer to question Q4 –
how can we improve the tool.
Still another question remains (Q4.1) – how to populate the two attributes. Manually
by the business analyst seems tedious, not user-friendly and error prone.
Automatically by the tool is not possible, considering the lack of data. Even given a
list of Error Events, how can we write an algorithm that will presume to know how to
handle these Error Events? We can't and we won’t try to. The Handlers list is
completely under the responsibility of the business analyst. It will be populated by the
Intermediate Error Events the business analyst will attach to the Activity. So, at the
very least let's make his life easier choosing the Errors.
We will start with a limited list of standard Errors that can happen to most Activities.
The user will be able to choose from this standard list.
Then, since meta-data of the Activity is not shared, we will extend the Activity
element further and add to its meta-data another attribute – Parameters. The
Parameters of an Activity are certain settings that describe the Activity behavior at
run time. And the hope is that from these Parameters one could deduce possible run
time exceptions.
We call this Activity extension, Construct. Also known as Building Block.
Constructs for BPMN
A Construct is a BPMN Activity with the attributes Parameters, Errors and Handlers.
These attributes should be the same for all references of the Activity. But due to
technical difficulties – system requirements – mentioned in the previous chapter, the
references are not related.
When we come to give a standard list of Parameters and Errors to the general
Activity, be it Task or Sub-Process, it occurs to us that if we can distinguish different
behavior of Activities we may be able give specialized lists to different Activities.
This is a much better help than just one standard for all.
After reviewing the different types of BPMN Tasks, we conclude that aside from the
base Task, there are only two types that can have special recognition – Send Task and
Receive Task. Knowing, at design time, that your Task will send data or is waiting for
a response yields some special Errors – depending on the Parameters of the data
transfer. But we do not look upon the Tasks themselves. We look on the combination
of Send Task with a Receive Task. This pattern, of a Send followed by a Receive,
unites in it the concept of data transfer. And the concept of simple data transfer is
what has the special Parameters and Errors. We call the base-Activity Construct,
Internal Activity, to tell apart from Activity. And we call the Send Receive Construct,
ahmm… Send-Receive Construct.
As we know, an Activity is either a Task or a Sub-Process. In general, and this is quite
true in Prosero, Sub-Process references a Process which begins with a Start Event,
which receives a message, and ends with an End Event, which returns a message. If
we assume that all Processes are built with this pattern then we can give a SubProcess special Parameters and Errors as well. So, we do assume that Sub-Process
refers to such a pattern and we name its Construct Receive-Process-Reply.
We will now begin an in-depth examination of these three Constructs. For each we
will present its relevant Parameters, its possible Errors, and then look for a connection
between the Parameters and Errors. This connection will allow the tool to
automatically choose an Error if the user chose the related Parameter.
Internal-Activity
 Behavior: Any single, finite stand-alone activity.
 Parameters:
o Maximal Duration
 The longest time the Activity is allowed to take.
o Failure modes (one by default)
 General failures that leads to exceptions.
o Resources 1,..,n
 Resources the Activity is using, such as databases, etc.
o Relevant external events 1,..,m
 Expected events to influence the Activity.
 Errors:
o Time-out
 The Activity took to long to complete.
o Failure-Mode 1,…, Failure-Mode n
 The Activity failed due to Failure-Mode X.
o Unavailable resource (1,…,n)
 The Activity failed due to unavailable resource.
o External event 1,…,External-event m
 The Activity failed due to an external event.
 Parameters → Errors:
o Maximal Duration → Time-out
o Failure modes → Failure-Mode
o Resources → Unavailable resource
o Relevant external events → External event
Send-Receive
 Behavior: Send a data-object, and receive a reply (optional).
 Parameters:
o Maximal Duration
 The longest time the Activity is allowed to take.
o Number of retries (default 1)
 Number of times the Task will attempt to send the data before
giving up. I.e. number of permitted failures.
o Security
 Is the Task using a security protocol of some sort.
o Non-repudiation
 Is the Task using a protocol to ensure the validity of the data.
o Synchronous/asynchronous
 Is the send-receive protocol synchronous or not.
 Errors:
o Time-out
 The Activity took to long to complete.
o Send failed
 Data was not received by the target.
o Send rejected
 The target received and rejected the data.
o Incompliance with security/non-repudiation
 Transmission did not comply with the security/non-repudiation
settings.
 Parameters → Errors:
o Maximal Duration → Time-out
o Security → Incompliance with security
o Non-repudiation → Incompliance with non-repudiation
Receive-Process-Reply
 Behavior: The top-level framework for a business process. Receive a request,
“execute” the process that handles the request and return a reply.
 Parameters:
o All activity arguments for process
 Arguments the process will use
o Maximal duration for the reply
 The longest time the End Even is allowed to take to send the
message.
o Number of retries for the reply

o
o
o
o
o
Number of times the End Event will attempt to send the reply
message before giving up.
Security
 Do receive and reply use a security protocol of some sort.
Non-repudiation
 Do receive and reply use a protocol to ensure the validity of the
data.
Synchronous/asynchronous
 Is the reply protocol synchronous or not.
Log update required
 This process will need to access a Log resource and update its
activity.
Commitment level
 How committed is the provider of the process to the validity of
the data it returns.
 Errors:
o All activity errors for process
o Time-out reply
 The End Event took to long to complete, sending the message.
o Receive rejected: format
 Improper syntax of the request. The received data is not of the
expected format – missing or unexpected fields. The Error can
contain either one or more field names.
o Receive rejected: authentication
 The sender of the received data, the caller, could not be
authenticated.
o Receive rejected: authorization
 Unauthorized request. The sender of the received data, the
caller, is not authorized to use this process.
o In-compliance with security/non-repudiation
 Reply transmission did not comply with the security/nonrepudiation settings.
o Send failed
 Data was not received by the Reply target, the caller.
o Send rejected
 The Reply target, the caller, received and rejected the returned
data.
 Parameters → Errors:
o Activity arguments → Activity errors
o Maximal Duration → Time-out reply
o Security → Incompliance with security
o Non-repudiation → Incompliance with non-repudiation
In the case of Receive-Process-Reply, the Parameter and Errors refer mainly to the
Receive and Reply Events. If we knew the process part is of certain functionality,
maybe we could estimate better the possible errors. The world of business processes is
complex and diverse. It would be quite difficult, for example, to compare one
"Purchase Order" process with another "Purchase Order". But if we look at a higher
level we can find a very general outline of short processes – simple handling of the
received message. "Purchase Order", for example, is a complex handling. We divided
the simple handling into four types:

Query – search for the data in the received message and return
the results.

Notification – update certain entries according to received
message.

Verify – compare the received message to your records and
approve or disapprove its validity.

Update – update your records with the received message and
approve its consistency.
And so we add to the Parameters:
o Process type: query, notification, verify, update.
We add to Errors:
o Query failed
o Verify failed
o Update failed
Each Error can contain one or more items of failures. Note that Notification does not
have an Error. It's not that the Process cannot fail; it cannot fail on account of business
Notification, which does not include any processing.
And we add to Parameters → Errors:
o Process type Query → Query failed
o Process type Verify → Verify failed
o Process type Update → Update failed
Let's sum up this sweet part. We divided all Activities to three categories of
Constructs: Internal Activity, Send-Receive and Receive-Process-Reply. All of which
hold Parameters and Errors to which the referenced Activity is, technically, unaware.
And we identified four basic types of business processes, aside from the general
business process: Query, Notification, Verify and Update.
Our innovation is giving the business analyst the ability to assign an Activity its
Parameters and Errors according to his knowledge. Although we help by suggesting
possible Parameter and Errors and associating items in the two lists, we can't really
verify his knowledge. Meaning, we can't make sure that a Process marked by the
business analyst as a Query is not in fact an Update, or even a simple Task. We
cannot verify the structure of the referenced Sub-Process or the type of the referenced
Task. But there is something we can do – we can allow the business analyst to create a
new Sub-Process which behaves in the expected manner and is referenced by the
Activity. This leads up to the idea of a Template.