Top 10 Things You Should Know About BPM 11g/12c

With the help of my A-Team colleagues (Sushil Shukla, Siming Mu, John Featherly, Pete Farkas), and based on collective experiences visiting numerous BPM customers worldwide, I have put together my “Top 10” list of things everyone should know when embarking on a BPM project.

You might agree, you might disagree, most of all, feel free to comment.

1. Auditing

BPM provides the business with extremely detailed visibility of runtime instances through its powerful auditing capabilities.

HOWEVER

This comes at a cost: detailed auditing requires frequent inserts into the SOAINFRA database increasing the likelihood of contention and causing significant database growth. As volume increases it is almost always the case that the consequences of Auditing produce the first bottleneck.

BUT…

Auditing can be tuned down where appropriate and purge scripts can remediate database growth

SEE…

Auditing Demystified

 

2. Payload Size

It can often be simpler at the time of BPM process design to have one large payload schema that includes all elements for every possible interaction within the lifetime of an instance, and pass this everywhere within the instance, including to human tasks and their UIs.

HOWEVER

The cost of this, both at runtime and in terms of the number and size of database rows, can be large. The whole payload must be written to SOAINFRA database at dehydration points within the lifetime of a process instance & in-between these dehydration points, data objects associated with this payload are held in memory.

BUT…

Appropriate design of the payload schema (flatter & simpler) can reduce the size considerably. The optimal solution would be to pass only key-values in the payload and retrieve detail values as-and-when needed inside the process, however this can lead to over-complicating the process design with technical services. A sensible balance is always the best approach.

SEE…

XML_DOCUMENT Table Growth

 

3. Partitioning / Purging

BPM audits heavily, this can be extremely useful for business insight

HOWEVER

The SOAINFRA database growth can be larger than expected

BUT…

Partitioning & purging are critical to limiting database growth. Test purging thoroughly as part of a normal stress/load test cycle. Determine whether “loop purge” outside of the online window is sufficient, if not consider also using “parallel purge” during quiet periods during the online day. Partitioning is a good option in most cases, in 11g SOAINFRA must be partitioned post-installation but in 12c it is an installation option.

SEE…

SOA 11g Database Growth Management Strategy Paper

SOA Partitioning

 

4. Negative Testing

SOA Suite provides a comprehensive fault policy framework & BPM has inbuilt fault-handling constructs, allowing the vast majority of technical and business exceptions to be handled gracefully.

HOWEVER

Failure to properly negative test potential exceptions, individually & in bulk, can lead to inadequate operational guidelines & faults occurring in production which can be hard to recover.

BUT…

Ensure that thorough negative testing happens in a like-live pre-production environment. Use this testing as a basis for building a robust fault-policy framework. Involve operations staff in this testing process in order to build an appropriate “Operations Guide”

SEE…

Fault Policy Framework

 

5. Faults & Recovery

Thorough negative testing and a comprehensive fault policy will allow the vast majority of exceptions to be gracefully handled

HOWEVER

Unexpected exceptions can still occur… exception conditions that were not tested prior to production and even issues in the BPM engine itself.

BUT…

All is not lost in situations like this. BPM process instances will roll-back to a prior dehydration point and can be recovered individually and in bulk from either the Enterprise Manager or via the API. 12c has the new Error Hospital features which make exception monitoring & recovery even simpler

SEE…

BPM Process Instances – Faults, Rollback & Recovery

Error Hospital (12c)

 

6. Performance / Load Testing

BPM running as part of SOA Suite can handle very high throughput and concurrent users.

HOWEVER

The BPM Engine, together with the other SOA Suite engines, the associated Weblogic servers and the underlying databases and JVMs are not tuned out-of-the-box for specific loads or usage patterns.

BUT…

Appropriate performance testing (load, stress, soak etc….) in a like-live pre-production environment allows for a highly tuned environment which can be used as a template for production.

SEE…

Oracle BPM 11g Performance Tuning Guide

 

