SAP HANA Cookbook
上QQ阅读APP看书,第一时间看更新

Using SLT to load data into SAP HANA

SLT stands for SAP Landscape Transformation. We use this technique for real-time replication of the data from source systems—SAP/non-SAP. This method is primarily used for replication from SAP source systems. Apart from real-time replication, we can also use SLT for batch mode loads as well. When the required landscape contains both real-time and batch mode, SLT is the best. This recipe shows us how to load data into SAP HANA using SLT.

Getting ready

In order to load data using SLT, we must first ensure that real-time data loading is required. Also, the exact number of tables that have to be replicated should be known before going for SLT; replicating unnecessary tables involves a higher cost.

How to do it…

We will now see the steps to configure SLT and replicate data in SAP HANA.

SLT configuration – creating a connection

Connections can be created from transaction LTR in the SLT system. This t-code is a browser-based application. Hence, it will take us to the browser where we have to log in again with the SLT system credentials, as shown in the following screenshot:

SLT configuration – creating a connection

After logging in, the Configuration and Monitoring Dashboard for HANA panel will be opened, as shown in the following screenshot. Here, we will have options to create new connections and edit, delete, or check the status of the existing connections.

SLT configuration – creating a connection

Now select New to create a connection. In the next step, the type of source system has to be selected, either SAP System or Non-SAP System. An RFC connection exists between the SAP source system and the SLT server, whereas a DB connection exists between the non-SAP and SLT server, as shown in the following screenshot:

SLT configuration – creating a connection

In the following screenshot, we can see that when we select Non-SAP System as the source, the drop-down menu changes, indicating the Database System.

SLT configuration – creating a connection

The mandatory parameters that have to be given to create a connection with the source system are as follows:

  • Configuration Name: For each connection, whether SAP or non-SAP, a unique name has to be given.
  • RFC Destination: For a SAP system: if the source is a SAP system, an RFC connection exists between the SLT server and SAP source. From the list of available RFC connections, one connection has to be selected. These RFC connections have to be created in t-code SM59 in the same way as you created connections between SAP systems.
  • Database System: For a non-SAP system, a database connection will be created between the source and the SLT server. Different databases that are supported are shown in the preceding screenshot.
  • Connection to HANA System: SAP HANA details—Host Name, Instance Number, User Name, and Password are to be entered. These details are required to connect the SLT server to the target SAP HANA system.
  • No. of Data Transfer Jobs: Data transfer jobs are responsible for replicating data to the SAP HANA system. This can be set depending on the available background jobs in the SLT server.

Once a connection is created, we can see all the details and edit the parameters. The following screenshot shows us the number of jobs running and their connection status:

SLT configuration – creating a connection

These parameters can be changed; we can edit a number of jobs and other options as shown in the following screenshot:

SLT configuration – creating a connection

Each connection will have a unique Mass Transfer ID. In the screenshot, the Mass Transfer ID is 093.

For each connection, jobs will be scheduled in the SLT server. This can be monitored from t-code SM37. Different jobs will be scheduled in the background up on creating a connection. They are given as follows:

  • IUUC_MONITOR_<mass_transfer_id>: This job monitors the status of the system connection. This is the first job that will be created up on creating the connection. This job recreates the other jobs.
  • IUUC_REPLIC_CNTR_xxx_yyyy: This is a replication control job (where xxx and yyyy are digits). Whenever there is a change in logging tables, this job runs and picks up all the data and writes to the SAP HANA system. These jobs will be always in a released state, and they start and complete in seconds. If these jobs run for a long time, that is, for minutes, it indicates that something is wrong or there is a huge amount of data to be transferred to SAP HANA.
  • DTL_MT_DATA_LOAD_xxx_yy: This is a data load job. This job should always be in an active state for data loading to happen. When there are data loading issues, cancelling these jobs will resolve the issues. These jobs will be recreated automatically from IUUC_MONITOR_<mass_transfer_id>.

For each connection created, a unique mass transfer ID will be created. In our example, it is 093. All the background jobs will have this mass transfer ID in the job name, as shown in the following screenshot:

SLT configuration – creating a connection

These are the steps to create a connection with the source system and monitor the status. Now let's see how to load data into SAP HANA using SAP HANA Studio.

From Quick Launch in SAP HANA Studio, select Data Provisioning. Now we will see the available connections in Select Source System and the corresponding schema in the Target Schema Configured list, as shown in the following screenshot. From the available connections, select a connection where data has to be loaded into SAP HANA.

SLT configuration – creating a connection

