The death of Web Dypro Java has been greatly exaggerated
I’d like to use this post to provide clarity on a topic that has gotten significant attention lately among customers and in the blogosphere: The future of UI technologies used in CE, particularly Web Dynpro Java (WD-J).
Firstly, I’d like to do some level-setting for those who may not be familiar with the UI technologies that can be leveraged with NW BPM:
- NW BPM leverages SAP UI technology of the SAPJava stack, Web Dynpro Java (WD-J) and Visual Composer (VC). By the way, you can also use Adobe forms technology with NW BPM, both on- and off-line.
- Both technologies can be used to generate and develop interactive user interfaces for process tasks (task UIs).
- The next release of NW BPM will also provide integration with Web Dynpro ABAP UI’s based on NW 7.3 and/or NW 7.0.2 (in Ramp Up with the SAP Business Suite 7 /2010 or EhP 5 of the Business Suite).
Now let me address the future of our Java UI technologies. First and foremost, further feature enhancements both for Web Dynpro Java and Visual Composer (examples below) have already been delivered. For example:
WD-J: Execution Modeler in WD-Java, Snippets integration, Web Dynpro Flex enhancements
Visual Composer: Services Registry integration, model debugging, context-sensitive help.
Both technologies will continue to be shipped with CE/BPM and will be supported per the relevant SAP licenses (they will not be going away so soon!). SAP plans to further:
open up the UI technology usage for NetWeaver BPM, compliant with the overall SAP UI strategy (HTML5, JSF)
invest in tool flow and usability between task management and task UI in BPM.
CE and selected BPM-related feature requests will continue to be handled and prioritized via standard channels to SAP development (e.g. SAP user groups, customer engagement initatives). Partners, customers and, of course, SAP mentors will be engaged to actively participate in this evolution via these standard channels.
I hope this post makes our position clear. To put it in a nutshell, although our UI strategy will continue to evolve based on requests from our customers and trends in the market, our customers should feel comfortable using Web Dynpro Java and Visual Composer to create UIs for business processes modeled and executed in NW BPM. SAP aims to enhance the existing UI offering with complementary capabilities based on new industry standards and technologies (HTML5, JSF).
It helps. But that means we'll still be debating ABAP vs. JAVA or both. 🙂
a year ago I started an discussion here about open sourcing WDJ (See: http://www.sdn.sap.com/irj/scn/weblogs?blog=/cs/weblog/search/wlg%3fid_user=221)
This idea was greatly welcomed by the community, while internally still a lot of people think it's not well adopted enough. But lots of ISV are just waiting for such a step as they need it to open source for the use in non SAP environments.
It would be a win/win situation for the community and SAP to do this!
Excellent idea a year ago and even more so today. As with any technology, the more people use it, the more each one of them benefits from all the other ones using it. Adoption by an Open Source community might even turn out to become a valuable innovation driver for (parts of) SAP's technology portfolio.
How ever every one from SAP tries to diffuse the situation, it is very well known fact(s) that
(a)SAP wants to put their spin on many a JEE standards, with a sole idea of making it a one-
way street, meaning clients only can use coming in to Netweaver, but can't port it to any other
Application Server. Eg. JSP, HTMLB.
Then to respond to Client's feedback and
innovation in the market, they will depricate widely used technologies and go to another one.
Why ? Their development budgets.
Why don't they go along with JEE technology, let Client's and Developer Community decide which UI technology they want to use ?
(b)If not for the budget reasons, why don't they continue to developing WD-J ? Not a question whether WD-J better or worse than WD-A. Being a Developer myself, where to throw away my years of expertise in WD-J and VC ?
(c)Look at SAP business package strategy. Why do they switch between Java and ABAP as implementation language there. ESS/MSS and CRM etc business packages for example. SAP confused itself and Developer community.
(d)There is no guarantee that in future SAP won't repeat this flip-flop behaviour. Everytime a new board member joins/leaves the SAP board, their technology preferences should NOT change. Remember ? With Shai Agassi in 2001/2002, all the hoopla about Java, and Java-ABAP dual stacks and now abondoning that slowly. Ex.PI 7.3
If I am sounding like, I don't like SAP as a UI technology Developer, you are 100% correct.
- Prasad Nutalapati
may I correct some misleading statements?
a) SAP supports Java EE as a standard and this is tested. Developing additional capabilities upon the standard is very common in the market and many of those capabilities have been integrated to the standard over time. We *are* supporting everything that is standard and you are always welcome to develop toward it. You may use JSP, Servlets, and JSF with SAP NetWeaver, all the standards that are available with Java EE 5. Did I miss one?
If you are unsatisfied why SAP does not use it, there is a clear answer: at the time development for WDJ was started there clearly was no UI technology available that fit with the demands of SAP Java development, for hundreds of developers to be ported to dozens of languages.
b)There is no need to throw away anything whatsoever, as SAP will support existing technology at least until 9 years from today. And this rule applies until we announce the sunset of a technology, which we have not done for WDJ. This means that WDJ support is sure until 2019 at least. Try to find this anyplace else.
c) I'm pleased to enlighten you on this: SAP has changed strategy on this because the mix up of technology turned out to be more complex than expected. On the behalf of customers expectations to reduce complexity SAP went back to a single stack strategy, that now prefers to have technology and business applications on their appropriate stack.
d) There is no guarantee that in future no new technology will come up. If you want us to stay with what once was developed, no problem: original dynpros, developed over twenty years ago still work and you even can develop there. But there are customers who are not that patient and expect that SAP follows latest technology.
I'm sorry if you are unpleased with SAP. There is always two sides of a medal and we have to decide for the one that serves best our customers (which may not be in the best interest of developers)
With Kind Regards,