SAP Web Dynpro Overview

Andreas Fahle
Seminar System Modeling 2005
Hasso-Plattner-Institute for Software Systems Engineering
andreas.fahle@hpi.uni-potsdam.de

Abstract
SAP Web Dynpro is a framework for developing user
interfaces for use with the SAP NetWeaver platform. It
comes with design tools that are part of the NetWeaver
developer studio, enabling developers to do most of the
programming in a graphical or declarative manner.
Web Dynpro applications can run on different
platforms, including Java, ABAP, and .NET.
Component-orientation supports reusability of user
interfaces.
The concepts covered in this article allow a
separation of layout and logics, and ease the
integration of different backends. Using contexts and
models, data may be synchronized automatically
between the user interface and the backend.
Besides discussion of basic concepts and a glance at
the development process, this article briefly illustrates
the client-driven execution of a Web Dynpro
application.
Keywords: Web
Interfaces

Dynpro,

NetWeaver,

User

1. Introduction
1.1. What is Web Dynpro?
Web Dynpro is a framework for development of
user interfaces (UIs) for use with SAP NetWeaver.
It supports programming for different platforms,
including Java, ABAP, and .NET. For Java
programming, Web Dynpro comes with extensive
design tools, which are based upon the Eclipse
framework and part of SAPs NetWeaver
Developer Studio.
The product name has a historical background:
SAPs legacy product lines, starting from the R/2
system, include a technology for interactive UIs
called Dynpro, an abbreviation for dynamic
program. Dynpro UIs are described in the ABAP
programming language and rendered in a

proprietary frontend application called SAP GUI.

In contrast, Web Dynpro UIs can be rendered in
non-proprietary,
ubiquitous
frontends,
particularly web browsers, employing dynamic
web technology like JavaScript. Thus, Web
Dynpro is aimed to combine high interactivity
(i.e. a dynamic UI) with zero installation (i.e. an
ubiquitous UI). [2]

1.2. Objectives and approaches

The Web Dynpro framework has been developed
to achieve some characteristic design goals, so
there is a bunch of technical approaches that
directly address those design goals. [2]
First of all, developers should be able to build
as much as possible without procedural
programming, according to the slogan minimize
coding, maximize design. The NetWeaver
Developer Studio offers facilities for graphical
and declarative programming here, where much
of the code is generated.
Another objective affecting the development
process is separation of layout and logics. This is
achieved through the view and controller
concepts: views can be equipped with controls
and navigation plugs independently of actual
data bindings and event handlers, which are put
into a view controller.
In order to support arbitrary backends, Web
Dynpro uses so-called models as an interface to
the functionality of backends. Currently, models
for JavaBeans, ABAP, and Web Services are
supported.
Applications should run on multiple platforms,
in terms of the program processor at the
presentation server side. Java, ABAP, and .NET
are suitable runtime environments at present.
Web Dynpro is aimed to be a high fidelity web
UI, which comprises flexible client-side solutions
as
well
as
accessibility
features
and
internationalization. Basically, there are three

view
EmployeeForm

control

to the
backend

component
EmployeeBaseDataEditor

"model manager"

view controller
of EmployeeForm

component
controller

control
"name" text field

context

context

model class
Employee

control property
text

context element
employee/name

context element
employee/name

model property
"name" attribute

control property

context element

context element

model property

model
Human Ressources

Figure 1 Simple example

types of client platforms:

JavaScript-capable web browsers (up from
Internet Explorer 5.5 or Mozilla 1.7),
mobile devices (PocketPC, Blackberry),
the Web Dynpro Client for Windows, which
can be regarded as the successor of the SAP
GUI application. [4]
In addition to client-side rendering using
JavaScript, other rendering modes are under
consideration, such as static HTML assembled by
the server. [2]
The remainder of this article will focus upon
Java development and rendering using
JavaScript-capable web browsers. However, the
basic concepts discussed in section 2 hold true for
other use cases as well. Diagrams use FMC
notation (see [8]).

2. Basic concepts
2.1. An example
The basic concepts of Web Dynpro are now
explained using the example in Figure 1. A form
for editing employee base data (like name, date of
birth and so on) should be realized as a Web
Dynpro application. Note that is a simple
example: it comes with only one view and no
further controllers beyond the view controller and
the component controller. Furthermore, it uses no
complex data types, i.e. only strings are mapped
between contexts.

