General Considerations When Consuming BPM Events

There are several aspects to consider when consuming BPM events:

• Use different BPM event types selectively

  Use the property configuration of the JEE service com.sap.glx.core.svc selectively. Activate only the event types that are really needed, in order to avoid unnecessary impact on system performance.

  If the implemented scenario requires one or more event types that need to be handled differently and additively, you can implement several MDB classes (and any other individual clients), as each of them are provided with the same events of the same topic. This broadcast-style behavior supports you in designing implementation logic according to separation-of-concern principles. Based on message selectors, these different implementations can select message types specific to their concerns.

  For more information, see Using Message Selectors.

• Subscribers should not maintain local state as BPM event provider is local

  The BPM event provider is implemented as a local provider. This means that in a clustered system, a BPM event is only delivered locally to subscribers on the same cluster node. As a BPM process execution cannot be guaranteed to stay on a particular cluster node, implementations of MDBs should not maintain a local state, as this might not remain available from one event to the next.

• Consider delivery guarantees

  If using JMS as a consumer, as in the given scenario, you need to consider delivery guarantees. The consumer needs to decide whether a subscription to the events should be in best-effort mode or with additional guarantees. Adding guarantees might have an impact on performance.

  For more information, see Using Transactions.

  One aspect of guarantees to consider when consuming a JMS message is, using transactions or binding the consumption of JMS messages to a Java Transaction API (JTA) context on the one hand, and processing it further and persisting it on the other hand.

  Another aspect of delivery guarantees to consider is whether a consumer is defined as durable. For instance, if a custom application is not started, a non-durable subscription is not active, which means the application might miss messages created in the meantime. In order to prevent such situations, consider using durable consumers.

  For more information, see Using Durable Subscriptions.

• Subscribers should not rely on in-order message delivery

  Implementations must not rely on the logical order of JMS messages for the BPM event topic. In a sequence of events, subscribers might see an event (for example. com.sap.bpm.jms.api.BPMEventType.SERVICETASK_COMPLETED) before another event that actually occurred before it (for example, com.sap.bpm.jms.api.BPMEventType.SERVICETASK_STARTED).

• Consider data security aspects

  This part of the BPM API provides read access to events occurring in BPM processes and tasks. Custom code that subscribes to the BPM event topic requires a particular UME action. For more information, see Authorizations and Roles. Once you gain this particular UME action, you can read all subscribed messages regardless of which business entity they represent.

  For example, if you have subscribed successfully to task events, you have access to the task-related events with the given data provided through the Java object com.sap.bpm.jms.api.BPMTaskEventMessage, regardless of whether or not you are involved in the given BPM task. It is up to the custom implementation to restrict access as required to information exposed by received Java instances of type com.sap.bpm.jms.api.BPMEventMessage.