SLT: Mass Tables for Replication to HANA

When using SLT to replicate tables from a source system to HANA, usually tables are entered for replication by using the HANA Studio.  For example, first select “Data Provisioning” from the Modeler perspective in the Studio:

Ensure the proper source and HANA systems are chosen, and select “Replicate”:

Then you can select tables for replication:

Details can be found in the SLT Technical Operations Manual.

But what if you have more than just a few tables to put into replication?  For example, I was recently helping setup SAP Analytics Content for ERP 1.0 (Note 1781992).  The list of tables for replication attached to the Note contains hundreds of tables!  The problem with the method above is that you have to select each and every table one-at-a-time, making it very time consuming and error prone.  There has to be another way!  Well, luckily enough, there is.

The Cowboy Method

When tables are selected for replication using the Studio, SQL statements are passed to the HANA engine to start the process.  What this means is that you can ultimately enter the underlying SQL statements into the SQL editor in the Studio to kick-off the process.  The buttons “Load”, “Replicate”, “Stop Replication”, “Suspend” and “Resume” insert entries into table RS_ORDER in the SLT replication schema.  RS_ORDER contains the following fields: SID, CI_HOST, TABLENAME, ORDERID and ACTION.  You could also look at table RS_STATUS to find some of the possible values. At the end, you end up with a SQL statement like this:

INSERT into "<SCHEMA>"."RS_ORDER" VALUES('<SID>', '<CI_HOST>,'<TABLE>','null','R')

The “R” at the end is the most important, here, as it means “replicate”.  So, you can do as I did, create a spreadsheet that creates the appropriate SQL statements and then cut-and-paste them into the SQL editor and run them.  This does work quite nicely and puts all of the tables into replication, but it is not an elegant solution in the least!  It is still susceptible to fat-finger syndrome and putting the wrong value into ACTION can wreak havoc.  This solution is also not documented.  But, if you’re feeling cowboy, well, hey, go for it.  Personally, though, I try not to mess with undocumented SQL statements if at all humanly possible.  After some fiddling around, I found…

The Better Way

1. In the SLT system the newer DMIS Support Packages have brought many improvements.  Most notably here are the improvements to the LT Cockpit, transaction LTRC (formerly IUUC_SYNC_MON (glad that got cleaned up )).  First, enter the Mass Transfer ID for your schema and Execute (screen shots from DMIS 2011_1_700 SP4):

Then, go to the “Table Overview” tab.  Here you will find the “Data Provisioning” button:

In the dialog box that appears, click on the arrow next to the “Table Name” field:

Now you get a screen to enter tables with two very useful buttons:

The buttons “Import from text file” and “Upload from clipboard” do exactly so.  Now that’s what I’m talking about!  You can upload a long list of tables if you wish.  This is a much easier method to work with the status of dozens or hundreds of tables in replication.  Just select the correct radio button, upload the table list, hit go and voilà! 

In the Studio you will see the entire list of tables appear in “Scheduled” status.  Eventually, they will pass through “Load” and then go into “Replicate”, “In Process”:

Source: scn.sap.com