BPEL Process Boundaries

I was just asked a really interesting question by a customer.  What are some good rules of thumb for splitting a business process into multiple BPEL processes?  What did he mean and what are the answers?

BPEL Processes

A BPEL process can be identified as a single BPEL file.  For a given business process there will be a BPEL process that represents it.  End of discussion right?  Well not quite because a BPEL process may itself call other BPEL processes.  Because a BPEL process is itself a web service, then it is trivial for one BPEL process to invoke another.  In fact the Oracle LoanFLowPlus demo included in the Oracle BPEL Process Manager uses this property to implement a CreditCheck service, as well as a couple of LoanProviders.

So although our business process is mapped onto a single BPEL process, that BPEL process may in turn invoke other BPEL processes (synchronously or asynchronously), meaning that we actually have lots of BPEL process files describing our business process.

How to Cut the Cloth

So now we know that we may have multiple BPEL processes making up our business process, how and why do we split up our process.  Let me make a few suggestions.  The following list is not exhaustive, there is no right answer as to how to split up a business process and I would welcome other suggestions for inclusion in my list.

1. Team Development

Because a BPEL process is a single file then only one person can work on it at a time.  Apparently the Oracle BPEL Process Manager can handle more than 20,000 steps in a single process.  I am delighted about this, but how long will it take one person to create that BPEL document!  Having multiple people working on a single document leads you down the route of merging changes in the version control system, sort of like putting lipstick on a pig as a method of team working.

It seems to me to be a good idea to break the large process up into smaller self contained sub-processes that can be edited and worked on in parallel.  If someone is going to work on a module of work in the business flow, then let them have their own BPEL process - one man, one file.

2. Interface Abstraction

A traditional integration approach is to have a common data model in the integration space.  Individual application formats are transformed into a single common format at the boundary of the integration solution.  This simplifies management because we now only need at most 2N transformations for N systems exchanging data, without the common format we would need up to N^2-N transformations.

The equivalent to this in BPEL is to have a common schema for use within our business process.  We then create seperate BPEL processes to encapsulate the systems we interface with, these processes will typically have a similar form

• Transform request from Common Format to Service Specific Format


• Invoke Service


• Transform response from Service Specific Format to Common Format

We are now insulated from change in the service we are invoking.  We are also in a good position to dynamically attach to services at run time.  Because all messages with a given purpose now have the same format, we can dynamically look up which service or services we are to use and invoke them using a common API.  For example we may talk to 3 airlines, each with their own unique web service format.  By have 3 interface processes to these 3 airlines we can invoke all of them using the same message format, making it easy to use them within a FlowN construct for example.

3. Component Re-use

The natural component level within BPEL is the BPEL process.  By seperating out our process into individual sub-processes we afford ourselves a great opportunity to re-use sub-flows.  By re-using the sub-flows we can ensure that everyone takes advantage of new ways of working when the sub-flow is updated.  For example several business processes may all need an "expenditure approval" sub-flow.  If the companies expenditure approval policy changes then it is only required to change the single sub-flow that is used by everyone, rather than going into every process that requires an expenditure approval sub-flow and updating multiple versions.

So the next time you are tempted to cut and paste some BPEL, think if you really should refactor it by splitting it out as a sub-flow and making it a BPEL process in its own right.  Over time you will build up a library of sub-components or as one customer called them, ingredients for a recipe.

4. Comprehensibility

A BPEL process should be readily comprehensible.  If it gets too large then it becomes difficult to find functionality within it and it hinders readability.  So when you find you are spending all your time zooming up and down a process trying to find the bit you need to modify, maybe it is time to refactor it into smaller process files.

And the Answer Is ...

There is no right answer.  My view though is the following

• Each developer should be allowed to work on his BPEL file/process without tripping over another developer in the same file - see point 1


• Any ugliness required in setting up calls to a service should be encapsulated in a boundary process that abstracts the ugly interface into a nice clean consistent one - see point 2.


• Keep an eye on scopes in your BPEL process that my be re-usable and make them seperate BPEL processes to facilitate this re-use - see point 3.


• As your BPEL process grows, make sure it stays readable by splitting it into smaller processes - see point 4.

Of course there are downsides to splitting up your 20,000 step BPEL process.  Suprisingly one of them is not performance.  The overhead of one BPEL process calling another in the same engine is not very great.  The downsides come in when we look at monitoring what is going on within a process.  We can see where we are in the top level process, but today we have to make a few more mouse clicks to drill down into seperate BPEL processes within the BPEL console.  Maybe this is something development could make easier for us.

So, I have no easy answer, just some musings, what do you think?