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
Hi Alessandro,
I like the idea of this blog. But unfortunately there is a "but", and thus I would like to post some feedback that you might consider for updating the content.
1) I think it's confusing that you start your blog with IDoc replication in general, but then jump to the MDG-F specific ways of replicating master data. As example, the MDG-BP/C/S is able to replicate IDocs, but there aren't any replication modes for the same. Furthermore MDG-F does not support transaction DRFOUT for replication in general (reason: you cannot specify the edition in DRFOUT), whereas this is allowed for MDG-BP/C/S (because you don't have editions in data model BP).
2) Report USMD_EDITION_REPLICATE is only relevant for objects that are not time dependent in receiving systems. For objects, that support full time dependency, the outbound implementations always replicate all time slices (see SAP Note 2106479). Since this is of course not possible for time independent objects, the outbound has to ensure that only data is replicated that is valid for the point in time the replication happens. An example:
There are two editions in the system, EDA is valid from 01.01.2016, EDB is valid from 01.01.2017.
I change an account in EDA. This is my currently valid data, so if I replicate by CR or object based, the data is sent.
I change the same account in EDB. Now the system has to prevent sending this data since it is simply not valid yet. This is a future change that must not be sent at any point in time before EDB actually becomes valid. Nevertheless, it is valid to release the edition EDB right now, and if configurred corretly USMD_EDITION_REPLICATE will replicate the data as soon as 01.01.2017 is reached.
Cheers Michael
Hi Michael,
you are completely right. Since I have only experience with MDG-F for now, I could not know these differences. I will be more careful next time considering also other MDG faces. Under your suggestions I made this blog specific or MDG-F, and about the DRFOUT I removed it. Maybe in the next blog about MDG-C I will include DRFOUT back 🙂
Thank you so much for your valuable suggestions!
Thanks Michael for the reply..
I just want to ask one question. For IDOC replication it is not required to add - Send Delta Information as IDOC replaces entire master data.
Regarding the other outbound parameter - Prevent remote checks - Is this relevant only for SOA based replication? How exactly it works?
Please share these points as well. It will be really helpful.
Kiran
Hi Kiran,
The parameter Prevent remote checks works for me using IDOCS. This parameter allow you to go ahead with replication even if there are errors (it will not perform remote checks before starting the idocs).
Obviously you will find some idocs in error.
Thanks for your reply. But what is the purpose of skipping the errors? Whether the same will work for SOA? The reason is when we replicate hierarchy, there is a check in MDG and well as in ECC. Most of the times it fails due to mismatch of validations or data. Do you know if it works for SOA based replication as well?
Thanks
Kiran
The reason to skip errors is to start Idocs anyway. Otherwise the idocs will not start!
I don't know if this is applicable for SOA I am sorry 🙁
Hi,
SOA replication always validates data during inbound in receiving system. This is possible since SOA sends confirmation messages back to MDG that contain the full information of success / warning / error messages that have happened in inbound.
This approach does not exist for IDocs. The ALE audit for IDocs can send only the general IDoc status back to MDG. If the IDoc failed, the MDG user has no clue, why this is the case. If it's a user that does not have access to the target ERP, you're in kind of a deadlock situation. That's why the IDoc outbound processes validations via a RFC call to the target. Since this RFC might take some time and is potentially not needed (assuming that your MDG system contains at least the same checks as the target ERP), you can use the parameter to skip the RFC checks.
Best regards
Michael
Hi Alessandro ,
thanks to share your knowledge ,
Thanks and best regard .