In a Sybase replication system, the purpose of a DirectConnect database gateway is to apply transactions from a Replication Server to a non-Sybase replicate database.
To accomplish this, Replication Server logs in to the DirectConnect gateway using the information specified for a Replication Server connection. Replication Server logs in to the server using the user_name and password, and issues a use database command for the database defined in the connection.
For Replication Server, there is nothing to distinguish a DirectConnect gateway from an Adaptive Server replicate database. Replication Server delivers the same commands—and expects the same results—from any DSI thread it communicates with.
This has the following implications:
A valid user ID, which the Replication Server uses to log in to the replicate database, must be defined in a Replication Server connection.
This user ID must be granted permissions to update replicate tables and execute replicate procedures.
The replicate database must be able to maintain a rs_lastcommit table and support rs_get_lastcommit functionality.
Replication Server provides sample scripts to set up the tables and functions required for a replicate database in DB2 Universal Database, Informix, Microsoft SQL Server, and Oracle databases.
For an overview of the expectations of a replicate data server and gateway, see Chapter 6, “Replicating Data into Foreign Data Servers,” in the Replication Server Design Guide.
Datatype representations must be translated to match the native datatypes of the replicate database. Replication Server provides sample scripts to set up the function strings, function-string classes, and base datatype definitions and translations necessary to support replication into DB2 Universal Database, Informix, Microsoft SQL Server, and Oracle data servers.
The Replication Agent User thread for this connection is not used (the DirectConnect gateway does not send transactions as a primary database). Remove the with log transfer on keywords from the Replication Server create connection command to bypass creation of a Replication Agent User thread for this connection.
The Replication Server command resume connection attempts to initiate activity with the DSI thread of the specified connection. For a DirectConnect, this is a sequence of logging in to the DirectConnect server, accessing the rs_lastcommit table in the replicate database, and then applying transactions to the replicate database. Any failure in this sequence is recorded as a failure in the Replication Server log.
Replication Server is an Open Server application. In an Open Server application, the preferred method for determining the location (host and port number) of another Open Server is to look up the location in an interfaces file. The interfaces file contains a list of labels, typically server names, of which each have a corresponding host name and port number, where the identified server should be “listening” for login requests.
In the interaction between a DirectConnect database gateway and a Replication Server, the interfaces file is important. Because the Replication Server does attempt to log in to the server identified by the server name in the Replication Server connection, that server name must exist in the Replication Server interfaces file. In addition, the interfaces file entry must also exist as a service name in the DirectConnect gateway configuration file entries.
A single DirectConnect can act as a gateway for one or many different database instances. In the DirectConnect configuration, each database to be accessed by the DirectConnect is configured as a unique service name. For DirectConnect to know which configured service name a client wants to connect to, it uses the server name passed at login time and expects to find a matching service name to use to complete the connection. Not only must the Replication Server server_name in the connection match an interfaces file entry, but that interfaces file entry must match the DirectConnect service name describing the database you want to connect to. For more information on the role of service names and their configurations, refer to the DirectConnect Access Service User's Guide.
A single Replication Server connection can support both a DirectConnect gateway and a Replication Agent, because each of these components connects to the Replication Server on a different thread. If you replicate information both into and out of the same database, having a common connection for both a database gateway and a Replication Agent can make the replication system network topology simpler. On the other hand, because the Replication Agent and the DirectConnect gateway are two separate servers, it might be more intuitive to have a separate connection for each one.
To share a Replication Server connection between a DirectConnect gateway and a Replication Agent, you must define the connection to correctly support the replicate database, then configure the Replication Agent appropriately:
In the Replication Server, use the create connection command to define the server_name and database_name for the connection. The server_name value must match a configured service name in the DirectConnect.
In the Replication Agent, set the value of the rs_source_ds parameter to that server_name, and set the value of the rs_source_db parameter to the desired database_name.
