SLT and SDA in SAP HANA

SAP HANA provides various methods for data provisioning, allowing you to bring data into the in-memory database for real-time analytics and applications.¹ Two prominent technologies for this are SAP Landscape Transformation (SLT) Replication Server and SAP HANA Smart Data Access (SDA). While both deal with data, they serve different primary purposes and have distinct characteristics.

Let's delve into their configurations, setup, differences, and similarities in the context of SAP HANA.

SAP Landscape Transformation (SLT) Replication Server

Purpose: SLT is primarily designed for real-time or near real-time data replication from various source systems (SAP and non-SAP databases) into SAP HANA.² It's ideal for scenarios where you need the most up-to-date transactional data for operational reporting, analytics, or driving real-time applications.³

Design and Architecture:

Trigger-Based Replication: SLT works on a trigger-based approach.⁴ When you configure replication for a table, SLT creates database triggers and logging tables in the source system.⁵ Any INSERT, UPDATE, or DELETE operation on the source table is captured by these triggers and recorded in the logging tables.⁶
SAP NetWeaver ABAP Stack: The SLT Replication Server itself runs on an SAP NetWeaver ABAP stack. This can be:
- Standalone SLT System: A dedicated ABAP system for SLT, which is recommended for complex landscapes or when replicating from multiple diverse sources.⁷
- Embedded in Source System: For ABAP-based source systems (like ECC, S/4HANA), SLT can be installed directly on the source system's ABAP stack, simplifying the architecture.
Components:
- Source System (SAP ABAP/Non-SAP DB): Contains the original data, triggers, and logging tables.
- SLT Replication Server: The central component that manages the replication, reads changes from logging tables, performs transformations (if configured), and writes data to the target HANA system.⁸ It contains control, read, and write modules.⁹
- Target System (SAP HANA): The database where the replicated data resides.
Connectivity:
- Source (SAP ABAP): Connects via RFC connection.¹⁰
- Source (Non-SAP DB): Connects via standard database connection (e.g., ODBC, JDBC).
- Target (SAP HANA): Connects via a database connection (e.g., HANA ODBC client).¹¹

Critical Configurations and Setup Steps:

Prerequisites:
- SLT Installation: Install the SLT Replication Server on a suitable SAP NetWeaver ABAP system (either standalone or embedded).¹² Ensure the correct DMIS (Data Migration and Integration Server) add-on version is installed and up-to-date with relevant SAP Notes.
- HANA Client: Install the SAP HANA database client software on the SLT system to enable connectivity to HANA.
- Authorizations: Ensure the necessary users have appropriate authorizations in the source system (for trigger creation, table access), SLT system (for configuration and replication), and target HANA system (for table creation and data insertion).¹³
- Network Connectivity: Verify network connectivity and open necessary ports between the source, SLT, and target HANA systems.
Configuration on SLT Server (Transaction LTRC - SLT Cockpit):
- Create Configuration:
  - Open LTRC (or LTR for older versions).¹⁴
  - Click "Create Configuration" to start a wizard.
  - Specify Configuration Name & Description.
  - Source System Connection:
    - For SAP ABAP source: Provide the RFC destination to the source system.¹⁵ Specify the source client and ensure "Allow Multiple Usage" is selected if this source will be used for multiple configurations.
    - For Non-SAP source: Provide the database connection details (DB type, host, port, credentials).
  - Target System Connection: Provide the database connection details for the target SAP HANA system (HANA DB name, host, port, user, password).¹⁶
  - Replication Options (Performance Settings):
    - Initial Load Mode: "Resource Optimized" (loads data in smaller chunks) or "Performance Optimized" (faster but consumes more resources).¹⁷
    - Number of Data Transfer/Initial Load/Calculation Jobs: Crucial for performance tuning. These correspond to dialog work processes in the source/SLT system. Sizing guidelines should be followed.
    - Schema Name: Specify the target schema in HANA where tables will be replicated.
