BPMN/BPEL posts

Why BPEL is not the holy grail for BPM [P. Vigneras, Oct 21, 2008]

BPMN-BPEL in Perspective: [B. Silver, Oct 25, 2008]

Directly Executing BPMN [K. Swenson, Oct 29, 2008]

BPMN usage and tips

Are Floating Intermediate Events Valid? The issue is an intermediate event (e.g., message or timer) “floating” in a process or expanded subprocess alongside the regular flow, the one bounded by start and end events.  The floating event has a sequence flow out, leading eventually to end event, but no sequence flow in.

When Are Error End Events Legal? Is it valid to end a top-level process in BPMN with an error end event?

Articles on Oslo

• Workflows, Services, and Models: A First Look at WF 4.0, “Dublin”, and “Oslo”, David Chappell:The focus is on three things: workflows, services, and models. Accordingly, this set of forthcoming technologies has three main aspects: (a) a new and expanded version of Windows Workflow Foundation (WF), a .NE, (b) extensions to the Windows Server application server, codenamed “Dublin“, that provide improved server support and (c) a group of technologies, codenamed “Oslo“, aimed at creating and running model-driven applications.
• MGrammar in a Nutshell: Provides a high level introduction to MGrammar, a language for writing textual, domain-specific languages. This document begins by covering the basics of grammar development using MGrammar before diving into specific features for input and output processing, and programming against compiled grammars. There is also coverage of modularity, and advanced grammar techniques, including parameterization and recursion.
• Microsoft.Business.BPMN: This module defines the data types, relationships, and constraints that together support an implementation that closely aligns with Business Process Modeling Notation (BPMN) 1.1 in the Microsoft code name “Quadrant“.
• System.WorkflowModel and System.WorkflowServiceModel: Describes the data types, relationships, and constraints that together represent the functionality of the Windows Workflow Foundation (WF) as implemented in the .NET Framework.
• Martin Fowler on Oslo

---

• Oslo Developer Center: “Oslo” is the code name for our platform for model-driven applications. The goal of “Oslo” is to provide a 10x productivity gain by making model-driven applications mainstream with domain-specific models, a new language and tools.
• MSDN Microsoft Modeling Platform (code named “Oslo”): The Microsoft “Oslo” platform is a set of technical investments that aim to significantly simplify designing, building, managing and scaling service-oriented and composite applications that can span from the enterprise to the Internet.

---

• Best PDC session so far : Lap around “Oslo” by Dennis van der Stelt
• Oslo, WCF, WF & Dublin PDC Bits Review by Alan Smith

Arbitrary loops (GOTO activities) in sequential workflows

The following BPMN diagram presents a situation where there is an arbitrary loop with two entry points (one before Task A and one before Task B) and one exit point (after Task C). In situations like that it is not possible to implement this loop with a WhileActivity, because the WhileActivity works only with well-structured loops (i.e. those that have one entry and one exit point).

In many cases, it is possible to implement a loop like that with a StateMachineWorkflow. However, in order to implement this loop inside a SequentialWorkflow, we must exploit the rather obscure EventHandlingScopeActivity.

According to the official documentation, “… an EventHandlingScopeActivity activity executes its main child activity concurrently with an EventHandlersActivity activity. Each EventDrivenActivity within the EventHandlersActivity might execute many times or not at all”.

According to Scott Allen, “… the EventHandlingScope activity is similar to a Listen activity in that it can have multiple branches waiting for events in parallel. We can view these branches by right-clicking the activity and selecting “View Events”. The primary difference between this activity and a Listen activity is that this event continues to listen for all events until its main child activity (the default view) finishes execution. Imagine we are setting up a workflow that will count employee votes over a period of 30 minutes. We could set the main child activity of the EventHandlingScope activity as a Delay activity, with a 30-minute timeout. We can then place event handling activities in the event branches that listen for Yes and No votes. This activity will continue to listen for the Yes and No events until the Delay activity completes in 30 minutes.”

The idea is to setup the appropriate event handlers and raise the events from inside (by emulating the receipt of an external event). A mathematically concrete presentation (by C. Ouyang, M. Dumas, S. Breutel, and A.H.M. ter Hofstede) of this technique can be found here and here.

