Top 10 Things You Should Know About BPM 11g/12c by Mark Foster
May 4, 2015 1 Comment
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… Read the complete article here
For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.
Blog 
Twitter 
LinkedIn ![image[7][2][2][2]](https://soacommunity.files.wordpress.com/2013/04/image7222.png?w=20&h=20 "image[7][2][2][2]"){kind=small}
Facebook ![clip_image002[8][4][2][2][2]](https://soacommunity.files.wordpress.com/2013/04/clip_image00284222.jpg?w=26&h=23 "clip_image002[8][4][2][2][2]"){kind=small}
Wiki
Best practice for High Availability
PaaS Community Blog 