- Review and Confirm: Complete the wizard.
Start Replication (in LTRC):
- Once the configuration is active, navigate to the "Data Provisioning" tab in LTRC.¹⁸
- Select the tables you wish to replicate.
- Choose one of the following:
  - Load: Performs an initial load of data from source to target. No ongoing replication.
  - Replicate: Performs an initial load AND sets up ongoing real-time replication (triggers and logging tables are created).
  - Stop Replication/Load: Stops the process and removes triggers/logging tables.¹⁹
  - Suspend/Resume: Temporarily pauses/resumes replication without deleting the setup.²⁰
Transformation Rules (Optional):
- SLT allows for basic transformations during replication (e.g., filtering rows, transforming column values, changing table structures).²¹
- This is done via Rule Assignment in LTRC or by writing ABAP routines.
Monitoring (LTRC):
- Monitor the status of replication, jobs, and any errors within the LTRC cockpit.
- Check source system logs (SM21, ST22) and SLT system logs for issues.

SAP HANA Smart Data Access (SDA)

Purpose: SDA enables virtual real-time access to data residing in remote databases without physically replicating or loading the data into SAP HANA.²² It allows you to create virtual tables in HANA that point to tables in external sources. Queries against these virtual tables are then pushed down to the remote database for execution.

Design and Architecture:

Virtualization: SDA's core concept is data virtualization. Data remains in its source system, and HANA accesses it on demand.
Adapters: SDA uses specific adapters (drivers) to connect to various external data sources. These adapters enable HANA to understand the data structures and query capabilities of the remote database. Examples include HANA (for connecting to other HANA systems), Oracle, SQL Server, Teradata, Hadoop, etc.
No Data Movement (Default): By default, SDA does not copy or move data.²³ It acts as a gateway.
Query Pushdown: A key feature of SDA is query pushdown. When a SQL query is executed against a virtual table in HANA, the HANA optimizer analyzes the query and pushes down as much of the processing (filtering, joining, aggregation) as possible to the remote database. This minimizes data transfer and leverages the processing power of the source system.

Critical Configurations and Setup Steps:

Prerequisites:
- HANA System: You need an SAP HANA database (on-premise or cloud).
- Database Client/Drivers: Install the appropriate ODBC/JDBC drivers (and sometimes the specific remote database client) on the SAP HANA server for the external database you want to connect to.²⁴ This is crucial for the HANA SDA adapters to communicate. (e.g., Oracle client for Oracle database, SQL Server ODBC driver for SQL Server).
- Network Connectivity: Ensure network connectivity and open necessary ports between the SAP HANA server and the remote database.
- Authorizations: The HANA user creating the remote source needs CREATE REMOTE SOURCE privilege.²⁵ The user defined in the remote source credentials must have sufficient SELECT privileges on the tables/schemas in the remote database.
Configure ODBC/JDBC Drivers on HANA Server (OS-level):
- For many non-HANA remote sources, you need to configure the odbc.ini file (on Linux) or other client configurations to define the DSN (Data Source Name) for the remote database.
- Ensure the LD_LIBRARY_PATH environment variable (Linux) is correctly set to include the paths to the installed database drivers.
- Restart the HANA database instance after driver installation/configuration.
Create Remote Source in SAP HANA (using SQL Console or HANA Studio/DB Explorer):
- This is the core configuration step for SDA.
- SQL Console (Recommended):
  SQL
  CREATE REMOTE SOURCE "<remote_source_name>" ADAPTER "<adapter_name>" -- e.g., 'hanaodbc', 'oracle', 'sqlserver', 'teradata', 'hadoop' CONFIGURATION ' <connection_properties_specific_to_adapter> -- Examples: -- For hanaodbc: 'ServerNode=<source_host>:<source_port>;Driver=libodbcHDB.so' -- For Oracle: 'Driver=<path_to_oracle_driver>;ServerName=<tns_entry_name>' -- For SQL Server: 'DSN=<dsn_name>' ' WITH CREDENTIAL TYPE 'PASSWORD' USING 'user=<remote_db_user>;password=<remote_db_password>';
- HANA Studio/Database Explorer: Navigate to "Provisioning" -> "Remote Sources", right-click and select "New Remote Source". Fill in the GUI fields:
  - Source Name: A logical name for your remote connection.
  - Adapter Name: Select the appropriate adapter from the dropdown (e.g., HANA (ODBC), Oracle, Microsoft SQL Server).
  - Configuration Properties: Enter specific details like hostname, port, database name, DSN, etc., depending on the chosen adapter.
  - Credentials: Provide the username and password for connecting to the remote database.
