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 following generic Tivoli Netcool/OMNIbus property:

The property relevant to your gateway depend on if it is a reader/writer gateway or a reader gateway.

Gate.RdrWtr.TblReplicateDefFile : Use this property with reader/writer gateways.
Gate.Reader.TblReplicateDefFile : Use this property with reader gateways.

The default table replication definition file, either gw_name.rdrwtr.tblrep.def or gw_name.reader.tblrep.def, is located in the following directory:

$OMNIHOME/gates/gw_name

Where the value for gw_name is found in the configuration files row of the gateway guide summary table.

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'.

If a filter condition is set for alerts.status, the gateway will also apply the filter condition for the alerts.journal table. Set the following properties so that alerts.journal data can be replicated correctly:

Gate.Mapper.ForwardHistoricJournals: TRUE
Gate.RdrWtr.IgnoreStatusFilter: TRUE