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.
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.
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.