Managing the OMNIbusEventReader with an ObjectServer pair for New Events or Inserts

The OMNIbusEventReader service uses the StateChange field by default when querying Netcool®/OMNIbus so that Netcool/Impact can fetch both New and Updated events. To configure the OMNIbusEventReader to receive only new events or inserts, you can clear the Get updated events check box in the OMNIbusEventReader configuration pane. Then, the query that is issued to Netcool/OMNIbus uses Serial instead of StateChange.

The limitation with using Serial is that in a Netcool/OMNIbus failover configuration each ObjectServer has its own unique values for Serial. During failover and failback the query that is issued by Netcool/Impact can result in events not being read or the same events being read again. The Serial value used in the OMNIbusEventReader query does not consider the unique value Serial has for each ObjectServer instance.

Scenario

The two ObjectServer instances are NCOMSA and NCOMSB. For NCOMSA, the current Serial is 9000. For NCOMSB, the current Serial is 7000.

When Netcool/Impact is connected to NCOMSA, the query is:

select top 1000 * from alerts.status where Class != 10500 AND Serial > 
9000 order by Serial;

NCOMSA goes down and Netcool/Impact connects to the secondary ObjectServer which is NCOMSB.

When connected, Netcool/Impact issues a select statement:

select top 1000 * from alerts.status where Class != 10500 AND Serial > 
9000 order by Serial;

NCOMSB has Serial 7000 and any new events that are inserted into NCOMSB would have Serial values as 7001, 7002, and so on. However, Netcool/Impact does not maintain a Serial value per ObjectServer instance and continues to look for events that are based on its last internal check pointed value, which was 9000.

As a result Netcool/Impact does not pick up the new events 7000, 7002, 7003, and so on. It would miss reading 2000 events from 7000 to 9000.

Once the inserted event gets a Serial value of 9001, Netcool/Impact starts fetching those events.