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:
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.
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.