Skip to Content

MDM 7.1: A Pre-implementation Point of View

It was a welcome change when SAP switched back from the Old(MDM4J) to the new MDM Java API i.e. from MDM 5.5 SP05 onwards…, I have myself enjoyed working on and using the new MDM Java API, but when MDM 7.1 was about to go into ramp – up. I started having nightmares…let SAP not bring back the Old(MDM4J) and make life difficult for developers.This one among others has been the primary reason, I have been following up with all documentation on MDM 7.1 available anywhere on the net.

It was such a relief to go through MDM 7.1  release notes,thankfully SAP has gone ahead and enhanced the new MDM Java APIs!! ………much against my fears. Along with MDM API enhancements there are couple of prominent data modeling enhancements:


  • Introduction of the Tuple (Structure) &
  • Multiple Main Table Concept

 ………both of these leading to structural changes within the MDM repository.

The following blog link raises certain questions about the need and performance impacts these changes might have, but most of what is with in this blog. I guess are bloggers pre-implementation fears, primarily based on assumptions. 

Using SAP MDM 7.1 effectively and effeciently

Using SAP MDM 7.1 effectively and effeciently

I did go through most of the enhancements, evaluated the new features over and above feature set available within prior version of MDM(5.5), all this to gauge if 7.1  would have addressed design issues, encountered during my earlier assignments.

In my view,

Tuples , would deliver considerable value for designers, developers & clients ……how ?

  • While customizing the standard Customers repository to meet client requirements, we can create a tuple collection of different tuples.For e.g. the Contact Details tuple constituting different tuples, one for the address, one for phone numbers, another one for e-mail  addresses etc.Unlike a table, a tuple can be defined once and reused many times.
  • This is what the definition says a tuple is like a table which groups together and names a set of related fields but without the actual storage container for the records of the table.Whereas a table creates a storage container for each of the record.

 Hence, facilitating reduction in redundant data via increasing resuability and saving storage space via using dynamic collections or tuples.

To look at the brighter side of Multiple main table concept, consider the following scenario, 

A standard Materials repository design, the organisation has multiple Vendors for material supply, distributed across regions. Each vendor has multiple suppliers(table) for raw materials, tables for maintaing their customers and related details.   

Given the scope of and features available with MDM 5.5, in an ideal scenario one would like to set up two different repositories Vendors and Materials, in process overlooking the amount of redundant data this kind of design would have to store.Multiple repositories in a scenrario invite further complexities w.r.t 

  • Creating and maintaining multiple portal system objects.
  • Configuring mdm business packages to fetch data from multiple repositories, for a certain use case can be quite a challenging task.   

Mutiple Main tables in a repository, would help us to overcome the disadvantages pointed above, i.e. it makes way for a clean, better and efficient repository design which would lead to better UI design in turn a better end user experience.

Since the major structural changes have already been discussed above, there are few more noticeable enhancements, which I would like to mention:

  • Integration into Solution Manager, thus providing for the central point of administration for the basis team
  • Enhanced Inbound & Outbound processing, primarily with support for parallel import processes and enhancements in the syndication performance w.r.t parallel syndication
  • For PI folks there’s a new MDM PI Adapter, and for the custom developers there are enhancements in the  MDM ABAP API, new MDM Java API (to support tuples and multiple tables, amont others), new MDM .Net API and the new MDM Publishing API.  

MDM 7.1 is out with a number of other enhancements, details about one’s discussed here and others can be fond out at the service market place URL provided (SMP login required).  

While the questions & concerns raised by my fellow blogger in the blog link included above, might be genuine to an extent (I will try and answer those, in the post-implementation version of this blog). But in my point of view MDM 7.1 would enable better, faster and efficient MDM implementations, deliver value to our clients and would give us opportunity to do some interesting work and deliver better quality.

You must be Logged on to comment or reply to a post.
  • Good blog Paras. While I agree with most of what you have mentioned, I am not sure how multiple tables in the same repository would help reduce Portal configuration time. I guess we’ll have to wait and watch! 🙂
    • Thanks Anant……, stay tuned for a Post Implementation Point of iView, I will be able to provide facts and figures…:)