Skip to Content

SAP Web Applications the Google Way

Recently, I submitted a proposal for a Teched session and I would like to use my first post to explain the idea behind the project in more detail.

Currently, almost all SAP developments in web based UIs are moving toward server side rendering e.g. WebDynpros.  However, companies like Google, Amazon and Netflix are moving toward developing applications that use more and more client-side rendering.  These companies are at the forefront of web technologies; they create new innovative web sites that people love to use.  (For those not indoctrinated into GMail, send me an email and I’ll invite you, or check out Amazon’s New Search Engine and/or Google Suggest)  These companies are starting to develop web applications with user-interfaces that rival desktop applications.  After reading up on how they were built and some reverse engineering of my own, I set out to create an Ajax (see: Ajax Applications) application using SAP data and SAP technologies.

Proof of Concept

I figured I needed to hack together a quick proof of concept, just to make sure I knew what I was doing.  The first step was to create a very simple BSP that took in one parameter, a table name, and output an XML document that was the 1st 100 lines of that SAP database table.  (Much thanks to Karsten Bohlmann, Christian Fect and Christoph Wedler for writing, “From XML to ABAP Data Structures and Back Bridging the Gap with XSLT.”)  Second, I created a “static” web page that used the xmlHTTPRequest object to query the BSP I created and return the XML data to the web browser.  Finally, all that remained was to write an XSLT to translate the XML data from the BSP back into presentable HTML and append that HTML back into the static web page.


After finishing the proof of concept, I decided to add one more layer of complexity.  I really wanted to be able to use ABAP objects from this new class of applications.  (Yes, I could have used web services but those are currently limited to RFC calls.  I didn’t really feel like wrapping every class I wanted to use in an RFC.)  The result, I hoped, would be the restoration of the fabled 3-tiered architecture.  Currently when you run a BSP on a WAS, it becomes both your application server and presentation server, they are in affect one in the same.  Writing a way to allow the ABAP objects to exist on the WAS but have the local browser handling the rendering, like my proof of concept, sounded like a good way to fully restore SAP’s 3-tiered architecture.


How to do this became the next interesting challenge, I started reading up on how Java uses RMI to remotely instantiate classes on another VM.  I felt this would be the best way to build a reusable framework in ABAP.  So, instead of having a simple BSP that takes in just a table name I wrote one that takes in a specially formed XML document.  This XML document contained all the information to make a method call on an ABAP object such as class name, method name to call and all its’ parameters.  The BSP then breaks up the XML document sent from the web browser, calls the method, then re-assembles an XML document with that methods response, and sends it back to the web browser.  Thereby, replacing my simple BSP with what amounts to an RMI server for ABAP objects. 

Essentially, this model of using XML and the web browser is a completely different way of creating client-rich, user-friendly web applications in the SAP environment.  There are many other details and challenges, as well as how-Tos, that I can post in future blogs depending on interest.

You must be Logged on to comment or reply to a post.
  • great to see that the Ajax hype has entered SDN. I did some quick&dirty BSP implementations, and like it a lot. I have to aggree with the majority of the Ajax early adopters that the results are just amazing. I assume this is
    kinda blowing away SAPs webdynpro and VC approach, unless SAP can react quickly on the technology turn. No doubt that the customers will like it and want to have it. However, it will be hard to introduce this in Web Dynpro, since there will be a lot of framework changes involved. I see already an uprising of either JSP or BSP applications.
    Go head and post some of your results. I'm curious to see, what you did. I will collect my results too and introduce it in a weblog.

    regards, Ulli

    • > I assume this is
      kinda blowing away SAPs webdynpro and VC approach

      I don't know.  I have only made a first pass over the Ajax documents included in the article, but this doesn't sound too far removed from what either of these tools could achieve.  As I understand it, the strenght of WebDynpro is that it isn't tied to a particular frontend technology.  I would hope that if a technology like Ajax became very popular that SAP would be able to introduce that as another rendering engine of WebDynpro without having to change any applications coded in WebDynpro (after all that is the vision that SAP has been giving us).

      Just at first glace it seems like the Delta Handeling (flicker free refresh) in BSP seems to be closely related to some of the concepts in Ajax. 

      Also I think SAP is taking a similar approach to richer clients in some of their tools.  Look at the upcomming functionality of VC where the rendering output is Flash.  It might not be that SAP is behind on rich client functionality - just that they have decided to back a different technology.  The recent aquision of Macromedia (the owners of Flash) by Adobe (a close partner of SAP's) might have something to do with this.

      • Hi Thomas,

        as far as I see, Ajax can help a lot in making web applications act like desktop applications, e.g. immediate response to user input
        and providing useful input help. With SAPs approach of having a separate presentation server (in cases like VC and Web Dynpro java
        connected to an abap backend) this is almost impossible to achieve with either web service or rfc, unless the browser is replaced by
        a new kind of client (but I'm talking about a timeframe of today+ 2/3 years).
        It's great to have a full-blown presentation/application layer separation, but all the user wants is an interactive user interface.
        Web Dynpro abap is a little different story, more is possible since the layers a closer together. But any changes would cause the
        abap-java frameworks drifting apart.
        Still my opinion: BSP is the perfect technology in getting Ajax-like features implemented, also because we can do it on our own. 

        regards, Ulli

        • I completely agree that BSP is the best/fastest solution for integrating conetent such as Ajax.  Besides the open framework, we have BSP Extensions. This would allow customers to create their own reusable components that generate content via Ajax.  We have already begun to do the same thing just using Flash and XML as the rendering output at my company.  This makes the insertion of these complex elements into existing BSP applicaitons quite easy.
        • I think that SAP Webdynpro is going in right direction if sap have to modify their code to adopt to requirements like AJAX. This is due to the fact that webdynpro is using CSF and DOM to change the user interface without flickering screens. Hence adopting to AJAX kind of scenarios wont be difficult with webdynpro architecture... What do you think?.
  • This is an interesting topic and I'd like to read more about it.  However, I don't think that the direction of SAP with WebDynpro is wrong.

    In my view, WebDynpro is largely to support SAP's effort to move their core applications to an ESA architecture by 2007.  This effort is going to require a lot of work to separate UI and business logic that is in many places mixed together.  When they pull this logic apart, they need a way to put these business transactions back together again, which is where WebDynpro comes in.

    I notice that SAP has also announced (somewhere) that they intend to have tighter integration with Macromedia Flex-based flash UI's.  Without knowing much about it, it seems another route to rich client-side UI's.

    That a9 site is pretty cool. Hadn't heard of that.


  • The other thing I forgot to ask. Are you using WAS 6.20 or 6.40? I thought that in 640 SAP had direct support for ABAP OO methods as end-points of a web service, possibly negating the need for your RMI approach.


    • I have a 640 system and the only WebSErvice Endpoints listed as options are the following:
      1. Function Module
      2. Function Group
      3. Bapi
      4. XI Message Interface

      Perhaps the XI Message Interface or the BAPI functionality is what you were refering to. Unfortunetely what I was hoping for (I bet you were refering to) was full support for any ABAP OO Method.

      • Well that's disappointing. I wonder if the invocation is still bound to RFC underneath like it was in 620? If so, I think I'll need to write a weblog about why this can be a problem...