Skip to Content
Technical Articles
Author's profile photo dinesh k

Index table replication using SLT for custom scenario

Unlike standard replications, table to table or postings through AUFK,CFIN objects etc, via SLT, Index tables follow a different approach as the data is stored in clustered format(field ‘CLUSTD’) and they cannot be mapped directly to target HANA which doesn’t support cluster replication.

The standard approach for ‘STXL’ replication is given in Note: 2430480

The focus here is the replication of another table ‘SOC3’ which is not available in standard knowledge base and we had to replicate specific SOC3 content for our requirement

Here, though the approach remains similar to what we do for STXL i.e.,

  1. Create a replication mass transfer id in LTRC
  2. Add INDX – like table in LTRS
  3. Generate template
  4. Map key fields
  5. Activate and save
  6. Trigger the Initial load/replication

( Full details about above given steps aree mentioned in Note: 2430480)

Challenge is, we will not be able to get the standard template for replication since there is no standard knowledge base available for ‘SOC3’ table and we do not have info on what would be RELID and Component details.

So, we had to analyze how the standard INDX replication works so that we might be able to stitch a custom solution for our requirement.

If we dig one step deeper and analyse how standard process of INDX replication works

  • Since INDX tables store the data in clusters in field ‘CLUSTD’ which is not usable in HANA. we cannot map this field one to one with HANA tables. that is where, standard process generates a template which builds a structure with TEXT field replacing the CLUSTD field.
  • Then, while actual replication, the data in CLUSTD field in source is declustered and is mapped to the new TEXT field in target
  • Replication happens in DB layer, as we cannot have source INDX table that mapped to same index table in target( because of CLUSTD).
  • So, the replicated data can be seen in schema created in the data base.

Now, coming back to our original requirement, for ‘SOC3’, since there is no standard knowledge base available, we had to find a way to decluster ‘SOC3’ entries then replicate it to some table in target or identify some other table instead of SOC3 for replication.

In this research process, We figured out that our source data is stored in ‘SOC3’ as RELID = ‘DT’ and component table = ‘OBJCONT_TAB’ with few other details.

So, we created a custom configuration explained as following:

Steps 1. Configure replication in LTRC

And, You can see the replication schema created on HDB

Step2:  Go to LTRS and add INDX table ‘SOC3’ and create a record as shown on the right

Step3: Create new entry with below details:

  1. Add a new Row as shown on the right in above figure with RELID = ‘DT’ COMPONENT = ‘OBJCONT_TAB’ STRUCTURE = ‘SOLI’
  2. Select the row and click on generate template.
  3. Click on ‘Map Key fields’ button in the same row
  4. Click on ‘propose mapping button…. Then select ‘ok’ once mapped
  5. Check ‘Use’ check box and click ‘Save’

Step4: Go to ‘LTRC’ and add ‘SOC3’ and start replication

As replication starts,

  • The template that is generated in Step 3, will get created in HDB under schema SOC3_repl1

  • Now, we can test this set up by creating some data in ‘SOC3’ and check if it gets replicated in target HANA db schema
  • To Test, we created a note in sales order

  • Corresponding entry got created in SOOD and SOC3 tables in Source SE11


  • And above entry got replicated to HDB in ‘/1LT/02POBJCON00’ table as shown below


This is an example of a customized replication scenario for index tables that are not provided in standard knowledge bases. Best part is we are using standard way of index table replication and we need not think about declustering separately as it is handled automatically as part of replication.

NOTE: In this example we focused only on specific entry of ‘SOC3’ created from sales order.

So same solution may not be relevant for other kinds of content stored in ‘SOC3’


The above shown scenario was replication from source ECC to HANA DB.

If we want to replicate to app layer instead of db layer i.e., into a custom Z table, we can give the table name in ‘target template’ field in LTRS configuration. This Z table needs to be created in target system with structure( same as generated template) shown in Step 3 above




2430480 – How to replicate INDX-like tables with SAP LT Replication Server

2730957 – How to specify filters for replication of INDX-like tables? – SAP Landscape Transformation Replication Server

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Nabheet Madan
      Nabheet Madan

      Thanks Dinesh for sharing this:)

      Author's profile photo F. Post
      F. Post

      Perfect information.

      Can you give insights how in your research you found the component.

      I am investigating if we can replicate table MDTC.

      Author's profile photo dinesh k
      dinesh k
      Blog Post Author


      Sorry for late reply... Hope you figured out a way by now.

      My research was more to understand how the standard functionality works with SOC3 table. I tried to debug and analyse FM ''SO_OBJECT_SEND' and similar FMs where 'SOC3' was used(read/modified).

      For example, in include 'FSSO0E04' there is Import from 'SOC3' like "import objcont_tab from database soc3(dtid sortfield'' . This gave a hint to use 'objcont_tab' as structure in LTRS config. So, we went ahead and it worked.

      I would also suggest to check how the data access from 'MDTC' works in standard way to get an idea on what our config should look like.


      Author's profile photo Can Gevgeli
      Can Gevgeli


      First of all it's a great post, very helpful.

      I have used this to replicate our STXL table however my filter on TDOBJECT is not working. In note 2730957 it states that "For INDX-like tables, Rule Assignments or Filters can be used to filter data, however, Filters only allow filtering on Key Fields."

      TDOBJECT being a key field in STXL table I expect my filter to work but it doesn't. Do you have any idea why?