Skip to Content

AJAX @ SAP – an Old Hat!

When I first heard about AJAX I had a twofold feeling : first  I was amazed and second I got angry. Why that? Because once again my company managed to be a technology leader without telling anybody in the world, as has happened a couple of times in our past with unimportant things like three-tier client server. But this is  another story.

That may sound to you like we already have AJAX available? You are right! But first of all for the convenience of people reading this without knwoing what I’m talking about at all, some background about AJAX.

AJAX is the acronym for Asynchronous Javascript and XML and entitles a front end technology that lately got large attention by the HTML and Java community. Even here at SDN we had already a couple of blogs about AJAX like Tron Stroemme’s  AJAX and htmlb – a sample BSP application or Daniel McWeeney’s How-To:  Create AJAX Applications in SAP. Most funny to me was an answer to Daniel’s weblog that was,

“The most important benefit that Ajax provides is response to a client side event without posting or reloading the whole page which is the case with server side sripting technologies like JSP, BSP, ASP etc. So its far more efficient and also improves the user experience in terms of not refreshing the whole page.” 

Anybody got an idea where I want to lead you?
Does anybody ever listen to TechEd sessions or read articles we all put a lot of effort in?
Frontend Javascript and a framework that sends data back and forth via XML?
Never heard about this? Didn’t we TEACH you for the last damn  four YEARS? This is *ridiculous*! YOU…

Ok. Once you start shouting at customers it’s time for a break. Even in Germany, the country lately known as the “service desert”.

What I’m talking about is the most important front end technology SAP released with NetWeaver, the famous Web Dynpro.
Yes, it does Javascript.
Yes, it does use XML to forward data between frontend and backend.
No, it doesn’t let you fumble around with Javascript.

And that maybe why nobody gets into this idea. Most programmers mean Javascript programming when talking about AJAX. And this is the big difference between AJAX and Web Dynpro. Unfortunately Javascript has some major drawbacks (which I have some experience with, when I tried to write a Javascript rich text editor before this was implemented in browsers):

  • It’s not a ‘real’ programming language, as it’s name says more for scripting and this means it allows awkward programming style
  • Using it for frontend programming means for most programmers: learning a new language
  • Different browsers use different dialects of Javascript. This leads to intensive testing with different browsers for all code written.
  • There is no security concept to encrypt the data traveling between the front and back end

These drawbacks can be worked around by using libraries, of course. Well, nothing else you are doing when using Web Dynpro – with the extension that you never have to use any kind of Javascript, as all of it is generated for you.

