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
REPORT zbw_replicate_ds.
TYPES: BEGIN OF ty_ds35,
oltpsource TYPE rsoltpsource–oltpsource,
END OF ty_ds35.
TYPES: BEGIN OF ty_ds7,
datasource TYPE rsds–datasource,
END OF ty_ds7.
DATA: t_ds35 TYPE HASHED TABLE OF ty_ds35
WITH UNIQUE KEY oltpsource,
w_ds35 LIKE LINE OF t_ds35.
DATA: t_ds7 TYPE HASHED TABLE OF ty_ds7
WITH UNIQUE KEY datasource,
w_ds7 LIKE LINE OF t_ds7.
TYPE–POOLS: rs.
PARAMETERS:
p_logsys TYPE rsds–logsys OBLIGATORY.
SELECT–OPTIONS:
s_ds FOR (rsoltpsource–oltpsource).
START–OF–SELECTION.
IF s_ds IS INITIAL.
***ALL DATASOURCES
CALL FUNCTION ‘RSAOS_METADATA_UPLOAD’
EXPORTING
i_logsys = p_logsys.
* i_osource = w_ds35-oltpsource.
ELSE.
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’ ).
***SELECTED DATASOURCES
WRITE : / ‘3.5 DataSources’.
LOOP AT t_ds35 INTO w_ds35.
WRITE: /5 w_ds35–oltpsource.
CALL FUNCTION ‘RSAOS_METADATA_UPLOAD’
EXPORTING
i_logsys = p_logsys
i_osource = w_ds35–oltpsource.
ENDLOOP.
SKIP.
WRITE : / ‘BI7 DataSources’.
LOOP AT t_ds7 INTO w_ds7.
WRITE: /5 w_ds7–datasource.
CALL FUNCTION ‘RSAOS_METADATA_UPLOAD’
EXPORTING
i_logsys = p_logsys
i_osource = w_ds7–datasource.
ENDLOOP.
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?
as an example...http://scn.sap.com/thread/1222228
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...
Ok, you might not see the intrest of such a program in your case. but it did in my situation. in order to broaden your world, take a look at the below presentation....
http://www.ted.com/talks/derek_sivers_weird_or_just_different.html
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 .
Regards,
Jaya
Nice work Tibollo.