"Kiss of life?" Stop snickering - I’m serious. Several years ago, SAP sentenced ABAP Dynpro to a slow death by declaring that SAPGui and ABAP Dynpro would eventually go away and be replaced entirely by Web Dynpro. This was the general UI strategy, but it was up to each application to make up their own timeline and decide when they would abandon ABAP Dynpro and make the transition to Web Dynpro. New developments were made in Web Dynpro or other web-based technologies, and several applications moved from ABAP Dynpro to web-based user interfaces. In other applications, new functionalities were added, but UI-wise, absolutely nothing happened for years. ABAP Dynpro clinged to life with an iron grip and simply refused to die.
While the original announcement that all ABAP Dynpro would eventually be replaced by Web Dynpro sounded a little hard-nosed, application architects soon began to expose a good portion of pragmatism by drawing demarkation lines right through the applications. For example, in CRM 7.0 the end-users work consequently with a web-based interface, while administrators and configurators do much of their work in SAPGui.
Now this pragmatism seems to be reflected in a changing general attitude towards ABAP Dynpro: ABAP Dynpro is definitely not the go-to UI technology, and SAP will continue to use Web Dynpro as the default UI technology for new developments and replace ABAP Dynpro screens with Web Dynpro and other UI technologies – but nevertheless, ABAP Dynpro has a place in the world and it won't go away anytime soon. Let’s have a look at the implications.
One reason for not killing off ABAP Dynpro entirely is surely the huge number of existing ABAP Dynpros developed by SAP, partners, and customers. It would be immensely expensive and disruptive to rebuild them all in web-based UI technologies, and wouldn’t necessarily add value in every case. After a few years with Web Dynpro, it has become clear that the benefits of browser-based user interfaces (flexibility, ubiquitous availability, small footprint, ease of use) are part of a trade-off and that native desktop-based user interfaces such as SAPGui also have their advantages (speed, offering all the features of a native user experience, optimized user interaction).
So I think it’s smart to decide on a case-by-case basis where each application is going:
It’s safe to assume that market strategic questions will also play an important role:
Now that SAP has faced the reality that ABAP Dynpro will not go away for quite a while, the opportunity is there to address some questions and pain points that have been bothering us for years but seemed transient while we still believed that ABAP Dynpro would go away sometime soon.
Maybe with a commitment the future existence of ABAP Dynpro (even if it’s a niche existence), SAP could perform some overdue renovations.
Allow me to explain.
Two ABAP Dynpro screens that are needed in conjunction are very easy to integrate seamlessly, even if they are located in separate SAP systems.
These are the criteria for a truly seamless dialog integration:
Currently, the integration scenarios with navigation from a web-based user interface to ABAP Dynpro don’t fulfil these criteria. (It’s only slightly better when navigating from ABAP Dynpro to a web-based user interface.)
It’s important to understand that, while Enterprise Portal and NetWeaver Business Client provide a great deal of integration between web-based and ABAP Dynpro UIs spread across your system landscape, the do not bring the seamlessness (new window/tab, F3 problem, result parameters) defined above.
These are indeed technological challenges that require new solutions at a rather fundamental level. I don’t expect them to be easy but I’d love to see SAP give it a try. If they succeed, the results could be truly awesome. They could demonstrate that, while allowing for a wide variety of rapidly evolving user interface technologies – best of breed for each development –, SAP is able provide an unbelievably seamless and consistent user experience.
As an object-oriented developer who sometimes creates ABAP Dynpro based user interfaces, it bothers me that I need all kinds of hacks and workarounds to bring object-orientation to ABAP Dynpro programming. I describe some of them in my recent blog post Get over ABAP Reports, create object-oriented Selection Screens and others in the SAP Press book on ABAP programming I wrote with my esteemed colleague and fellow SAP Mentor Tobias Trapp - links are in the same blog post.
The capability to embed Dynpros not only in executable programs, function groups, and module pools, but also in global classes, would be the very minimum and could probably implemented without much effort.
I’m not even going to ask for a truly MVC-oriented ABAP Dynpro framework and programming model with type-safe interfaces and genuine support for screen polymorphism (similar to the interface concept in Web Dynpro) because that would probably be asked too much in the light of the presumed niche existence of ABAP Dynpro with regard to new development.
I’ll also stop short of dreaming of a floor plan manager and advanced screen personalization options similar to what Web Dynpro and Webclient UI Framework are getting – again, I understand that ABAP Dynpro is primarily going to be supported because of existing applications.
This is a requirement that would add actual value. SAP positions their Composition Environment based BPM (Business Process Management) as a process engine for fringe innovation, allowing customers to easily create and govern so-called Composite Applications: new business processes that combine newly-built functionality (rapidly implemented with NetWeaver CE’s Composition Tools) with the reuse of existing Business Suite functionality in the ABAP system.
In a BPM process, you can already consume web services and Web Dynpro screens that reside in an ABAP system.
Thus, for simple ABAP screens, you already have the option of consuming read and write web services from the ABAP system and the Composition Tools will even help you generate a Web Dynpro Java screen in your Composition Environment. Additionally, you can now choose to build a new screen in Web Dynpro ABAP and use it in your BPM process.
However, some ABAP Dynpro screens are so rich, complicated, and rapidly-changing that it makes no sense to rebuild them either in Web Dynpro ABAP or Web Dynpro Java. The richness of the screen would cause high initial costs and the frequency of change would lead to a never-ending nightmare of unwanted release-dependencies, redundant development, and accidental deviations, resulting in inconsistent data.
In this case, the best option for the BPM process would be to be able to consume the ABAP Dynpro screen directly. This is currently not possible but the connector technology could be written.
It’s technologically possible: Before there was BPM, the Enterprise Portal had Guided Procedures, a now-obsolete process engine that was able to consume all kinds of content, including web services, portal iViews, BSP pages, Web Dynpro ABAP and ABAP Dynpro, while passing parameters and receiving results.
It’s a reality that ABAP Dynpro will not go away anytime soon because in some areas it just doesn’t make any sense to replace it. This means that the integration challenges between ABAP Dynpro and Web Dynpro ABAP (as well as Web Dynpro Java, Webclient UI Framework and other UI technologies) will not go away, either.
Sitting out the problems is now no longer an option – so now’s a good opportunity to start working on the solutions for the most urgent integration problems. It’s an opportunity to not only protect the investments made by SAP, partners, and customers, but also to add great value to them.