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