Assured event emission

Assured event emission is a specific mode of event processing that permits you to build business-critical, event-based solutions. With assured event emission, event formatting and emission processing is completed synchronously within the unit of work of the capturing transaction. The EP adapter is linked under the application task; that is, the event is not queued for asynchronous processing by an EP dispatcher thread or separate EP adapter task. The unit of work completes successfully only when the event is emitted.

The combination of emission mode, transaction mode, and transport must be set up correctly for assured event emission. The emission mode for events can be synchronous or asynchronous; synchronous mode is specified for assured events.

Events are specified as transactional or not. Events that are transactional are emitted when the capturing transaction completes successfully; however, events that are not transactional are emitted regardless of whether the application completes successfully. When the emission mode for an event is synchronous, the EP adapter emits transactional events to its transport in a recoverable manner. Writing to a transport in a recoverable manner means writing to the transport under the control of a sync point, so that transactional events are backed out if the application is backed out. Similarly, the EP adapter emits events that are not transactional to the corresponding transport in an unrecoverable manner. An event cannot be backed out when it is written to its transport in an unrecoverable manner.
Note: Do not permit transactional synchronous events to be emitted from long-running tasks that do not syncpoint because the transactional event emission causes records to be written to the CICS® log; the CICS log is not trimmed until the task syncpoints.
The type of EP adapter that is selected affects transactional support when the emission mode is synchronous; the CICS Event Binding Editor enforces the correct combination of transactional support and emission mode.
Notes:
  • The Transaction start and HTTP EP adapters cannot emit their events in a recoverable way and therefore do not support synchronous, transactional event emission.
  • The TS queue that is used for synchronous, transactional events must be defined as recoverable; the TS queue that is used for synchronous, nontransactional events must be defined as unrecoverable.

When an event fails to be emitted, the EP adapter provides information about the event and why it was not emitted, increments relevant event statistics, and causes the unit of work for the capturing transaction to be backed out. Further events that are not transactional could be emitted before the application is backed out.

Considerations for planning

Understanding the way that assured event emission works helps you to understand how to make the best use of this important capability. Some things to consider when you weigh the advantages of assured event emission include: security, performance, transport, and impacts to applications.

The event-capturing transaction must have write authority to the event emission transport (for example, the WebSphere® MQ queue for the WebSphere MQ EP adapter) for synchronous emissions; the EP dispatcher or adapter task that emits events needs write authority for asynchronous emission.

Synchronous, transactional event emission is recoverable. When you use the CICS WebSphere MQ EP adapter, events are put on the WebSphere MQ event queue under sync point; therefore, you might need to review your WebSphere MQ log data set space allocation. When you use the CICS TSQ EP adapter, this increases the use of your recoverable TS queue so you might need to review your CICS log stream size and attributes.

Assured event emission offers the opportunity to build event-based applications, and extensions to applications, that are critical to your business. The trade-off is that the synchronous processing that is essential to assuring that events are emitted might have an impact on your application response time. Decide which events are critical and which applications emit those events; a judicious use of assured event emission minimizes the application impact. See Event processing performance for more information about performance considerations for assured event emission.

A single unit of work might cause many events to be emitted, where some events are transactional and some events are nontransactional. If a capturing transaction fails to emit a synchronous event, the UOW is backed out with any transactional events that it captures. Nontransactional events might be emitted.

Event processing statistics show the number of events that were emitted and backed out for the event binding.

The EP adapter, its resources (such as a WebSphere MQ queue), and the event consumer need to be configured with enough capacity to process the expected peak volume of events to be emitted in order to prevent the capturing transaction from failing.