All Sybase ECDA Options provide basic connectivity to non-ASE data services. In particular, they provide access management, copy management, and remote systems management. Each ECDA Option consists of a DirectConnect server and one or more access service libraries. The server provides the framework in which the service libraries operate. From the server, each access service library accesses data from a particular target database, such as DB2 UDB, Microsoft SQL Server, or Oracle.
Each access service library contains one or more access services that are specific sets of configuration properties. An access service transfers data between Replication Server and the target databases.
The DirectConnect server listens for, validates, and accepts incoming client connections, such as language events or remote procedure calls (RPCs). These events are routed to the target data source (replicate database) through access services, which provide target-specific
connectivity features, including datatype conversion, network connectivity, and SQL transformation.
Interface File
The interface file contains a list of labels, typically server names, each of which has a corresponding host name and port number, where the identified server should be “listening” for login requests.
Replication Server is an Open Server application; the preferred method for determining the location (host and port number) of another Open Server application is to look up the location in a file.
In the interaction between an ECDA database gateway and a Replication Server, the interface file is important. Because the Replication Server attempts to log in to the service identified by the server name in the Replication Server connection, that service name must exist in the Replication Server interface file. In addition, the interface file entry must also exist as a service name in the ECDA gateway configuration file entries.
A single ECDA can act as a gateway for one or many different database instances. In the ECDA configuration, each database to be accessed by the ECDA is configured as a unique
service name. For the Replication Server to know which configured service name 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. The connection must match an interface file entry. For Microsoft SQL Server, the database name must be a valid database for that service. For more information about the role of service names and their configurations, see the ECDA Access Service Users Guide.
Connection Shared by Replication Agent and ECDA
A single Replication Server connection can support both an ECDA 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 less resource intensive.
To create a Replication Server connection to a database that is both primary and replicate, you must define the connection to correctly support the ECDA database gateway, 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 ECDA.
• 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.
To use direct-load materialization, you must have two database connections: one for incoming data and one for outgoing data. You must create the connection for incoming data—which is used by Replication Agent—using the appropriate connection profile
(rs_rs_to_<replicate>_ra, where <replicate> is oracle, mssql, udb, or hanadb). Use a connection profile supporting normal replication to create the connection for outgoing data.
ECDA Database Gateways
ECDA database gateway applies transactions from a Replication Server to a non-ASE replicate database in a Sybase replication system.
To accomplish this, Replication Server logs in to the ECDA 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 an ECDA 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.
• 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.
• Replication Server provides connection profiles to set up the tables and functions required for a replicate database in DB2 UDB, HANA DB, Microsoft SQL Server, and Oracle databases.
For an overview of the expectations of a replicate data server and gateway, see Replication Server Design Guide > Data Replication into Non-Adaptive Server Data Servers. • Datatype representations must be translated to match the native datatypes of the replicate
database. Replication Server provides connection profiles to set up the function strings, function-string classes, and base datatype definitions and translations necessary to support replication into DB2 UDB, Microsoft SQL Server, and Oracle data servers.
• The Replication Server command resume connection attempts to initiate activity with the DSI thread of the specified connection. For an ECDA, this is 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.