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.