What about the good old Dynpro?
Call me conservative, call me old-fashioned, call me unprogressive – but I still don’t get it! I’m talking about SAPs User Interface Roadmap and/or Strategy – especially regarding development in and for SAP ERP – the system environment I am most familiar with, so with this disclaimer let’s start with some thoughts on UIs, business processes and custom development.
A couple of years ago, the SAP world for its customers and users was so simple! There was the SAP GUI with its now “outdated”, proprietary programming model Dynpro for creation of user interfaces. It undoubtedly had an has some major drawbacks – mainly the various limits regarding user interaction and experience, which had mainly been overcome with the introduction of the enjoy controls. Together with the control framework, SAP GUI had again become a environment for efficient, rich, highly integrated user interface development with high performance.
- Efficient development: If you take the different use cases for UIs in a ERP system into consideration – reporting via selection screen and list output, creating, editing and displaying business objects and their relations – old UI techniques like selection screens together with its variants in combination with modern controls like ALV, Tree, Split Screen a.s.o. provide a very effective way for the user to handle his or her business data. Simple reports, data maintainence views, complex business transactions (either single screen or multi-step) – everything built with proven, stable technology and high developer efficiency. And – not to forget – if you need/needed a developer or consultant, you always get/got one – try the same for SAP UI5, WDA with FPM or the unspeakable Java-based technologies.
- Rich user experience: Okay, I admit that SAP GUI as a frontend is not what the standard iPad user would call fancy or user friendly. But has it to be fancy and is it really not user friendly? SAP GUI was always and is still meant for daily business processes – from mass data processing to handling single business objects. No app experience needed here as far as I can see. Icons and pictures where necessary, colors where needed – e. g. for status display. Right click, double click, Link click, Drag & Drop, menus, context menus – everything available but a colorful UI itself with everything floating, moving, blinking. Does such a fancy UI really add business value to the software-support of a business process? I highly doubt it.
- High integration: The main ERP processes are – and as far as I can see will always be – implemented as SAP GUI transactions, from HCM over Financials and Project System to Material Management and Sales. So in case you want to adapt a SAP delivered GUI program you always have the largest variety of enhancement techniques – from the UI itself to the possibilities for user interaction and the ABAP-based functionalities. Create a custom program and provide access to SAP programs? No problem. Call a custom program from a SAP program. The same. Try this with WDA and SAP GUI for HTML and enjoy the experience!
- High performance: You don’t expect me to compare DIAG with HTTP, do you?
So, the question for me is the following:
Why does SAP push itself and its customers to use Web-based technologies like WDA, FPM, CRM Web UI, SAP UI5, Web Dynpro Java, Guided Procedures, JSF, Adobe Interactive Forms – and what was this SAP Portal-based code generator called again – with more than the half of these programming models called obsolete just some months after the first painful customer implementations set productive?
Why not continue development of core technologies like Dynpro and Control Framework, for which customers have spent lots of money in consulting, development, in- and outsourcing know how and in which they now have to maintain a large code base?
Just my 2 cents!
PS: In case you didn’t guess it yet – I just finished my first big project with WDA!
I have always wondered about this.
Web Dynpro was always pushed as the "replacement" for everything that ran in an SAP GUI, but it is not really a replacement as it runs in a web browser, hence the name, as opposed to the GUI. A real replacement for DYNPRO, for example, would be something that runs in the GUI and is more MVC aligned.
Horror of horrors, sometimes running in a web browser is not the be all and end all. It's slower, I'm sorry, i will be burned as a witch for saying this, but it is. In my companies system whe I am in SAP GUI everything is fast as lightning, except when I am in BRF plus, a Web Dynpro application, where I spend half my time staring at a big whirling circle. Whatever happend to the hourglass, not good enough was it?
If you want to replace something it has to do what the original thing did, only better. SAP often offer "replacements" which are quite different than the original and then get puzzled when people don;t jump all over them. It is rather like the new SALV model in ECC6.0 where you can't edit the data, so you have to go back to CL_GUI_ALV_GRID (in fact there is a way round that, not that I ever said such a thing).
Beauty is in the eye of the beholder, but does Web Dynpro ABAP really look better than the SAP GUI, or are they just both hideous gray things? My first impression of Web Dynpro was it was just as ugly as SAP GUI but just different enough to confuse the hell out of the user.
The other very good point you raise is the short shelf life of the new technologies. Just last year I had an ECC6.0 system for the first time, so I started mucking around with Web Dynpro. I had just got a simple demo application going, and was trying to work out how to stop it asking for your password every time (something I still have not solved) when out comes the news that REALLY we should be looking at UI5, this Web Dynpro nonsense is so ten minutes ago.
We spent a lot of time and money putting in the Web Dynpro Java things for the HR applications in the portal and the INSTANT we were finished we had to take it all out againa nd replace it with Web Dynpro ABAP, due to the upgrade. Strangely the "archaic" DYNPRO applications stting in R3 were unaffected.
I feel a lot better now, i am sure 99.9% of people will disagree...
Cheersy Cheers
Paul
Paul,
it' s amazing how stories look alike all over SAPs user groups.
I first came into contact with ERP during the upgrade of an 4.7 Enterprise system, when all the ITS-based ESS scenarios weren' t supported anymore. Get yourself together, install a Portal, a NWDI and the shiny new WDJ with the Homepage Framework (can anybody remember this) and these marvellous Interactive Forms, SAP said.
So we did - and it was a horror, even though I started my SAP career with Java development (which were basically some neat demo programs where everything worked superfine). How to get the enhancements and modifications out of the previous ABAP-based applications into the WDJ services? There were cookbooks, tutorials, lots of good advice in SDN - but nothing that would work at first hand.
Finally, after getting the whole mess productive, SAP started its EHPs - and the replacement of WDJ and Interactive Forms in ESS with WDA - first saying that WDJ will be supported until the end of time. A couple of EHPs later, the last WDJ application was replaced, Portal wasn't needed anymore - and everything had to be done with WDA.
So, people started moving their adapted WDJ applications back to ABAP and WDA - not to forget that this meant bringing the SAP system as a web server somehow into play.
Now, after migration of WDJ back to WDA the first slides appear saying that UI5 was and will be the only technology needed for user-centric UI development anymore.
Now, WDJ is as dead as Interactive Forms are - and this for a good reason, and maybe WDA is next, as well as UI5, ADT in Eclipse, BRF+ and all the other wonderful new gadgets.
And while the poor guys that are still in HCM service delivery silently suffer, developers in logistics and financials can lay back and have a pitiful smile on them knowing that their modules will remain stable and basically the same until their retirement.
Regards,
Thomas
Thanks for showing the courage for going against the tide.
I'm working with the "classic" technology since 20 years, in recent years I got in touch with WDA via SRM 7.0 and TDMS 4.0. While I clearly see the advantage of the forced MVC-style "separation of concerns", I am much less convinced of the performance and complexity aspects. If I put a breakpoint in my SRM BADI implementation, I'm stopping 40 levels deep in the callstack, with loads of HTTP-request, FPM-framework and specific /SRM/-framework levels on top. Can this be more robust than the classic technology? Debugging has become much trickier. Is a certain problem caused by customer enhancements or by a bug in the multi-level frameworks?
In my humble experience at various clients, regular and power users prefer the classic SAP GUI at any time. The "average" manager who approves a few shopping carts per week however is probably fine with the browser access and does not require a full SAPGUI installation (and a more costly license, if I am correctly informed). So as always, "it depends..."
As a conclusion I'd like to think that both old and new can live quite well together, and I am hoping that SAP will not abandon the proven and robust technologies too soon, even if only for the sake of my crusted old braincells 😉
Thomas
Thomas,
I totally agree with you on the necessity of different ways of access (call it multi-channel or whatever) to a SAP system; let there be a browser-based technology, a mobile one and a fat client, namely the SAP GUI - but let them be equal before the law. 🙂
What I cannot approve is the bad habit SAP showed in the recent years when it came to the field of UI technologies. Push a new, half-baked technology on the market and state that everything before has become obsolete. This is not what SAP stood for during decades - namely protection of customer investments.
Let the labs try out new things, let the developers have their fun, too - but keep the basic technologies like Dynpro and Controls alive, for customers sake!
Regards,
Thomas
Can't wait for your next blog: "Why use Adobe forms or even Smartforms? SAPscript is the way to go!"
Jokes aside, you do raise a few good points, especially concerning the ever changing SAP "default" UI technology.
I think that with the Screen Personas, Dynpro might have a revamp
Cheers,
Custodio
Custodio,
Thanks for the input. I already started working on that.
Your' re right - the most annoying thing is the SAP UI Roadmap itself - if I only had kept those of 2004/5, when I started with the WDJ topic. They would definitely have a certain amount of entertainment value today!
And I am quite curious on the development and adoption of Screen Personas, too.
Regards,
Thomas
Ok, can't have everyone agreeing here that the old stuff is so good!
My point of view:
Dynpro solution is ugly, mostly not written in an MVC manner, prone to global variables and horrible to maintain and enhance. It does not work properly on anything other than a windows PC (Java GUI is horrible to work with when you are more than a casual user).
Customers that sit at their desks running processes on big monitors all day are likely to be the ones going out of business as the more nimble mobile based, faster to respond companies take all their market share. UI that can be consumed on multiple platforms (including and importantly touch based mobile solutions) is becoming more and more important. The newer UI technologies enable this. WDA is able to run on your iPad if you restrict some UI elements! And UI5 can run on just about anything.
I do not think "both old and new can live quite well together". The old solutions have had their time, where possible they should be replaced with new UI to enable businesses to adopt new ways of doing things, by encouraging old Dynpro options SAP would be hamstringing their ability to build competitive solutions.
In the HR area where I work having a good UI is incredibly important. It is no surprise that HR have been the early adopters of most new UI techs (which causes pain!) Having a poor fully Dynpro based UI would loose sales (and has done - hence adoption of new UI techs!)
Thomas Z -> remember debugging dynpro doesn't expose the internal guts of the GUI rendering engine, so you aren't really comparing apples! Why are you not worried that the GUI rendering engine is the cause of your application error when you worry that the WDA code might be? This isn't apples and apples either to be fair 🙂
Paul -> are you now finding that some of those archaic dynpro screens are being replaced? Just because the latest UI technologies are changing rapidly (witness the landing pages in UI5) does not imply that the less often used transactions are better, just less worthy of being upgraded.
The SAP best built apps guide clearly states:
and also recommends that amongst other techs you don't use Dynpro. It is a shame not everyone follows it.
Although I did throw my hands up in despair when the Gateway team built their new solution using dynpro. When I queried them on this, they said that they did that because that's what their team knew. 🙁
I don't think any of the UI techs are "half-baked" (and I'd challenge you to justify that statement!)- including Dynpro. But I do believe that a change in the way businesses are working, empowered by mobile technology, is going to mean that tying a user to a keyboard and PC which is what dynpro would do (unless we wrap it in Persona) is not a good idea.
Anyway SCN is flashing internal server error messages at me, so I guess that is a hint to hit the add comment button and finish up!
It was an well put together blog, even if I didn't agree with it. 🙂
Cheers,
Chris
this is a nice video that I'm sure you won't like 😈
[embed width="425" height="350"]https://www.youtube.com/embed/qakdu8DrzkI[/embed]
Chris,
Thanks for your comments - and thank goodness not everybody is in line with my opinion (where would the fun be otherwise).
Regarding MVC: There are some pretty cool examples of Thomas Jung on how to apply MVC design pattern with in function modules encapsulated screen dialogs - something that SAP itself made use of extensively. Of course you will find some pretty old and ugly stuff in the module pool world - select at pbo, update at pai.
You will come along a very colourful mix of good and bad, old fashioned and red-hot development habits in every big software system that has reached a certain age and been developed by generations of programmers.
What I do not agree on is that WDA itself with its programming model enforces good structuring, encapsulation and reusability. The existence of a component controller entity doesn't t automatically mean that developers use it for controlling the program flow. Just because there' s a view controller entity won' t necessarily mean that all user I/O activity is being handled through and by it . The WDDOMODIFYVIEW method is the best example on how to break the wonderful design approach of separating layout from coding.
I have seen some smaller one-component WDA custom applications which used to put all database handling into the assistant class. What' s the benefit of that compared to the module pools of previous times? They are very application specific programs, these helper classes, and do not really encourage code reusability.
Regarding half-baked technologies: I consider the whole Java-based development approach and the integration of its servers into SAPs system landscape to be that way. Just think of the first Portal development techniques, the pain-in-the-butt "adaptive RFC" in WDJ or the funny enhancement strategy for WDJ based ESS scenarios.
And finally SAPs guidelines - well, they of course state what is SAPs current approach - I wonder what they will look like in 5 years or so. As a customer, we simply cannot afford to jump on every technology train that leaves Walldorf in a new direction.
Regards,
Thomas
Last week in Sydney it was the "Optus Vision 2013" one day conference and it was brilliant, and they didn't try and sell you anything it was just so called "thought leaders", all about the gigantic leaps forward being made right now in technology. I came away filled with hope for the near future.
How can I feel that way and still doubt the wonder that is the replacment of the ugly SAP GUI DYNPRO screens with the equally ugly MVC WDA screens?
If the predictions come true and in a few years everyone is using mobile devices instead of laptops and PC's then yes, UI5 or whatever the user interface of choice that week is will be the way forward, if SAP can truly find a way to decouple the user interface layer from the current SAP release, as they claim they will be able to..
But let us just say, for the sake of argment, that the old fashioned companies which flaty refuse to use a Web Browser for their standard SAP transactions, because of, for example, performance issues, don't go out of business in the next five years. Difficult to imagine I know, but let's say.
There is not actually any replacement for the DYNPRO technology that runs in the SAP GUI? Or have I got that wrong? I don't mean ALV grids I mean interactive things like VA01.
So to answer your question, no, I have not seen any archaic DYNPRO standard SAP transactions like VA01 get replaced in the SAP GUI world, because there is nothing to replace them with that does not run in a Web Browser. Or am I missing something obvious?
Cheersy Cheers
Paul
PS Thanks to Thomas for startng this emotive deabte. That is what SCN is all about.
I'm a bit torn at the moment. On one side I HAD a lot of fun developing applications with WDA/FPM and HAVE fun developing with SAPUI5 (in my spare time!). On the other side I don't see any of my clients developing this way in the (near?) future. Learning Javascript on top of ABAP? Payed? Really?
At my clients I am (mostly) the one who works with new technologies. Ie. WDA and NW Gateway. And who do you think is maintaining the apps? Me.
I think as long as the main MM/SD ERP functions are not transformed into <enter the most current UI tech here>, the companies will not invest in any new UI technology. Why should they?
Maybe SAP doesn' t port their core ERP applications to one of their new UI technologies not only because they can' t afford the migration costs, but also because they themselves don't really know which of the web and mobile trends will survive the next 3 years.
The only thing that stays solid as a rock is the SAP GUI.
While I am always up to new technologies personally most of our customers still use classic Dynpro. I do not see that this will change in the next two or three years.
But I see a huge advantage of SAP UI5 compared against Dynpro, WDJ and WDA: It is built on open standards. That will make it a lot easier to integrate the GUI with other SAP and Third Party products. Also I am sure you will find developers more easily for the GUI part.
Therefore I do not think that UI5 is fading away soon.
Also the programming model is much nicer in SAP UI5 than the Dynpro framework with its obsolete technology. Only the integration of UI5 into the NetWeaver platform has to be much better than it is at the moment.
Features like SELECTION-SCREEN should be possible in UI5 in an easy way. That would buy many of my programming colleagues for trying somwething new 😉
Mark,
Using open standards for communication and UI creation certainly brings many advantages into a software product that offers custom development capabilities - at least, as you mentioned, the sourcing of development resources gets easier.
I just wonder whether or not this holds true for SAPs flagship products out of the business suite, ERP, SRM a.s.o., too.
From my own experience programming within these environments in most cases means developing the UI as well as business logic - every software architects nightmare.
Either the size of the average SAP development projects, which in our company is between 5 and 30 days, doesn't justify separate UI development, or extensive know how of SAP technologies is also required for UI programming in order to work efficiently.
The latter could be observed during the rise and fall of WDJ technology, when data handling in most applications was done by ABAP function modules, which have been utilized in the WDJ frontend via Adaptive RFC. If a new field had to be shown up on the UI, a Java and an ABAP developer was needed, the same if a problem occurred and cross system debugging was necessary. No '/h' to be found anywhere.
And, regarding UI features: As far as I can remember first things SAP delivered with its new WDA were Select Options and an ALV, two UI elements that never made their way into WDJ.
Regards,
Thomas
In the customer I'm currently working decision was made to use all available WDA/FPM applications over the old Dynpro ones. I'm more focused in PM at the moment, and there are lots of new standard WDA applications (no FPM) in ECC6 EhP5 and even more WDA/FPM ones in EHP6.
However... Lots of the functionality we have in IW21/22/23 and IW31/32/33 are not in the newest version, so now new decision has to be made to enhance the newest application (most likely) or go back to dynpro
Tough call.
Cheers,
Custodio
And here's the updated (VERY interesting!) SAP UI Roadmap: SAP User Interface Technologies - Road Map
SAP App Designer? Screen Personas? If I had only printed out all the different UI Roadmap's of the last 5 years, I could have decorated every room of my apartment with them.