SAP HANA as a Source

Overview

This page provides the required information for setting up replications using SAP HANA as a source connection.

Syniti Replicate supports use of SAP HANA for:

• Refresh replications.

• Mirroring replications. For source connections, Syniti Replicate offers Triggers-based replication options.

Enable a Refresh replication in SAP HANA

Refresh is a batch replication executed once, based on the time setting specified in the Scheduling screen.

Permissions

When setting up replications that use SAP HANA as a source database, you need to be sure that the user ID used for making connections to the database has sufficient privileges to complete all the operations required for Syniti Replicate to perform a replication.

The following two user permissions are required when using SAP HANA as a Source in Refresh (Snapshot) mode:

• AUTHORITY TO CONNECT TO DATABASE: This should already be granted when the user is created.

• AUTHORITY TO SELECT TABLES: Syniti Replicate runs a SELECT statement to identify records to replicate. Therefore, the user ID used to make a connection must have adequate authority to run a SELECT statement for tables involved in replication. The command is not needed if the user is the owner of the table (i.e., created the table.)

Enable a Triggers-based replication in SAP HANA

A database trigger is code that is automatically executed in response to certain events on a database table. To define a trigger-based replication (mirroring or synchronization), you need to provide information in the Source and/or Target Connection wizards so that triggers can be created to log table changes for replication.

For each table involved in the replication, Syniti Replicate creates 3 triggers in the source table that fire when a specific event occurs on a record:

• INSERT trigger which fires when a new record is being inserted in the table

• UPDATE trigger which fires when a record is modified

• DELETE trigger which fires when a record is deleted

If the replication is later deleted, the triggers are removed by Syniti Replicate. However, note that if you change a replication from mirroring to refresh, the triggers on the source table are not deleted. All transactions will continue to be recorded in the log tables. If you are not planning to reset the replication to mirroring, it is better to delete the replication, so that the triggers are removed, and create a new refresh replication.

Permissions

This section includes information on the minimum permissions needed to set up and run mirroring where triggers are used to identify changed data.

This section includes information on the minimum permissions needed to set up and run mirroring where triggers are used to identify changed data. For precise details on syntax for SAP HANA, check the following resources:

CREATE USER FOR SYNITI REPLICATE OPERATIONS  

The DBA should create a user for Syniti Replicate operations on the database. The user ID you are planning to use should have sufficient permissions to complete all operations in Syniti Replicate: permissions to connect, select tables, insert/update/delete records and so on.

1. AUTHORITY TO SELECT TABLES

Syniti Replicate runs a SELECT statement to identify records to replicate. Therefore, the user ID used to make a connection must have adequate authority to run a SELECT statement for tables involved in replication. The command is not needed if the user is the owner of the table (i.e., created the table.)

2. AUTHORITY TO CREATE AND DROP TRIGGERS

To set up transactional replications, you need permission to create triggers in the schema where the source data table resides.

3. AUTHORITY TO CREATE AND DROP SEQUENCES

You need permission to create sequences as part of the setup of the Syniti Replicate master table.

4. AUTHORITY FOR AN EXTERNAL USER TO WRITE TO THE TRIGGER SCHEMA

When triggers are executed (following an INSERT, UPDATE or DELETE by an external user), the external user ID requires write access to the trigger schema (which contains the master table and the log tables.) GRANT INSERT ON SCHEMA TO GRANT SELECT ON TO where: is the schema used for the master table is any possible user that will run DML commands to the replicated tables. is the sequence defined with the master table. The sequence name is generated from the master table name using the suffix "_SEQ": _SEQ.

CREATE ROLE <your_role>;
GRANT CREATE TRIGGER, USAGE ON SCHEMA <schema_name> TO <your_role>;
GRANT SELECT ON ALL TABLES IN SCHEMA <your_schema> TO <your_role>;
GRANT INSERT, UPDATE, DELETE ON SCHEMA <your_schema> TO <your_role>;
--Assign role to user
GRANT <your_role> to <your_user>;

For more information on Triggers-based replication, refer to Triggers.