The main child activity contains two activities: Raises the starting event and waits for the end event. For the example above we need to setup two event handlers. A rule of thumb is that we need one event handler for each activity that has two or more input flows.

The first event handler contains Task A and raises the event for the second event handler.

The second event handler contains the Task B activity and an IfElseActivity, which represents the first gateway of the diagram. Now, the IfElseActivity checks the first condition (a==1) and if true, we raise the event captured by the first event handler. If false, we execute Task C and invoke a second IfElseActivity, which represents the second gateway. This IfElseActivity checks the second condition (b==2) and if true, we raise the event captured by the second event handler, otherwise we raise the event that ends the activity (the event that the main child activity listens to).

A sample project containing the workflow of the above diagram can be downloaded from here.

Marlon Dumas on BPMN-BPEL round-trip engineering

This is a copy of a very interesting answer of Marlon Dumas in the Workflow Research Forums:

The approach taken in eClarus is promising. However, I am afraid that this approach will break when it gets to BPMN processes where multiple instances of the same activity occur in parallel. Consider for example Figure 1(a) in page 4 of the following paper: http://eprints.qut.edu.au/archive/00002976/01/2976.pdf
You will notice that activity D may execute twice, and these two instances of activity D may occur concurrently (for example if B and C finish more or less at the same time).
Even worst, consider the example in Figure 1(c): the number of instances of D that may be active simultaneously is unbounded.
In the general case, such processes can not be mapped into BPEL structured activities, simply because BPEL structured activities can not generate multiple instances of the same activity. You can still go around a case like the one in Figure 1(a) by duplicating the path containing activity D (and assuming there is no cycle thereafter), but you’ll never manage to capture a case like Figure 1(c).
Up to now, the only way that we have found to map any BPMN diagram to BPEL is by relying on BPEL event handlers. BPEL event handlers have the characteristic that it is the only construct in BPEL 1.1, which allows an unbounded number of instances of the same activity to execute in parallel.
Of course, mapping BPMN models to BPEL defeats the purpose of getting readable models, and round-trip engineering is out of question from there on.
However, if we restrict ourselves to certain subsets of BPMN, some relatively simple algorithms can do the job, see for example: http://eprints.qut.edu.au/archive/00003615/01/3465.pdf
Using such a mapping, round-trip is achievable. This is where tools like eClarus are likely to play a role.
So in summary, don’t expect you can draw any BPMN diagram, hit the button, and get a readable BPEL def. that can then be reverted back to a BPMN model. This can only be (easily) achieved for some classes of BPMN diagrams. There are fundamental differences between BPMN and BPEL, and the mapping is far from trivial.
For some further discussions on this issue, see: http://itredux.com/blog/2006/02/03/the-nex…ocess-modeling/

04Jul06 Links

David Chappell – Standardizing the Right Thing: BPMN or BPEL?

… Fully standardizing BPMN, complete with a standard file format, seems likely to be a better solution than standardizing just an executable language such as BPEL.

John Evdemon – BizTalk and WF – Which To Use When?

• BTS is a licensed product designed to implement workflow (“orchestrations”) across disparate applications.
• WF is a developer framework designed to expose workflow capabilities within your applications.

Ted Neward – The Vietnam of Computer Science

BPM Market Overview

OMG created a page as a follow up to the information provided at the Think Tank workshop held on May 23-25th 2006. From the keynote “BPM Market Overview” presented by Connie Moore, Vice President and Research Director of Forrester Information Delivery Research Group, I picked the following slides:

BPMN-WF Mapping: The GOTO problem

I expected that the transformation of a BPMN diagram to a WF workflow would be accomplished by mapping each BPMN Process to a Sequential Workflow. But, there is a structural difference between the BPMN diagram and the Sequential Workflow. The difference is that the Sequential Workflow is block-structured (i.e. all paths from a split or branch reconverge at a single node), while the BPMN diagram is a free form graph. The arbitrary sequence flows allowed in BPMN are similar to GOTO statements. Given that Sequential Workflows does not have a GOTO activity (see a related thread from MSDN forums), the transformation is not possible without redrawing (re-engineering) a semantically equivalent block diagram.

The problem is equivalent with the problem of transforming BPMN to BPEL. Bruce Silver wrote a useful post on the topic and Yi Gao (Chief Architect of eClarus Software) wrote an interesting white paper. From these sources I copied an example BPMN diagram that presents the problem of block-oriented representations (like Sequential WF and BPEL).

