MDG 8.0 in real life blog series – Replication via IDocs explained for MDG-F
Hello and welcome to the 4th episode of this serie.
Today I want to make some clarifications on the replication for the new entries in MDG.
First of all what is replication?
Replication is the function to replicate data from the Master Data Governance (MDG) hub to target systems. The data replication is carried out using the Data Replication Framework and can be implemented using IDocs, SOA, RFCs or files.
What are the replication modes in MDG-F?
In MDG Hub, an administrator can set the replication timing for an edition to either Manually Started After Release of Edition, On Final Approval of Change Request or Selected in Each Change Request.
If the administrator sets the replication timing of an edition to Selected in Each Change Request, a processor of a change request can set the replication timing for the change request to On Final Approval of Change Request or to Manually Started After Release of Edition.
How the replication Works in MDG-F?
1) Selected option: On Final Approval of Change Request
If the valid from date (or period) is earlier than or the same as the date (or period) in which the change request is approved, the data is automatically replicated. If the valid from date (or period) is later than the date (or period) in which the change request is approved, the data is only replicated if the target system supports time dependency for the specified object. If there is no support, the administrator must schedule the USMD_EDITION_REPLICATE report to run.
2) Selected option: Manually Started After Release of Edition
In this case the administrator has to use the options for manual replication such as the wda applications (replication by object selection– that can be performed also if the edition is not yet released / replication by distribution model– that can be performed only when the edition is released).
If the valid from date (or period) is later than the date (or period) in which the change request is approved, the data is only replicated if the target system supports time dependency for the specified object. If there is no support for time dependancy, the administrator must schedule the USMD_EDITION_REPLICATE report to run.
In particular the manual replication using wda replication by distribution model or the scheduled report USMD_EDITION_REPLICATE have the same behaviour: if they select at least one edition that needs to be replicated, with the specified filters, they replicate all the objects in this edition and all the objects in the released old editions (asked to SAP for this and the reason is to keep the data consistent).
How to select the destination system for the replication for MDG-F
For manual replication the destination is selected manually from a list of possible destinations. For automatic replication the destination is taken from customizing (actually all the possible active replication models for the current objects are used).
What happens if there is an error during the replication?
Depending on the following option in the customizing
we have two possible behaviours:
1) The replication is rolled back completely.
2) The idoc with error remains in a status different from ‘3’.
In case you are using the option “Manually Started After Release of Edition”, once you get an error is difficult to revert it, because most likely the edition is released and you can’t just delete the object. You will get the error only after the edition is released and replicated. So my suggestion is: before releasing an Edition is a good idea to try the manual replication using the replication by object selection. If this is not possible there are the following possible options to correct the error.
– Try to fix the object in error in a newer edition
– Try to delete the object in error in a new edition with a starting date = starting date of the edition in error +1 (the end date of the object will be set to starting date of edition -1 and so not replicated anymore) – NEVER create two editions with the same starting date putting the same objects in both: the system can’t handle this situation and you will get a bad inconsistency (it’s a known bug: the system should not allow you to do it. Instead it is.)
– ask to the development team to fix the error directly in the data model