Table Replication

Use the table replication definition file to define which tables the gateway replicates and the types of events that it monitors in the ObjectServer.

Overview

The gateway creates and updates requests in BMC Remedy ARS when alerts are created and updated in the ObjectServer. The gateway populates and updates the fields in the request by replicating data from the ObjectServer. The gateway uses a table replication definition file called bmc_remedy_v9.rdrwtr.tblrep.def to determine which ObjectServer tables to replicate. Specifically, the bmc_remedy_v9.rdrwtr.tblrep.def file specifies REPLICATE command clauses that define how the gateway replicates data between an ObjectServer and a target database or application, in this case BMC Remedy ARS.

See the IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide for descriptions of the syntax associated with the REPLICATE command clauses. See the IBM Tivoli Netcool/OMNIbus Administration Guide for a description of the ObjectServer SQL interface for defining and manipulating relational database objects such as tables and views. The bmc_remedy_v9.rdrwtr.tblrep.def file makes use of the ObjectServer SQL interface. The IBM Tivoli Netcool/OMNIbus Administration Guide also describes the column names of the alerts.status and alerts.journal tables.

This topic describes the specific REPLICATE command and FILTER WITH clauses specified in the delivered bmc_remedy_v9.rdrwtr.tblrep.def file. The topic also provides examples of other possible FILTER WITH clauses.

The information that follows describes the bmc_remedy_v9.rdrwtr.tblrep.def file. See the IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide for more information, including information on the structure of the table replication definition file, the REPLICATE command, and the available clauses.

The table replication definition file

The table replication definition file defines which tables the gateway replicates and the types of events that it monitors in the ObjectServer. The table replication definition file also identifies the mapping between data fields in the ObjectServer and those in a BMC Remedy ARS request.

The table replication definition file supplied with the gateway is named bmc_remedy_v9.rdrwtr.tblrep.def, and resides in the $OMNIHOME/gates/bmc_remedy_v9 directory. Use the Gate.RdrWtr.TblReplicateDefFile property to specify the path to (including the name of ) the table replication definition file.

The table replication definition file contains one or more REPLICATE command clauses and as supplied contains the following:

REPLICATE ALL FROM TABLE 'alerts.status' 1 
	USING MAP 'StatusMap';  2 

REPLICATE ALL FROM TABLE 'alerts.journal' 3 
	USING MAP 'JournalMap';  4 
  FILTER WITH "Text1 NOT LIKE 'Generated by Remedy Gateway*'";  5 

# REPLICATE ALL FROM TABLE 'alerts.details' 6 
	#  USING MAP 'DetailsMap'  7 

The following descriptions explain each of the numbered items in the supplied bmc_remedy_v9.rdrwtr.tblrep.def file:

  1. Specifies that the gateway replicates all insert, update, and delete operations from the source table (alerts.status) to the target table.
  2. Specifies that the gateway uses the StatusMap defined in the bmc_remedy_v9.map file to map Tivoli Netcool/OMNIbus alert fields to their corresponding BMC Remedy ARS request fields.
    Note: A separate data mapping file called bmc_remedy_v9.map contains the definitions of the data mapping.

    See Mapping for details of the data mapping definitions.

  3. Specifies that the gateway replicates all insert, update, and delete operations from the source table (alerts.journal) to the target table.
  4. Specifies that the gateway uses the JournalMap defined in the bmc_remedy_v9.map file to map Tivoli Netcool/OMNIbus alerts.journal fields to their corresponding BMC Remedy ARS fields.
  5. Specifies how the gateway should filter the rows that are selected for replication. The NOT LIKE operator instructs the gateway to perform a string comparison between the string 'Generated by Remedy Gateway*' and the table column represented by the string Text1. The result is the gateway replicates all rows in the target table in which Text1 does not contain the string 'Generated by Remedy Gateway*'.

    This ensures that rows containing journal entries created by the gateway are not replicated.

  6. Specifies that the gateway replicates all insert, update, and delete operations from the source table (alerts.details) to the target table.
  7. Specifies that the gateway uses the DetailsMap defined in the bmc_remedy_v9.map file to map Tivoli Netcool/OMNIbus alerts.details entries to their corresponding BMC Remedy ARS fields.
    Note: Uncomment the lines (lines that begin with the hash sign (#)) for these REPLICATE command clauses if you want alert details. If you do not remove the commented lines for these REPLICATE command clauses, the gateway ignores the DetailsMap specified in the bmc_remedy_v9.map file.

    See Mapping for more information.

FILTER WITH examples

The bmc_remedy_v9.rdrwtr.tblrep.def file is supplied with the following FILTER WITH clause:

FILTER WITH "Text1 NOT LIKE 'Generated by Remedy Gateway*'";

The following examples show other possible FILTER WITH clauses. Create FILTER WITH clauses that are suitable for your environment. See the IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide for information on the FILTER WITH clause.

Note: When considering which characteristics of alerts to use as a filter, use those fields from the alerts.status table whose values do not change over time. For example, ServerName, Class, Manager, and so forth.
FILTER WITH 'Acknowledged>0';  1 

FILTER WITH "Text1 NOT LIKE 'GW%'"  2 

FILTER WITH 'Text1 NOT LIKE \'GW%\' '  3 

FILTER WITH 'Node != \'localhost\'  4 

FILTER WITH 'ServerName IN (\'NCOMS_US\',\'NCOMS_CA\')'  5 

The following descriptions explain each of the numbered items in the FILTER WITH clause examples. The gateway uses these FILTER WITH clauses to filter the database rows that are selected for replication as follows:

  1. Uses the > (greater than) comparison operator to test the ObjectServer alerts.status table field called Acknowledged to determine if the value is greater than 0 (zero). The result is the gateway selects only those alerts that have been acknowledged (that is, Acknowledged is equal to the value 1).
    Note: The Acknowledged field is either 0 (Not Acknowledged) or 1 (Acknowledged).
  2. Uses the NOT LIKE operator to instruct the gateway to perform a string match between the pattern GW% and the table column represented by the string Text1. (The % (percent) operator is used as a wildcard in matching operations.) The result is the gateway replicates all rows in the target table in which Text1 does not contain the string GW%.
  3. Uses the != (not equal to) comparison operator to test the ObjectServer alerts.status table field called Node to determine if the value is not equal to 'localhost'. The result is the gateway selects all Node alerts except those that originate from the local host.
  4. Uses the IN list comparison operator to compare the ObjectServer alerts.status table field called ServerName to the list of values NCOMS_US and NCOMS_CA. The result is the gateway selects only those alerts that originate from the ObjectServers named NCOMS_US and NCOMS_CA.
    Note: This FILTER WITH clause shows that if a filter contains quotation marks (single or double), an escape (the \ (backslash)) character must be specified before each quotation mark to escape it.