Skip to Content

As in real life often happens, nothing works from the first time and you never find the true love exactly when you need it. Searching for the “perfect” partner to share your life with is a long and sometimes painful process. No matter how absurd it sounds, the same rule applies to the SAP Ecosystem. It takes some time to find our, exactly which technologies pair well with others and which you just have to leave out before writing your thousand and first workaround:)

I am about to spare you some time, which you can use for your girlfriend, and try to give you an insight on why I think I found the perfect wedding partners in the face of MDM API and Web Dynpro for Java.

First of all the Web Dynpro technology has become very mature and stable within the SAP Ecosystem. Almost all SAP standard applications are built using this technology and this is no coincidence. The clear message from SAP to the outer world is that Web Dynpro is and will be THE UI technology for future developments. It is also one of the most researched sectors inside the SAP development. Each new release brings up new enhancements and improvements to make Web Dynpro even better than before.

There are three major things about Web Dynpro that make it a perfect match for the MDM API:

  1. It implements the MVC – model-view-controller paradigm, which on it’s turn provides a very clear separation between the mdm model, the business logic of the application and the view mask.
  2. The Web Dynpro context – each MDM API call generates additional traffic to the MDM server, which we well know is anyway under heavy load. The Web Dynpro context provides us with a convenient storage for objects that we already retrieved once, so that we do not have to execute the API call again.
  3. The automatically generated Hook methods of the non-visual and visual controllers – they provide additional flexibility on to when and how do we create the different session of the MDM API and when do decide to destroy them.

I would rather not go very deep into details regarding those 2 points, since then it might take about 10 pages to cover all the aspects that I have in mind. I’d rather give you some real time scenario examples, which hopefully will be enough self-explanatory.

image

The above graphic shows exactly how the model view controller is being implemented regarding Web Dynpro. It has some specifics, which each good Web Dynpro developer should know, but since the topic of this blog is not Web Dynpro, rather its cooperation with the MDM API, I will rather concentrate on it. So how does this MVC bring us closer to the dream “marriage”?

The answer is not an easy one, nor is it easy to be seen. You’d have to have implemented a MDM application with Web Dynpro and only then probably you would understand the real meaning of intuitive, easy and productive development of UIs for MDM. Basically you just initiate your session parameters in the non-visual controller, save them in the context, map the context to the view controllers, bind visual attributes to UI elements, build, deploy and run. This is as easy as it gets.

Potential candidates for saving to the context are often used objects like attribute and repository schema as well as the 3 different session contexts, since exactly those attributes quite certain won’t change at all, or at least not so often within your Web Dynpro application session. Saving them to the context would spare you and your end users quite some time.

The hook methods are probably the best thing that happened to the MDM API since the day it was developed. Especially the wdDoInit and the wdDoExit methods of the non-visual controller seem to be the perfect place to initialise and accordingly destroy our sessions. This way, we can always be sure that we are on the save side and that we haven’t left any open session on the server that just consume CPU time and memory resources until their timeout is being reached.

To shortly summarize all of the above – start small, think big and then change to Web Dynpro, because only with applications that extend beyond reading the fields of your MDM main table you can harvest all the “goodies” that Web Dynpro has for you in store.

 
To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Mausam Kakkad
    Hi Todor,

    A very nice blog. I have been working on MDM project since last 2 years and we are exactly following whatever you have written.

    However, a couple points,
    1. Are you suggesting that we should create a Model (mostly Java Bean)out of MDM APIs in Web Dynpro. Designwise, it seems fine but the issue comes when something new gets introduced and when you have re-import the model with new JAR.

    2. Connection/Session information in context: We have adapted to a method where in we close the session as soon as the operation gets over rather than keeping it open wihle user enters the data on screen. I was wondering after reading your blog, what should be a good way for managing sessions.

    Regards,
    Mausam

    (0) 
    1. Todor Petrov Post author
      Hi Mausam,

      first of all thanks for reading the blog. I would try answering your questions the best way I can.

      1. The JARs are not hard coded and imported in the project, they are only referenced during build time. The runtime reference is deployed on the server, so once you update your server MDM libraries, you’ll automatically get the newest funcitons available in your program at runtime. For the design time, you would have to change the JAR files in your external library, but that is also not too much pain:)

      2. The connection/session information is assumed to last until the user quits the web dynpro applicaiton. In my humble opinion it is always better to leave it open until it expires, or until the user closes the applicaiton, since at one point of time he/she may decide to do something else and then if you had closed the session before, you would have to open it once more. However it all depends on the usage scenario. If you have short usage times for your application, it would make sense to close the session right away and give a message to the user that further operations would require the creation of a new session.:)

      I hope the explanation has helped you at least a bit.

      Best regards,
      Todor Petrov

      (0) 

Leave a Reply