SAP MDM Training-SAP MDM Tutorials,SAP MDM Jobs,SAP MDM Resumes-SAP MDM: Oct 28, 2009

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.