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.

Using JAXB for Manipulating Payload of Human Tasks in SOA Suite

In some cases you may want to manipulate the payload of a human task of an OPBM or BPEL process instance using JAXB. An example would be when you are using some other framework than ADF Faces for creating the UI, and you want to work with Java objects instead of manipulating XML programatically.

To do so with JDeveloper, you can generate the JAXB content model by right clicking the xsd and choose "Generate JAXB x.x Content Model".




Be aware that you must do this using the human-task-specific payload, and not the xsd that was used to define the variable that gets passed into that human task, otherwise to your sad surprise you will get all kind XML validation issues when trying to push the data back to the process. Fortunately on its turn the xsd of the human-task-specific payload imports the original xsd, so when the original xsd changes, the human task specific payload automatically changes with it. You still have to regenerate the JAXB content model to let it reflect the changes.

The following picture shows the OrderCreationPayload.xsd of an OrderCreation human task. It imports an Order.xsd. The JAXB content model has to be generated using the OrderCreationPayload instead of the Order.