OBPM versus BPEL, That's the Question

Recently I was pointed to the so-called Oracle Learning Streams http://education.oracle.com/streams which provide short presentations on all kind of topics.

While ironing my clothes on a Sunday afternoon, I watched one with the title "Leveraging OBPM vs BPEL" by David Mills. An excellent story where he explains in less than 13 minutes the high-level difference using a practical example.

One reason why I like about this stream is that it is in line with what I preach for years already. Otherwise I would have told you it sucked, obviously.

The main point David makes is that you should use the right tool for the right job. OBPM aims at orchestrating business functions, whereas BPEL aims at orchestrating system functions. The example used is an orchestration of system functions to compose an Update Customer Profile service, which then can be used in a business process, orchestrating business functions where one person is involved to approve some update, while someone else needs to be informed about that. Watch, and you'll see!

For understandable reasons the presentation does not touch the (technical) details. Without any intention to explain those, one should think about differences in the language itself (for example in BPEL you cannot create loops while in BPMN that quite normal to do), and also in the area of configuration and tuning (for example in case of BPEL there are more threads to tune, and you can do in-memory optimization, etc.).

Maybe I find some time to give you a more detailed insight in those more detailed differences. Would help if you would express your interest by leaving a comment!

Why You Should Create BPM Suite Business Object Using element (and not complexType)

In this article I describe why you always should base your business object based upon an element, instead of a complexType.

With the Oracle BPM Suite your process data consists of project or process variables. Whenever the variable is based on a component, that component is either defined by some external composite (like a service), or is defined by the BPM composite itself, in which case it will be a Business Object. That Business Object is created directly or is based upon an external schema. Still with me?

When using an external schema you should define the business object based upon an element instead of a complexType. Both will be possible, but when you define it based upon a complexType, you will find that any variable using it, cannot be used in (XSLT) transformations nor can be used as input to Business Rules.

As an example, see the following schema:

The customer variable (that is based on an element) can be used in an XSLT transformation, whereas the order variable cannot:

The reason being that XSLT works on elements, and not complexTypes.

For a similar reason, the customer variable can be used as input to a Business Rule but the order variable cannot:

Of course, if you are a BPEL developer, you probably would already know, as there you can only create variables based on elements ;-)

Did You Know that You Can Buy OUM?

The Oracle Unified Method (OUM) Customer Program has been changed in that, next to the already existing option to get it by involving Oracle Consulting, you now also can buy it if (for some reason) you don't want to involve Consulting.

Next to that there also is the option to purchase a subscription (initial for 3 years, after which it can be renewed annually) allowing to download updates for OUM.

OUM aims at supporting the entire Enterprise IT lifecycle, including the Cloud.

Work-around Instance Migration Limits of BPM Suite 11g

The following describes a work-around for 2 situations for which instance patching and migration is not supported, being changing the level of an activity, and removal of an embedded sub-process. In short this work-around consists of re-implementation of the activities to move, and emptying the reusable sub-process.

There are a couple of restrictions for the Oracle BPM Suite that can make that process instances cannot be patched (deployment using same revision number) or migrated (deployment using new revision number, and then move from old to new revision). Two of them are that you cannot change the scope of an activity (like moving it in our out of an embedded sub-process) or removal of an embedded sub-process. For both situations there is a work-around, that I can demonstrate with one case.

More information about instance patching and migration can be found here for BPM 11g (11.1.1.7) and here for BPM 12c (12.1.3).

The Work-Around

Suppose you have a process (A) like this:

And you want to change it to this (in real life you may want to move the activity inside to a totally different location, or even remove the embedded sub-process altogether) to this model (D):

As migration of running instances is not supported:

1. Because of changing the scope of the activity, and
2. Because of removal of the embedded sub-process

you will get an error like this when trying to do so:

 However, what you can do, is change the model like this (C):

The trick is that the Say Goodbye activity has not been moved outside, but re-implemented. In this case I created a new activity with the same name, and reused the existing task definition. So I only had to redo the data mappings.

You won't win any prize for most beautiful process model with this but it works. In practice you want to collapse the embedded sub-process and rename it to something like "Empty".

The Proof of the Pudding

To make sure it actually works for running processes I used an extra step between (A) and (C), being this model (B):

 First I started with the first model, created 2 instances with one in Say Hello, and the other in Say Goodbye. I then deployed the last model with "Keep running instances" checked (instance patching). The result was that both instances were automatically migrated (i.e. just kept on running).

Then I created a start situation of 3 instances, each of them being in a different activity. The most interesting is the one in Say Goodbye in the re-usable sub-process, as in this case the token is in an activity that is going to be removed.

 In line with the documentation, when deploying model (C) all instances were put I status Pending Migration. Using Alter Flow I was able to migrate the instances in the first and last activity as-is. After that I could successfully complete them.

The interesting one though, is in the second activity:

I was able to migrate that with Alter Flow by moving the token from the embedded sub-process (not the activity inside the embedded sub-process!) to the last activity:

The engine never knew what hit it ;-)