Master Data Management posting confirmation


SAP Master Data Management 5.5 (MDM) distributes master data to SAP ERP Central Component (ECC). As MDM does not have a direct interface into SAP ECC, SAP Exchange Infrastructure (XI) will be used for distribution of the master data objects. This could be vendors, customers or banks or any other master data object. In a central Master Data Management scenario, there is no feedback provided by the backend system if the distribution was successful or not. If this is mandatory in your project, the following process might be considered. There will be a complex process developed via Business Process Management (BPM) to be able to send master data into SAP and query the delivery status and post it back to MDM in case of success. Also the process needs to send emails to the requestor of the master data change/creation in case of success or send an email to a general administrator email address in case of failure. In the described business case, there will be a portal view to enter master data requests via SAP Enterprise Portal through a person called “requestor”. Please see URL for full article.

Syndicator Batch and Java Wrapper

MDM Syndicator branch of tools include:

1. Syndicator GUI: Used to Create/Save/Export/Import Mappings, Configure Output Types etc. Can not run without a user

2. Syndication Server: Runs as an OS Service and executes configured Syndication Ports. Once configured, produces output in a designated location. Less flexible to integrate with external tools

3. Syndicator Batch: Executes syndication process in batch mode without launching fat GUI and it is highly configurable and allows flexibility to create Wrappers to work with external tools such as XML/XSL Transformers, FTP Clients and anything under your imagination

This blog walks you thru using Syndicator batch from Windows Command and creating a Java Wrapper to dynamically execute

Syndicator Batch requires a special installation and is available only on windows OS. Upon installation, it will create a windows executable "SyndicatorBatch.exe" in the designated folder and here are the options available:


The following shows how Syndicator Batch output when executed with appropriate parameters:

Caveat: Syndicator batch is required to be executed inside the installation folder. You should navigate to the installation folder in Command shell.

No big deal right? Now, I will show you how to create a simple java program that passes all Syndicator Batch parameters dynamically:

