Once the event has been extracted it can also be emitted, routed, or enqueued.

This functionality is provided by the following methods of the Event class:

The route method generates a new event that is dispatched back into the correlator. Any active listeners seeking that event then receive this. There is no difference between an externally sourced event (passed in through a live message feed) and an event that was issued internally through a route method, other than that internally routed events are placed at the front of the input queue, although in the same order as they are routed within an action.

The emit method dispatches events to external registered event receivers, i.e. sends them out from the correlator. Active listeners will not receive events that are emitted.

Events are emitted onto named channels. For an application to receive events from the correlator it must register itself as an event receiver and subscribe to one or more channels. Then if events are emitted to those channels they will be forwarded to it.

Channels effectively allow both point-to-point message delivery as well as through publish-subscribe. Channels can be set up to represent topics. External applications can then subscribe to event messages of the relevant topics. Otherwise a channel can be set up purely to indicate a destination and have only one application connected to it.

The enqueue() method generates an event and places the event on a special queue just for events generated by the enqueue() method. A separate thread moves each enqueued event to the input queue of each public context. This arrangement ensures that that if a public context's input queue is full, the event generated by enqueue() still arrives on its special queue, and is moved to that context's input queue when there is a room. Active listeners will eventually receive events that are enqueue’d, once those events make their way to the head of the context's input queue alongside normal events.

Use the enqueue() method when you want to ensure that the correlator processes the generated event after it processes all routed events. This means that you want the correlator to finish processing the current external event. Completion of processing the current external event means that all routed events that resulted from that external event have been processed.

In a parallel application, you can enqueue an event to a particular context by calling the following method on an instance of com.apama.jmon.Event:

This method provides the same functionality provided by the EPL enqueue ... to statement. See Enqueuing an event to a particular context in Developing Apama Applications in EPL.

However, it is important to mention that when you enqueue an event to a particular context the event goes on that context’s input queue and not on the special queue for enqueued events. Consequently, when you call this method from an application thread that was created from the main Java application and the destination context’s input queue is full, this method blocks until the queue is able to accept the event.

Call the following method to enqueue an event to a array of contexts:

Call the following method to enqueue an event to a list of contexts: