Skip to Content

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

To report this post you need to login first.

13 Comments

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

  1. Luke Marson
    An interesting viewpoint on how an “old” technology still has relevance in the Web 2.0-orientated world. Going full-on web based with UIs doesn’t offer value to many people as you pointed out. It’s good to see SAP recognise this and not try to end the functionality as they had originally intended.

    Keep up the good work!

    Luke

    (0) 
  2. Clemens Li
    Thank you for this excellent analysis of pros and contras of existing UI technologies.

    Regarding integration of object-oriented UI technology (thank you for that blog) I’d like to add my wishes for a better integration of GUI controls and their respective events. For developers it is always somewhat difficult to distinguish between dynpro events like PBO, PAI, value and help request and control events with similar or comparable functionality.

    (0) 
  3. Olivier CHRETIEN
    Very goos blog here.
    I completely agree that Abap dynpros will stay for a long time in such systems as ECC.
    But, in my opinion a redesign is much needed.
    A lot of user frustration comes that the dynpros were designed years ago when the standard screen resolution was very low compared to now (640×480).

    A lot of dynpros, especially for ALV lists, are much too small and display too few information at once. As the size of dynpro cannot be dynamically changed, it is needed to modify these dynpros to increase their sizes.

    An other part which needs to be adressed to keep dynpros is the quality of translation which is very bad specially for French. We often have to translate “SAP French” to standard French to our French users…
    Often there is also space to display full text but only abreviations are used.

    The bad impression that dynpro UI gives to users (they are used to web 2.0 now…) could be bettered a lot with these 2 changes : better dynpro sizes and better translations…

    Web dynpros could also benefit from the same 2 changes : a lot of times web dynpros just look like sapgui in a web browser and the lists are so frustrating (only 6 lines displayed on a huge browser screen and the need to click hundred of times on the next page button).

    Olivier

    (0) 
  4. Sergio Ferrari
    This is another of your interesting blog, Thorsten.
    In add to be very well written and much informative, I wonder to understand which is your real goal.

    Maybe I’m wrong but I got the idea that your asking support from the community to send a soft request to SAP in order to improve the integration between Web Dynpro ABAP and ABAP Dynpro and Reporting?

    If I’m right, you found one more supporter.

    It was 2007 when together with colleagues I realized a Web Dynpro for ABAP to deliver alternatives to SAPGui transactions FB01 and FB05. In other projects we realized something similar to VK12, XK02, MM02 in add to several reporting functionalities related to various kind of documents (sales, purchasing).
    Then it was the time of Flash Islands but yes, after years of experiences, the integration between SAPGui and WDA is still a source of trouble.

    In the new SRM 7.0 WDA taken the control leaving, as you said, SAPGui for the administrators and developers.

    There are several nice to have feature about the integration between WDA and SAPGui and I list here some of them.
    My personal dreams:
    – SAPGui integrates WDA : please support Web Dynpro applications within SAPGui (about FM WDY_EXECUTE_IN_PLACE see OSS notes 1388562 and 1388392). SAP Portal and NWBC are often not used/configured/installed on customer site and the proposed solution to open a new browser window cannot be considered a very tight intergation

    – WDA integrates SAPGui : In add to the Flash, SilverLight, HTML5 Islands what about to have a SAPGui Island providing some powerful integration between the two worlds

    – Back (F3) in WDA : The support for the navigation stack in SAPGui Dynpro is fantastic thanks to statements like CALL TRANSACTION … AND RETURN, the SUBMIT .. AND RETURN and so on so forth. Indeed ‘Back’ is the second more used command in Internet too (the first is the click on hyperlinks). The pity is that on one side the WDA stateful implementation is not compatible with the browser navigation (Back/Forward) and that the typical SAPGui navigation has not been implemented within the WDA framework to be such easy to be used. The SUSPEND & RESUME technicque (http://help.sap.com/saphelp_nw70ehp1/helpdata/en/45/19bf8c16f25d7ae10000000a11466f/content.htm) is a bit more complex then the way available in old ABAP Dynpro environemnt and it is even more complex if you want to integrate WDA with ABAP Dynpro transaction

    I still remember one year ago when the fantastic guys from NL4B (http://www.nl4b.com/) showed enhanced integration between the different technologies, what a dream.

    To close this long comment (sorry for that), I like the idea of SAPGui for administrators and developers and WDA for the extended community that’s way I always laugh when lunching /nSOAMANAGER.

    (0) 
    1. Thorsten Franz Post author
      Sergio,
      Thanks a lot for your thoughtful comments and the interesting links and notes. I knew WDY_EXECUTE_IN_PLACE but not that there was a note discouraging its use.
      Could you please point me to a link about what NL4B did to enhance the integration between different technologies? I couldn’t find it on their website at once.
      Thanks and cheers,
      Thorsten
      (0) 
      1. Thorsten Franz Post author
        P.S.: Yes, my intention was to get feedback from the community and show to SAP that the pain points are real and the demand for a solution is there.
        I think in a company like SAP, many smart people will have arrived at the same conclusions. They do their best to anticipate and resound what customers and partners really need but I know from many discussions that sometimes it is hard for SAP employees to be heard even if you say the right thing.
        We as customers and partners sit on the other side of the table and voicing our requirements may “ground” the discussion and accelerate it a bit. So that’s also what I’m trying to do.
        Cheers,
        Thorsten
        (0) 
      2. RA Eijpe
        We, from NL4b, don’t published our integration possibilities on our website, because our customers are not interested in technology, but solved solutions.
        But in our presentation on technical events, we showed and present we can solve almost all SAP integration issues. We connect all kinds of Adobe and SAP technology with each other and connect SAP systems to a lot of different non-SAP systems. If you want to know more, please sent us a email.
        (0) 
  5. Michelle Crapo
    We have ABAP Dynpro and ABAP Web Dynpro.  Integration between the two would be a nice feature.

    An update the ABAP Dynpro!  Wow – it boggles the mind.  That would be awesome.  It really hasn’t changed a lot over the years.

    We are still using ABAP Dynpro in maintenance mode, but also creating new ones.  No support for ABAP Web Dynpro yet for our RF Devices.

    Good blog!

    Michelle

    (0) 
  6. David Lees
    Hi,

    A further point probably worth adding is that the NetWeaver Business Client offers a unified environment for our different UI technologies including standard GUI.

    Cheers,
    David

    (0) 
    1. Thorsten Franz Post author
      Hi David,
      Thank you for pointing this out – I believe NWBC is mentioned twice in the weblog, but more in passing as the focus is primarily on what integration capabilities would be required beyond the very good features that NWBC is currently offering. It was important to me to make a point beyond the simple message that NWBC solves all the integration problems between ABAP Dynpro and Web Dynpro. 🙂
      Cheers,
      Thorsten
      (0) 
  7. S. ERPentine
    Hi Thorsten,
    your Dynpro wish list blog made me re-activate my long forgotten SDN-user.

    Indeed, a renovation of ABAP Dynpro would be highly welcomed by most SAP customers and partners.
    While the ABAP language itself was enhanced with new features over the last years (thanks for that!), the ABAP Dynpro has fallen in a deep sleep about 10 years ago. Let’s hope, that this will not last 100 years as in the Dornröschen fairytale.

    And yes, the integration of WDA into the SAP-GUI would greatly help during the transition towards new UI-technologies. Sure, it is not the perfect solution, neither from a technological point of view, nor for Ux. But technology advancement is like evolution, things are never perfect. And there is F3 already.

    So for your wish list ++ or to say it in ABAP + 1.

    Silke

    (0) 
  8. Neil Butler
    Isn’t ABAP Dynpro the exact amount of UI technology an ABAP coder can handle? If anything, the slow death of Web Dynpro shows that MVC is beyond the reach for the business programmer. Your wish list is fine. But you would overwhelm most of the code slaves using ABAP.
    my 2 c
    (0) 
    1. Michelle Crapo

      REALLY!!!!  Overwhelm?  Code slaves?  Wow – is that the way you truly think?  Or are you waiting for replies?  That it may fry my little brain because I will never learn and use new technology?  We’ll I guess a lot of us have our little brains fried and we still function.

      (0) 

Leave a Reply