Skip to Content
HI,
this blog describes the procedure to replicate from different source systems into one HANA schema the same table.
In this example the table SFLIGHT is available in System UA7 and UA5, the SLT system is U72 and the HANA Box is SLO.
     1. Setup of configurations
         You have to setup the first configuration. In this example I connect the system UA5 to the HANA box. I named the configuration N_1_SCHEMA.
         The same name is used as the schema name on the HANA side.
/wp-content/uploads/2013/06/1_229577.jpg
Afterwards you can wait until the DD* tables are all loaded to HANA and the configuration is ready to use.
/wp-content/uploads/2013/06/2_229586.jpg
Now it is time to create the second configuration. To achieve a N:1 replication, we have to replicate into the same schema. So it is quite easy – just use the same configuration/schema name you used for the first configuration. Only the source system information (RFC destination or DB connection) is different.
Before you can finish the creation of the second configuration you will receive the following message:
/wp-content/uploads/2013/06/3_229587.jpg
To connect the second configuration to the already existing schema on the HANA system – just confirm and that is all 🙂
After you finished the creation of the second configuration, the DD* tables will be dropped and loaded again. Just wait until this is finished.
/wp-content/uploads/2013/06/4_229588.jpg
Both configurations are running and enabled for N:1 replication.
    2. Avoid duplicates (optional)
         What will happen when you want to replicate the same table (e.g. SFLIGHT) from multiple systems and merge it to one table on the HANA side           and the records are not  totally unique over all involved systems? – You will run into duplicates.
         
           How can SLT support to avoid duplicates and transfer all records? To achieve a record that is also unique over more systems – a additional key           field has to be added to the target table. For the new key field would suggest the system id.
   
          a.) Extend target table structure for the first configuration
               You can extend the target table structure within transaction IUUC_REPL_CONTENT. You can dowload the full guide for this transaction here.
               When you access the transaction IUUC_REPL_CONTENT you will find both created configurations.
               /wp-content/uploads/2013/06/5_229628.jpg
                Select the first configuration and navigate to the table setting screen (IUUC_REPL_TABSTG) and choose Edit table Structure.
                 /wp-content/uploads/2013/06/6_229630.jpg 
                Add a new field. In this example I added a new field  name SID, at position 2 od data type CHAR and length 3.
               /wp-content/uploads/2013/06/7_229640.jpg
               After you confirmed your input and saved the settings for the first configuration.
          b.) Fill new field with the system id for the first configuration
               In the next step you have to assign a transformation rule to fill the new key field with the system id.
               Navigate to the transformation rule screen (IUUC_***_RUL_MAP) and choose and apply the following rule.
               /wp-content/uploads/2013/06/8_229667.jpg
                    

Field name Value Comment
Table Name SFLIGHT This is the table you would like to transform a field.
EVENT Let it empty to use parameter-based rule.
Export Field Name SID This is the field you would like to modify.
Import Parameter 1 ‘UA5’ This is a literal an point to the id of the source system.
Insert Line of Code E_SID = I_P1. This is the rule, do not miss the space between the equal and the full stop at the end.
               Save all settings afterwards for your first configuration.
          
          c.) Extend target table structure for the second configuration

         

               Select the second configuration and navigate to the table setting screen (IUUC_REPL_TABSTG) and choose Edit table Structure.

               Extend the target table structure by an additional key field as described in a.)

              

               After you have extended the structure, an additional setting has to be specified. In the N:1 case – you would start replication for the first source                table and afterwards for the second source table. Usually SLT will drop a existing table on HANA before it creates a new replication for this table.                This behaviour would lead to the fact, that you will never get both tables at the same time into HANA.

               To avoid this, just check the field No Drop.

               /wp-content/uploads/2013/06/9_229668.jpg

               Afterwards, you can save the settings for the second configuration.

         

          d.) Fill new field with the system id for the second configuration

               In the next step you have to assign a transformation rule to fill the new key field with the system id.

               Navigate to the transformation rule screen (IUUC_***_RUL_MAP) and choose and apply the following rule.
                                  
            

Field name Value Comment
Table Name SFLIGHT This is the table you would like to transform a field.
EVENT Let it empty to use parameter-based rule.
Export Field Name SID This is the field you would like to modify.
Import Parameter 1 ‘UA7’ This is a literal an point to the id of the source system.
Insert Line of Code E_SID = I_P1. This is the rule, do not miss the space between the equal and the full stop at the end.
            
            All records replicated from the second source system will get as additional key field the id ‘UA7’.
            Save all settings afterwards for your second configuration.
    3. Replicate the Table
         
         a.) Start the replication for the first configuration for your table (e.g. SFLIGHT)
         
          /wp-content/uploads/2013/06/11_229679.jpg
               Wait until the table is in action Replicate and status In Process.
  /wp-content/uploads/2013/06/12_229681.jpg
     Let us have a look at the structure, numbers of records and the content.
     The structure is enhanced by SID defined as a key field.
/wp-content/uploads/2013/06/14_229691.jpg
     In total we replicated from the first source system 2712 records.
/wp-content/uploads/2013/06/15_229692.jpg
     Example of the first four records – the records are now unique also over multiple systems.
/wp-content/uploads/2013/06/13_229693.jpg
b.) Start the replication for the second configuration for your table (e.g. SFLIGHT)

     Wait until the table is in action Replicate and status In Process.

     When you check now the numbers of records: 5034