But, what if we map the BPMN diagram to a State Machine Workflow? Then we can solve at least the GOTO problem. We can map each task and each gateway of the BPMN to a State activity, which contains a single StateInitializationActivity, which executes its contained activities when entering the state. The State Machine Workflow diagram is the following:

Each StateInitializationActivity which corresponds to a BPMN task contains two childs activities: one for the implementation of the task and a SetStateActivity which causes the transition to the next state. Each StateInitializationActivity which corresponds to a BPMN gateway also contains two child activities: an IfElseActivity to evaluate conditions and again a SetStateActivity which causes the transition.

Mapping BPMN Graphical Objects to WF Activities

(Draft, to-be-updated post)

Activities

BPMN	Windows Workflow Foundation
Process
Sub-Process	Maps to any CompositeActivity.
Loop Sub-Process	Maps to a WhileActivity.
Multiple Instance Sub-Process	Maps to a ReplicatorActivity.
Ad-Hoc Sub-Process
Compensation Sub-Process	Maps to a CompensateHandlerActivity.
Task	Maps to any atomic Activity that has only implementation semantics (e.g. CodeActivity or InvokeWebServiceActivity)

Events

BPMN	Windows Workflow Foundation
Start Event [None]
Start Event [Message]
Start Event [Timer]
Start Event [Rule]
Start Event [Link]
Start Event [Multiple]
End Event [None]
End Event [Message]
End Event [Error]	Maps to a ThrowActivity.
End Event [Cancel]	This type of End is used within a Transaction Sub-Process (aka inside a TransactionScopeActivity). Maps to a ThrowActivity.
End Event [Compensation]	Maps to a CompensateActivity. The attribute Activity:object maps to property TargetActivityName:string.
End Event [Link]
End Event [Terminate]	Maps to a TerminateActivity. BPMN does not has an equivalent of the property Error:string.
End Event [Multiple]
Intermediate Event [None]
Intermediate Event [Message]
Intermediate Event [Timer]	When used within the main flow, acts as a delay mechanism: Maps to DelayActivity.When used for exception handling it will change the Normal Flow into an Exception Flow.Either the attribute TimeDate:Date or the attribute TimeCycle:string are mapped to the property TimeoutDuration:TimeSpan
Intermediate Event [Error]	When used within the main flow, maps to ThrowActivity.The attribute ErrorCode:string maps to properties FaultType:Type and Fault:Exception.When attached to the boundary of an activity maps to FaultHandlerActivity.
Intermediate Event [Cancel]	This type of Event MUST be attached to the boundary of a Sub-Process. Maps to CancellationHandlerActivity.
Intermediate Event [Compensation]	When used within the main flow maps to CompensateActivity. The attribute Activity:object maps to property TargetActivityName:string.When attached to the boundary of an activity maps to CompensateHandlerActivity. The attribute Activity:object is ignored.
Intermediate Event [Rule]	Maps to a PolicyActivity. The attribute RuleName:Rule maps to property RuleSetReference:RuleSet.
Intermediate Event [Link]
Intermediate Event [Multiple]

Gateways

BPMN	Windows Workflow Foundation
Exclusive (XOR) Gateway [Data-Based]	Maps to a IfElseActivity.
Exclusive (XOR) Gateway [Event-Based]
Inclusive (OR) Gateway
Parallel (AND) Gateway	Maps to a ParallelActivity.
Complex Gateway

XAML vs. Standards

John Evdemon (Microsoft Architect) notes in a recent forums post:

Regarding WF, the underlying XML representation is XAML.  Why did we choose XAML instead of BPEL or some other standard?  Simple – XAML enables us to avoid the constraints imposed by a focusing on a single standard (e.g. BPEL lacks human workflow and sub-processes).  WF is capable of supporting multiple standards

• A BPEL 1.1 import/export tool is currently being tested and will be released later this year.
• We are in talks with partners to add BPMN modeling for WF
• I am aware of a couple of projects looking at XPDL and BPSS for WF
• The custom loader (I believe it becomes available in Beta 2.1) enables us to directly transform a BP standard to an executable representation, possibly enabling support for executable BPEL.