SAP Landscape Transformation Replication Server (SLT) – A Cost Saving Use Case

[rashi_singal1]

In this blog post we will discuss about using a SAP product, which perhaps is not much talked about any more - SAP Landscape Transformation Replication Server (SLT).  However, from my experience, I think it should still be one you should consider if you want an established and straightforward way of replicating data into HANA – whether for real-time or batch replication.

On one of my project, the customer had previously been reporting directly against their HANA ECC database using Calculation Views using SAP and non-SAP reporting tools.  This meant they required an Enterprise licence for the full ECC instance at a significant cost.

By deciding to stop reporting directly against the main ECC system and using a “sidecar” HANA Enterprise instance with replicated data, it was possible to reduce the overall cost.  The requirement was for simple replication and, as an SLT runtime Licence is included with the HANA Enterprise Licence, this was the recommended choice.

SLT Positioning

A common requirement for businesses using HANA as a reporting database is the need to replicate data into HANA as quickly and as easily as possible to facilitate reporting and decision making.

Often you have data coming from a variety of different sources – both SAP and non-SAP – and you need to balance the needs of the business to get up-to-date data, alongside the impact that data replication can have on your source systems.

This is where SAP Landscape Transformation Replication Server (SLT) comes into its own.  It is a good solution for all HANA customers who need real-time or schedule based replication sourcing from both SAP and non-SAP sources, whether on premise or in the cloud.  Using SLT replication will ensure you provide the business with the right information at the right time whenever or whereever they need it.  There are other tools such as SAP Data Services or HANA Smart Data Integration (SDI) and these need to be evaluated along with the requirements, but SLT (usually) doesn’t carry any extra licencing cost and is reasonably simple to implement and support.

SLT is a long-standing product and has its roots as the real-time data replication tool for SAP HANA since 2010 (DMIS – Data Migration Server 2010).  Over the years, SLT has evolved into a middleware solution that supports change data capture and real-time replication scenarios for SAP Business Warehouse, SAP Data Services, SAP Simple Finance and native DB targets, with the latest version being SLT 3.0 SP03 (DMIS 2018).

Examples of use cases for SLT include:

1. Real-time provisioning of data for operational reporting and dashboards


2. Batch loading of Enterprise data warehouses


3. Reduce admin effort for high frequent master data updates


4. Replicate financial data from SAP and non-SAP ERP systems to SAP Simple Finance.


5. Synchronizing data between two or more SAP ERP systems.


6. Replacing an existing solution with SLT in order to get real-time data replication.

If any of these scenarios seem familiar or useful to you then please read on to understand how SLT works and your options around implementing it.

Features and Benefits of SLT

SLT is highly recommended for Real-Time replication because of the following Features & Benefits:

• It uses a Trigger based approach to transferring data – that means that it captures all updates, inserts, and deletes for a table that has been marked for replication with minimal effect on source system performance.


• It can be configured for both Real Time & Scheduled Data Transfer and can be aligned to multiple use cases.


• It can support and be configured for multiple system connections (1:N and N:1 scenarios).


• It provides data transformation, conversion and filtering capability to allow you to manipulate data before loading to a HANA database.


• It handles all native SAP table formats including Cluster & Pool – something that other technologies will struggle to support.


• SLT is integrated with HANA studio.


• You can monitor data with SAP HANA Solution Manager.


• It supports non-Unicode and Unicode conversion during load/replication.


• Mobile Capability – SLT Replication manager (Mobile Application) can monitor the data replication process and system parameters and it can run anytime, anywhere from a mobile device connected to the internet.

Architecture of SLT:

SLT has a number of different components of SLT that are involved in the flow of data, so let us look at them:

• DB Trigger: records changes to the table


• Logging Table: stores key information for each table


• Read Module: Read Modules read data from Source system and transfer it to SLT, based on the key data stored in the Logging Tables


• Control Module: Used to perform small transformation on the source data. Data from here will be moved to write tables.


• Write Modules:The functionality to write the data to HANA system.

Real time data replication being the main focus of SLT means that data is transferred from a source system to a target system in near real time.  SLT divides this process into two parts:

The Initial Load – Full Load

SLT reads the data and loads the existing data (Transformed if required) from the source system to the target system (the initial load), and the source system creates a logging table for each application table that needs to be replicated.

While the data is still in initial load, SLT starts identifying any changes taking place on the data (with the help of DB Triggers), these changes are then saved to the Logging tables and written to the Target system once the initial load is complete.

The Replication Process

Once the initial load is completed, SLT keeps on monitoring the Source System logging tables and performs real time replication of changed data (inserts, updates and deletes) from the source system to the target system.  As changes are held in logging tables in the source system, if the connection between SLT and the source system breaks, or SLT is taken down, when connectivity/SLT is restored, replication will pick up where it left off.

Installation Approaches

There are different implementation scenarios possible with SLT. SLT can be installed either as a standalone system (on SAP NetWeaver based system with DMIS add-on) or on top of an existing SAP system. To understand more about the implementation scenarios and their differences let’s review them one by one.

SLT installed on Source System

SLT can be installed on the source system only if the Source system is SAP ABAP based.

Pros/Cons of this approach:

• Pro – simplified landscape and administration


• Con – software maintenance dependencies will impact Performance


• Con – multi system support will have a high impact on the performance

SLT as a Standalone System.

Here SLT has its own dedicated application server (with the DMIS add-on, on SAP NetWeaver based source system).

Pros/Cons of this approach:

1. Pro – no software dependencies.


2. Pro – flexibility


3. Con – investment and maintenance effort for separate server / SAP NetWeaver instance

Note: While each approach has its Pros and Cons, the best practice recommendation is to install SLT as a Stand-alone system where possible.  This is because a dedicated server for SLT will minimize the impact on the source and target systems.

Installing (and using) the SAP LT Replication Server in the target system is only recommended If the use case is to only replicate data into SAP Central Finance and SAP Landscape Transformation Replication Server is used as part of the target S/4HANA system

Project Learning

Before implementing SLT there are few things that you should consider which could potentially affect the performance:

• Sizing the SLT system and target database appropriately to avoid resource constraints.


• Impact on and sizing the source system (extra dialog processes and assessing any extra processing needed for the triggers).  Disk space is a factor but it is not a large extra footprint.


• Network Bandwidth across systems – this is a key one and can delay both the initial load and increase replication latency.

Conclusion

Overall SLT is an effective, easy to use, low maintenance tool to tap into SAP data and replicate it to HANA for fast analytics and data processing.  It is a proven solution for simple and easy data replication, which can break open some of the uglier parts of SAP data models, for example it can read data from both Pool and Cluster tables very easily.

You should consider using SLT over other Data Replication products if you want to quickly transfer data in near Real-Time and do not require complex data transformations.

Supporting documentation and information.

https://help.sap.com/viewer/product/SAP_LANDSCAPE_TRANSFORMATION_REPLICATION_SERVER/3.0.03/en-US

https://www.sap.com/uk/products/landscape-replication-server.html

https://launchpad.support.sap.com/#/notes/1605140  (SLT central note)

https://launchpad.support.sap.com/#/notes/2014562  (FAQ- SLT)

https://launchpad.support.sap.com/#/notes/2707835 (SLT Licensing)

 

I hope this blog post has helped you understand SLT better. Thank you very much for reading it; please provide your valuable feedback, and if you have any questions, please contact me.

Please note that this blog post was first published at

https://nttdata-solutions.com/uk/local-blog/sap-landscape-transformation-replication-server-slt-a-co....