Here we have five options—Load…, Replicate…, Stop Replication…, Suspend…, and Resume…. Each action has its own prominence. This is as explained as follows:

  • Load: This will dump all the data from the source to SAP HANA. It is a single-time load. Furthermore, if there are any changes or if new data is created in the source system, the changes will not be replicated to SAP HANA. All the data present in the source system table at the time of starting this activity will be loaded into SAP HANA. Triggers and logging tables are not created when we use the Load option. Hence, when a Load option is used, it is recommended to drop all the data in the table and then go with Load. If we load data without dropping it, data will be duplicated.

    Click on Load and search for the table that has to be loaded into SAP HANA. We can select multiple tables at a time and start loading them, as shown in the following screenshot:

    SLT configuration – creating a connection
  • Replicate: This is similar to the Load action, except that Replicate creates triggers and logging tables in the source system. Hence, when there is new data or a change in data, this will be captured in logging tables and replicated to the target SAP HANA table. When we replicate a table, the status of the selected table will be In Process. This means replication is in process and whenever there is new or altered data, this will be loaded to SAP HANA.
  • Stop Replication: This action stops the replication process. This will delete the triggers and logging tables for the selected table. Hence, no more altered or new data will be replicated to SAP HANA. When we stop replication, we have to drop the table content before we select Replicate again, as shown in the following screenshot:
    SLT configuration – creating a connection
  • Suspend: This will stop the replicating process temporarily. Triggers and logging tables will not be deleted, but they just become inactive. All the changes are captured in the logging tables and this can be loaded to SAP HANA using the Resume option, without losing data and compromising data integrity. It is recommended not to suspend loads for a long time, as the size of the logging tables in the source system will increase, which becomes a burden after resuming the loads.
  • Resume: This option will resume data loading from the last suspended state. All the changes captured in the logging tables since the last suspend action will be loaded to SAP HANA upon resuming.

How it works…

SLT can be used for data replication from a SAP or non-SAP source system. The installation of SLT Replication Server depends on the type of source system that we connect with. If the source system is SAP, SLT Replication Server can be installed on a separate SAP system or in the existing SAP system itself, depending on the technical constraints. If the source system is a non-SAP system, SAP Replication Server has to be installed on a separate system. However, it is best to install SLT on a separate machine, as maintenance activities such as upgrades and applying patches will be easier. This avoids impact on the SAP source system when there are software changes in the SLT system.

For data replication, settings have to be maintained. This involves creating connections between the source and target systems. All these configurations have to be made in SLT Replication Server. The configuration details include the source system, target system, and type of connection. We can replicate data from one source to one target system (1:1), for example, the SAP HANA system, from multiple sources to a single target system (N:1), or from one source system to multiple target systems (1:N). Furthermore, we can also specify the nature of the load: either real-time, or scheduled by time or interval.

SLT is a trigger-based approach to loading data, where data is replicated from the application tables of the source system. After the required configurations are done, we can select the tables from SAP HANA Studio for replication. All the data from the table can be loaded, or selective loading is possible by creating transformation rules and filtering data.

The following diagram shows us how the architecture will look if SLT is configured on the same server on which SAP ECC is installed.

How it works…

As explained earlier, installing SLT on a separate server is always recommended as maintenance becomes easy. The following diagram shows us the architecture if SLT is installed on a separate server, connecting SAP ECC and SAP HANA:

How it works…

Having seen the architecture of the SLT configuration with SAP ECC as the source system, the following diagram explains the architecture when the source system is a non-SAP system:

How it works…

The different components of SLT that are responsible for data replication from the source to the target are given as follows:

  • Logging tables
  • Read module
  • Control module
  • Write module

Logging tables

When an application table is replicated, logging tables and database triggers are automatically created on the source system side. After the table is replicated for the first time, DB triggers read any change in these application tables and immediately store the changes in the logging tables. After data is written to the target system, the data in the logging tables is cleared.

Read module

Read modules take data from the logging tables and pass the data as requested by the control module. The placement of read modules depends on the source system. If the source system is SAP, then read modules will be installed on the SAP system itself. If the source system is a non-SAP system, read modules will be installed on the SLT server. Read modules also take care of the declustering of the table classes into a transparent format.

Control module

The control modules that reside on the SLT Replication Server instance manage the replication process and initiate data replication through the read modules in the source system to the SAP HANA system. Control modules ensure mapping between the SAP HANA database structure and the structure of the source system. Field conversion or migration abilities are only provided by the control modules, for example, the requirement may be to have data fields as strings. This can be achieved with the help of control modules. The data replication process is managed by these modules. The data load frequency can be set, whether it has to be a real-time load or a periodic load that is based on a time interval. All these features are included in these modules. After reading data from the read module, the control module takes care of all the intermediate activities, such as field conversions and load frequency, and then the data is passed to the write module. Then, the the control module activates the triggers of the write module.

Write module

The main purpose of a write module is to write data to the SAP HANA system through a DB connection. This module also offers flexibility to switch from single operation (that is, insert or update or delete) to the array operations.

There's more…

Apart from replicating all the data, we can also replicate data by maintaining additional settings. This can be done in the t-code IUUC_REPL_CONTENT as illustrated in the following screenshot:

There's more…

Settings have to be maintained for individual tables. Input the table name on the left-hand side of the screen and maintain the settings in the right-hand section.

See also