A brief history of WebDynpro Java

When WDJ was defined and first released, web 2.0 was still unknown. This was a long, long time ago. One of the most hyped technologies was Java. Java web application were either pure HTML or JSP. While the web was – considering todays standards – ugly, it was hyped. At that time, SAP was already considered outdated: costly, proprietary programming language (ABAP), not future ready (no web), depending on a proprietary client (SAPGui). Basically, SAP technology had the same standing as today. Showing that SAP is a modern technology constant: same problems as today were raised 20+ years ago.

A way out of this situation was WDJ. It brought many things with it that were considered cool:

• Interactive UI
• Web access
• Java
• Consumption of services (web services!)
• Easy consumption of business data

High hopes

As a result, WDJ was once a recommended technology by SAP when the task was to write web applications. SAP had many components in WDJ united to make it fit the general idea of what is needed: web and Java. Not a big surprise, WDJ was also seen as a way to bring new developers to the SAP world. The hope was that Java developers – at that time it seemed that everyone was learning Java – will be turned into being SAP developers. Allowing SAP to compete on the market with other companies, attract new talents, develop new solutions. WDJ had the role as the door opener. The technology stack for WDJ was also Java based: NetWeaver Java. SAP got much appraisal from analysts, journalists, the general SAP community. Everything was set the make WDJ a big success at SAP, to bring millions of developers to the SAP world: world domination via WDJ was only a matter of time. At least when you believed the message communicated through the years at several events and occasions.

Radio killed the video star

The dream some had regarding WDJ and the role it should play to bring new developers to SAP started as a dream, and that’s it. In retrospect, the number of new developers entering the SAP through Java was not as dramatic as hoped for (depending on your point of view, it can be considered dramatic). While some were onboarded through WDJ, many entered directly via ABAP or via Web Dynpro ABAP (WDA). As SAP announced WDA as the ABAP counterpart to WDJ, the destination of WDJ was written in stone: RIP. Without having to go through all the hassles with WDJ and NW Java, WDA allowed to be cool and at the same time learn what was and is needed to survive in the SAP world as a developer: ABAP and the SAP internals.

The additional work to combine both worlds of WDJ and SAP ERP in ABAP added more steps and complexity. It was not just WDJ as a technology: you had NW Java as the application server, NWDI to manage the code, CTS+ and so on. Different worlds collided, like code repositories – at that time: git, cvs, subversion, bitbucket, bazaar, etc – and SAP’s approach with NWDI. While Java developers were more used to tools that help – maven -them and to focus on the actual developer task. The developer experience between Tomcat and NW Java was also different. Innovation did not stop in Java. Trying and rolling out new features was relatively easy. Yet, in the SAP world, it was not so easy: wait for a new service patch, a new feature introduced by SAP, wait until it was available in the landscape.

2010 SAP decided to focus on Web Dynpro ABAP and to announce that WDJ won’t receive many more updates. If you are old enough you might remember the Kiss of Death blog post. When it became obvious that SAP won’t continue to push WDJ, the question if open sourcing WDJ might help came up. The rationale behind it was: WDJ is not so bad compared to other web frameworks. Offering it as open source could allow developers to maybe use it to write WDJ apps not only on NW Java, but on any other J2EE server too. And maybe developers would still find their way to SAP through working with WDJ. As we know, SAP did not open source WDJ. Which makes sense as WDJ was too much focused on SAP specific requirements and porting it to another J2EE server seemed too costly and time consuming. And other web frameworks started to gain the hearts of the end users: mobile friendly and interactive.

The ugly Duckling

And customers? And developers? The adoption of NWJ and WDJ was not bad at customers. Mostly not because of the technology. SAP delivered business apps in WDJ, so customers had little choice. Trying to optimize investment, developers were somewhat forced to develop apps in WDJ. Besides these rather fortunate conditions, and after an initial outcry, there was not much done to save WDJ. Looking at the reality, WDJ development and usage always struggled with several points:

• Costs. The parallel infrastructure effort and costs needed to run WDJ apps was high. It was not possible to share the costs for the WDJ development environment with the other non-SAP development environments. The costs were pushed down by using SA Portal or Adobe Document Service. If you have seen the sizing and amount of DI needed to run WDJ apps for 10.000+ users, you know the effort required.
• Not Java. Even with Java developers coming to WDJ, it was still proprietary SAP technology. Just because someone knew Java and JSP did not mean that it was easy or even intuitive to write a WDJ app. People had to learn what a WDJ app is, how it works, how to consume an SAP backend.
• Knowledge. The apps written with WDJ had a very clear business focus. After all, they were used to interact with company data. Developers had to learn what this means. What is a sales order, how does it work. The developers had to learn about business processes, relationships, etc. Short: they had to learn SAP.
• UX. Writing enterprise apps for business users is different than writing apps for a public web site. Developers need to take care of things that may be not as important in a non-company context. Things like accessibility, logging, traceability, message handling and value helps, presenting data in tables, navigation flow is very important.
• SAP. Yes, this can be seen as a problem. WDJ and NW Java development was defined by SAP. What SAP did not deliver: no chance. And SAP likes to prioritize features on what their own teams need. If you wanted to have SAP implement a feature: good luck. And it took time. Releasing wasn’t just to provide the code. You had Service Packs, Enhancement Packages, all of this had to be installed in the landscape. Even with the feature released by SAP, it took weeks if not months before it could be used.

The king is dead. Love live the king

Companies –aka SAP customers – looked also at this and found out: with WDA many of the above listed points vanished. The high effort associated with WDJ was reduced to something marginal. Hire Java people and let them learn what SAP is, how SAP works and how business users interact with business data throughout a business process? Let them learn ABAP, all the rest is the same effort and on top the company gets a developer that can do more than just WDJ. Of course, the trend towards WDA and ABAP developers was firm. If you still must upskill developers, then do it right. Invest in a WDJ developer that still needs an ABAP developer because some backend functionality is missing? Get a WDA developer that does both.

SAP would not be SAP if the decision announced in 2010 would have ended the WDJ product and technology immediately. It took SAP years to reposition their own shipped WDJ apps to WDA or now to Fiori. Customers developed new WDJ apps years after the announcement. WDJ developers were still busy developing and maintaining apps. As less and less people opted to learn WDJ, the demand even increased for them – on the short term. NW Java will simply be around until 2027. Until WDJ is really gone, it will almost 2 decades after the kiss of death. Some people might even have entered the labor market as a WDJ developer and retire as one. Still, WDJ failed to deliver on the (high) expectations. It did not bring a mass of customers and developers to SAP.

I know more people developing Dynpros than still apps in Web Dynpro ABAP. WDA outlives WDJ by at least a decade, as WDA runs on S/4HANA and even in the cloud via S/4HANA cloud. But the active WDA development might not survive for much longer. ABAP developers have proven to be able to adjust. The next big thing here is now RAP and Fiori Elements. An interesting combination of technologies, as it allows ABAP developers to benefit from their domain knowledge and at the same time produce Fiori apps that work. In that regard, the ABAP developers just started to aim at their next victim: UI5 freestyle developers.