/wp-content/uploads/2013/06/16_229748.jpg
     And when you have a look at the extraxt of the table you see:
     /wp-content/uploads/2013/06/17_229749.jpg
    Now you can consume the data of a table that was feeded from to different source systems in realtime.
Enjoy your N:1 repliction 🙂 – Feedback is appreciated.
Best,
Tobias
To report this post you need to login first.

22 Comments

You must be Logged on to comment or reply to a post.

  1. Edgar Jubillar Vera

    Hi Tobias,

    very interesting post.

    Do you think it is possible to create a 1:N replication process, at table level, using transformation capabilities of SLT?

    Kind regards,

    Edgar.

    (0) 
  2. Tobias Koebler Post author

    Hi Edgar,

    sure, you would setup a 1:N replication and apply a rule for both configuration. The rule for target system A only process e.g. GJAHR = ‘2013’ and the rule for target system B process all other GJAHR < 2013.

    Is this what you are looking for?

    Best,

    Tobias

    (0) 
  3. Orel Stringa

    Hi Tobias,

    nice post!

    if I were to set up 1:N replication via the same SLT config (“allow multiple usage” = ‘X’), can I possibly apply different transformation rules to the target table structures in the differerent HDB Systems. Say I have 1 source replicated to 2 hdb systems (A and B). In hdbsys A I’d like to extend the table structure by 2 extra fields whereas in hdbsys B I just would like to have the same table structure as in source. Can LTR and IUUC_REPL_CONTENT allow this?

    Thanks,

    Orel

    (0) 
    1. Tobias Koebler Post author

      Hi Orel,

      sure – when you setup a 1:N replication then you habe to define one configuration to replication into target A and one configuration for target B. When you then go to IUUC_REPL_CONTENT you will see two configuration. Rule assignments will defined per configuraiton. So you can define for configuration A another rule or structure enhancement than for configuration B.

      Best,

      Tobias

      (0) 
  4. Orel Stringa

    Hi Tobias,

    thanks for your quick answer.

    If I were to add a new configuration for  a new HANA target, then what impact does it have on the single source system. Basically, we are looking for a one-time initial load no matter if we are replicating to one or multiple HANA target systems.

    Kind regards,

    Orel

    (0) 
    1. Tobias Koebler Post author

      Hi,

      the impact on the source system is the same like for the first initial load (if you use the same setup of jobs and reading type)

      The general procedure would be that for each new target an initial load will be started and is also recommended (without SLT cannot ensure that all data is available and transfered correctly).

      So far there is no option to prepare all settings and start the initial load in a dual/triple target way.

      Best,

      Tobias

      (0) 
  5. Ronald Konijnenburg

    Hi, tx, great blog!

    we’ve set up the double connection and seperator, but it seems at first replication the table in HANA is dropped. That means once the second system is replicated, we loose the records from the first replication (source system 1).

    Any thoughts?

    (0) 
    1. Tobias Koebler Post author

      HI,

      have a look at c)

      To avoid this, just check the field No Drop

                     /wp-content/uploads/2013/12/9_351247.jpg

                     Afterwards, you can save the settings for the second configuration.

      Best,
      Tobias

      (0) 
  6. Cosmin Jimborean

    Hi Tobias,

    First, thanks for the very good info here.

    To avoid duplicates, would it work if instead of adding the SID as an additional key field to the target table, one would increase the length of data type of one of the existing key fields of the target table and concatenate SID+ORIGINAL_KEY and store it into the target key field?

    I would assume so, but I wanted to double-check since modifying key fields could cause issues.

    Thanks and best regards,

    Cosmin

    (0) 
  7. Marco Baiocco

    Hi Tobias,

    Thanks for this post (old, but still good!).

    I am trying to setup an N to 1 replication, and I have created the first and the second configuration without errors. I have so far only created the two connections, no other action taken.

    However, if I look in LTRC at the table overview, I only see tables DD02L, DD02T and DD08L in the FIRST activity that I have configured. Table overview for the second mass activity is empty.

    Is this correct, expected, or does it mean error?

    (0) 
  8. SAP Team

    Hi Tobias,

    Excellent post. Thank you.

    Just small doubt, regarding if connecting several clients from the same source system to on HANA database, will it be in the N:1 replication type ?

    If yes, then why its given an error that: cannot use duplicate schema name: SYS_REPL ?

    Looking forward for your reply =)

    Thank you in advance.

    Andres Toyos

    (0) 
      1. Andres Anatolii Toyos Kozub

        Thank you Tobias, for the info.

        Just one more question, then it will be needed to create several New Configurations for each client ?

        Cause if yes, then it gives the error of the duplicated schema SYS_REPL =(

        Thank you again.

        best regards,

        Andres Toyos

        (0) 
        1. Marco Baiocco

          Hello Andreas, as Tobias write above, it would be not.

          When you create a configuration for a system, unless you don’t specify “Read from single client” in the source rfc connection screen, you get all clients for the table copied. So you just create one connection and get all the clients transported.

          That’s the reason why you get duplicated schema if you create multiple configurations the way you did.

          (0) 
  9. shenhav lavie

    Hello,

    Very helpful information.

    Is there any dynacim way, to sign the source system (sid) without write it hardcoded. so we want have to add value to the parameter again and agin in every new configuration and for all the table?

    Thanks and best regards.

    (0) 

Leave a Reply