Recently, I had a discussion with several colleagues and one of our large customers about when to use BPMN and when to use BPEL to model business processes. I have discussed this topic before in this post but this conversation opened up an interesting new angle on the topic, which I wanted to share with you all.

First of all, let me be clear about the scenario here. This is a large customer who is going to make extensive use of both BPMN and BPEL in their BPM/SOA environment. They are not trying to decide which one to use exclusively – it is given that both BPEL and BPMN will be used extensively. So the question here is about how to come up with a consistent approach to deciding which to use when – what to do with BPMN and what to do with BPEL.

The new perspective in this conversation was about how to choose the modeling language based on the fault/exception handling requirements of the process. If you are not familiar with the options available for fault handling in BPMN and in BPEL, you should quickly review these sources:

You will notice that there are some differences in the capabilities of the products today. If you look back over the last few releases of BPM, you will see that there has been a significant investment in adding more fault management capabilities for BPMN processes, and it would be reasonable to assume that this will continue.

But even while the Oracle platform holds the promise of equally rich fault handling in either BPEL or BPMN, one can make a case that the fault handling capabilities in BPEL are especially suitable for system to system integration, particularly when you need to use a distributed transaction or when compensation is required. Besides, these kinds of highly technical fault handling capabilities are a task probably best suited for more technical kinds of processes and people. And finally, the directed graph nature and ‘alter flow’ capability in BPMN can make it more difficult (or potentially impossible) to employ the same techniques.

However, the fault handling in BPMN is rather well suited to ‘business’ faults – not enough stock to fill an order, credit check failed, order line contains a discontinued product, order cancelled, things like that.

So this leads to the following suggested approach for this customer use-case:

Write top level (i.e. true ‘business’ processes) in BPMN,

Do not perform any kind of system interaction in these processes – don’t use adapters, call web services, etc.,

Use activities or embedded sub-processes with boundary events and event sub-processes to handle all business faults that may occur,

Make sure to have a ‘catch all’ event sub-process to handle any failures that are not specifically handled,

Theoretically there should never be a system fault in these BPMN processes,

Whenever there is a need to do some actual work, delegate this to BPEL, i.e. use a service activity with implementation type ‘service call’ to have BPEL go do the work,

Make the BPEL processes atomic, so that they can easily be retried, rolled back, etc.,

Use the fault management framework to control the handling of faults in the BPEL processes, and

This may not be perfect, but we think it offers a new, and very relevant, real-world perspective on how to decide which modeling notation is right for your processes. We are sure interested to hear your thoughts and comments.

For a start, here are Dave’s thoughts on this idea:

First I would just like to reinforce the constraints around the scenario that this advice applies to because I think customers would come up with different approaches, and Oracle would have different best practices, when the question is asked around a greenfield project as to when to use BPEL and when to use BPMN. In those scenarios, the advice would not be to wrap each system call in BPEL, since the unique value proposition of the Oracle platform is that the same system integration capabilities are available natively in both BPEL and BPMN. However, I think the guidelines above make sense for a customer who will be mixing and matching BPEL and BPMN throughout their processes and applications and where it is assumed that most projects will include both. In this case, it becomes important to strive for consistent guidelines as to where to draw the line for what to do in the BPEL part of a process and what to do in the BPMN part. In this case, the fault handling capabilities are indeed richer in BPEL today vs what is possible in BPMN and even though they may be equivalent in the future, there are certainly many kinds of fault handling logic, compensation, etc. that will be deeper than the business would want to go. The division of labor described above by Mark then results in not just using the best tool for the job, but also leverages the heterogeneous BPEL/BPMN architecture at this customer to make the BPMN “business view” of the process as clean as possible.

Share this:

Like this:

LikeLoading...

Related

About Mark Nelson

Mark Nelson is an Architect (an "IC6") in the Fusion Middleware Central Development Team at Oracle. Mark's job is to make Fusion Middleware easy to use in the cloud and at home, for developers and operations folks, with special focus on continuous delivery, configuration management and provisioning - making it simple to manage the configuration of complex environments and applications built with Oracle Database, Fusion Middleware and Fusion Applications, on-premise and in the cloud. Before joining this team, Mark was a senior member of the A-Team since 2010, and worked in Sales Consulting at Oracle since 2006 and various roles at IBM since 1994.

Copyright 2009-2015 Mark Nelson, Tanya Williams and other contributors. All Rights Reserved. The views expressed in this blog are our own and do not necessarily reflect the views of Oracle Corporation. All content is provided on an 'as is' basis, without warranties or conditions of any kind, either express or implied, including, without limitation, any warranties or conditions of title, non-infringement, merchantability, or fitness for a particular purpose. You are solely responsible for determining the appropriateness of using or redistributing and assume any risks.

The header image is a photograph of a house in China, taken by one of my favourite photographers, Roland Slee. Used with permission. Copyright Roland Slee.

About Advertising

WordPress does not allow blog owners to advertise on blogs hosted on wordpress.com, however they do sometimes inject their own advertisments into some pages for some users in order to produce revenue to support the great service they provide to us at no charge. WordPress provide blog owners with the ability to opt-out of this advertising for a small yearly fee. We prefer not to have advertisements displayed to readers of our blog and have opted out for your viewing pleasure.