Sending events to other monitors
After you inject a monitor into the correlator, it can communicate with other injected monitors under the following conditions:
If the source monitor instance and the target monitor instance are in the same context, the source monitor instance can route an event that the target monitor instance is listening for. A routed event goes to the front of the context's input queue. The correlator processes all routed events before it processes the next non-routed event on the context's input queue. If the processing of a routed event routes another event, that event goes to the front of the input queue and the correlator processes it before it processes any other routed events on the queue. See
Event processing order for monitors.
If the source monitor instance and the target monitor instance are in different contexts, the source monitor instance must have a reference to the context that contains the target monitor instance. The source monitor instance can then send an event to the context that contains the target monitor instance. The target monitor instance must be listening for the sent event or the context that contains the target monitor instance must be subscribed to the channel that the event is sent on. See
Sending an event to a particular context and
Subscribing to channels.
Within a context, an application can use routed events and completion event listeners to initiate and complete a service request inline, that is, prior to processing any subsequent events on the input queue. See
Specifying completion event listeners.
In the following example, the event listeners trigger in the order in which they are numbered.
monitor Client {
...
listener_1:= on EventA() { route RequestB(…) }
listener_5:= on ResponseForB () { doWork(); }
listener_6:= on completed EventA() { doMoreWork(); }
...
}
monitor Service1{
...
listener_2:= on RequestB(…)
route RequestC();
listener_4:= on ResponseForC{
route ResponseForB ();
}
...
}
monitor Service1a{
...
listener_3:= on RequestC (…)
route ResponseForC();
}
Best practices for working with routed events include:
Keep them small — preferably zero, one, or two fields.
Specify wildcards wherever appropriate in definitions of events that will be routed.