You must be Logged on to comment or reply to a post.
  • Hi Benny,
    I agree with the most things that you have figured out in your Weblog and I think that it was absoultly nessesary to underline that inside Web Dynpro uses already a technology that other people try to sell us as the future.
    But … and it is very hard for me to say but against a guru like you … AJAX can be very interesting in the area of BSP Applications. If you want write a flickerfree, stateless application and because of some reasons you have to use BSP, AJAX can be a good extension. Actually one customer asked me last week if it is possible to improve an existing BSP Application. Probably I will use AJAX and probably I will write a weblog about it.
    Web Dynpro is great and uses great technology, but BSPs are not that bad and sometimes we have to build in the area of BSPs something that already already exists in the area of Web Dynpro (Oh no, please no discussion Web Dynpro against BSP!!!)

    Best regards

    • Go ahead. If you are for some reason limited to BSP, of course to add AJAX is the way. Question is if you are *really* limited…

      But that’s another question.


  • Hi Benny,

    >Frontend Javascript and a framework that sends >data back and forth via XML?
    >Never heard about this? Didn’t we TEACH you for >the last damn  four YEARS? This is *ridiculous*! >YOU…
    Well the MSIE might have supported it with its
    XML support. But was not a standard.

    >What I’m talking about is the most important >front end technology SAP released with >NetWeaver, the famous Web Dynpro.
    >Yes, it does Javascript.
    >Yes, it does use XML to forward data between >frontend and backend.
    >No, it doesn’t let you fumble around with >Javascript.
    Yes WD has a very good UI framework. And employs
    javascript much than we do know. One thing I don’t like with WebDynpro is that it has a very limited controls! And seems to be made to work
    properly with IE only! Try using it in Firefox
    or other browsers and you will see some differences.

    AJAX and WD are 2 different things. WD may be implemented using the AJAX framework but not the other way around.

    But personally, I still like Flash frontend than
    any of this UI framework.


    • I am using firefox on a daily basis and since mozilla is officially supported I don’t have problems with WD (while still suffering in our internal portal, that seems not quite to support it).
      About controls the following: I know this makes you developers unhappy, because you cannot invent newer ones. But think what happens the other way around! Everyone would start producing controls that had to be transported with the apps, ending up having hundreds of different controls on the same system with same functionality. And I’m not even considering the mess in dev environments!

      Different things? I don’t think so! WD IS an AJAX framework – with the difference that you don’t fumble with Javascript yourself. For a good reason!


      • >Everyone would start producing controls that had to be transported with the apps, ending up having hundreds of different controls on the same system with same functionality. And I’m not even considering the mess in dev environments!

        Come on now.  There are many valid technical reasons that you could provide why SAP choose to go with a closed framework – future proofing and multiple delivery clients being the most prevelant.  But your explanation that developers would make a mess if you gave us too much control is just insulting. 

        We are your customers, not your children.  You don’t need to yell at us and you don’t need to insult our ability to manage our own development environment.  SAP has many fine developers – but guess what – not every skilled developer in the world works for SAP.  There are still a few people outside of Walldorf that know how to write and organize code.

        • Hi Thomas,

          at least you got it. I was unsure if that could be published and asked some colleagues…
          Of course, if *you* in your company had the ability to use additional controls, you could organize yourself. But if *everybody* (ISVs, SAP itself)had this ability, controls would spread all over the place.
          Once again this would not be the biggest mess, as we know even in the existing software things are sometimes implemented more than once.
          But tell me how this goes together with allowing you to change our software? That means that every single control somebody adds has to go into the development environment. How can that be achieved?(Sure it could- on significant effort, of course).
          Again, I’m *not* saying developers are native messies, I’m saying that having large groups working “together” uncoordinated produce mess for sure.

          Does that clear up things for you?

          • I’m afraid that I have to disagree with this line of thought.  It is true that “having large groups working together uncoordinated produce mess for sure”; but who says that this has to be uncoordinated. 

            Just look at what other Developer’s Communities (who remain unnamed) have been able to achieve.  Or look at the success of SourceForge.  With the correct tools, mechanisms, and proceedures; component sharing/selling can have great benefits for the entire ecosystem.

            This is ultimately where SDN is headed.  SDN is all about sharing information.  Code sharing is just an extension of that.  Already there are discussion about how best we (developers within and outside of SAP as well as ISVs) can share/exchange code. 

            In the case of WebDynpro this really just moves up a level.  We can’t created and exchange UI Elements for valid technical reasons, but surely there will be an exchange of WebDynpro components. 

            Look what SAP was able to build with the ALV component by combining existing UI elements.  Customers and ISV will follow suit.  Then do you not run the risk of the same “mess” that you describe? 

          • Hi Benny,

            I read about AJAX few weeks ago. and yesterday i read your blog which says that Web Dynpro is somewhat same as the AJAX Programming.
            Well well, first of all have a look at the following link:
            Now before reading this i never knew what AJAX was but since i am a heavey user of GMAIL, i understood what AJAX is. But still i do not understand the relation between AJAX and Web Dynpro. I have been doing developement in Web Dynpro since so long but never felt it similar to AJAX.
            I would surely like to develop something in portal/web dynpro which works as fast as Gmail (the response time..) with the help of AJAX Programming.

            AJAX Says that “Ajax applications, on the other hand, can send requests to the web server to retrieve only the data that is needed, usually using SOAP or some other XML-based web services dialect. On the client, JavaScript processes the web server response. The result is a more responsive interface, since the amount of data interchanged between the web browser and web server is vastly reduced. Web server processing time is also saved, since much of it is done on the client.”

          • Hi Gaurav,

            if you just read your last paragraph, that describes nearly exactly how WD works. Exception: Meanwhile the amount of Javascript was reduced drastically for the better of client performance.
            The protocol is http, that transports XML…


          • Thomas,

            I agree completely – for the future. Once we are in such an environment, I’m pretty sure we can think about that too. Actually I think that open source will force us to go that way.(not that I’m unhappy with this!)
            As I said before, it really makes me unhappy that we  constantly develop technology ahead of the market and once the idea reaches the masses it is reimplemented in open source. It would be a nice idea to go open source immediately with such technologies, also because it is not the core of our business and not the stuff we make the money with…
            I’ll fight for this.

        • Hi Thomas,

          It seems like you are taking something personally which is not meant personally at all.

          The question boils down to supportability and indemnification.  If you come up with an awesome new control, and SAP includes it in the standard delivery (the only way to “share” your control at the moment AFAIK), who supports the control?  Who takes care that your control doesn’t kill other controls?  Who takes care that your control doesn’t kill the portal under certain conditions?  Who takes care that your control doesn’t do something sneaky?  Put another way, who supports/gaurantees Firefox extensions?

          What we need is some sort of extension architecture which would support such work.  The current delivery mechanisms of SAP do not (again AFAIK) support such community collaboration.



    • Now, if my sense of english doesn’t fool me *this* would be insulting, wouldn’t it?
      eh, I see you’re from Austria, though you’re supposed to be in my language area, which makes us both non native english speakers. Well, as we can see sometimes in every language, I guess, non native speakers overdo the use of insulting language sometimes – which gives the native speakers somehow the impression of rudeness.
      OK, I started and provoked all this and apologize to all directions!
      Besides this we could continue in a couple of german dialects, that don’t only allow the use of indignity, but even show friendship and intimacy that way 😉


    • I read it and commented.
      I’m running around for a couple of years now presenting slides that exactly say this: WD is using XML, and does rendering on the client (to a less extend as was the case in earlier versions) and we are using the term flicker-free since I heard the first time about it (which I fight since then, as the effect is not ‘flicker’-free, but reload free – in opposition of a html form).

      Of course it is hard to see that stuff, as the Javascript obviously is not documented.


  • In attempting to use BW Web Reporting with Portal Client Side Eventing and every time you responded to an event the entire BW Reporting iView was refreshed.  We had some Lighthammer iViews on the same page and there you could just refresh the applet and the data was refreshed without refreshing the page.  We were using SSL at the time and BW iView requested a SSL certificate every time and the Lighthammer iView did not.

    It makes a big difference to the user if you can refresh the data in an applet vs the entire page being refreshed.

    It would be better if all data objects could be freshed without the need for a URL refresh.

  • and is putting such a heavy load on the client.

    I think the only reason for AJAX is performance. But WebDynPro is not fast! I learned that WebApps are supposed to be “light weight”. How many MB of Client-Code has to be transfered until a WebDynPro App works?

    Don’t get me wrong. I am in favor of the WebDynPro approach, especially with upcoming features like multi-client-support (write once, run on any front-end), but I really do not get your point to claim the credits of AJAX (= performance) for WebDynPro.

    BTW: The better approach is anyway to use rich-client front-end technologies (like Flex) if you need to write feature-rich applications 😉

    • Hi Georg,

      what version are you using? In the beginning WD really was quite slow because alot of code was transported. Meanwhile through the SPs of NetWeaver04 this has been balanced much better and I have not the impression it is slow. This may depend on what you’re doing elsewise. Have you seen the new nwa (NW Administrator), that *is* a WD app.

      Of course, the approach to not let you play around with Javascript also doesn’t let you squeeze out the last second out of the environment. But well, I’m pretty much under the impression you are in an early version?


  • It is true that WebDynpro sends data back and forth using XML. But AJAX is much more than just XML and JavaScript. The real power of AJAX is that it enables the browser to send/receive “asynchronous” HTTP requests/responses to/from the web server. This communication is done in the background, thereby giving the web application a user-experience and responsiveness that is close to a thick client UI. The best examples of AJAX-enabled sites are Flickr (the photo site), Google Suggest etc. I am not sure whether WD can be compared to this.
    • Catherine,

      the HTTP protocol itself is asynchronous by nature. So, at the moment your are using it as a transport protocol for Javascript this becomes asynchronous.

      And if you have alook into the DOM and Javascript that comes in a WD page, you might get the impression that there happens exactly what you describe… (background communication)

      • Hi,

        what about ‘the HTTP protocol is asynchronous by nature’ (or any other disaster)?

        If i look at RFC2616 Chapter 1.4 the standard type of operation is synchronous (let alone proxies).

        If I open a telnet connection to some URL, port 80 on the commandline and issue ‘GET /index.html HTTP/1.0’ I get an immediate response on the same socket connection, I’d call that synchronous.

        If I try it in JAVA I’d use

        URL url = new URL(“http://some_url“);
        URLConnection conn = url.openConnection();
        OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream());
        // Get the response
        BufferedReader rd = new BufferedReader(new InputStreamReader(conn.getInputStream()));
        String line;
        while ((line = rd.readLine()) != null) {
          // Process line…

        Since I did open only one connection, I’d call this synchronous too.

        What am I missing? Maybe I deserve the three little dots after ‘YOU’ to be articulated for me 😉


        • You’re right, I’m wrong. Nevertheless it mostly is *used* asynchronous, as browsers break connection after every call.
          I know they could keep connection and do this sometimes, but it generally is not a good idea.