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…
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…
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
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…
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…
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)
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)
Summary
They are my Top 10… what are yours ?
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission