Skip to Content

Replicate DataSources via program

Is there a program/function that we can use in order to schedule the replication of DataSources?

this is one of the most recurring questions on the forum. I recently created such a program. Many posts in the forum indicate FM RSAOS_METADATA_UPLOAD as the FM to use, so I did. The code is simple: if no DataSource is specified, all is replicated, also the new DS. If DataSources are specified, a check is done with the tables to check if they exist and to get a list. Once this is done, the function module is called.


REPORT  zbw_replicate_ds.

TYPES: BEGIN OF ty_ds35,
         oltpsource TYPE rsoltpsourceoltpsource,
        END OF ty_ds35.

         datasource TYPE rsdsdatasource,
        END OF ty_ds7.

       WITH UNIQUE KEY oltpsource,
       w_ds35 LIKE LINE OF t_ds35.

       WITH UNIQUE KEY datasource,
       w_ds7 LIKE LINE OF t_ds7.


   p_logsys    TYPE rsdslogsys OBLIGATORY.

   s_ds FOR (rsoltpsourceoltpsource).


   IF s_ds IS INITIAL.
         i_logsys = p_logsys.
*        i_osource = w_ds35-oltpsource.

     SELECT DISTINCT oltpsource
       INTO TABLE t_ds35
       FROM rsoltpsource
       WHERE logsys = p_logsys
         AND oltpsource IN s_ds
         AND ( objvers = ‘A’
          OR objvers = ‘M’ ).

     SELECT DISTINCT datasource
       INTO TABLE t_ds7
       FROM rsds
       WHERE logsys = p_logsys
         AND datasource IN s_ds
         AND ( objvers = ‘A’
          OR objvers = ‘M’ ).

     WRITE : / ‘3.5 DataSources’.
     LOOP AT t_ds35 INTO w_ds35.
       WRITE: /5 w_ds35oltpsource.
           i_logsys  = p_logsys
           i_osource = w_ds35oltpsource.
     WRITE : / ‘BI7 DataSources’.
     LOOP AT t_ds7 INTO w_ds7.
       WRITE: /5 w_ds7datasource.
           i_logsys  = p_logsys
           i_osource = w_ds7datasource.

You must be Logged on to comment or reply to a post.
  • Hello Tibollo,

    May I know under what circumstances is there a need for such a program? Why does one need to schedule the replication of DataSources?

      • Thanks for the example in that thread.

        The way that replication works – with it being a step to be done after R/3 transports are moved into Production, and before BW transports are moved into Production, leaves very little chance/time for it to be automated by the system.

        If one needs to replicate datasources, it means you have made changes to the extraction structures (be it a major or minor change), and it means that you surely have BW transports changing the data flow model that needs to be imported into Production.

        Unless the purpose behind scheduling the replication job is because you also have your BW transports *scheduled* to be moved into Production, which ultimately may become a major risk if anyone tries to do this sort of thing in Production via automation…? If the BW transports are to be imported manually (which is a common practice in many companies), there is no need to schedule such a step…

        Otherwise, if there are no follow-up BW transports to be imported after replication (why then does one need to replicate if there are no BW transports thereafter?), why is it so important that it must be scheduled right after the R/3 transports have been imported?

        I just find the practical uses of scheduling such a step to be very limited… hence the original question. Unless there is something which I missed out here in understanding the real need for scheduling of this replication step?

        • BW transport are often as automated as R/3 transports. often done by people who receive a file with steps to execute in a precise sequence. it’s called segregation of duty and is very popular at big companies. Hence the need of a simple step to do a replication. it might not be scheduled, but if you can tell somebody who’s not familiar with BW to execute report X with variant Y, the risk for errors is smaller.

          it also comes in handy after a system refresh. after the refresh basis team has tree steps to perform, replicate, activate datasources, activate transfer rules. the latter two can be done by standard programs. so now the first can also be done by a program, again the risk for errors is smaller.

          ‘Schedule’  was perhaps not the correct expression…maybe ‘add as a step’ would have been better.

          • Thanks for the heads up Tibollo!

            I guess we can conclude that the uses of this program would be highly-valued by companies with source systems that are very fragmented (hence the need to replicate all datasources in one go with a program), and who have basis personnel with little BW knowledge, doing BW transports (to reduce risk of errors by “missing out the step of replicating a particular datasource”)…

            As for the system refresh part, I am a little skeptical, as these things don’t happen every single month. And even so, system refreshes are done on non-production systems. So the real need for replication of datasources can actually be done on an adhoc basis by the BW developer who needs to test that particular datasource in the development/quality system. There is really no need to have it as a critical/mandatory step as part of a system refresh, no? I agree that it could be included “as a step” for completeness, but the value it adds seems just very insignificant…

          • Hello Tibollo,


            Just a question out of curiosity, how often do you execute this program in your organization, and how much savings (in terms of time/man-hours) has the program generated for you?

  • Nice blog ,

    This is really helpful with 3.x data sources where replication is mandatory after transports and will also help in replication in bulk .