First of all… what in the heck is a Browser Based UI? When I first started reading about it all I could think was that all modern user interfaces in this day and age are “browser based”? I mean honestly I have been coding webpages since the dark ages of 1995 and thought that although I was writing in a variety of markup and scripting languages that everything I was doing was ultimately browser based. Well, it appears that in some ways I am right in my thinking and that in other ways I have been coding too much for too long.
In essence “Browser Based” simply means that you do not have to install any application onto the client that is requesting the applications it would like to run or retrieve. This is similar to requesting any webpage to retrieve information via http or https. In the early days pretty much everything on the Internet was static html; meaning that the information was hard coded into an html page and then published to the web where most likely it was never changed and quickly became outdated. This worked quite well for information that was well static… As times began to change the web moved from informational to a dynamic “real-time” environment. Suddenly there was need for dynamic information and sales portals.
So we as web developers had to strive for faster loading “real-time” transactions while keeping packet size and loss to a minimum over the web. This all somehow brings me back to “real-time”. At my previous employer I headed up a development team that was responsible for eCommerce. We were tasked to connect to our SAP R3 system in a “real-time” manner and create the magic of Internet commerce for our customer base. Things were often slow, frustrating and tedious. Rarely was there any code re-usability to be found. At night I would drift off to sleep with visions of interactive GUI Development platforms and re-usable UIs only to wake up the next morning and find it all to be a dream.
Alright… Now let’s zoom ahead several years to the beginning of 2004. I am no longer a development manager for a medium sized computer wholesell/reseller but I am now an SAP Web Application Server Product Manager (sounds exciting doesn’t it?). So one of my first tasks as a Product Manager at SAP was to get on a plane and fly to our main SAP offices in Germany and sit through a two week onslaught of NetWeaver ’04 training. During those two weeks I was introduced to something truly amazing. Something that I had once dreamed of perhaps in the old days of trying to develop Internet eCommerce by connecting to a now ancient R3 31h installation. Web Dynpro was finally right there in front of me and as far as I could tell it was good. Really good in fact.
So what is Web Dynpro and what does it do you ask? – Here are six key facts on Web Dynpro:
- Web Dynpro is SAP’s tool based design and development environment for all User Interfaces (UIs) for business applications, which include sophisticated runtime services. Its model-driven approach minimizes manual coding and uses visual tools to design and reuse UI components.
- Web Dynpro is based on a powerful and flexible Model-View-Controller architecture that ensures a clear separation of User Interfaces and business layer so short-term changes and modifications can be made in both layers without one layer interfering with the other. Developers have the full control of the generated code at all levels of the development process.
- A Web Dynpro applications browser based and you do not have to install anything on the client (zero footprint). The Dynpros built-in Client-Side Framework (CSF) a small Java script based program – is loaded from the browser by the first request. It minimizes the bandwidth requirements and client-server communication, through sophisticated delta handling. That provides a professional user interface with screen updates without page reloads.
- The Web Dynpro component concept allows you to reuse either entire Web Dynpro applications or just parts of them as required. If you embed one Web Dynpro component in another the resulting application is highly structured and this greatly increases the reuse potential for existing views, controllers, and even for models.
- Different data sources can be used to retrieve the data for an application like ABAP Java and Web Services. So you can use the Web Dynpro model to provide the Web Dynpro application with existing SAP business functions from BAPIs. And for instance Enterprise JavaBeans (EJB) for the Java World or Web Services can be used as a data source for the model.
- Through the declarative and graphical tool based design an adaptation to other devices will be easy. The comprehensive Web Dynpro tool supports user personalization 508 accessibility compliance and internationalization support.
So what does this mean to the average front end UI developer? It means that SAP is going to use one tool for all its UIs. Web Dynpro.
Why is a model-driven approach important to you as a developer? To me this is the best part and the easiest for me to understand… Less time to production code than traditional programming. This to me is a huge advantage. It means that I can lay out my floor plans visually and that much of the code will be written “on the fly” by the developer studio. I define the logic pieces that I need for the code and the developer studio does the rest. Plus I can reuse components without having to re-write them or search my hard drive for them.
Now let’s talk about the Model-View-Controller architecture. To me the biggest mistake that most UI developers make is believing that they are responsible for the business logic. I know… I have done it and bought into it as a web developer and maybe you have too. The fact is UI developers should not be writing any true business rules and logic within their UI code. We as UI developers are only responsible for presenting the logic and business rules that the backend developers (those ABAP’ers) have spent their heart and souls pumping out. It is highly important for the UI developer to have control over ever aspect of the code that they are creating but at the same time the UI developer should have respect for and not tamper with the underlying business logic. Web Dynpro allows us web geeks to go full steam on our code without fear of damaging the business layer. This means that ABAP’ers everywhere are raising a beer to the developers that made sure that there was a clear separation in the layers.
zero footprint – This little bit of geekery is my favorite of all… Imagine if you will for a moment a world where you click on a drill down and the entire page does not refresh but rather just a single section refreshes to expose the new dataset that you have requested. Think about it… Less packet transfer on your browser, less stress on your CPU, the network, the originating webserver that you made the initial get request to. This all makes for less waste of bandwidth and much more efficient rendering. All because of a small bit of java script based code called the Client-Side Framework (CSF).
The use of the component concept is something that I like to look at as building blocks of sorts. I can grab bits and pieces of Web Dynpro applications or I can take the entire application and then use it in another Web Dynpro making the application as stream lined or as complex as I need to for any given UI task. It appears as if the Browser UI is finally becoming somewhat object oriented… That is a good thing.
I currently have a large growing patch of gray hair on my head and most of it is do to fact that I have been asked to gather, assimilate, join data from various databases and/or external websites and then package it up nice and neatly to write back to a central system. So you know that being able to access BAPIs directly and the use of Web Services will really come in handy. If you combine the above features with internationalization support, personalization and a visual tool set there really are no set limits to the UIs you can build and deploy. Looks like my dreams of old have finally started coming true… Browser Based UIs, I think I finally get it.