AJAX @ SAP – an Old Hat!
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,
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?
Hello?
HELLO?
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.
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
Renald
But that's another question.
Regards,
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.
jg
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!
Regards,
Benny
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.
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?
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?
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: http://en.wikipedia.org/wiki/Ajax_%28programming%29.
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."
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...
Regards,
Benny
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.
Regards,
Benny
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.
Best,
Jeremiah
http://en.wikipedia.org/wiki/2600_hertz
Now I'm not only in a battle of inapropriatism, but also set into relationship with illegal hacker activities.
*Thank You*, Mark.
😉
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 😉
Regards,
Benny
Read it and prove your claim...
Are Web Dynpros and Ajax Related?
jg
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.
Regards,
Benny
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.
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 😉
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?
Regards,
Benny
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)
Regards,
Benny
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();
conn.setDoOutput(true);
OutputStreamWriter wr = new OutputStreamWriter(conn.getOutputStream());
wr.write(data);
wr.flush();
// Get the response
BufferedReader rd = new BufferedReader(new InputStreamReader(conn.getInputStream()));
String line;
while ((line = rd.readLine()) != null) {
// Process line...
}
wr.close();
rd.close();
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 😉
greetings,
anton
I know they could keep connection and do this sometimes, but it generally is not a good idea.
Regards,
Benny
i was convinced after some research and experiment
that WD does not fit into the Ajax category.
Is Web Dynpro using AJAX?
regards
jo