Oracle SOA/BPM - Searching and Reporting Using Process Payload

For searching business process instances using specific attributes from the payload, the regular way to do so when using the Oracle SOA Suite is by using mapped attributes (formerly known as flex fields).

Using mapped attributes is pretty straight-forward. You configure them in the Administration tab of the Workspace, and map a specific element of the payload onto a mapped attribute. Once it has been mapped, the attribute can be added as a column to the task list and is available for filtering. The mapped attributes can also be used in custom code via the API.


Things to Consider

Mapped attributes have some important aspects to consider:

• They can only be used for simple type attributes (String, Number, Date),
• Mappings are task-specific, so to be able to search for example on an order.status element throughout the process you have to map it for each activity,
• There is a limited amount of mapped attributes (20 Strings, 10 Number and 10 Dates),
• Changes to mapped attributes are only applied to instances instantiated after the mapping took place,
• When instances are purged all historical data of those instances will no longer be available. In a production environment, purging of instances typically is done by a Systems Administrator with no (functional) knowledge of specific processes.

Especially the latter two aspects may require a different approach to secure full flexibility regarding searching and reporting on instances. This might for example be the case when there is a requirement that historical data should be kept indefinitely, or should only be purged in a controlled way by a Applications Administrator. In case of BPM, the requirement for a flexible approach on searching and reporting on process instances is pretty common.

In such cases an alternative to using mapped attributes (and reporting using the dehydration store) is to have a some custom database in which significant updates to process data are being stored. The advantage over using flex fields would be that:

• There is no limitation in the amount of attributes,
• The data of old instances can be manipulated, e.g. by providing default values for new attributes,
• Management of the custom database can be delegated to some Application Administrator that does have (functional) knowledge about the process.

The advantage of not needing to create a mapping per task, will obviously be over-compensated by the fact that the process has to do a service call every time the data needs to be saved, but again this buys back a lot of flexibility.

Instead of using service calls to save this data, you may consider composite sensors. A composite sensor is a specific type of BPEL Process Manager Sensors. Be aware though that composite sensors can only monitor incoming and outgoing messages, and not changes of the payload within a process instance. For this reason in most cases this won't be an alternative.