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.

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 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.
A Web-dynpro pop-up screen will appear for login to SAP SLT server.
- Enter Client / User id / password
- Click on logon tab
A pop-up screen for Configuration will appear as below-
Click on “New” Button for the new configuration.
Step 2) In this step,
- Enter Configuration name and description.
- Select SAP System as the source system.
- Enter RFC connection for SAP System.
- Enter Username / Password / Host Name and Instance number.
- Enter Job options detail โ number of data transfer jobs and number of calculation jobs.
- Select Replication option as Real Time.
- Once all the settings are maintained click on ‘OK’ to create a new schema in SLT.
A Configuration Name “SLTECC” will be added and active.
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 Schema – SLTECC.
- 1 User โ SLTECC.
- 1 Privileges
- 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.
- 4 Roles โ SLTECC_DATA_PROV, SLTECC_DATA_POWER_USER, SLTECC_DATA_USER_ADMIN, SLTECC_DATA_SELECT.
- 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-
- Go to Data provisioning from Quick View.
- Select SAP HANA System.
- Click on Finish Button.
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-
- Source and Target system details are selected according to SAP SLT configuration.
- Click on Load Button and select the table (LFBK) which we need to load/replicate in SAP Hana.
- Table (LFBK) will be added to Data Load Management Section with Action “Load” and Status “Scheduled.”
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 –
- Login in SAP HANA Database through SAP HANA Studio and select SAP HANA System HDB (HANAUSER).
- Select Table (LFBK) under Table node.
- Right click on Table (LFBK) and click on Open data preview option.
- Loaded Data through SLT process will be displayed in Data preview screen.
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 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.
- 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.
- Use transaction LTRC for detail. The Load Statistics and Data Transfer Monitor tabs show throughput per table and reveal which one is lagging.
- 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.
- 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.
- 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.
- 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.
- 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.









