Overview

Listeners and listener notifications work together to create a much more powerful model than polling notifications in detecting and processing events in the adapter resource.

Integration Server instantiates and initializes a polling notification object with settings from the node.

Integration Server then invokes the polling notification object by calling its runNotification method on a periodic basis.

The polling notification object must retrieve a connection and use it to determine if publishable events have occurred in the adapter resource.

If an event has occurred, the polling notification object must generate a WmRecord object conforming to the output signature of the polling notification node, and publish it by calling the doNotify method.

The polling notification object then goes to sleep until the next time it is invoked.

If the overlap option is enabled in the notification schedule, a second object may be instantiated while the previous instance is still processing events detected in a previous invocation. The second instance retrieves another connection, and interrogates the resource again. This model can make state management significantly more difficult.

When the user of the adapter uses a listener notification, the responsibility of monitoring the adapter resource and processing any events is divided between a listener and its notification(s).

A listener object is instantiated and is given a connection when the user of the adapter enables the associated node.

The listener object remains active with the same connection to monitor the resource activity until it is disabled either explicitly or by disabling the containing package, the adapter, the connection, or Integration Server.

When the listener detects a publishable event in the resource, it passes an object back to Integration Server.

Integration Server interrogates a configured list of listener notifications associated with the listener node until it finds a listener notification node that can process the event. Integration Server accomplishes this by calling the listener notification's supports method. The first notification to return true from this call is invoked using its runNotification method. This behavior is similar to the polling notification where any data about the event that was provided by the listener is passed as an argument to the runNotification method.