2.1.1. View
A view describes a visible screen area, which
contains and lays out controls (also called UI
elements or widgets). In the example, a view
called EmployeeForm contains controls of type
text field for displaying and entering information
such as the name of an employee. Actions are
defined for designated user input (i.e. entering
text, or pressing a button), they may trigger event
handling.
Views can be arranged to complex screen
layouts using view areas, view sets and windows,
and navigation plugs may be added to a view for
switching between views. Both is beyond the
scope of this article.

2.1.2. Controller
For realization of dynamics, controllers are
required. Every view has a dedicated view
controller, and every component has a component
controller. Custom controllers may be added for
further structuring of the system.
A view controller performs event handling
based of the actions invoked in the view. For
example, the view controller of EmployeeForm
may react on pressing a button by updating data
(see section 2.1.6) or switching to another view.
Besides event handling (which is described in
event handler methods), controllers may perform
other activity described in methods.

2.1.3. Model
A model describes data in the backend, for
example using JavaBeans. Those data are

provided through model classes which comprise

model properties. In the example, the Web
Dynpro component uses a model called Human
Ressources. Inside this model, the Employee
model class contains an employees data, in
particular the name attribute as a model
property.
Models may also contain executable model
classes, which can be called. These are not
covered in this article.
It should be noted that the classic Model-ViewController pattern (MVC) is not apparent in Web
Dynproalthough the same wording is used and
although this is claimed in various publications.
In classic MVC, a view gets updates directly from
the model ([7], i.e. without indirection via a
controller), which is not true for Web Dynpro.

2.1.4. Component
A reusable, encapsulated part of the system (and
the describing software package) is called a
component. In most cases, a component contains
several views and controllers (in fact, a
component controller is always present), and uses
one or more models. In the example, the
component is called EmployeeBaseDataEditor.
Components are able to communicate with other
components via component interfaces.

2.1.5. Application
An application, which is not embodied in Figure 1,
serves as the entry point for users in terms of
something runnable from the frontend. It is
identified by a uniform resource locator (URL).
Running an application means
1. starting a designated component, and
2. navigating to an initial view, which in turn is
displayed in an initial window.

2.1.6. Context
All data processing in a Web Dynpro application
is done via contexts. Each controller has a context,
which represents a hierarchical data model1 as
depicted in Figure 2, where leaf nodes are typed
using Java native types (e.g. String as in the
example) or Java dictionary types.
Typically, a view controllers context keeps the
Model means a structure of metadata (i.e. types and their
relationships) here. The quotation marks are used to
distinguish this term from a WebDynpro model as
introduced in section 2.1.3.
1

model of the data to be presented in controls of

the view, and a binding exists between these
context elements and control properties. Then, a
component controllers context keeps the model

Figure 2 A context

of all data required in the component, and these

context elements are bound to a model. Moreover,
context elements may be mapped across contexts.
According to context mappings, data changes
are synchronized between controls and models,
so one may have the idea of only one location for
the data. In Figure 1, this is illustrated by the long
rounded node for the employees name, which
comprises the corresponding control property,
context elements, and model property.

2.2. Meta-model
In Figure 3, all the concepts introduced so far are
put together to form a meta-model. The entity
types and relationships concerning screen layout
and navigation are grayed out since they are not
covered in this article.
As Figure 3 depicts, a component consists of
views and controllers, may use models, and is
started by an application. Controllers are
partitioned into view controllers, component
controllers, and custom controllers, whereas there
is exactly one component controller, and one view
controller per view. A view consists of controls,
which have control properties. As well, a model
consists of model classes, which have model
properties.
A context is part of each controller and
consists of context elements. To simplify matters,
context elements are not partitioned into non-leaf
and leaf elements in Figure 3, so it is true that
context elements may be bound to both model
classes and model properties. On the other hand,
context elements may be bound to control
properties, and can be mapped to context
elements in other contexts.

screen layout
application

start

component

have

use

window

consist of

component
controller

custom
controller

consist of

view
controller

controller
model

view
outbound
plug

have

navigation
link

context
inbound
plug
plug
model
class

control

have

have

model
property

context
element

control
property

bind

bind

navigation

map

Figure 3 Meta-model

3. Development process
As mentioned before, the NetWeaver Developer
Studio provides tools to create Web Dynpro
applications in a graphical or declarative manner.
Usually, this includes all the layout and
navigation, as well as context data and model
binding. These pieces of system description are
known as Web Dynpro metadata, for which the
corresponding
Java
code
is
generated
Web Dynpro Tools
Editor

developer
Generator

Web Dynpro
Metadata

Java Code

Figure 4 Development process

automatically. In addition, programmers may