Create Virtual Tables in SAP HANA:
- Once the remote source is established and verified, you can create virtual tables in your HANA schema.²⁶
- SQL Console:
  SQL
  CREATE VIRTUAL TABLE <schema_name>.<virtual_table_name> AT "<remote_source_name>"."<NULL>"."<remote_schema_name>"."<remote_table_name>";
- HANA Studio/Database Explorer: Expand the remote source, navigate to the desired schema/table, right-click the remote table, and select "Add as Virtual Table".
Querying Virtual Tables:
- You can now query these virtual tables just like local HANA tables using standard SQL. The HANA optimizer handles the pushdown.

Differences between SLT and SDA

Feature	SAP SLT Replication Server	SAP HANA Smart Data Access (SDA)
Primary Use Case	Real-time data replication (copying data) to HANA.	Virtual data access (no data copying) from remote sources.
Data Location	Data is physically moved and stored in SAP HANA.	Data remains in the source system; accessed on demand.
Latency	Near real-time replication with minimal latency.	Real-time access, but query execution depends on remote system speed.
Data Movement	Yes, continuous data flow from source to target.	No, data is not physically moved (only results of queries).
Source Impact	Creates triggers and logging tables on the source DB, which might have a minor performance overhead.	Minimal to no direct impact on source DB (just query execution).
Data Volume	Suitable for large volumes of transactional data where persistence in HANA is desired.	Better for smaller result sets or when data freshness is paramount and source data volume is not excessively large.
Transformations	Offers basic transformations during replication (filtering, column manipulation, rule-based).	Primarily for direct data access. Complex transformations usually happen after data is accessed in HANA (e.g., via Calculation Views).
Architecture	Runs on an ABAP stack (standalone or embedded).	Part of the HANA database engine, uses adapters to connect.
Data Type Support	Supports a wide range of SAP and non-SAP data types.	Relies on adapter capabilities; might have limitations for certain complex data types or custom types.
Offline Access	Data is in HANA, so it's available even if the source is offline (after replication).	Requires the source system to be online for data access.
Historical Data	Can easily capture and store historical changes in HANA.	Accesses current state of data. Historic states are not preserved by SDA itself.

Similarities between SLT and SDA

Data Integration: Both are methods for integrating external data into the SAP HANA ecosystem.
Real-time Focus: Both are geared towards providing timely data. SLT through replication, SDA through direct virtualization.
SAP HANA Context: Both are core features of SAP HANA for data provisioning.
Support for Diverse Sources: Both can connect to a variety of SAP (like ECC, S/4HANA) and non-SAP databases (Oracle, SQL Server, etc.).
Performance Considerations: Both require careful planning and monitoring to ensure optimal performance. Incorrect configuration can lead to bottlenecks.
Security: Both require proper user authorizations and secure network communication setup.
Managed by SAP Basis/HANA Admin: Configuration and monitoring of both technologies fall under the purview of SAP Basis and HANA administration teams.

When to Use Which?

Use SLT when:
- You need to physically move and store the data in HANA for high-performance analytics, reporting, or transactional applications.
- You need continuous, real-time updates of transactional data.
- You want to leverage HANA's in-memory capabilities for complex calculations and aggregations on a full dataset.
- The source system is an SAP ABAP system, allowing for simplified setup.
Use SDA when:
- You need to access data that frequently changes or is very large, but you don't want to replicate all of it to HANA (e.g., historical archives, external master data).
- You want to combine data from HANA with data from external sources without physically moving the external data.
- You want to leverage the processing power of the remote database for initial query execution (query pushdown).
- Data latency is critical, and the source system can handle the direct query load.
- You want to avoid storage costs in HANA for data that is not frequently accessed or is not a core part of your HANA data model.

In many complex scenarios, SLT and SDA (and even Smart Data Integration - SDI, which builds on SDA's capabilities for more advanced transformations and real-time streaming) are used together to create a comprehensive data integration strategy for SAP HANA.

Rakshit Ranjan Singh

Search This Blog