After the initial problems of downloading MDM SP02, we were finally successful in getting the server up. However the tricky part is getting the iViews. Because unless the standard business packages, MDM gives you couple of .SDA files which when deployed will get the MDM connector up and some MDM content on the EP stuff. It will not give us ready made iViews which we can start using immediately. And there are good reason behind the same. The reasons are that the repository will be different from customer to customer and so will be the data model. So, the iView has to pick fields from the specified repository and then build the screen. In order to do that, the standard thing that you will have to do is to create a MDM system on the Enterprise Portal, where in you specify the MDM server details and also specify which repository you want to connect to. Once that is done, do the user mapping for the MDM system. Now, coming to the creation of iViews, what SAP gives you as standard are the following iView types for MDM. The following is the screen shot taken from what will be displayed in EP while you are creating the iView. (I did this because I don’t have to type the list myself). image You might be wondering what each of these mean it looks different from the standard iView types that usually see for R/3, CRM etc systems. Let me try and explain the same. The following 4 are meant for customizing the search criteria. MDM Search Hierarchies - This iView will allow you to search the data by any look table that you have defined as Look up –Hierarchy. So, while creating this iView it will prompt you to enter which Hierarchy table you want to use, if you have multiple. image MDM Search Attributes - This iView is to search on the attributes of your product. However, this has the dependency as it requires a Category so that it can take the list of attributes for that category. image Now that we have chosen the category, the iView that we have created by specifying the table. In the above picture, we have selected Goggles as the category. So, below we see the attributes of the Category. I have tried to show that it also lists the possible of each of the attribute, so that if you want to further narrow down your search, you can do that too. image MDM Search Picklists - This is more or less a straight forward search on a specific column of your main table in the repository. In this case I have chosen Manufacturers. image MDM Search Texts This is the best iView that I personally like. Here you can search by a Keyword. image Now comes the fun part, as I have narrowed down my search, where is my list of product list being displayed. This happens in the MDM Resultset iView image Now, we need to keep in mind that these iViews are interdependent on each other. The data is the filtered data which you have done in the other iViews. While creating this iView you can select what are the fields that you want to display. MDM Item Details This is pretty straight forward, once you select the radio button in the resultset iView, this one shows all the details of the product. In this also, while creating this iView you can select what are the fields that you want to display. If the product has got attachments, they will appear as hyper links, and once click will open the corresponding document. image Oops, I almost forgot about the last iView type – MDM Search States What this does is that it will tell you what are the search criteria the user has applied. image image If you want to remove search criteria, its pretty straight forward, just click on reset search for the specific field or the button for resetting the entire search criteria. So, from a Catalog management perspective we are good to go. We need to remember that the standard functionality given by these iViews are only Search and Display. If you have business process that requires extension for the same, we need to enhance this. In further continuation for learning process of MDM, we will see about the process of synchronizing data between R/3 and MDM using Syndicator and XI.

Often we come across the dilemma of which adapater should I use while integrating with SAP systems. Will try and discuss on the options available and what could be some of the points that one should consider before you zero in one of the adapters. If you see the list of Adapters given by SAP, a quick seggregation can be done depending on the type of systems that these adapters are going to communicate with. Now, one of the obvious systems with which XI is going to communicate will the SAP systems (SAP R/3 - 4.6C, 4.7, ECC 5.0, CRM, SRM etc etc). Now these systems could be on the sending side or on the receiving side or could be on both sides where R/3 is integrating with SRM / CRM .... or vice versa. So, what are the options that SAP gives us to communicate with SAP systems. 1. IDOC Adapter 2. RFC Adapter 3. Proxy Now, how do you choose the right one for a given scenario. One of the things that SAP strongly suggests is the usage of PROXIES. Now, if you take a close look at the adapters specified here, the one thing that strikes right away is the usage of proxies. We know that proxy generation is possible only if your WAS is >= 6.20. So, that is one parameter that comes up straight away for the usage of proxies. -- Use Proxies only if the WAS version is >= 6.20. We will also look into other reasons where we should go for a proxy. Let's take a case and discuss the same. The immediate question that probably you are getting is : I am on WAS 6.2 or higher and also at the same time either I have a standard BAPI / Remote enable function module for the given functionality on the application system. So, what should I do now? In this case, there are 2 ways in which the implementation can happen. 1. Configure a RFC Adapter and call the BAPI / RFC. However the potential problem that I could see is that the RFC adapter existing on the Java stack communciating with the BAPI existing on the SAP application system. 2. The second option that I have got is to write a proxy on the SAP application system (which will be called by XI) and internally the proxy will call the BAPI. At this point of time if your question is, as long as I am dealing with the latest versions of SAP systems, should I totally avoid using RFC Adapters - MY TAKE on this would be, YES. Do NOT use RFC Adapter, rather go ahead and use the proxy. However, the problem could be that the pre-built meta data and the mapping that SAP delivers might not be useful as the BAPI is wrapped with a PROXY now. But as the proxy is also expected to have the same message interface as that of the BAPI, we might still be able use the pre-defined mapping. This is something that we need to try out and then decide how do I go about this interface. But for whatever reasons, if you are not getting advantage of the pre-defined integration content, PROXY is the way to go. Now, if you are dealing with SAP systems < 6.20, we do NOT have choice of PROXY anyway, so go ahead and use a RFC adapter. Now, as far as the IDOC adapter is concerned I think the choice would be straight forward. Where ever there is a standard IDOC given by SAP (usually mapping also will be delivered for SRM / CRM system integrations), so go ahead and use the same. The questions that you might be having now is that for a standard object if I have an IDOC as well as a BAPI, which one do I go for. My opinion would be its going to be dependent on the specific scenario that you are trying to develop. We can think of multiple variations of design for this case. For Exapme
1. Send one IDOC at a time.
2. Club multiple IDOCS and send as a single IDOC.
3. Make one single RFC call, for each business transaction.
4. Avoid making multiple calls to the same BAPI / RFC, rather have a wrapper BAPI and send all the records in one time.
5. Use the PROXY and send all the data in one shot and make single calls to the BAPI from the PROXY on the application system - only if you can use PROXIES.
The biggest advantage of the proxy is that it always by passes the Adapter Engine and will directly interact with the application system and Integration engine - so it will and should give us a better performance. So, there are the choices that you have while designing a SAP interface, so take a close look at the interface and identify your priorities for the interfaces. The parameteres could be some thing like PERFORMANCE, ERROR LOG, AUDIT LOG, MONITORING OF THE TRANSACTIONS INDIVIDUALLY. Do a comparison of the pros and cons of the choice of adapters that you have for the parameters for the specific interface and then make a call. Initially, it might look alike - what's the big deal, its a simple case of sending / receiving data from SAP - especially if you are coming from R/3 world, but bellive me, you have got good chances of landing up in trouble, if you don't take care of your priorities of the interface.