Executable BPMN via BPEL

In a short burst of discussion about whether BPEL was a viable execution mechanism for BPMN, Keith Swenson provided an excellent example of a valid BPMN expression that could not be expressed directly in BPEL with a follow up in his blog showing that the BPMN could be directly executed using his product.

This was followed up by a spirited exchange between factions with assertions that BPEL could indeed express the business process but no definitive BPEL as far as I can tell. Alex Boisvert acknowledged a bug in the BPEL produced by Intalio Designer v5.2 but unfortunately did not describe the code that should have been produced. [[Update:ActiveVOS provides an answer in its tutorial material ]]

However, the BPMN 1.1 specification provides a couple of items for thinking around this problem.

The use of a new signal element to provide synchronisation behaviour across processes covers exactly the intent of Keith's example.

There may be situations within a Process where the flow is affected by or dependent on the activity that occurs in another
Process. These events or conditions can be referred to as milestones. The process model must be able to identify and react
to the milestone.That is, the continuation of a Process may be triggered by Signal Events, which pass the flow between
processes (see Figure 10.48 reproduced below). The type of Workflow Pattern called a Milestone.

In para 10.2.1.11 Avoiding Illegal Models and Unexpected Behavior of the BPMN specification, the authors touch on the root cause of the issue.

The situation where alternative paths cross the implicit boundary of a group of parallel paths can cause an invalid model.

If there is to be a future for BPMN to BPEL, we need an indication of what transformation needs to be done to otherwise valid BPMN to produce the intended executable.

The use of BPMN signal elements suggests that the bright people at Intalio could replace the doubtful synchronisation with whatever mechanism they are going to employ to implement signal intermediate events (not implemented in v5.2!). That is, implement it as though the BPMN looks like this ...

This then gives us a manual work around until the transformation rules can be codified into the product.

Which raises the question ... does the catch event need to be reached before the throw can be effective? Should I draw the BPMN like this? ...

Executable BPMN call for action

In BPMI.org Redux Ismael Ghalimi of Intalio calls for participation in a group to sort out a true executable BPMN. The tentatively titled BPMNLab looks to be a good practical approach to the issues.

• What consitututes executable BPMN?
• Are there useful BPMN flow patterns that cannot be translated into WS-BPEL? If so, how are they best dealt with to produce an executable?

After what has been a bit of sniping from the sidelines on my part, I would be happy to be involved in this effort.

The transformation to BPEL approach seems to me pretty sound. Here is a working language definition appropriate for the BPM domain that is capable of withstanding rigorous assurance testing. Why attempt to define another?

A few BPMN constructs may produce really ugly BPEL code, but who cares except for a few developers in Intalio and the like who have to develop the transformation code. The last thing that anyone in the real world should be doing is fiddling with the generated code. I am reminded of a very successful Unisys product LINC which developed totally unreadable and arguably inefficient COBOL code. In years of use, we had no more reason to look at the generated intermediate COBOL than the final machine level code.

Comply with the specification for BPMN

Bruce Silver in BPMN-BPEL in Perspective responds to the same article as I did here and raises the issue of compliance.

OMG could define a compliance spec for BPMN 2.0 - the elements,
attributes, and flow patterns that MUST be supported to claim BPMN
support. They have made some murky noises about it, but I haven’t seen
anything concrete yet. Since IBM and Oracle are driving the bus there,
it would make sense that that subset would have a defined mapping to
BPEL, but it would allow non-BPEL engines to be compliant as well.

That would be a healthy thing for the industry. But I’m not holding my breath.

I may be more used to specifications for computer languages (like FORTRAN, COBOL) than business process but I suggest that the specification for BPMN 2.0 itself should be what vendors comply with and not a separate compliance statement. Compliance statements from vendors will then effectively state what they have not achieved (yet). Purchasers and consultants can then judge whether the level of compliance of a particular product is sufficient for there purpose.

As BPMN is unlikely to stop at 2.0, a really supportive vendor should not only be compliant with the currently approved specification but also support proposals for future versions, so that practitioners can work with the new ideas while they work through the acceptance process of a standard.

Execution is a different issue. A vendor could opt for a BPEL execution engine (as Intalio uses at present) and reflect that decision by flagging bits of the model as not-executable. An organisation working from the compliant BPMN model could than decide on a method for implementation ...

• use a tool that will generate an executable directly from the model, or
  
• hand the model to an IT developer as a requirement specification

I will be looking for solutions in the first category but we must not lose sight of the fact that a vast number of organisations like to keep a developer shop and consultants busy re-inventing processes in Java or whatever language is the flavour of the month.

Even for Intalio, the execution engine could be replaced by something easier to map to BPMN without changing the user view.

To BPEL or not to BPEL

In Why BPEL is not the holy grail for BPM, Pierre Vigneras thoroughly covers the issues of using BPEL as the implementation layer of a business process solution. From the article conclusions ...

• Therefore, we consider BPMN notation as the only currently viable solution for Business Analysts
• Transformation from BPMN to (readable) BPEL is quite hard to implement, and produces --- when correct --- hardly readable code.
• Therefore, we may wonder why BPMN is transformed to BPEL since there
  exist a graph-based standard that maps directly BPMN constructs ---
  namely XPDL v2.0
