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

 

clip_image001With 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… Read the complete article here

SOA & BPM Partner Community

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] Facebook clip_image002[8][4][2][2][2] Wiki

Best Practices for SOA Suite 11g to 12c Upgrade By Jay Kasi

clip_image002A lot of effort has been put in by Oracle to make this major upgrade as smooth and easy as possible. The basic approach is to install SOA Suite 12c in a new oracle home and upgrade the domain and schemas in place. Customers undertaking the upgrade are primarily interested in a smooth upgrade, minimizing the number of manual steps in the upgrade, reduce the down time to a minimum, and minimize or eliminate any changes to client apps that use SOA APIs or web interfaces.

The key to a successful and smooth upgrade experience are the preupgrade preparations that you perform. The upgrade must be planned carefully. If the preupgrade preparations are not performed, there is a possibility that upgrade will fail in the middle or the system does not behave properly post upgrade. The only recourse to a failed production system upgrade is to roll it back from a full backup.

If your SOA domain includes BAM, then the upgrade is more complex because BAM does not support inplace upgrade. Please read the documentation carefully. The basic idea is to migrate the whole BAM deployment to a seperate domain using export/import, remove BAM from the soa domain during upgrade, and upgrade your soa domain to interop with the bam 11g domain. Later slowly and carefully migrate to BAM 12c from BAM 11g.

There are six top steps that should be performed before upgrade of your production system as a best practice.

  • Carefully review the prerequisites for upgrade in the documentation. Some of the prerequisites are checked upfront before we upgrade the schema in Upgrade Assistant but not all. Read all relevant upgrade documentation before starting on upgrade. Some of the key prerequisites are:

· Can only upgrade a domain that is 11.1.1.6 or 11.1.1.7. Migrate to a supported starting point before upgrade.

· Can only upgrade a deployment using a 64 bit JVM. Migrate to 64 bit JVM before upgrade.

· Can only upgrade a production domain not using XE DB and is not an admin server only domain.

· Can only upgrade a domain using LDAP or DB OPSS policy store. Migrate file based policy store to DB or LDAP based policy store before upgrade. Read the complete article here.

SOA & BPM Partner Community

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] Facebook clip_image002[8][4][2][2][2] Wiki

B2B – AS2 Best Practices for MDNs by Scott Haaland

An MDN (Message Disposition Notification) is a transmission level acknowledgment used in the AS2 standard, so that the sender knows that the receiver successfully acquired the message in a B2B scenario.  B2B (Business to Business) is an integration term used to describe the sending and receiving of business messages between business partners.  When the business messages are being sent over the internet via HTTP or SMTP, it is critical to business operators to know that the messages were transmitted successfully to the right party.   In order to give assurance to the business operators, specific B2B transmission standards have been developed.  We call these standards "Message Exchange Standards". These include AS1, AS2, AS4, ebMS and RNIF, to name a few.  AS2 is a very common standard for EDI messaging.  It is important for everyone using the standard to do so in the same way, or else inter-operation becomes very difficult or impossible.  Here is a diagram showing a typical EDI interaction over AS2 between two fictitious partners named OracleServices and MarketInc.

AS2 provides features such as Non-Repudiation of Origin, Non-Repudiation of Receipt, and Message Protection.  When sending a message, the sender includes a digital signature, and the receiver replies with an acknowledgement called an MDN (Message Disposition Notification) that includes the receiver’s digital signature.  Because each message is signed digitally, the receiver can be sure that original message has really been sent by the sender, and that the message has not been tampered with, which we call Non-Repudiation of Origin.  When the receiver replies with the signed MDN, the sender can be sure that the receiver obtained the message successfully, and that it was the correct receiver, which we call Non-Repudiation of Receipt.  When message encryption is turned on, then the message can be protected in flight because it can only be decrypted by the receiver. Read the complete article here.

SOA & BPM Partner Community

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] Facebook clip_image002[8][4][2][2][2] Wiki

Best Practices for SOA 11g Multi Data Center Active – Active Deployment – White Paper

Best practice for High Availability

This paper describes the recommended Active – Active solutions that can be used for protecting an Oracle Fusion Middleware 11 g SOA system against downtime across multiple locations (referred to as SOA Active – Active Disaster Recovery Solution or SOA Multi Data Center Active – Active Deployment). It provides the required configuration steps for setting up the recommended topologies and guidance about the performance and failover implications of such a configuration.

Get the white paper here.

SOA & BPM Partner Community

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] Facebook clip_image002[8][4][2][2][2] Wiki Mix Forum