"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.
The reasons
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:
- Is it a new development?
- What are the requirements for UI integration with other applications – and on which UI technologies are these bases?
- Does the application’s UI need a major overhaul anyway?
- Are there user types that would benefit from accessing a browser-based solution?
- How disruptive would the move be for most customers of that application?
It’s safe to assume that market strategic questions will also play an important role:
- Is the application strategic and has the potential to win customers, thus increasing SAP’s market share? (Or does SAP think they have made all the money they can in that particular field or industry?)
- Is the application important for defining SAP’s image in the eyes of analysts? (For example, a few years ago SAP absolutely needed to have a web-based CRM or industry analysts would have written of the entire SAP solution suite off as outdated.)
The signs
- Some time ago, SAP stopped saying that all SAP applications would eventually go away from ABAP Dynpro so that SAPGui could eventually be discontinued. Instead, recent UI strategy messages stressed the variety of UI technologies and how something was in the basket for everyone.
- On the one hand, new applications are done with Web Dynpro and even very old applications are redone in Web Dynpro or Webclient UI Framework. However, EHP after EHP, new business functions adding functionality to existing ABAP Dynpro based applications were done in ABAP Dynpro.
- With NetWeaver Business Client, SAP has invested heavily in a user interface technology that integrates ABAP Dynpro and web-based UIs, leveraging and stressing the advantages of the native user experience with local Web Dynpro rendering.
- A few days ago, I learned that SAP has concentrated the responsibility for their user interface technologies in one product management organization that is responsible for the entire breadth of UI technologies. I believe that this is the right step towards a user interface strategy that is consistent, with an emphasis on pervasiveness and integration, while allowing for rapid innovation and special solutions – goals that are not easy to pursue at the same time. Putting all the strings into one hand offers the opportunity to harmonize, integrate and, where special solutions are required, rope off the various user interface technologies, and tackle some long-dormant challenges.
How is this an opportunity?
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.
- Create a truly seamless dialog integration for ABAP Dynpro
- Better support for object-oriented ABAP Dynpro programming
Allow me to explain.
Create a truly seamless dialog integration for ABAP Dynpro
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:
- One can easily call the other in a seamless screen flow in which one screen follows the next.
- Navigating to the second screen will not open a second, disconnected window (which would break the seamless dialog flow because F3 (back) is not possible in the second window, the user can prematurely navigate away in the first window, and there is no communication between both windows).
- The dialog flow is consistent because F3 (back) will always work.
- The first screen can pass parameters to the second screen (e.g. display business partner 123 in dialog mode edit, create a new business partner with certain default values).
- Upon completion, the second screen can pass parameters back to the first screen (e.g. success or error messages, creation of the new business partner successful, number 124 was created, or creation of the new business partner was aborted).
- The glue code is not a custom hack or copied and pasted from ingenious SCN blogs (cheers to the incredible Gregor Wolf!), but from SAP and well-supported if something goes wrong.
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.
Object-oriented ABAP Dynpro programming
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.
A man can dream, can’t he? MVC, Floorplan Manager, Personalization
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.
Consuming ABAP Dynpro screens in BPM processes
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.
Summary
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.
