Explain HANA Data Provisioning: SLT, SDI & Smart Data Access in SAP

44 / 65

HANA DBintermediate

HANA Data Provisioning: SLT, SDI & Smart Data Access

Real-time and batch data replication techniques for feeding HANA from source SAP and non-SAP systems.

Getting data into HANA from elsewhere has three standard answers. They differ on one question: how much do you copy?

SLT is like a live news wire service continuously feeding fresh updates from an SAP source into HANA's newsroom as they happen; SDI is a general wire service that can pull stories from many different outside sources, not just SAP; Smart Data Access is picking up the phone and asking a remote correspondent for the story on demand each time you need it, rather than keeping any copy of it in your own newsroom at all.

Key Concepts

SLT — real-time replication from SAP systems. SAP Landscape Transformation Replication Server puts triggers on the source tables. Every insert, update and delete is captured and applied to HANA within seconds.

    source table --trigger--> logging table --> SLT --> HANA table

It is configured and monitored in LTRC. One setup covers both the initial full load and the ongoing delta.

LTRC

This is the standard way to feed BW/4HANA or a side-by-side reporting system from ECC or S/4HANA. No nightly extract window is needed.

The cost falls on the source. Triggers add work to every write on a replicated table, so replicating a busy table is not free for the system you are reading from.

SDI — broader ETL, including non-SAP sources. Smart Data Integration provides HANA-native adapters for other databases, files and applications. Where the source supports it, there is change data capture too.

Use it when the source is not an SAP ABAP system, or when the data needs real transformation rather than a straight copy.

SDA — do not copy at all. Smart Data Access creates a virtual table. The query is forwarded to the remote system when it runs:

    SELECT * FROM virtual_table WHERE x = 1
    -> runs on the remote system; results come back

Nothing is stored. Nothing can be stale. There is no pipeline to operate.

The catch is speed. Every query is as fast as the remote system and the network allow. A join between a virtual table and a large local one can drag a lot of data across.

Choosing.

    SLT   SAP source, low latency needed         copies data
    SDI   non-SAP sources, or transformation     copies data
    SDA   queried rarely, duplication unwanted   copies nothing

Real landscapes mix them. SLT replicates the few high-volume tables reporting depends on. SDA federates a reference table read once a week, because a full pipeline for that is not worth operating.

The question underneath all three. Each trades freshness against load on the source and operational complexity. There is no default — only the latency you need and the load the source can carry.

What the interviewer is probing.1. "When do you use SLT versus SDA?" Probing: the fit. Stalls: "They are the same." *Moves up:* SLT replicates data in real time by reading database triggers; SDA leaves the data remote and queries it virtually.

2. "What is the cost of a virtual table?" Probing: the trade. Stalls: "None." Moves up: every query crosses to the remote source, so performance depends on that system and on how much the optimiser can push down.

3. "What does SDI add over SDA?" Probing: the distinction. Stalls: "Nothing." Moves up: adapters, transformation and replication through flowgraphs, so it covers batch and real-time movement rather than only federation.

4. "Which would you pick for a daily report over a legacy system?" Probing: the practical call. Stalls: "SLT." Moves up: often SDA or a scheduled flowgraph — real-time replication costs source-system overhead that a daily report does not justify.