7. LDAP & Active Directory

BPM is highly flexible in where its users & groups are stored. They can be in LDAP providers such as Active Directory or Oracle Internet Directory, they can be in other LDAP providers, they can even be in a database or a combination of any or all of them.

HOWEVER

The interaction between BPM and its users & groups can often be a bottleneck in production systems if the LDAP structure is not fully understood and/or the area has not been appropriately tested in a like-live pre-production environment. Active Directory can be a specific problem area since the settings for this inside Weblogic server are not tuned out-of-the-box for BPM.

BUT…

Appropriate testing will help to tune the properties and the caching at the level of the Weblogic provider and, if necessary, libOVD, OVD and the LDAP provider itself.

SEE…

Active Directory and BPM

BPM, libOVD and LDAP

 

8.Process Versioning

BPM is highly flexible in the management of process versions and the in-flight instances that run on them. Old and new revisions can run in parallel in a co-existence strategy. Small fixes to a revision can have the associated in-flight instances patched automatically. New revisions of a process can have some or all in-flight instances migrated from an older revision.

HOWEVER

Not all changes to the design of a process will allow automatic patching or migration of in-flight instances.

BUT…

It is possible to design around these limitations, and also possible in some case to force deployment and/or use “Alter Flow” post deployment to massage in-flight instances to the appropriate activity with the correct instance data.

SEE…

Restrictions on patching of in-flight instances (11g)

Restrictions on migration of in-flight instances (11g)

Alter Flow (11g)

Instance Patching

Instance Patching Revisited

 

9. When to Use BPEL

The benefits of BPM being part of a larger SOA Suite offering are huge, the appropriate product (BPEL, Mediator etc… ) can be used to solve the problem at hand.

HOWEVER

When to use BPEL instead of BPM can be a problem. It can be overly simplistic to assume that; if all that is required is service orchestration, if the process has no human interaction and the need for a business view of the running instances is not needed then BPEL should be chosen. BPEL has less database overhead and has been shown to be marginally more performant in terms of throughput but there are drawbacks, mainly in terms of instance patching (it is not possible) and instance migration (only sync processes, i.e. with no durable activities)

BUT…

A correct choice between BPM & BPEL (and other products such as mediator) should be made at design time in the full knowledge of the benefits and limitations of each. A safe rule of thumb is never to mix BPM processes and durable BPEL processes in the same composite.

SEE…

Modifying Running Process Instances (11g)

 

10. Flex Fields & Composite Sensors

Flex fields provide an ability to customize the BPM Workspace tasklist with business data, allowing business users to optimize how they prioritize and work on tasks. Composite sensors provide a similar ability within Enterprise Manager, i.e. give operational staff the ability to find running instances based on business data.

HOWEVER

It can be difficult to understand which of public or protected flex fields to use, there is a limit to the overall number of flex fields available & flex fields often cause performance problems as they are not indexed by default in the SOAINFRA database.

BUT…

Correct usage & indexing of flex fields can be invaluable to business users. Composite sensors likewise for operational users.

SEE…

Flex Fields with Oracle BPM (external link)

Composite Sensors

Summary

They are my Top 10… what are yours ?

Comments

  1. Congrats for this article.
    About error handling and fault recovery on BPM 12c, I also would suggest this other interesting article: https://community.oracle.com/docs/DOC-910406

    About your list, I would amend the item “9. When to Use BPEL” or include a new item about process modelling, granularity and decomposition.
    In my opinion it is very important have a well done balance in terms of the flow size (talking about number of activities in a single bpmn flow) and a good decomposition using partners (other processes – BPEL or BPM, java webservices, OSB proxies, etc ). This also can make a huge impact to a successful BPM implementation. In a similar way a spaghetti code can be a nightmare to maintain, a big process flow with all activities, business rules, outcomes and exceptions together in one single project also can be hard to maintain, test, and assure a minimal quality.

    Regards,
    Luis Fernando Heckler

Add Your Comment