The Event Replicator for Adabas is not an application in the traditional sense. Rather, it is made up of several components that work together to replicate data to a target application without disrupting normal Adabas operations. A portion of the replication task occurs within the Adabas nucleus address space, while another portion of the task occurs within an address space known as the Event Replicator Server.
Pictured below is a diagram of the Event Replicator for Adabas architecture and the main components involved.
This document describes the details of this architecture in the following topics:
The definitions and settings required for replication can be specified in any of the following ways:
They can be specified as initialization parameters, which are read from the DDKARTE statements of the Event Replicator Server startup job. The parameters for this batch administration are described in Event Replicator Initialization Parameters.
They can be specified in the Replicator system file which is read at Event Replicator Server startup. The definitions are maintained in the Replicator system file using the provided online menu-driven interface, Adabas Event Replicator Subsystem (a subsection of Adabas Online System). For more information, read Using the Adabas Event Replicator Subsystem.
In addition, the Adabas Online System (AOS) can be used to maintain the definitions for the source Adabas database as well as the Event Replicator Server and it can be used to activate and deactivate replication resources. For more information on how it can be used to activate and deactivate replication resources, read Managing Replication Definitions from AOS.
The Adabas nucleus is a set of programs that control an Adabas database and coordinate all of its work.
For information on the setup that must be performed to replicate data from your Adabas nucleus, read Adabas Nucleus Replication Setup. For information on the processing that occurs in an Adabas nucleus during replication, read Replication Processing, paying specific attention to the section Adabas Nucleus Detail Processing.
The Adabas replication pool is a buffer area used to store the replication data processed by the Adabas nucleus. The Adabas replication pool is updated solely by the code within the Adabas nucleus address space. The size of this pool is set by the ADARUN LRPL parameter.
The Adabas replication pool may become full if:
The ADARUN LRPL setting is too small to accommodate the replication data for parallel transactions.
Adabas temporarily or persistently produces more replication data than the Event Replicator Server or the messaging system can process
An outage of the Event Replicator Server or messaging system occurs.
When the Adabas replication pool becomes full, the replication system will deactivate replication for a file and a message is issued indicating which file was deactivated. When replication is inactive for a file, Adabas does not collect any further replicated updates for the file. Deactivated files may be explicitly reactivated via the ADADBS REPLICATION function once pool storage becomes available.
You can request warning messages when the replication pool usage exceeds a threshold that you specify using the ADARUN parameter RPWARNPERCENT. An initial message will be generated when this value, expressed as a percentage of replication pool usage, is exceeded. Additional messages will be generated when usage increases or decreases by the value you specify with ADARUN parameter RPWARNINCREMENT.
To avoid flooding the console with warnings, you can specify ADARUN parameters RPWARNMESSAGELIMIT and RPWARNINTERVAL. If more than RPWARNMESSAGELIMIT warnings are issued within the number of seconds specified by RPWARNINTERVAL, further warnings will be suppressed for the duration of the interval. When the interval expires, you will receive a message showing how many warning were suppressed, and warning messages can then resume.
The Event Replicator Server nucleus is a set of programs that control the Event Replicator Server and coordinate all of its work. This includes the components that parse and process all replicated data received from the Adabas nucleus and that receive and process inbound requests from the target application via the messaging system.
For information on the setup that must be performed to replicate data using a Event Replicator Server nucleus, read Event Replicator Server Nucleus Replication Setup. For information on the processing that occurs in an Event Replicator Server nucleus during replication, read Replication Processing, paying specific attention to the section Event Replicator Server Nucleus Processing.
The Event Replicator Server replication pool is a buffer area used by the replication code running in the Event Replicator Server address space. It is used to store decompressed and transformed replication data processed by the Event Replicator Server, along with other information. The pool is allocated in the address space of the Event Replicator Server. The size of this pool is set by the ADARUN parameter LRPL.
The Event Replicator replication pool may become full if:
The ADARUN LRPL parameter setting is too small to accommodate the replication data being gathered from participating Adabas nuclei.
The Event Replicator Server temporarily or persistently produces more replication data than the messaging system can process
An outage of a participating Adabas nucleus or message system occurs.
When the Event Replicator replication pool becomes full, the replication system may deactivate its resources, including destinations, subscriptions, files, or databases. The replication system determines and deactivates the resource having the greatest impact on the Event Replicator replication pool usage.
When a destination is deactivated, all subscriptions sent to that destination and to no other active destination will also be deactivated. A message is issued indicating which destination was deactivated.
A destination may be explicitly reactivated once pool storage becomes available using the ADADBS REPTOR function or using the Event Replicator Server management screens in the Adabas Online System. For more information, read Managing Replication Definitions from AOS.
When a subscription is deactivated, all files that occur in that subscription and in no other active subscriptions are also deactivated. A message is issued indicating which subscription is deactivated.
Deactivation of a subscription does not cause deactivation of related destinations. Those destinations containing only subscriptions that have been deactivated simply receive no more data.
A subscription may be explicitly reactivated once pool storage becomes available using the ADADBS REPTOR function or using the Event Replicator Server management screens in the Adabas Online System. For more information, read Managing Replication Definitions from AOS.
When a file is deactivated, subscriptions containing the file remain active. Subscriptions that contain only files for which replication has been deactivated simply receive no more data. Subscriptions that contain both deactivated files and active files will continue to deliver replication data to the target application, even though only partially replicated data will be delivered.
Once a file has been deactivated, the target application will be responsible for determining what to do with any partially replicated data. The application may decide to keep the partial data, and thus avoid the potentially costly refresh of large files for which replication has (or could have) remained active all the time. The target application has the choice to:
Store the partially replicated data in the target database, but deactivate access to that part of the database until full replication has been reestablished.
Store the partially replicated data in some temporary file and pick it up once full replication is being reestablished. Meanwhile, access to the replicated data can continue, as of the time when replication for the file was deactivated.
Deactivate some or all subscriptions that contain the file for which replication has been deactivated.
Deactivation of a file in the Event Replicator Server causes deactivation of the file in the Adabas nucleus. A message is issued, indicating which file was deactivated.
A file may be explicitly reactivated once pool storage becomes available using the ADADBS REPTOR function or using the Event Replicator Server management screens in the Adabas Online System. For more information, read Managing Replication Definitions from AOS.
When a database is deactivated, all of its currently active replicated files are also deactivated. Messages are issued indicating which files were deactivated. See the information above on file deactivation for more information on actions that can be taken when a file is deactivated.
A database may be explicitly reactivated once pool storage becomes available using the ADADBS REPTOR function or using the Event Replicator Server management screens in the Adabas Online System. For more information, read Managing Replication Definitions from AOS.
You can request warning messages when the replication pool usage exceeds a threshold that you specify using the ADARUN parameter RPWARNPERCENT. An initial message will be generated when this value, expressed as a percentage of replication pool usage, is exceeded. Additional messages will be generated when usage increases or decreases by the value you specify with ADARUN parameter RPWARNINCREMENT.
You can reduce the risk of Event Replicator Server replication pool overflows by requesting that the Event Replicator Server temporarily write replication transactions received from the Adabas nucleus to the SLOG system file. The Event Replicator Server then processes them using a throttling mechanism so that only a limited amount of replication pool space is used at a time. This functionality is controlled by the setting of the optional LOGINPUTTRANSACTION initialization parameter for the Event Replicator Server. For more information, read Reducing the Risk of Replication Pool Overflows and LOGINPUTTRANSACTION (Log Input Transaction) Parameter.
To avoid flooding the console with warnings, you can specify ADARUN parameters RPWARNMESSAGELIMIT and RPWARNINTERVAL. If more than RPWARNMESSAGELIMIT warnings are issued within the number of seconds specified by RPWARNINTERVAL, further warnings will be suppressed for the duration of the interval. When the interval expires, you will receive a message showing how many warning were suppressed, and warning messages can then resume.
These intermediary systems process messages from the Event Replicator Server and send them to the target application. They also transmit requests from the target application to the Event Replicator Server.
The Event Replicator Server sends replicated data to a messaging system (for example, webMethods EntireX or WebSphere MQ) for delivery to the target application.
The target application may send initial-state requests, status requests, and prior-transaction (resend buffer) requests to the messaging system for delivery to the Event Replicator Server.
Note:
The target application can be another Event Replicator Server accessed via an
EntireX or WebSphere MQ destination and over an EntireX or WebSphere MQ queue.
This arrangement might be useful if an Event Replicator Server cannot access a specific Adabas
database or if the connection between them is very slow.
For information on integrating the message system with your target application, read Integrating the Messaging System with the Target Application.
The target application is the outside application to which replicated data is sent.
Note:
The target application can be another Event Replicator Server accessed via an
EntireX or WebSphere MQ destination and over an EntireX or WebSphere MQ queue.
This arrangement might be useful if an Event Replicator Server cannot access a specific Adabas
database or if the connection between them is very slow.
Target requests are requests from the target application to the Event Replicator Server. Such requests include status requests, initial-state requests, and prior-transaction (resend buffer) requests.