alter the generated code in order to add event
handlers or additional methods (see Figure 4). [5]
The Web Dynpro tools require custom code to
be restricted to designated regions, which are
marked with special comments. In the following
code, only the blocks between the //@@begin
and //@@end markers may be edited and would
be preserved during code re-generation:
//@@begin javadoc:onActionBack(ServerEvent)
/** Declared validating event handler. */
//@@end
public void onActionBack(
<...> IWDCustomEvent wdEvent
)
{
//@@begin onActionBack(ServerEvent)
wdThis.wdFirePlugToStartView();
//@@end
}

Writing a Web Dynpro application typically

includes some common steps as listed in Table 1.
For each step, the table states if graphical,
declarative, or procedural programming is
appropriate.

Table 1 Common development steps

Step
Start
create component
(code is generated)
Design views
create view (code is generated)
place controls on view
(metadata are generated)
add control properties
(metadata are updated)
Design screen layout
apply screen layout to views
(metadata are generated)
Design navigation
create and connect navigation plugs
(code is generated)
write event handlers
Design data flow
populate and map contexts
(metadata are generated)
use models
(metadata are generated)
Add additional features
add controllers, write event
handlers and methods

Web Dynpro
client

4. Execution

decl.

Figure 5 depicts the execution environment of a

Web Dynpro application. At high level, one can
have the idea that the application, which runs on
a presentation server, reads and writes screen
data (i.e. control properties and layout) at the
client, and communicates with the backend
application in order to use business data. All
information about data binding and contexts is
stored inside the application on the presentation
server.
Considering the control flow in more detail,
its the Web Dynpro client (e.g. implemented as a
bunch of JavaScript functions) that initiates all
activitynamely when an action fires. The
resulting request/reply cycle is called a roundtrip
and includes

decl.
graph.
decl.

graph.

graph./
decl.
proc.
graph./
decl.
graph./
decl.
proc.

a message from the client to the server, and

context update at the server,
possibly further activity by controllers at the
server, and
a message from the server to the client, and
screen update at the client. [1]
The application makes use of the Web Dynpro
runtime, which performs, amongst other things,
event dispatching and model management for
communication with backends. According to the
type of the backend server, different protocols are
used for communication: Remote method
invocation (RMI) for Java-based beckends, SAP
Java Connector for ABAP-based backends, or
SOAP for Web Services.

Web-Dynprobased application

screen data

Type

Web Dynpro
runtime

RMI

Backend
application

J2EE
Application Server

business
data

Backend server
(J2EE-based)

User
R
R

Web browser

Web server
HTTP

Client

SAP Java
Connector
R

Backend server
(ABAP-based)

Web Service provider

Presentation server
SOAP

Figure 5 Execution environment

Finally, at low level the Web Dynpro client

and the Web Dynpro runtime make use of a web
browser2 and a web server, respectively, so the
client/server communication takes place via the
Hypertext Transfer Protocol (HTTP).

5. Conclusion
With Web Dynpro, SAP introduces a powerful
framework for user interfaces in NetWeaver.
Although the combination of Java-based server
applications
and
JavaScript-enabled
web
browsers is the most common use case at the
moment, it is open for different programming
languages and platforms, different frontend
types, as well as new backend types.
Most of the programming can be done in a
graphical or declarative manner. The NetWeaver
Developer Studio, which offers the tools to do so,
is in turn based upon the Eclipse framework and
thus excellently extensible. At product level, the
component concept supports reusability of Web
Dynpro applications.
From a technical point of view, the mapping
and synchronization of data between UI controls
and the backend via models and contexts is a
distinguishing feature. All activity is initiated
from the client, forming roundtrips. This
approach makes Web Dynpro feasible for a large
class of frontend types (particularly, limited web
browsers).
It's a simplified association that the Web Dynpro client
communicates with a web browserin fact it is implemented
by parts of a web browser. However, one can consider these
components two agents (one for screen interaction, one for
page loading) to preserve the idea of layering.
2

References
[1] Kessler, K., Tillert, P., Dobrikov, P.: JavaProgrammierung mit dem SAP Web Application
Server. Galileo Press, Bonn 2005.
[2] McNulty, P.: Web Dynpro Overview. SAP AG,
2002.
[3] Tillert, P., Wilson, A.: Web Dynpro
Introduction/Concepts. SAP AG, 2003.
[4] SAP Library Development Manual, Web Dynpro.
[5] SAP Library Architecture Manual, Web Dynpro
Architecture.
[6] SAP Online Help, Creating Your First Web Dynpro
Application.
[7] Knpfel, A.: Konzepte der Beschreibung
interaktiver Systeme. Universittsverlag Potsdam,
Potsdam 2005.
[8] Fundamental Modeling Concepts home page,
http://www.f-m-c.org