This document describes how the Event Replicator Target Adapter works. It covers the following topics:
The Event Replicator Target Adapter requires the use of:
An Event Replicator for Adabas subscription for which a global format buffer (GFB) and field table (GFFT) has been generated. If no field table has been generated, the Event Replicator Target Adapter will not work. For more information about generating a global format buffer (GFB) and field table (GFFT), read Generating a GFB using the Adabas Event Replicator Subsystem or Generating a GFB and Field Table Using the Data Mapping Tool .
At least one Event Replicator for Adabas destination definition with a destination class type of "SAGTARG". This destination must be used by the subscription. For information on maintaining destination definitions, read Maintaining Destination Definitions using the Adabas Event Replicator Subsystem.
Note:
Destination class types of SAGTARG (DCLASS=SAGTARG) cannot be
specified for Adabas or file type destinations (DTYPE=ADABAS or FILE). The
SAGTARG destination class type is only valid for webMethods EntireX, WebSphere MQ, or NULL
destinations. When DCLASS=SAGTARG is specified, the ADARUN RPLPARMS parameter
must be set to "FILE" or
"BOTH" to provide access to any field table (GFFT)
definitions.
The subscription and destination definitions listed above must be activated. To activate subscription and destination definitions using Adabas Online System (AOS), read Managing Replication Definitions from AOS.
Proper user authorization privileges to maintain the target application.
User authorization to maintain any new RDBMS tables via Event Replicator Target Adapter is inherited from the site's privilege settings for the database. Authorization is managed by the user's RDBMS privileges and not by Event Replicator Target Adapter. Event Replicator Target Adapter will no longer grant RDBMS privileges to the user. Therefore, if you want to use Event Replicator Target Adapter to maintain tables in an RDBMS, verify that your authorization privileges are correct for the maintenance you want to perform.
For more information on Event Replicator for Adabas subscription and destination definitions, read Definition Descriptions.
When a subscription definition and one or more of its associated destination definitions have been defined in the manner described in Requirements and if they are activated, the Event Replicator for Adabas automatically creates a schema that maps the replicated data.
The Event Replicator Target Adapter uses the schema to transform and apply the replicated data to your relational database. It will dynamically create tables if they don't exist and populate the tables with Adabas data using insert, update, and delete processing as these processes occur in near real-time in the replicated Adabas file. For more information about activating the Event Replicator Target Adapter, read Activating Event Replicator Target Adapter Processing.
Event Replicator for Adabas and Event Replicator Target Adapter high-level processing are depicted in the following diagram.
The Adabas data is replicated as usual by the Event Replicator using a subscription with Event Replicator Target Adapter processing activated. The subscription transforms the replicated data and creates a schema from the generated field table. The schema and the transformed replicated data are then sent to the Event Replicator Target Adapter. The Event Replicator Target Adapter then processes the data and populates and creates appropriate tables or data in the target, as described next in Table Structure.
Event Replicator Target Adapter creates and populates tables with replicated data in the RDBMS as follows:
Note:
The Event Replicator Target Adapter will not process updates for a field that is the
primary key for an RDBMS table or for any fields that comprise a composite key
for the table.
If an SQL table has not already been established for the data, the Event Replicator Target Adapter will create one using the XML schema. XML schemas are identified as "Create" operations in the transferred data. Once the SQL table has been established for the data, the replicated data is inserted, updated, and deleted in the table as specified by the "Insert", "Update", and "Delete" operations in the transferred data. Subsequent XML schemas that might be sent are ignored.
The name of the SQL table created by the Event Replicator Target Adapter is determined by combining the name of the subscription with the name of the schema file. For example, if the subscription name is PAYROLL and the schema file name (Predict view name) is EMPLOYEE, the table name will be PAYROLL_EMPLOYEE. The names of the columns in the table are taken from the long names in the generated field table.
Note:
If you specify keyword "NOSPRE"
for the destination class parameter (DCLASSPARM parameter) in the Event Replicator
destination definition, the subscription name will not be used to
prefix the names of the tables produced by the Event Replicator Target Adapter. When
"NOSPRE" is specified (it must be specified in
uppercase only), the schema file name (Predict view name) alone is used for the
table names. For more information about modifying the destination class in an
Event Replicator destination definition, read DCLASSPARM Parameter
,
Maintaining Destination
Definitions Using the Adabas Event Replicator Subsystem, or .
Event Replicator Target Adapter will process each transaction as a unit-of-work and will only do an SQL commit if all parts of a transaction are successful. For example, if an insert operation is requested and a row with the same primary key already exists in the table, an error occurs and the whole transaction is rejected. Likewise, if an update operation is requested and a row with the specified primary key does not exist in the table, an error occurs and the whole transaction is rejected.
Error messages are written to the Event Replicator Target Adapter console and the sqlrep.log file . Read Managing Event Replicator Target Adapter Log Files for more information.
All SQL root tables require a primary key. If the schema submitted to the Event Replicator Target Adapter does not specify a primary key (which must be defined to Adabas as a Unique Descriptor), the Event Replicator Target Adapter uses the ISN as the primary key. You can define as many other unique keys as you like. All keys will be used to create SQL indexes.
MU and PE fields are supported by the Event Replicator Target Adapter. By default, when MU or PE fields are included in the replicated data, additional tables are created, as described in MU and PE Field Support.
Note:
Terracotta is not a Relational Database (RDBMS) and data
replicated to the cache does not create tables in the same way RDBMS target
tables are created. Rather, the cache is populated with data in a structure
that mimics the Adabas data structure.
Multiple-value (MU) and periodic group (PE) fields are supported by the Event Replicator Target Adapter:
Support for MU fields requires that counters for MU fields be available in the initial Predict data dictionary definition that was used to generate the global format buffer field table for Event Replicator Target Adapter processing. Counters for MU fields are available if the Predict data dictionary definition either specifies fields with field types of MC (MU fields with an automatic counter) or includes explicit CM field (MU counter fields) definitions. For more information about CM, MC, and MU field types, refer to your Predict documentation.
Support for PE fields requires that counters for PE fields be available in the initial Predict data dictionary definition that was used to generate the global format buffer field table for Event Replicator Target Adapter processing. Counters for PE fields are available if the Predict data dictionary definition either specifies fields with field types of PC (PE fields with an automatic counter) or includes explicit CP field (PE counter field) definitions. For more information about CP, PC, and PE field types, refer to your Predict documentation.
You can control how many occurrences of PE and MU fields are
generated in the global format buffer field table, and thus, how many
occurrences are available for Event Replicator Target Adapter processing. This is accomplished using a
combination of the Predict Occ field attribute
setting and the Occurrences used setting specified when
the global format buffer field table is generated. By altering the
Occurrences used setting, you can specify that the maximum
number of occurrences be generated, that no additional occurrences be
generated, or that the number of occurrences defined by the Predict
Occ attribute should be generated. For more
information about the Occ field attribute, refer
to your Predict documentation.
For more information about generating a global format buffer field table, read either Generating a GFB using the Adabas Event Replicator Subsystem or Generating a GFB and Field Table Using the Data Mapping Tool.
At this time, the Event Replicator Target Adapter does not support the use of MU or PE fields as primary keys or in composite keys.
By default, when MU or PE fields are included in the replicated data, additional tables are created, as follows:
| Field Type | Tables Generated |
|---|---|
| MU | A new MU table is generated for each MU
field. Each value of the MU field will be a row in the MU table.
The name of the MU table is comprised of the name of the root table (for example, PAYROLL_EMPLOYEE_ADDRESS-LINE) and the column name of the MU field. The MU table will consist of two columns:
|
| PE | One table is generated for a PE group
field. The elements that comprise the PE group field become columns in the
table. For example, if the PE field consists of five subfields, five columns
are created.
The name of the PE table includes the name of the PE field (for example PAYROLL_EMPLOYEE_INCOME). The columns in the table are given the subfield names. |
Using the Data Mapping Tool, you can flatten MU and PE fields in the replicated data so that they are replicated as columns in the resulting table, rather than as separate tables. For more information, read Flattening Fields for Replication .
If, at any time during normal Event Replicator Target Adapter processing, the Event Replicator Target Adapter detects that the RDBMS is not operational, it will attempt to reconnect to the database at an interval specified by the Retry Interval parameter defined for the Event Replicator Target Adapter source definition. The number of times it attempts to reconnect to the database is determined by the setting of the Retry Count option. You can set the values for these options, as described in Maintaining the Event Replicator Target Adapter Engine Configuration. If you use the default settings of these environment entries, the Event Replicator Target Adapter will attempt to reconnect to the RDBMS database every 30 seconds for a total of five attempts.
If a reconnect attempt is successful, Event Replicator Target Adapter processing continues normally. If, however, all of the reconnect attempts fail, the Event Replicator Target Adapter remains up, but the source from which the message was received is shut down. Unprocessed messages remain in the message queue, so no transactions are lost. The Event Replicator Target Adapter will not remove a transaction from the message queue unless its associated transaction has been successfully committed to the RDBMS database.
If a SQL error is detected in a given transaction, by default the Event Replicator Target Adapter will write the transaction to the sqlrep.log file and will shut down the source from which the message was received. However, you can change the value of an environment entry, called Error Continue, that logs the error, but allows Event Replicator Target Adapter to continue processing. For more information about error processing, read Managing Event Replicator Target Adapter Log Files. For more information about processing options, read Configuring Target Definitions for Event Replicator Target Adapter, Specifying Target Database Processing Option Definitions, and Configuring Source Definitions for Event Replicator Target Adapter.