Replicating data using the table replication definition file

The gateway replicates data between ObjectServer tables and the gateway target. The table replication definition file is used to define which tables and event types are monitored in Tivoli Netcool/OMNIbus and forwarded to the target that the gateway is configured to send data to.

You can specify the location of the table replication definition file using the following generic property:

Gate.RDRWTR.TblReplicateDefFile

The default table replication definition file is in the following directory: $OMNIHOME/gates/tivoli_eif/tivoli_eif.rdrwtr.tblrep.def

The default table replication definition file contains example commands. You should make a backup copy of the default file for future reference.

Note: You should use the REPLICATE command to replicate data from the primary tables (alerts.status, alerts.journal, alerts.details) and dynamic secondary tables (if required).

You can add one or more optional clauses to the REPLICATE command to further process the data during replication. The available commands are listed in the following syntax example. Use the optional clauses in the order in which they are listed in the syntax. For example, when using both the

FILTER WITH and AFTER IDUC DO clauses, the FILTER WITH clause must precede the AFTER IDUC DO clause.

REPLICATE ALL | (INSERTS, UPDATES, DELETES)
FROM TABLE sourcetable
USING MAP mapname
[FILTER WITH filter]
[INTO targettable]
[ORDER BY order, ... ]
[AFTER IDUC DO afteriduc] ;

Table 1. Optional replication commands
Command	Description
`FILTER WITH 'filter'`	Filters the database rows selected for replication, where `filter` defines the filter that the gateway uses in the `WHERE` clause of the `SQL SELECT`. Filtering is positive by default, which means that only those events that match the filter definition are replicated. You can use a negative filter by putting an exclamation mark (!) before the equals sign (=) in the filter clause. For example, the following filter clause replicates all events whose severity is not 5: `FILTER WITH 'Severity !=5'`
`ORDER BY 'order'`	Order results by the `SQL SELECT ORDER BY` clause used to get data. A potential use case might be to order by first occurrence, so that alerts are processed in chronological order, in which case the value specified for `order` would be `'FirstOccurrence'`.
`AFTER IDUC DO 'afteriduc'`	Updates replicated rows, where `afteriduc` specifies which field to update with what value. This uses the `SQL UPDATE` action to execute on rows retrieved by the `SQL SELECT` action used to get data, e.g. 'SentToCRM=1'.

Optimizing the eif_gw_resync trigger

When many or most alerts within an ObjectServer are of no interest to the gateway and you use a filter in the tivoli_eif.rdrwtr.tblrep.def file to exclude the corresponding events, then you should modify the eif_gw_resync trigger within the tivoli_eifgw_setup.sql file to use the same gateway filter. This modification optimizes the eif_gw_resync trigger by reducing the number of ObjectServer alerts that are touched during resynchronization operations.

To modify the eif_gw_resync trigger within the tivoli_eifgw_setup.sql file, add a where clause that has the same effect as the filter that you are specifying for the gateway to the update alerts.status clause. For example, if you are using the filter EIF_flag=1, then extend the following sql statement:

update alerts.status set Severity = Severity;

to this:

update alerts.status set Severity = Severity where EIF_FLAG=1;