ABAP is an abbreaviation of the German word Allgemeiner Berichtsaufbereitungsprozessor if you run the phrase through babelfish and it translates to “General report preparation processor”. For a long time ABAP was seen as that a report writing language, to the uninitiated it was viewed as a lesser easy to learn language and the programmers who used it were looked down on as coders and not developers. ABAP has gone through many iterations, the biggest of which would have to be the introduction of SAP WebAS where ABAP finally broke away from being a report writing language and became the backbone to a suite of web application development platforms.
Prior to the SAP WebAS Web enabling was quite frustrating for SAP developers. The SAP ITS (internet transaction server) programming model was SAP’s preferred enabling technology, essentially you screen scraped SAP transactions and with the aid of a template language you could present browser based screens. It was very proprietary, hard to integrate, hard to extend and tightly coupled. Other techniques for e-enabling were to use lightweight SAP connectors or roll-you-own. Without a reliable framework most companies opted for the trusted reliance of brokered middleware solution.
Then along came the SAP WebAS server, it promised and delivered open integration. Web applications and webServices written in ABAP. Initially there was very little help available. Then in late 2003 when most needed the SAP Developer Network (SDN) arrived. Everyday there was a must read article. We were learning from the ground up, direct from the horses mouth – product developers and architects. To begin with we learn t the basics like how the webserver worked, then on to more advanced topics reusable patterns and creating patterns engines. We weren’t only learning about iterators, singletons, factory methods and effective coding principles like serializing, data binding, stateful vs stateless, but getting context into how they could be best incorporated into our developments.
6 months after SDN started and SAP integrated Java into the WebAS platform, previously SAP like many of its competitors had been using Tomcat to deploy its J2ee apps, a few smart takeovers later like TopTier and InQMy and SAP had their own J2ee engine. Here was a framework which incorporated arguably the most complete Java environment. No more source control headaches, the Java Development Infrastructure (later NWDI) had a completely integrated change management and transport system. The development tool set offered a WYSIWYG model driven RAD design IDE. The main benefits webServices and webdynpro meant that SAP had now got enterprise interoperability – structured (EJB, webServices, RFC,s etc) and unstructured data could be presented in a client agnostic enterprise grade front-end.
For many the introduction of Java was seen as the beginning of the end for ABAP, SAP would surely see the error in the way and stop investing in the legacy of ABAP and start looking to the future.
For a good 2.5 years up until 2006 there was a real thinktank on SDN and the ABAPers were leading the way. Now in 2008 and the developer thought seems to have been replaced with strategic talk around eSOA and business processes, the must read articles for me are few and far between.
What happened – is ABAP dead?
My view is that the Netweaver development platform has matured to a level where currently there is just nothing new to talk about at present, this will change.
As I read the agenda for SAP TECHED 08 “CONNECT. COLLABORATE. CO-INNOVATE!” SAP seems to be veering away from proprietary Netweaver and heading towards “heterogeneous inter-operable” Netweaver. This will mean adopting a more plug and play approach for development to cater to for the best of breed needs of its customers, case in point the Enterprise Service Bus. To me ESB means a paradigm shift from middleware hub-and-spoke integration to event driven peer to peer integration, containers and standards will replace the central hub as a means to providing guaranteed delivery.
Hey what do you know ABAP WebAS integration engine is a standalone webservice container, it plays well on its own and also plays well with other containers like the ESR (UDDI compliant – enterprise service registry ) without the need for a centralised hub in the middle (PI). WS-RM is one of the standards adapted into both ABAP and Java webservices as a means to guarantee delivery, this is only the start, better things are sure to follow.
June 30, 2008 at 3:24 pm
Solution Manager and PI are the only ABAP stacks where the J2EE engine is also Mandatory. You may want to include BI in that list depending on the type of reporting you do.
If you have an ABAP only stack and want to do web reporting, you don’t need to implement a Java stack. You develop in ABAP Dynpro.
In a dual stack system, while SAP’s preference is Java WebDynpro, they will support both – The decison is now a business decison; what developers do do you have ? where’s the business knowledge amongst the devlopers ?
Don’t use BSP – this technology provides the ability to perform much more ambitious stuff than WebDynpro, but does it by providing much MUCH less ‘prewarapped’ stuff (like reuse of existing branding, security etc). In short, WebDynpro will not let you hang yourself no matter how hard you try, while BSP will kill most of the time, regardless of what you want.
June 30, 2008 at 8:20 pm
Hi Martin, thanks for comments
I agree with you that the decision of what and how to develop is totally upto the business and the available resources, I feel sometimes they chose technology for the wrong reasons.
I think that businesses should chose JavaWD if they want to have a common front end for all enterprise web developments. Having worked on a couple of big Java WD projects I can tell you that the framework is very powerful but easy to pick up. The majority of your time developing is spent on the Model (proxy to backend) and very little on the View and Controller coding. If you are going to enable SAP functionality it is easier to teach an ABAPer JavaWD than to teach good Java developers the ABAP necessary to investigate the functionality they are enabling. Even the best documented RFC interface will often require analytical skills far beyond an ABAPer with say 3 years commercial experience. As Webdynpro is rendered to essentially the same frontend code regardless of technology, I would suggest a horses for courses approach if you want to avoid mythical man month.
With BSP you are right there is lot more scope and freedom for developers. To be used effectively it requires a lot more upfront design work and skill than ABAP WD. Projects normally have tight deadlines and limited skilled resources, therefore ABAP WD offers a lot more quick wins than BSP. Having said that each time I go onto SAPnet I see new applications written on BSP, SAP themselves have invested heavily in the development methodologies necessary for developing in BSP and can imagine they will continue to do so when it is required. Regardless of whether you chose WD or BSP without skilled resources and good design upfront you will get a large technical debt on a big development.
July 2, 2008 at 2:58 pm
Technical debt I like it. If Webynpro wasnt so easy to pick up I would lose money cleaning up the mess.
July 2, 2008 at 5:16 pm
Thanks for the screen shots of CRM 2007 and reminding me that the CRM web UI framework has the flexibility of BSP and the power of Webdynpro – looks sweet as!!