* Created on Jan 5, 2007
package com.sitacorp.mdm.util;
* @author Venkat Vadlamannati
* A Java Wrapper to Syndicator Batch
public class SBDemo {
public static String SYN_BAT_DIR = "D:\\Program Files\\SAP MDM 5.5\\Syndicator Batch";
public static String SYN_BAT_EXE = "SyndicatorBatch.exe";
public static void main(String[] args) {
//Define and assign required parameters
String host = args[0];
String port = args[1];
String outputFile = args[2];
String user = args[3];
String password = args[4];
String language = args[5];
String synMap = args[6];
String clientSystem = args[7];
if(args.length<8 ){
System.out.println("Usage: java SBDemo <host> <port> <outputFile> <user> <password> <language> <syndication map> <client system> ");
//Construct a Command to be executed
String COMMAND = "\""+SYN_BAT_DIR+"\\"+SYN_BAT_EXE+"\" -f \""+outputFile+"\" -o "+
" -s "+host+" -p "+port+" -u "+user+" -w "+password+
" -r \""+language+" \" -a "+clientSystem+" -n "+synMap;
//Make sure command is constructed correctly
System.out.println("COMMAND: "+COMMAND);
Runtime rt = Runtime.getRuntime();
try {
//Execute Command
Process proc = rt.exec(COMMAND,null,new File(SYN_BAT_DIR));
//Buffer console output
BufferedReader consoleOutput = new BufferedReader(new InputStreamReader(proc.getErrorStream()));
String str = null;
//Show buffred output to console
while((str = consoleOutput.readLine()) != null) {
int retVal = proc.exitValue();
System.out.println("Syndicator Batch Exited with Return Code "+retVal);
} catch (IOException e) {
System.out.println("Error in Syndicator Batch Location "+SYN_BAT_DIR);

Compile this java code and running it will invoke Syndicator Batch dynamically and you can add your own functionality to enhance it.

Referencing the MDM Java API during development and runtime

How to reference the MDM Java API during development and runtime

Although there are several ways to include and reference the MDM Java API in your Java projects, I am describing here the best practice of doing it.

Use case

Typically your Java application will be deployed on the SAP NetWeaver Application Server, either as a J2EE or Web Dynpro application. The JAR files of the API should not be included in the application archive itself, but rather referenced only - both during development and runtime. The API is deployed as a library on the application server. This gives you the possibility to easily update the API:

  • On the application server by simply deploying a new version of the API. This can be done by an admin without the help of a developer.
  • On the machines used for development without the need to update several projects.
Download the MDM Java API

You find the JAR files in the archive MDMJavaAPI_Ver<build-number>.zip on the installation media you received. You can download it also, especially important after an update of the MDM Server, from the SAP Service Marketplace:

-> Download
-> Support Packages and Patches
-> Entry by Application Group
-> SAP NetWeaver
-> SAP MDM 5.5

During development in NWDS

  1. Unpack the archive with the JAR files and the Javadoc of the MDM Java API on your PC. Copy or move all the JAR files into any folder. Always use the same folder name every time you update to a new version. Example folder name: C:\MDMJavaAPI

  2. In the Preferences dialog of the NWDS, go to Java - Classpath Variables and create a new variable with the name SAP_MDM_JAVA_API and the path set to the folder of step 1.

  3. In the properties dialog of your NWDS project, go to Java Build Path - Libraries and add each JAR file of the API using the Add Variable button. You need to select the variable created in step 2, click on Extend and select all 6 JAR files (mdm4j.jar, mdm-admin.jar, mdm-common.jar, mdm-core.jar, mdm-data.jar, mdm-protocol.jar).

  4. If you are developing an J2EE application: Open the deployment descriptor application-j2ee-engine.xml and create a reference to the MDM Java API using the values:

    - Reference target:

    - Reference type: hard

    - Reference target type: library

    - Provider name:

  5. If you are developing a Web Dynpro application: Open the properties dialog of the project, go to Web Dynpro References - Library Referencesand add a new entry for the MDM Java API using the name

Deploy on the application server

Deploy the MDM Java API using the SCA named MDMJAVAAPI<SP-number>_<Patch-number>.sca.

Testing and Monitoring an Interface Between MDM & XI

Hello and welcome back to the last of a three part series on integrating MDM with ECC with XI (sorry for the onslaught of acronyms). If you missed out on the first two you can find them here: Part I, Part II. In this one we will focus on testing out your scenario, and how to troubleshoot (where to look) in both MDM and XI. You may have already noticed that in the previous two parts of this series I used a sample scenario dealing with material master data and the MATMAS05 IDoc structure. Ultimately we want to generate a new material in ECC based on the creation of a material in MDM.So lets go ahead and get started. First we'll start with the syndication process in MDM, and making sure our settings are correct.

1. MDM

First we'll start with the syndication process in MDM, and making sure our settings are correct.

1.1 Check Configuration
1.1.1 Client-Side Settings
  • Open the MDM Console
  • Navigate to Ports in the repository to which your map is located.


  • Verify that you have selected the correct map (built in Part I)
  • Select your processing mode as Automatic


  • Open the MDM Syndicator (Select the repository and press OK)
  • Select File->Open
  • Select the remote system representing ECC
  • Select your map and press OK
  • Select the Map Properties tab


  • Check Suppress Unchanged Records so we automatically update only changed records.
  • Close and save your map


1.1.2 Server-Side Settings
  • Open your mdss.ini file on the MDM server
  • Verify that Auto Syndication Task Enabled=True
  • For testing purposes, change the Auto Syndication Task Delay (seconds) to something rather small, such as 30 or less. This way you don't have to wait a long time for syndication when testing.


  • Verify that the service is started.
  • UNIX systems: ps -ef | grep mdss
  • WINDOWS systems: open services, and look for entry regarding syndication server
  • If service is not running, run command ./mdss (UNIX) or rightclick->start service (WINDOWS)


1.2 Important Locations

I'd like to go over some of the important locations (directories) on your server that will come in handy when troubleshooting and testing. One of the trickiest parts of working with MDM is figuring out where things go and where to look. Because it's so different from the SAP software that we are all used to, navigating the system is not as easy as running a transaction code. Also, MDM reacts to certain situations differently that you may expect, so it's important to know where to look when things aren't working properly. I'm working with MDM installed on HP-UX, however I will try to address each topic as it would appear in Windows to the best of my knowledge.

1.2.1 Home

Log onto your MDM server and navigate to the home directory for the MDM application server. On the server I am working with (sandbox) it happens to be located on the opt filesystem, and the path looks like /opt/MDM. In this directory take note of several important directories:


The Distributions folder is very important because this is where the port directories get created. When you create a port in the MDM Console for a particular repository, it creates a subset of folders in the Distributions directory based on which repository the port was created in, and whether the port is inbound or outbound. For example, in our particular scenario we may navigate to the path/opt/MDM/Distributions/install_specific_directory/Material/Outbound/. Here we will notice a folder entitled ECC which (if you followed the fist part of this series) corresponds to the port that we created earlier. This directory was created as soon as the port was created in the MDM Console. We will focus more on the contents of our port directory shortly.

The Logs folder contains several important log files, however most of them will not apply to our particular scenario, because the logs that we will want to look at are going to be specific to the syndication process, and are located within the port directory. Neverless, I thought it was important to mention that in certain troubleshooting scenarios, don't forget that these log files also exist.

The Bin directory is critical because that is where the files that start the app servers are located. The programs mds, mdss, and mdis are critical files.

1.2.2 Port

Your port directory is going to have the following format:
For example the we created looks like this:
Here you should see the following directories:


The Archive directory is not as important during the process of syndication as it is with the process of importing data into MDM. This directory contains the processed data. For example, if you were to import an XML document containing material master data, a message would get placed in the archive directory for reference later if you ever needed to check.
The Exception directory is very important because often times when an error occurs you can find a file has been generated in the Exceptions folder that should look similar to that file that either the import server or the syndication server are attempting to import or syndicate. In other words, lets say you were attempting to import an XML document that contained material master data, but the map that was built in MDM has a logic error, the document will instead get passed to the Exceptions folder and the status of the port will be changed in the MDM Console program to "blocked".
The Log directory is important for the obvious reason. Logs are created each time the syndication server runs. So if your interval is 30 seconds, then a log will be generated in this folder every 30 seconds. It will give you the details of the syndication process which ultimately can be critical in the troubleshooting process.
The Ready folder is the most important folder in our scenario. When the Syndication Server polls during it's interval and performs the syndication, the generated XML message will appear in the Ready folder. So in the case of our scenario, we are going to have material master data exported to this directory and ultimately Exchange Infraustructure is going to pick up the data and process it to ECC.
The Status directory contains XML files that hold certain information pertaining to the import / export of data. This information includes processing codes and timestamps.

1.3 Testing

Now are going to test out our scenario and make sure that the export of materials works correctly. First things first, we need to create a new material in the MDM Data Manager. Make sure that your MDM syndication server is turned on! Remember on UNIX we can start it by running ./mdss in the /bindirectory, and on Windows by simply starting the service.

1.3.1 MDM Data Manager
  • Start MDM Data Manager
  • Connect to Material repository.


  • Add a new material by "right-click".


  • Fill in required fields to satisfy the map built in Part I.


  • Verify the new product is saved by clicking elsewhere in the Records screen, and then back to the new Material.


1.3.2 Check Syndication

We are now going go verify that the syndication process is taking place as it should based on the settings in your mdss.ini file. If you have set the MDM Syndication Server to perform the syndication process every 30 seconds, as I set it for testing purposes, then by the time you log into your server the syndication should have already occured. Lets check by logging onto the server and navigating to the Ready folder in our Port directory.
If all went as planned your Ready folder may look something like this:
Those files are XML files that contain the data for each material in your repository that has changed. In this case the only materials in my repository are the two that I just added, so the MDM Syndication Server updated the Ready folder with both new materials. Now they are waiting for XI to pick them up and process them. Before we move over to the XI part lets take a look at one of these files and verify that the data in them is correct. Keep in mind that if you have already configured XI to pick up the files from this directory and process them, it's possible you won't see them here because they have already been deleted by XI (based on the settings in your communication channel).

1.3.3 Verify Data

Lets go ahead and open one of these files. I copied the file from the server to my local Windows running computer to examine the file, but of course you can read the file straight from the server if you prefer. If your mapping was done similar to mine, your file should look like a MATMAS05 IDoc in XML structure. This is to make it easier for XI to process since we can export in this format from MDM without much difficulty.

2. Exchange Infrastructure

Now we'll take a look at the second half of this scenario and test out our XI interface.

2.1 Check Configuration

The only configuration we are going to check is the outbound communication channel. This is what tells Exchange Infrastructure where to pick up what file (location, filename) and do what after it's processed by the inbound communication channel (processing mode, ie: delete).

  • Start your Integration Directory (Integration Builder: Configuration).
  • Navigate to your outbound communication channel.
  • Examine your File Access Parameters.


In my case, because this is a test scenario, I have a bash script picking up the file from the port directory and dropping it onto a drive that all of the SAP systems have access to; this being the /depot filesystem. As you can see I made a temporary folder on that filesystem for the files for this interface to be stored while waiting to be processed. Of course, the simplest way to do this would be to mount the Port directory from your MDM machine to your XI machine. Next take a look at your Processing Parameters and change the settings accordingly. For this particular scenario I have set the poll interval to 5 seconds for testing purposes. Also, notice that I am using delete as the processing parameter. This is so that I can verify that the file was processed, and so the folder doesn't get cluttered up with files.
If everything is the way you want it, lets go ahead and take a look at some important locations that will come in handy for testing and debugging the interface.

2.2 Important Locations
2.2.1 Integration Repository - Map Testing

Start the Integration Repository (Integration Builder: Design) and navigate to the map that we built in Part II. Select the Test tab.
To test our map, we can actually use the XML document that MDM generated via the Syndication Server. Lets go ahead and try this.

  • Press the "Load Test Instance" button.


  • Select the XML file MDM generated.


  • Press the "Start Transformation" button.


If everything went smooth then you should see a pop up screen that says "Executed successfully". Otherwise you will recieve an error to which you can begin your debugging process.

2.2.2 Runtime Workbench - Component Monitoring

The runtime workbench is one of the most powerful and useful features of Exchange Infrastructure. Here we can get very detailed descriptions of errors that may occur with each component of XI. The component that we will want to pay particular attention to is the Adapter Engine.

  • Log into your runtime workbench and select Component Monitoring -> Display.


  • Click the Adapter Engine link.


Here you can view the status of the adapter. If there is an error in your configuration of a particular adapter it will show up here.

2.2.3 Runtime Workbench - Message Monitoring

Follow a similar procedure to display that Message Monitoring.

  • Select your time filter, in this case I will select the last hour.
  • Press Start.


You can now see the list of messages that have been processed by the Adapter Engine over the last hour. On my system only one message has been processed in the last hour. You can press either Details or Versions to view more information about any particular message that was processed.

2.2.4 Integration Engine - Monitoring

This is a particularly useful component of Exchange Infrastructure that allows us to view various aspects of the messages that get processed. Lets start by logging into the XI system and taking a look.

  • Run transaction SXMB_MONI.


  • Double-click Monitor for Processed XML Messages.
  • Press F8 or the Execute button.


  • Select a message and press Display.


You may notice that I have selected a message that coantains an error and did not actually reach it's destination. In Call Adapter -> SOAP Header take a look at Error. If you double click that button a screen will appear on the right hand side that shows the details of the error.
This error tells us that something is wrong with the IDoc Adapter. It tells us that transaction IDX1 contains errors, but in this case the error is actually in the configuration of our communication channel, in which we have made reference to the wrong Port. If you select Call Adapter -> Payloads you can see the content of the XML message that came from MDM.
If you go back to SXMB_MONI you may want to also take a look at the Processing Statistics program that will show a good overview which can be helpful when testing your interface with thousands of materials.

3. Testing

Now we're going to go ahead and test out the interface from end to end. I'm assuming that by now you have turned on the MDM Syndication Server and your XI interface is activated in the Integration Directory. Lets log into the MDM Data Manager and create a new material for testing purposes.

  • Right click -> Add


  • Enter enough data to satisfy your interface requirements (ie: which fields must be populated?)


  • Click on another material to save changes
  • Close the MDM Data Manager
  • Turn on your MDM Syndication Server (if it's not already turned on)

If your Syndication Server settings have been configured correctly then we can assume that because you added a new material to the data manager, it will now syndicate as soon as your interval cycles through (set in the mdss.ini file on your server). Lets go ahead and move over to the Exchange Infrastructure Runtime Workbench to see if it has processed our message. Keep in mind, depending on your interval time it may take a few minutes. Hopefully you should see something like this:
If the runtime workbench shows the message transferred successfully then lets log ino ECC and see if the IDoc was posted.

  • Log into ECC system
  • Run transaction WE02


  • Press F8
  • In the left hand pane, select Inbound IDocs -> MATMAS


  • In the right hand pane, select the IDoc that just transferred and double click on it
  • In the IDoc display, on the left hand side expand E1MARAM and select E1MAKTM


  • Verify that the material data is correct


  • Expand Status Records -> 53 and double click the only record available


  • In the pop up window, copy the message number that was issued to the IDoc
  • Press Proceed
  • Paste the message number that you copied


  • Press F8


You may notice that my image says material 11696 created. This is because a modification was made to an ABAP program to create a material when an IDoc is processed with a certain code. In this blog, the ABAP modification is out of scope, but I'm assuming if you are familiar with ALE then this process should be familiar as well. In any case, this is not a permanent solution, just a temporary solution to finish our prototype. If we take that newly generated material number and run transaction MM02 we should be able to pull up the details on that material.
Press Select Views and select Basic Data and continue.
Hopefully if all went as planned, the material should have transferred smoothly, with no loss in data. This concludes the three part series on MDM and XI. Thanks for reading, hopefully it helps!

XI Configuration for MDM Integration - Sample Scenario

Welcome back. This is the second part of a three part series on integrating MDM with ECC using the Syndication Server and Exchange Infrastructure. I’ve decided to use the MDM Syndication Server in cooperation with XI is for several reasons. First, MDM is not a typical SAP app. The standard ALE approach is not applicable quite yet, because the product has not been adapted into SAP’s usual format; therefore, you can’t set up RFC destinations and logical systems, etc. MDM does, however, offer an ABAP API. From what I’ve heard, this will allow you to integrate MDM with other SAP products like ECC without having to use XI as a middleman. But we gain several things from using XI. Most importantly, it’s the proven method. We know that XI works, but the ABAP API is rather new, so I’d like to let SAP iron out some of the issues before depending on it too much. We also gain the benefit of being able to monitor our messages in great detail using XI’s internal message monitoring and the runtime workbench. Last, SAP is pushing XI as a central hub for all interfaces in and out of SAP.

For this interface, transferring master data from MDM to ECC, we can use XI to perform the data transformation and content conversion. Then, possibly in a later blog I will explore the possibility of using the ABAP API for generating IDoc acknowledgements of the material delivery. Because keep in mind, when you first create a material in MDM, there will be no corresponding material number, so ECC will generate one upon creating the material. We will then need to respond to MDM and provide it with the material number that ECC generated. This will make it easy for us to include some logic in our mapping that simply says “if material number (field) is empty, generate a material number, otherwise edit the existing material”. Make sense?

Now, last thing before we start. This blog isn’t addressing any new topics regarding Exchange Infrastructure. Most likely everything I will go over has already been explained before in another blog on the SDN. However, I would like to go through the entire process of integrating MDM with ECC, and writing this blog must be done in order to do so. Also, there are several pitfalls that I ran into while building out this scenario, and I would like to address them in this blog in the event that they are common mistakes that others may run into as well during their first few integration scenarios. In addition, please pay no attention to my terrible nomenclature in this scenario. I am using a sandbox environment, and the naming convention was not on the top of my priority list, hah.

So here we go…

1. Registering MDM in the System Landscape Directory (SLD)

This has been a topic of discussion that I have seen appear more than once on the SDN forums. It's also raises a few good questions, that unfortunately don't have solid answers right now. The obvious delimna is that MDM doesn't follow typical SAP standards with regards to integration. There is no way to configure ALE in MDM. In other words, you can't configure some of the pieces that are normally required for SAP products to be registered in the landscape directory as an official SAP business system. These pieces include RFC destinations, ALE ports, and logical systems + destinations. However, with that said SAP has provided a means to register MDM in the SLD. It involves using a tool called sldreg.exe, off hand I don't know the unix equivalent. You can find more information regarding the SLD registration here (requires marketplace ID). However, for our scenario, I am going to register MDM the same way we would register a legacy or third party software product in the SLD. The reason for doing this is because (once again) this is the proven method, and we know this way will work.

1.1 Define Software Product

So we'll start by logging into our SLD and defining a new Product, which can be found under the Software Catalog section.

  • Click "Products".


  • Press "New Product Version".


  • Fill in details, such as MDM by SAP, version 500 (for 5.0), then press "Create".


  • Enter a "Name", such as MDM, then press Create. In case you were wondering, it doesn't make a great deal of difference what you type into these fields. Everything will still work regardless of what you name the system in the SLD, just as long as you stay consistant throughout the entire scenario.


1.2 Define Software Component

If everything went smoothly, then you should now be looking at a screen similar to that of the picture shown below. Fill in the remaining information (Name and Version) and then press "Create" to finish making your product registration.


You should then be taken to a screen that looks similar to the following image. You should also see an entry in the "Software Components" tab if you were to click that.


1.3 Create New Technical System

Return to the homepage of the SLD and click the Technical Systems link.


  • Select Third-Party and press "Next".
  • Enter the system name and host name of your MDM server, then press "Next".
  • From the list of installed products, select the software component that you just created.


1.4 Create New Business System

Now this particular step is very important. As I mentioned before, MDM does not have the typical ALE configuration of other SAP products. Well, now is our chance to define the information that we will need in order for XI to communicate with MDM. In this case, we are going to create a logical system name for MDM during the process of creating a new business system. The logical system name is critical, and that is the only thing that XI will use to represent the product when building an intergration scenario, so make sure to make note of the logical system name that you enter when creating a new business system.

  • From the SLD home page, select Business Systems.
  • Select "New Business System".
  • Select, "Third-Party" and press Next.
  • From the System drop down menu, select the third party technical system that you created.
  • Enter a logical system name, and press Next.
  • Enter a name for your business system, such as companyname_mdm, or such.
  • Select the Product and Software Component and press Next.
  • In the "Related Integration Server" drop down menu, select your XI machine and press Finish.

You should now be able to see a screen such as the following when selecting your new business system.


2. Integration Repository (Design)

As most of you probably know, this is where we are going to do two main things. (1) Specify the XML format of the message that comes into XI, and that of the message that leaves XI. And (2) perform the mapping from one XML format to another. But first thing is first, we must start by importing our MDM software component from the SLD.

2.1 Import MDM component from SLD
  • Open the Integration Repository (Integration Builder: Design).
  • Navigate to Tools -> Transfer from System Lanscape Directory -> Import Software Component Versions


  • Scroll down until you reach the component that you built in the SLD.
  • Select the component and press Import.


You should notice that on the left hand column, where the navigation bar of software components is, there is a new item that has the name of the software component you just imported. It should look something like this:


2.2 Create Namespace

Now, I would like to address a question that I had when I first started working with XI, in the event that someone reading this may have the same question. What exactly is a namespace and why is it important? I'd like to first explain by comparing it to traditional software development in an object oriented language. I come from a C background, but have done some development in C++ and C#, both of which can incorporate an OOP (object oriented programming) design. The reason I would like to compare the namespace to OOP is because I imagine that many of the developers out there who are just starting out with XI have probably already previously done some programming and it may make a bit more sense to compare XI to something we are all familiar with. Well in OOP, as you may know, we declare namespaces in order to keep all of our variables organized. This way, if we declare a variable with the name temp1 for example, and then another developer comes along and uses that same variable name in another namespace, the compiler won't throw an error and all will work out fine. The same applies in Exchange Infrastructure. Ultimately we are going to be defining data types, which are sort of like variables. Or more specifically, they are sort of like structures in programming. So, we create a namespace in XI so that other developers can create their own scenarios on the same box and use the same names for repository objects and not cause issues with the ones you create. Makes sense right?

  • Expand the subtree for the newly added MDM software component.
  • Right-click -> Namespace.
  • In the screen that appears on the right, add a new row in the namespaces section and enter your namespace.
  • Don't forget to save!


2.2 External Definitions

So now we will define the data type that is going to be used in our mapping. In other words, this is the variable that I was referring to when describing namespaces. In this example I was working with the MATMAS05 IDoc. So we are going to cheat a little bit, and simply export the XSD (XML structure) of the MATMAS05 IDoc from one of the other components that should be registered by default in your integration repository. From there, we will import that XSD into an externel definition in our namespace. The reason for doing this is so that we have everything we need in our namespace, which keeps organization good. So, for this case I am going to steal the XSD from the SAP APPL component.

  • Expand the subtree for the SAP APPL software component.
  • Expand the second subtree for the SAP APPL *version (ie: 6.00).
  • Expand Imported Objects.
  • Expand IDocs.
  • Navigate to MATMAS.MATMAS05 IDoc and double click to bring it up.


  • Go to Tools -> Export XSD.
  • Save the file to a directory on your computer.


Now lets return to our namespace and import the XSD that we just exported. Seems a bit silly doesn't it?

  • Expand the subtree for your MDM component.
  • Expand the subtree for your namespace.
  • Expand Interface Objects.
  • Right-click External Definitions -> New...
  • Enter a name for your definition, such as MATMAS05, or something similar.
  • Press Create.


  • Change the category to XSD.
  • Press the button next to the File* field to navigate your computer for the saved XSD.
  • Don't forget to save!


2.3 Mapping

For this particular scenario, the mapping is going to be incredibly simple. Because the file that we are picking up from MDM will already be an XML file with the same structure (almost) as the MATMAS05 IDoc. We merely have to make some minor changes and logic additions in the mapping and we'll be all set. If you are brand new to mapping and exchange infrastructure I would highly recommend checking some other blogs as well, that may be more well suited for instructing the basics of mapping. I would recommend this one. I am simply going to show you only the bare minimum mapping that needs to get done in order to make this interface work, assuming there are no special business requirements on the mapping.

  • Expand the subtree for your MDM component.
  • Expand the subtree for your namespace.
  • Expand Mapping Objects.
  • Right-click Message Mappings -> New...
  • Enter a name for your map, such as matmas05_to_matmas05. That's a really bad name, but you get the point ;)


  • Click the icon in the source message section that has a questions mark.
  • Select Source Message -> Search for Repository Object.


  • Navigate to the MATMAS05 external definition that you created.
  • Select Apply.


Repeat this process for the target message as well, using the same external definition. Your screen should now look similar to this:


Now for the fun stuff, the actual mapping. If you are new to mapping, it's rather straightforward, you simply double click on an object in the right hand side (target), and then you can choose to either bring in an object from the left hand side to map with it or use one of the prebuilt functions at the bottom of the screen to work with constants and other transformations. We are going to start by working with some constants. Notice the BEGIN field and the EDI_DC40 context in the target message are both highlighted red. This is because BEGIN is a required field, and the EDI_DC40 context contains required fields below it. This means that those fields must have a value or the mapping will not work. Because the source message is coming from MDM, and won't contain any IDoc information, we have to use constants to fill this void.

  • Double-click MATMAS05\IDOC\BEGIN element from the target message to bring it into the mapping window in the lower part of the screen.
  • From the Functions dropdown menu at the bottom of the screen, change to Constants.
  • Click the Constant function to add it to the mapping screen.


  • Double click the Constant function in the mapping window to bring up it's properties.
  • Change the value to 1.
  • Press Ok.


  • Drag your mouse from the white box in the constant function on the right side, to the white box in the BEGIN element on the left hand side and release.
  • Notice they turn green. You have now mapped those fields.


I am now going to outline the maps to be made for the EDI_DC40 context, assuming that you can follow a similar procedure as above and repeat it with minor changes to the rest of the element's mappings.

(constant)1 :: (target) MATMAS05\IDOC\EDI_DC40\SEGMENT
(constant)EDI_DC40 :: (target) MATMAS05\IDOC\EDI_DC40\TABNAM
(constant)2 :: (target) MATMAS05\IDOC\EDI_DC40\DIRECT
(constant)MATMAS05 :: (target) MATMAS05\IDOC\EDI_DC40\IDOCTYP
(constant)MATMAS :: (target) MATMAS05\IDOC\EDI_DC40\MESTYP
(constant)NA :: (target) MATMAS05\IDOC\EDI_DC40\SNDPOR
(constant)NA :: (target) MATMAS05\IDOC\EDI_DC40\SNDPRT
(constant)001 :: (target) MATMAS05\IDOC\EDI_DC40\SNDPRN
(constant)NA :: (target) MATMAS05\IDOC\EDI_DC40\RCVPOR
(constant)NA :: (target) MATMAS05\IDOC\EDI_DC40\RCVPRT
(constant)NA :: (target) MATMAS05\IDOC\EDI_DC40\RCVPRN

Next we are going to map the rest of the fields and contexts 1 to 1. Meaning, all of the source fields from E1MARAM and E1UPSLINK contexts will be directly mapped.

  • Select the E1MARAM element in the source structure.
  • Select the E1MARAM element in the target structure.


  • Press the mapping button shown in the picture below
  • Say Ok to the warning.


You can now hide all mapping, and then show all mappings to display something that should look similar to this:


Repeat this process for the E1UPSLINK contexts.

The last step involved with the mapping is to add a very simple piece of logic to the MSGFN field, which will represent the IDoc status code. This is a potential pitfall that you can run into when integrating MDM and ECC. Because MDM is not a standard SAP product, no material numbers will be generated for materials that are loaded into MDM for the very first time that have not previously been loaded into ECC. When materials are loaded into ECC or R3, a material number is generated. Of course, in this scenario, ultimately we want to update the materials in ECC whenever a change is made in MDM. So we need some logic that will essentially do something like this:

If a material number exists, map MSGFN field with constant 002
If a material number does not exist, map MSGFN field with constant 005

This is important because we are later going to modify an ABAP program so that inbound matmas05 IDoc with code 005 have a material number generated for them, and a material created. And those with the code 002 already exist in the system and will consequently be modified with the updated material information instead of creating a new one. Obviously, you must be wondering how we will get the material number back to MDM after ECC generates it for the first time. Well, for this we have two choices. We can either create another XI interface using acknowledgement IDoc, or we can use the ABAP API. Either way, we won't cover it in this blog, but I will try to get to it shortly in a future blog. But for now, lets go ahead and add the mapping so that it reflects the following two images:



Our mapping is now done, lets save the message mapping and continue on.

2.4 Message Interface

The next thing we need to do is create a message interface.

  • Navigate to Software Component -> Namespace -> Interface Objects -> Message Interfaces.
  • Right-click -> New...
  • Enter a name for your message interface. In this case I use the terrible name of MaterialMDMtoECC. Which, I might add, should never ever ever be used in a real environment (or anything past sandbox) unless you are interested in losing your job.


Modify the settings to reflect those of the settings shown in the below image, then save the message interface:


2.5 Interface Mappings
  • Navigate to Software Component -> Namespace -> Mapping Objects -> Interface Mappings.
  • Right-click -> New...


In the source interface section, select the message interface that we built in the last step.


In the target interface section, you can simply select the MATMAS05 IDoc from the SAP APPL component.


Then press the "Read Interfaces" button and the rest of the information should be filled in for you.


Save your Interface Mapping, and it's time to move on to the next phase! Of course, don't forget to activate your change list.


3. IDoc Adapter

Before we jump into the other Integration Builder component and start configuring our communication channels, lets go make sure that the appropriate settings have been made for the IDoc adapter. We are going to be using this adapter to convert our mapped XML message into an actual IDoc message and send that to ECC. You would think that you could simply provide the communication channel with the RFC destination and port and it would be able to post the IDoc to the designated system, but unfortunately it's not that simple. But if you have never configured an IDoc adapter, don't worry, it's just as easy as making RFC destiantions. However, I am going to assume that your basic ALE and RFC destinations have already been configured. Also, check this guide for a very good tutorial on configuring IDoc adapters. I am going to go over the setup again here in order to show the exact configuration we need for this scenario.

3.1 Create IDoc Adapter Port
  • Run transaction IDX1 on your XI system (not your ECC system).
  • Press F5, or click Create.


  • Enter your Port name using the format SAPxxx, where xxx is the SID of your target destination. In this case, my target is RS1, because RS1 is the SID of my ECC sandbox environment. Do not deviate from this format, or it will not work!
  • Enter the Client number for your target system. Such as 100.
  • Enter a Description.
  • Enter the RFC Destination of the target system.
  • Save the Port.


3.2 Load Metadeta
  • Run transaction IDX2 on your XI system.
  • Press F5, or click Create.
  • Enter a Description.


  • Enter the IDoc Type as MATMAS05.
  • Enter the Source Port as the port you created in the last step (ie: SAPRS1_100).
  • Save.


4. Integration Directory (Integration Builder: Configuration)

This is the last step in the process before we move on to testing. In this step we will configure the communication channels which specify the IDoc adapter configuration that we created in the last step, as well as the file adapter configuration for picking up the source XML file and processing it.

We are going to start by creating a new scenario and assigning our business systems to a service without party. Basically, this means that we are telling XI which systems we want to talk to.

4.1 Create New Scenario
  • Click the New Object button, as highlighted in red below.


  • Enter a name for your scenario.
  • Enter a description for your scenario.
  • Press Create.
4.2 Create Communication Channels
  • Right-click Service Without Party and click "Assign Business System".


  • Press Continue.
  • Leave the party field blank, and press Continue.
  • Select the business system for MDM and ECC as created in the SLD.
  • Uncheck the "Create Communication Channels Automatically" selection and press Finish.

Now you should notice that if you expand the Business System subtree you will see the two systems that you just added. Now we have to create the first communication channel, which will be the outbound communication channel. Keep in mind, when referring to communication channels, outbound means the data coming out of MDM and inbound means data going into SAP. It's very easy to make a mistake and follow an incorrect naming convention (well, not the standard way) by thinking inbound is data coming into XI, and outbound is data leaving XI. But SAP prefers you refer to your communication channels in the manner that inbound data is data going into SAP. So, our first communication channel I am simply going to name "Outbound".

  • Right-click Communication Channel and press New...
  • Enter a name for the channel, such as Outbound, and press Create.


  • In the parameters tab, in the Adapter Type field press the "Display Input Help F4" button, marked by a blue circle and a question mark to bring up the input selection for adapters.
  • Select the file adapter.
  • Press Ok.


  • Select the "Sender" radio button.
  • I am using NFS, and picking the file up from a directory.
  • No file conversion is needed, so for Message Protocol simply select File.
  • Select Integration Server as the Adapter Engine.


  • Specify the source directory for XI to pick up the file.
  • Specify the filename of the XML file that XI will be picking up.
  • The processing parameters I chose to use are as follows:
  • Don't forget to save.


Now we will build the communication channel for the inbound message to SAP. Repeat the process for creating a new communication channel, but this time using the business system that represents your ECC machine. For adapters, select the IDoc adapter.

  • Choose IDoc adapter.
  • Select the Reciever radio button.
  • Transport Protocol : IDoc.
  • Adapter Engine : Integration Server.
  • Message Protocol : IDoc.
  • Enter the RFC destination created in SM59 for the ECC server.
  • Enter the IDoc adapter port created in the IDX1.
  • I used 700 as the release.
  • Save.


4.3 Receiver Determination
  • Right-click Receiver Determination and select New...
  • Select your ECC business system as the service.
  • Select the interface that was built in the integration repository as the interface.
  • Select your namespace for the scenario as the namespace.
  • Select use virtual receiver checkbox.
  • Press Create.
  • Save.
4.4 Interface Determination
  • Right-click Interface Determination and select New...
  • Enter MDM business system as sender service.
  • Enter ECC business system as receiver service.
  • Select your interface.
  • Select your namespace.
  • Press Create.
  • Save.
4.5 Sender Agreement
  • Right-click Interface Determination and select New...
  • Enter MDM business system as sender service.
  • Select your interface.
  • Select your namespace.
  • Press Create.
  • Select Outbound as your Sender communication channel.
  • Save.
4.6 Receiver Agreement
  • Right-click Interface Determination and select New...
  • Enter MDM business system as sender service.
  • Enter ECC business system as receiver service
  • Select your interface.
  • Select your namespace.
  • Select Inbound as your Receiver communication channel.
  • Press Create.
  • Save.

Now we're all done with the configuration in XI; activate your changelist and you're ready to go! The next part (III) in the series will be focusing on testing and monitoring.

SAP Developer Network Latest Updates