SAP provides many ways to enable communication with third party systems; one option is the IDOC (Intermediary Document) mechanism. Dedicated IDOCs exist in SAP ERP for each master data domain, for example, Customer (DEBMAS), Vendor (CREMAS), and Material (MATMAS). Each individual document contains all the data elements and segments (representing 3NF relationships in an XML format) for a particular domain. In addition, it contains other data used by SAP or Partner systems that regulate how the documents are processed, and indicates the type of operation on the data, such as Create or Update, by specifying the MSGFN message type.
Understanding the implications and shortcomings when using this type of mechanism is key for a successful integration process, where maintenance of existing, not in scope for mastering data, is a concern.
When designing processes to maintain master data in SAP ERP using the IDOCs maintenance mechanism, decide what action to take on the physical source fields that require maintenance as part of the new MDM solution. Often, the necessity around maintaining existing, not in scope for mastering data, is misunderstood or unintentionally neglected. This can become a problem when using the IDOC mechanism, and in particular where existing data (albeit not being maintained) is affected by the new synchronization processes.
When mapping the MDM input structure to the IDOC output structure, map the data that you are maintaining, as shown in Figure 2 below:
Mapped fields are highlighted and shown by the arrows emerging from the input on the left side. SAP processes any unmapped or blank fields and structures as nulls, and overrides the existing information in SAP ERP. Figure 3 is an example of unintended changes, where the built processes did not provide the information, so the data was overridden with nulls. This is not the intended effect a process should have on data that is not being mastered, unless this has been agreed upon beforehand and captured as part of the requirement gathering process.
Note: Information has been hidden to preserve anonymity.
Before deciding which data will form the scope of maintenance as part of your MDM consolidation and synchronization strategy:
Ensure that you have a full understanding of all source systems and their relevant tables, objects, and fields. Once you have scoped the information you want to maintain, ask yourself:
What about the other tables/objects/fields you are not maintaining?
What is the impact of not maintaining this information? Capture the decision and reason why so that you and others can refer to it in the future.
Ensure that you have a full understanding of the mechanism you will employ to build the maintenance processes, then ask yourself:
Does the mechanism provide the ability to synchronize only data that is in scope?
What is the impact of the process you are putting in place using the specified mechanism? What is the impact on the data that is not in scope, that is, not being maintained?
Regarding the solution to an employee using IDOCs, SAP provides a simple solution in the shape of a No Data indicator, a forward slash (/). The integrator must use this to avoid overriding historical data during the synchronization processes. Figure 4 shows the use of a constant to maintain not-in-scope data for the field BAHNS Train station.
Note: This solution is not applicable to the maintenance of the Address Master domain. As such, a BAPI function must be used instead, to access the existing data in SAP to pass this to the synchronization service so that data is not lost. Contact your SAP administrator for information on the IDOCs No Data indicator.
Another aspect to consider is whether you are using synchronous versus asynchronous interactions, as the data loads can potentially have an impact on performance. Always ensure the full impact is understood.