With Dave Shaffer
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:
- For BPMN, read Chapter 19 of the Modeling Guide
- For BPEL, read this article by my colleague Greg Mally
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
- Keep BPEL ‘worker’ processes in separate composites from BPMN ‘business’ processes.
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.