Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at [email protected].
Getting started with Web Dynpro
OK, like I promised, I will dive deeply into the MVC Object design pattern and the way SAP has modified and extended it.
While many of you may be familiar with the MVC design paradigm, SAP has modified and extended it, so you need to understand what the differences are, why they are there, and what consequences those differences will have on the way you think when writing Web Dynpro applications.
The Model View Controller (MVC) design concept
The MVC design concept is not at all new.12 In fact, it was created in 1978 by a Norwegian software designer named Trygve Reenskaug. At that time, he was working as a visiting scientist in the Smalltalk group at Xerox PARC and was faced with the problem of designing a system in which users would have to control large and complex datasets. Here’s how he assessed part of the problem:
Problem
The input and output aspects of the [program] are technically very different with few inter-dependencies. Their combination in a single object tends to make this object unnecessarily complex.
Solution
Let the [program] contain two objects; a View object responsible for presentation, and a Controller object responsible for taking and interpreting input from the user.
I believe this is the very first time the idea of separating data presentation from data processing had actually been stated as an explicit design requirement. This idea is commonplace today, but in 1978 it was a huge conceptual leap. The result is that he split the program up into at least two parts: the view and the controller, with each part having a very distinct role to play. Having the view and controller was all very well, but the part of the program that would perform the actual business processing had still not been identified. Reenskaug recognized that a third unit of software was needed in order to have a fully functional program. This is where the model came in. To use Reenskaug’s own words again:
MODELS
Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects…
OK…I get it now…So, the model represents what the user knows (e.g., how to create a sales order), and all the information held within it relates to the business task at hand, or if the task is very complex, relates to some well defined stage of the business process.
The view is the part with which the user interacts (i.e., what appears onscreen, such as menus, push buttons, drop-down lists, and option buttons).
Finally, the controller is the intelligent part — this is where the processing takes place to determine the views the user sees on the screen, and then, based on the user interaction, determines the views the user sees next.
The essence of the MVC design concept
Many people think of MVC design pattern as a means for separating data presentation from data processing, and this is certainly true. However, the separation of data presentation from data processing is only one use case of a much more fundamental concept — namely, the separation of those parts of the program that generate data from those parts that consume data — and it is this fundamental principle that you see time and again within the Web Dynpro architecture.
Those parts of a Web Dynpro application that generate data (the models) are strictly separated from those parts of the application that consume data (the views). A controller acts as a middleman between the models and the views, and its role as a consumer or generator varies depending on which entity is being communicated with.
When designing and writing Web Dynpro applications, you must be careful not to blur the boundaries between data consumers and data generators. If, through lack of understanding or wanting to achieve a quick result, you do blur these boundaries, then it is possible that you will end up writing poor quality code.
Understanding the generator/consumer concept explains why SAP has extended Reenskaug’s original concept and consequently implemented an MVC toolset that is different from other vendors’ MVC implementations.
SAP’s adjustment to the view concept
To achieve the required level of client independence, SAP found it necessary to modify the concept of a view. Traditionally, views have been implemented as templates containing HTML and some executable coding; for example, Java Server Pages (JSPs) are HTML templates containing embedded Java coding. Unfortunately, this type of implementation carried with it all the problems SAP was trying to escape from in Web development.
With views implemented as HTML templates, the developers needed to be concerned with such client-specific rendering issues as:
HTML
JavaScript
Cascading Style Sheets (CSS)
Support for multiple client types
These development areas alone can consume in excess of 50% of the implementation timescale. This is exactly the situation the SAP Web Dynpro designers wanted to avoid. Instead, a Web Dynpro view needed to hold the UI definition in a client-independent manner. Then at runtime, the Web Dynpro Framework (WDF) determines which HTML and JavaScript statements are needed to render the screen on any particular device. To achieve this, SAP needed to modify the concept of an MVC view.
It is within a view controller that you define the layout of the screen, but to avoid having to write any HTML or JavaScript, you define the screen by making simple abstract declarations:
“I want an input field here” or “I want a drop-down list over there.” This approach means you don’t waste time struggling with HTML and JavaScript because the task of generating HTML and JavaScript has been delegated to the WDF. At runtime, the WDF renders your view for whatever type of client device is currently running the application (and this could be something other than a browser, for example, a Blackberry or a Nokia Communicator).
The view controller has its own section of coding that prepares data for display and responds to user actions on the client. All this coding has been designed to operate without you ever needing to worry about how the specific UI elements should be rendered on the client. All you need to remember is that Web Dynpro displays information on the screen using a special type of controller (one with a visual interface).
So I am sure you have a question…..
So when I write a Web Dynpro program, I’m just writing views, models, and controllers?
Remember I am a consultant…. the answer is ……. Well — not exactly……
MVC is just a design concept in the same way that object-orientation is a design concept. Therefore, every software vendor that implements an MVC-based design tool does so in a slightly different way and with a slightly different interpretation of the principles. SAP is no exception here. In fact, SAP has extended Reenskaug’s original MVC concept by introducing a completely new entity known as a “component.” Without this new entity, the Web Dynpro designers found they could not correctly implement one of their key design requirements: namely, code reuse at a business level.
The Web Dynpro component concept
When you write a Web Dynpro program, you will need to write models, views, and controllers. However, these units of code are packaged together into a larger unit called a Web Dynpro component. When you write a Web Dynpro application, you must write at least one component. The component is now both your unit of development and your unit of reuse. Now I can hear you saying why not just reuse a view, well It could be argued that views, controllers, and models could all be reused as independent units. This is true, but this was not the type of reuse SAP was after. If the only reusable units of code were low-level ones such as views and controllers, then you would create the situation in which object reuse was not directly related to any step of a business process.
Since the whole thrust of Web Dynpro was aimed at modeling and then solving business problems, the technical details of how the problem should be solved were of lesser importance. Therefore, the unit of software reuse should correspond to a distinct step of the business process, not some low-level, technical unit of coding. So when it comes to code reusability, MVC uses the following unspoken principle:
Coding is bad…if you have to write the same piece of code twice.
Using Web Dynpro’s component reuse concept, the thought is you should be able (with some careful design) to slash UI development times by more than 50% by creating a library of reusable components — each one corresponding to a distinct step of a business process.
When developers are now asked to write a new application, their job consists of:
1. Analyzing the business process to identify where currently available Web Dynpro components can be reused
2. Designing and writing new Web Dynpro components to fill any functional gaps
3. Assembling the components together into the required business application
The whole emphasis of code reuse in Web Dynpro focuses on discrete steps in the business process and not on the low-level units of code required to implement those steps. This means that a Web Dynpro component contains several distinct coding entities that all function together to deliver a single unit of business processing. A Web Dynpro application is then built using one or more Web Dynpro components as reusable building blocks.
OK at this point I am sure you want to start writing Web Dynpro’s. I understand, so I will end this with a quick recap on concept and principle and then provide you with several links. The first set will be to a great series on the SDN to learn and build a series of Web Dynpro’s from scratch starting with the infamous “HELLO WORLD”. The other link will be to a great book I believe will help further your understanding.
Let’s quickly recap what you’ve learned about Web Dynpro:
– Web Dynpro is a toolset for developing the UI layer of a business process.
– The Web Dynpro application does not care what front-end technology is used to display the business data.
– All Web Dynpro development is packaged into reusable units known as components. The component is both the unit of development and the unit of reuse.
– Try, as much as possible, to design each component so it represents an atomic unit of business processing.
OK, here are the links to the series on the SDN. Please take them in order.
Introduction to Web Dynpro ABAP: Part 1
This eLearning explains in depth the Web Dynpro programming model and how to develop Web Dynpro applications within the ABAP workbench. In this first part we begin by explaining the motivations in the design of Web Dynpro.
Introduction to Web Dynpro ABAP: Part 2
This eLearning explains in depth the Web Dynpro programming model and how to develop Web Dynpro applications within the ABAP workbench. In this second part we discuss the Web Dynpro ABAP programming model.
Introduction to Web Dynpro ABAP: Part 3
This eLearning explains in depth the Web Dynpro programming model and how to develop Web Dynpro applications within the ABAP workbench. In this third part we learn about the View and placing UI elements on the screen.
Introduction to Web Dynpro ABAP: Part 4
This eLearning explains in depth the Web Dynpro programming model and how to develop Web Dynpro applications within the ABAP workbench. In this fourth part we explore how to model data in the context and respond to events with event handler methods of the controller.
Introduction to Web Dynpro ABAP: Part 5
This eLearning explains in depth the Web Dynpro programming model and how to develop Web Dynpro applications within the ABAP workbench. In this fifth part we expand our project to include the Component Controller, Context Mapping and multiple Views.
The book I recommend is
http://www.sap-press.com/products/Getting-Started-with-Web-Dynpro-ABAP.html
If you want to read Part 1 of this Blog series click An introduction to Web Dynpro – Part 1
If you want to read Part 2 of this Blog series click An introduction to Web Dynpro – Part 2
