Table replication definition file

The gateway replicates data between ObjectServer tables and the gateway target application. 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.

Note: You can configure the gateway to operate in one of two modes of operation: standard mode or IBM Operations Analytics - Log Analysis (LA) mode.

You can specify the location of the table replication definition file using the Tivoli Netcool/OMNIbus Gate.Reader.TblReplicateDefFile property, which is defined in the G_XML.props file for gateways operating in standard mode and G_SCALA.props file for gateways operating in LA mode. The default name for table replication definition file is xml.reader.tblrep.def and is located in the following directory:

$OMNIHOME/gates/xml - For gateways operating in standard mode.
$OMNIHOME/gates/xml/scala - For gateways operating in LA mode.

If you are running the gateway using a transport module, the default table replication definition file is located in the following directory:

$OMNIHOME/gates/xml

If you are running the gateway with IBM Operations Analytics - Log Analysis, the default table replication definition file is located in the following directory:

$OMNIHOME/gates/xml/scala

Running the gateway in standard mode

If you are running the gateway in standard mode, the default table replication definition file contains example commands. You should make a backup copy of the default table replication definition file for future reference.

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

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'`
`INTO 'targettable'`	This specifies the table in the target database to which data will be replicated, where `targettable` is the name of the target table. Note: The `INTO` clause can only be used when the target is a table. Note: This clause is not required when replicating the main `alerts.status`, `alerts.details`, and `alerts.journal` ObjectServer tables. Even though these tables are dynamic, these primary tables have specific properties to specify the name of the target database table for storing their data. See the following properties in the properties file supplied with the gateway. `Gate.gw_name.DetailsTableName` `Gate.gw_name.JournalTableName` `Gate.gw_name.StatusTableName` Where the value for `gw_name` is found in the gateway guide summary table.
`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, for example, 'SentToCRM=1'.

Running the gateway in LA mode

You can configure the gateway to replicate with LA using the UPDATE, INSERT, or FT_INSERT table replication definition settings. FT_INSERT uses the Accelerated Event Notification (AEN) fast track channel to send events from an ObjectServer to the Message Bus Gateway; this is the recommended replication setting when configuring the Message Bus Gateway to send events to LA.

If you set the gateway up for AEN, it requires triggers to be activated on the ObjectServer and the FT_INSERT replication settings to be specified. For details about how to set up this configuration, see Configuring event forwarding using AEN.

For details of the best practices for Log Analysis deployment scenarios, see Deployment scenarios. For further details about monitoring accelarated events, see Monitoring accelerated events.