Decoupling Oracle BPM Process Instance Information by Dan Atwood

Separating Oracle BPM business processes from their underlying data is a topic that comes up regularly with customers.  When first starting out, most customers create a large set of process data objects that carry the payload of each work item instance throughout the life of a process and its subprocesses.  While it is tempting to begin this way, the work item instance process data should be kept light by storing an ID field that can be used to look up information from a relational database when it is needed.

What Information Should be Stored in the Process Instance’s Payload

Although you should always strive to keep the process instance’s payload small, you can go overboard.   Each work item instance should contain variables that provide:

• The unique way to identify a single instance in the process (e.g., the order id).  This would be used by the user interface forms to retrieve information from a database and for process instance correlations.
• The variables used in the process’s Exclusive Gateway conditional sequence flow logic should be driven from easily accessible process data object variable information in the instance’s payload.
• The information you want to use to populate public or protected flex fields should to be stored in the instance’s payload.
• The information used to populate Business Indicator measures and dimensions for Business Activity Monitoring (BAM) should to be stored in the instance’s payload.

Reasons to Keep to Process Instance Payload Small

This has long been a best practice recommended by Oracle.  In Oracle’s Performance Tuning for Oracle Business Process Management Suite 11g document, on page 17 it states:

    “Minimize the amount of data stored in the process instance. Obviously, there is a tradeoff between the cost of storing data locally compared to storing keys and retrieving data for use within the process, which needs to be considered.

    A reasonable starting point would be to model the process state to hold only values that are needed to control the process flow and keys to get any other (external) data on an ‘as needed’ basis. If retrieval is too frequent/slow, or the systems holding that data are not always available, then move more data into the process.”

AVIO Consulting strongly recommends decoupling the process payload and the underlying data.  Recently, Carlo Arteaga, Mark Peterson, Kris Nelson, Bhaskar Rayavaram, Suyash Khot, Adam DesJardin and I discussed this with a customer and went over these reasons for process data decoupling:

1. Differing Lifecycles – The underlying data and the processes typically have different lifecycles and need to be independent of one another.  There is often a need to maintain each at different times.  They are sometimes modified by different parts of the organization.  The data stored in a database is typically the “source of truth” that sometimes must be able to be accessed and easily manipulated by applications outside of Oracle BPM.  If stored as process instance data instead of in database tables, the outside applications would need to access it through Oracle BPM APIs that they will not be familiar with. 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 Facebook Wiki