• Of course, one may claim that XPDL 2.0 lacks some execution specifications that makes him (sic) unsuitable for direct execution.

Although I am generally a fan of Intalio, Pierre provides a good example of the problems they get when BPMN is used as though it is a convenient graphical expression for BPEL. In particular, a real business analyst can express the process in valid BPMN which is then transformed by Intalio into BPEL which bears little relation to the designer's intention. Worse, the Intalio developers have removed valid BPMN constructs from the business analyst, probably because they do not readily fit with the BPEL implementation. To add insult to injury, there is a general impression that if your valid BPMN does not work, you must have designed your process against some mystic best practice rather than expressed real business events and activities.

I am less concerned about the round-trip issue. If the BPMN is transformed by a product into an execution language which then remains untouched by human developer hand why we should care about the readability of that executable code? The answer is that the maturity of product development in BPM does not give users much faith that the generated code will do what we expect.

If we concentrate on developing BPMN into the way of real business analysts express the business processes and assume an automatic transform into a executable, the choice of implementation paths is only of concern to product developers. Out in the real world we can judge their products by the ease with which we can describe the processes that we find (as-is) and design (to-be).

BPMN Modeler Eclipse Sub-project

Intalio has announced a move to raise the status of the BPMN Modeler component to
a sub-project under the top level project Eclipse SOA Tools
Platform (STP).

The BPMN sub-project will focus on building an usable and extensible
graphical modeler by leveraging the tools provided by the Graphical
Modeling Framework and the EMF Validation Framework.

• Provide a first class user experience when it comes to designing processes, using graphical assistants.
• Provide a graphical notation according to the BPMN standard.
• Provide ways to extend the modeler to integrate it within commercial products.

Great stuff.
Let us avoid the situation where people describing their view of the real world are constrained by a developer's pain of how the real world may have to be transformed into code.
I would really like to see a mandate to allow modelling in line with major proposals in BPMN rather than limited to published specifications. This seems to be a real benefit of extensibility. Perhaps it is a bit late for BPMN 2.0 but it would be good to be able to explore major changes within the normal modelling toolset.

Adventures in BPMN?

Keith Harrison-Broninski is undertaking an adventure in BPMN to demonstrate its shortcomings and to promote an alternative approach to descibing business processes.

... I will take simple scenarios drawn from everyday knowledge work and
show how BPMN cannot express these situations. I will also show how
easy they are to express in the Human Interaction Management notation ...

Unfortunately, he chooses to ignore the rules and semantics of BPMN (it is not just a set of Visio shapes) and so detracts from his argument. There are plenty of issues with using BPMN but a good starting point is to use what is there at BPMN 1.1 correctly. For clarity, I have reproduced the offending diagram below:

This diagram shows the following incorrect BPMN expressions

• Messages (dashed arrows) originating at gateways
• Messages between activities in a POOL (the saleperson, technical consultant amd account manager are LANES)
• Use of message as a sequence flow
• Loops

I think that the BPMN that expresses the ideas behind Keith's drawing is:

Note that the loops continue (perhaps indefinitely) while the proposal is not OK.

Keith asks a number of questions that purport to show that BPMN is inadequate for his purpose

What are the goals responsibilities of each player?

How can the salesperson know what the others are looking for?

etc

None of these questions are relevant to the business process and the purpose of BPMN. Overloading an expression of sequence, orchestration and choreography with specification of the activities, policies and human interactions will confuse rather than communicate. There are plenty of other modelling artifacts that can be employed in an enterprise architecture to complete the picture.

Modelling Timer Interrupt in BPMN

Modelling Timer Interrupt in BPMN

Real-life processes are often limited by time and exception paths are taken when "Time's Up". The rich notation of BPMN provides for this. The BPMN 1.1 specification provides an example from Voting operations.

The normal sequence flow and error flow from "Moderate E-mail Discussion" in this case are merged into the subsequent activities but it is easy to imagine circumstances where the subsequent activities were  not identical.

Modelling this in BPMN using Intalio immediately presents a problem because error flows are not permitted to go anywhere beyond the error handler activity which may be a Sub-Process. (This is a compliance issue in Intalio v BPMN 1.1 specification ).

A further issue is that, in Intalio, the timer itself does not interrupt the activity within the sub-process. That is when the timer event is triggered, the error flow is executed and  the activities within the subprocess continue.
This is counter-intuitive and inconsistent with the implementation of the intermediate error event so is probably a bug. The BPMN 1.1 specification (10.2.2) only requires the error flow to be started, there is no clear direction as to the operation of the normal sequence flow. As a workaround in Intalio, to interrupt the flow within a subprocess by a timer, a fault has to be raised in the error-flow. To avoid that fault stopping the whole process, it has to be trapped and handled within the process (at an outer scope or subprocess boundary). How do other BPMN products treat the timer?

An explicit example of this is shown below. If the timer expires for the sub-process timed exec then execution is halted by the error end event in the error flow handler. This error end event is processed by the error handler activity fault in the outer subprocess.

This example is available as a complete Intalio project on the community forum