What is SLT in SAP HANA? Replication & Configuration

โšก Smart Summary

SLT, the SAP Landscape Transformation Replication Server, loads and replicates data into SAP HANA in real time or on a schedule. A trigger based approach captures changes from SAP and non-SAP sources alike.

  • โšก Core Method: Trigger based replication passes data from source to target in real time or at scheduled intervals.
  • ๐Ÿ–ฅ๏ธ Deployment: The SLT server runs on a separate system or directly on the SAP ECC system.
  • ๐Ÿ”Œ Connections: RFC links SLT to an SAP source; a database connection links SLT to SAP HANA.
  • ๐Ÿงฑ Cluster Support: SLT handles cluster and pool tables, which simpler replication tools cannot.
  • ๐Ÿ”ค Encoding: Unicode and non-Unicode conversion is applied automatically during load and replication.
  • โš™๏ธ Configuration: Transaction LTR creates the configuration, which generates a schema, user, roles, and control tables in HANA.
  • ๐ŸŽ›๏ธ Five Actions: Load, Replicate, Stop Replication, Suspend, and Resume control each table individually.

SAP SLT in HANA

What is SLT (SAP Landscape Transformation Replication)?

SLT is the an ETL tool that allows you to load and replicate data in real-time or schedule data from SAP source system or Non SAP System into SAP HANA Database.

SAP SLT server uses a trigger-based replication approach to pass data from source system to target system.

SLT server can be installed on the separate system or on SAP ECC System.

Benefit of SLT system is as below-

  • Allows real-time or schedule time data replication.
  • During replicating data in real-time, we can migrate data in SAP HANA Format.
  • SLT handles Cluster and Pool tables.
  • This support automatically non-Unicode and Unicode conversion during load/replication. (Unicode is a character encoding system similar to ASCII. Non-Unicode is encoding system covers more character than ASCII).
  • This is fully integrated with SAP HANA Studio.
  • SLT have table setting and transformation capabilities.
  • SLT have monitoring capabilities with SAP HANA Solution Manager.

The trigger based design is what makes real time possible. A database trigger on the source table writes every change into a logging table, which SLT then reads and applies, rather than repeatedly scanning the whole table for differences.

SAP SLT Connection Architecture Overview

Architecture Overview of SAP SLT server with SAP / Non-SAP System is as below-

SAP SLT Connection between SAP System and SAP HANA

SAP SLT Replication Server transforms all metadata table definitions from the ABAP source system to SAP HANA.

For SAP source, the SLT connection has the following features –

  • When a table is replicated, SAP SLT Replication server create logging tables in the source system.
  • Read engine is created in the SAP Source System.
  • The connection between SAP SLT and SAP Source is established as RFC connection.
  • The connection between SAP SLT and SAP HANA is established as a DB connection.

A database user with the same authorization as user “SYSTEM” can create a connection between SAP SLT and SAP HANA Database.

SAP SLT Connection between SAP System and SAP HANA DATABASE
SAP SLT Connection between SAP System and SAP HANA DATABASE

SAP SLT Server automatically create DB connection for SAP HANA database (when we create a new configuration via transaction LTR). There is no need to create it manually.

Configure SAP SLT Server for SAP Source System

First we need to configure SAP SLT replication server for connection between SAP Source and SAP HANA database. T-code, LTR is used for creating a connection between SAP Source and SAP SLT.

Step 1) Login to SAP SLT server, and Call transaction “LTR” from SAP SLT replication server.

Configure SAP SLT Server

A Web-dynpro pop-up screen will appear for login to SAP SLT server.

  1. Enter Client / User id / password
  2. Click on logon tab

Configure SAP SLT Server

A pop-up screen for Configuration will appear as below-

Configure SAP SLT Server

Click on “New” Button for the new configuration.

Step 2) In this step,

  1. Enter Configuration name and description.
  2. Select SAP System as the source system.
  3. Enter RFC connection for SAP System.
  4. Enter Username / Password / Host Name and Instance number.
  5. Enter Job options detail โ€“ number of data transfer jobs and number of calculation jobs.
  6. Select Replication option as Real Time.
  7. Once all the settings are maintained click on ‘OK’ to create a new schema in SLT.

Configure SAP SLT Server

A Configuration Name “SLTECC” will be added and active.

Configure SAP SLT Server

After configuration SAP SLT server successfully, SAP SLT Server automatically create DB connection for SAP HANA database (when we create a new configuration via transaction LTR). There is no need to create it manually.

In next step, we import data to SAP HANA from SAP Source.

Import SAP Source Data to SAP HANA through SLT

Once we have successfully configured SAP SLT server, a SCHEMA as configuration name above in SAP SLT is created in SAP HANA Database.

This Schema contains following objects-

  1. 1 Schema – SLTECC.
  2. 1 User โ€“ SLTECC.
  3. 1 Privileges
  4. 8 Tables โ€“ DD02L (SAP Tables Name), DD02T (SAP Table Texts), RS_LOG_FILES, RS_MESSAGE, RS_ORDER, RS_ORDER_TEXT, RS_SCHEMA_MAP, RS_STATUS.
  5. 4 Roles โ€“ SLTECC_DATA_PROV, SLTECC_DATA_POWER_USER, SLTECC_DATA_USER_ADMIN, SLTECC_DATA_SELECT.
  6. 2 Procedures โ€“ RS_GRANT_ACCESS, RS_REVOKE_ACCESS.

All configuration is completed, now we load a table from SAP ECC (ERP Central Component).

Step 1) To load tables from SAP ECC to SAP HANA database, follow below steps-

  1. Go to Data provisioning from Quick View.
  2. Select SAP HANA System.
  3. Click on Finish Button.

Import SAP Source Data to SAP HANA

Step 2) A screen for SLT Based Table Data Provisioning will be displayed. There are 5 options for data provisioning as below-

Provision Option Detail
Load (Full Load) This is a one-time event, which starts an initial load of data from source system.
Replicate (Full Load + Delta Load) It start initial load (if not done earlier), and also consider delta change. Database trigger and related logging table will be created for each table.
Stop Replication It stops the current replication process for a table. It removes database trigger and logging table completely.
Suspend It pause a running replication process of a table. The database trigger will not be deleted from the source system, and recording of changes will continue. Related Information is stored in the related logging table in the source system.
Resume Resume restarts the replication for a suspended table. After resume, the suspended replication process will resume.

โš ๏ธ Warning: Suspend and Stop Replication are not interchangeable. Suspend keeps the trigger and the logging table, so changes accumulate and are applied on resume. Stop deletes both, so every change made while stopped is lost and a full reload is required.

We use the first option from the table “Load option” for initial load of the table (LFBK) data from source to SAP HANA table.

Step-by-step is as below-

  1. Source and Target system details are selected according to SAP SLT configuration.
  2. Click on Load Button and select the table (LFBK) which we need to load/replicate in SAP Hana.
  3. Table (LFBK) will be added to Data Load Management Section with Action “Load” and Status “Scheduled.”

Import SAP Source Data to SAP HANA

After data load, Status will be changed to “Executed”. The table will be created in “SLTECC” schema with data.

Step 3) Check Data in the table (LFBK) by Data Preview from Schema “SLTECC” as below –

  1. Login in SAP HANA Database through SAP HANA Studio and select SAP HANA System HDB (HANAUSER).

Import SAP Source Data to SAP HANA

  1. Select Table (LFBK) under Table node.
  2. Right click on Table (LFBK) and click on Open data preview option.
  3. Loaded Data through SLT process will be displayed in Data preview screen.

Import SAP Source Data to SAP HANA

Now we have successfully loaded data in table “LFBK”. We will use this table future in Modelling.

SAP SLT Connection between non-SAP System and SAP HANA

SAP SLT Replication Server transforms all metadata table definitions from the non-ABAP source system to SAP HANA.

For Non-SAP source, the SLT connection has following features –

  • When a table is replicated, SAP SLT Replication server create logging tables in the source system.
  • Read engine is created in the SAP SLT Replication server.
  • The connection between SAP SLT and SAP Source / SAP HANA is established as a DB connection.
SAP SLT Connection between non-SAP System and SAP HANA

SAP SLT Connection between Non-SAP System and SAP HANA System/DATABASE

SAP SLT can only do simplest transformations, so for complex transformations, we need another ETL tool such as SAP Data services.

The single architectural difference is worth noting: for an SAP source the read engine sits in the source system and the link is RFC, whereas for a non-SAP source the read engine sits on the SLT server itself and both links are database connections. Everything downstream behaves identically.

SLT vs Other Replication Methods

SLT is one of several routes into SAP HANA, and its distinguishing feature is latency rather than transformation power.

Parameter SLT SAP Data Services DXC
Latency Real time or scheduled Batch Batch
Mechanism Database triggers and logging tables Scheduled ETL jobs Business Suite extractors
Source systems SAP and non-SAP databases Almost any source SAP Business Suite only
Transformation Simple rules only Rich graphical transformations Applied by the extractor
Cluster and pool tables Handled natively Requires extra work Handled by the extractor
Extra landscape An SLT server A Data Services landscape None

Where transformation matters more than latency, SAP Data Services is the better fit, and where the extractor logic already exists, DXC avoids a server entirely. The full comparison sits in the data provisioning tutorial.

SLT Monitoring and Troubleshooting

Because replication runs continuously, problems are usually noticed as stale data rather than as an error message. These checks find the cause quickly.

  1. Check the configuration in LTR first. The overview shows each configuration with its status and the number of tables in each state. A configuration in error stops every table beneath it.
  2. Use transaction LTRC for detail. The Load Statistics and Data Transfer Monitor tabs show throughput per table and reveal which one is lagging.
  3. Watch the logging table size. A logging table growing steadily means changes are being captured but not applied. This usually points at too few data transfer jobs.
  4. Tune the job counts. Data transfer and calculation jobs were set during configuration. Too few and replication falls behind; too many and the source system suffers. Adjust in LTR rather than guessing at the source.
  5. Investigate a table stuck in Scheduled. No free background work process on the SLT server is the usual reason, not a fault in the table.
  6. Never drop a replicated table in HANA. The trigger in the source keeps writing to a logging table with no consumer. Stop replication properly first, which removes the trigger.
  7. Review RS_STATUS and RS_MESSAGE. These control tables in the generated schema record what SLT itself believes about each table.

The most expensive mistake is replicating tables nobody needs. Every replicated table carries a trigger on the source system, so an unused replication imposes a permanent cost on the transactional system it reads from.

FAQs

Suspend keeps the trigger and logging table, so changes accumulate and are applied on resume. Stop deletes both, so changes made while stopped are lost and a full reload follows.

A separate server isolates replication load from the transactional system and is preferred for high volume. Installing on ECC saves a system and suits smaller landscapes.

AI reviews which replicated tables are actually queried and flags those consuming triggers and memory for no benefit, which reduces load on the source system.

Yes. Monitoring logging table growth against apply rate predicts a widening lag, allowing job counts to be increased before reports start showing stale figures.

Only simple rules such as filtering rows or converting a field. Anything involving lookups, cleansing, or combining sources belongs in SAP Data Services instead.

Summarize this post with: