Web Dynpro:

Context Mapping and Model Binding

Matthias Weidlich
Seminar System Modeling 2005
Hasso-Plattner-Institute for Software Systems Engineering
matthias.weidlich@hpi.uni-potsdam.de
Abstract
In this paper the main concepts and basic technologies
concerning data management in Web Dynpro are described.
After the context concept has been explained, the focus
turns to the different types of dataows in a Web Dynpro
application. Therefore the mechanisms Data Binding, Con-
text Mapping and Model Binding will be discussed. Com-
pleting the given impression of the link between frontend
system and backend system, the import of models and their
connections at runtime will be characterized.
1. Introduction
With the launch of the NetWeaver platform, SAP
introduces a new framework for developing browser
based user interfaces, Web Dynpro. As it claims
to be the user interface technology for all applica-
tions within the scope of NetWeaver, it comprises
many complex concepts, such as a generic, platform-
independent meta model oriented on the Model View
Controller (MVC) design pattern. An introduction
into these general concepts can be found in [9, 12].
Referring to [5], Web Dynpro allows the separation
of design decisions, navigation issues and data mod-
elling, which includes the concepts to store and trans-
port data inside an application.
Context Mapping and Model Binding, mentioned
in the title, are two mechanismfor data passing in Web
Dynpro. Nevertheless this paper focuses not only on
these issues, but also explains the basic principles con-
cerning data management. That is why the article is
divided into two parts.
Firstly the context concept, the main concept re-
garding data storage in Web Dynpro, will be dis-
cussed. On account of this the utilization and the
structure including the most important properties will
be explained. The rst part ends with a short descrip-
tion of the approaches for context programming.
In the second part the focus will turn to the
dataows in a Web Dynpro application. Therefore the
three different dataow types, Data Binding, Context
Mapping and Model Binding, will be introduced. Af-
ter the questions of the model origin will be answered,
communication scenarios are illustrated.
Finally the main points about dataows in Web
Dynpro will be concluded.
2. Context Concept
2.1. Utilization of Contexts
A Web Dynpro application consists of active parts,
the controllers, and passive parts the contexts. More-
over each controller, for instance a view controller or
a custom controller, has its own context. Although all
data used by the controller or views is stored in the
corresponding context, another aspect is even more
important. Contexts are used as interfaces to pass data
from the frontend, the user interface, to the backend
system and vice versa. That brings us to the question,
how these contexts are structured.
2.2. General Context Structure
Contexts are always structured as a tree, consisting
of nodes (the non-leafs) and attributes (the leafs), as it
is shown in the Entity Relation Model in gure 1 on
the following page. Each context has a root node,
underneath the data elds are stored. Although the
name implies something different, the root node is not
a usual node, but a pointer that simply denes the en-
try point into the tree. That is why the cardinality is
unchangeable, set to 1..1 (see also 2.3). Both types of
context elements, subnodes and node attributes, exists
1
Context Element
Subnode
- name
- cardinality
- selection
- singleton
Root Node
- cardinality = 1..1
Value Node
- leadSelection
Model Node
- modelClass
Context
Node Attribute
- name
- readOnly
Value Attribute
- calculated
- type
Model Attribute
consists
of
consists
of
Figure 1. Context Structure
in two avours: a model and a value avour. The dif-
ference is not only a varying set of properties. In addi-
tion value nodes have no binding to the Web Dynpro
model (the model will be explained in 3.4), the typical
services existing for a model node, like data transfer
to the model, are not available for the value node. The
same term is endowed for value attributes and model
attributes.
Since it is not possible to discuss all properties of
context elements within the scope of this article, in the
next part the focus will be laid on the most important
ones.
The property name should be self-explanatory, it
contains the name of the context element that have to
be unique in the whole project. As type declares the
data type of a value attribute it can be a Java Native
Type. Nevertheless Java Dictionary Types
1
are even
better to use as attribute types, due to the possibility
to attend a Data Binding.
2.3. Cardinality and LeadSelection
Causing the fact that the context is a data model
that describes entities and relations, each node repre-
1
The Java Dictionary contains central, platform- and source code
independent type descriptions, including meta data for database
objects and user interfaces.
sents either an individual instance
2
of an object type
or a list of instances at runtime [2]. This property
of a node is called cardinality, which is specied via
minimal appearance .. maximal appearance and
can take on four values:
0..1
The node contains only one element instance,
which have not to be instanced.
1..1
Again the node contains only one element in-
stance, but this time it has to be instanced.
0..n
The node is called multiple node and can contain
several element instances, of which none have to
be instanced.
1..n
Again the node is a multiple node and can contain
several element instances, of which at least one
have to be instanced.
According to the possibility to dene multiple nodes,
a mechanism to mark a specic element instance in
the list is necessary. For that reason each element in an
instance list belonging to a value node has a boolean
property called leadSelection. This property can be set
true for only one element of the list at one time. If
nothing else is specied, the rst element of the list is
automatically assigned the lead selection property.
2.4. Calculated Attributes
A special type of value attributes are the calculated
attributes. Hence these attributes are not stored as
memory objects at runtime, they are automatically cal-
culated by the Web Dynpro Runtime on demand. This
demand can be triggered by the Web Dynpro Runtime
or some controller coding by accessing the attribute.
After setting the property calculated true, the body of
a setter- and a getter-method is generated and the de-
veloper has to add the calculation part.
A short code example for a calculated attribute can
be seen on gure 2. It shows how a full name of a
person can be calculated by simply combining the rst
name and the last name.
2
To be accurate it has to be said that the individual instance is
also embedded in a singleton list.
2
java.lang.String getUserFullName (
IPrivateFormView.IUserDataElement element)
{
//@@begin
return element.getFirstname() +
+ element.getLastname();
//@@end
}
Figure 2. Calculated Property Code Example
2.5. Singleton Property and Supply Functions
Another important property is the singleton prop-
erty that can be found in value nodes as well as in
model nodes. Unlike the cardinality of a node, which
describes the number of possible elements within
the node, the singleton property determines whether
these elements are set for all elements of the parent
node
3
(non-singleton) or for exactly one element of the
parent node (singleton) [2]. The afliation of these sin-
gleton elements is realized in the following way: the
singleton elements correspond to the parent node el-
ement which is highlighted by the property leadSelec-
tion (as it was described in 2.3). Therefore a change of
the lead selection in the element list of the parent node
makes it necessary to update the data in the singleton
elements.
For that reason a special type of controller meth-
ods for lling value nodes with elements exists, the
Supply Functions. These functions are called by the
Web Dynpro Runtime whenever the element list of
the associated node is accessed. Although each node
can have a Supply Function they are mainly used in
connection with singleton elements. The data origins
used to ll the singleton elements can be various, for
instance other elements of the current context.
2.6. Context APIs
While Supply Functions only deal with the in-
stances belonging to a context node, there also has to
be the possibility to change the structure of the con-
text by programming. On account of this Web Dynpro
provides two different types of Application Program-
ming Interfaces (APIs).
The rst one is the set of generic APIs which are
needed for the dynamic creation of new context ele-
ments at runtime. Examples for generic APIs are the
global interfaces IWDContext (to gain access to a spe-
3
A parent node of a context element is the node, which is located
directly above the element in the hierarchical structure.
cic context) and IWDNode (to modify, respectively
create a context node).
The typecasted APIs, the second type of provided
APIs, are generated automatically for all statically de-
ned context elements. These interfaces are type-
casted, meaning that the signatures of the methods
already contain the corresponding object types re-
spectively Java Dictionary Types. The typecasted in-
terfaces, for instance IContextNode (the interface to
modify a specic node) or IContextElement (to mod-
ify a specic node element), are derived from the
global interfaces.
3. Web Dynpro Dataows
3.1. Overview
In this chapter the three types of dataows in a Web
Dynpro application, the Data Binding, the Context
Mapping and the Model Binding, will be explained.
Before the focus turns to the structural details the
relevance of these dataows should be motivated. On
the one hand the Data Binding realizes the link be-
tween the user interface and the data structures be-
hind, in the sense of ordinary input- and output mech-
anism. On the other hand it allows controlling the ap-
pearance of the user interface by the data structures.
The Context Mapping, which enables data to be cir-
culated between contexts, is mainly used to make the
data persistent, due to the limited lifetime of viewcon-
trollers. An example for such a usage can be found in
[5]. Moreover the Model Binding connects the inter-
nal data structures of a Web Dynpro application with
the model that represents the backend system(see also
3.4).
Furthermore it is necessary to envision the struc-
ture of a typical application which is shown in the
block diagram in gure 3. The Web Dynpro Runtime
embeds the application, which consists of agents, for
instance a view controller, a custom controller and a
model agent. To keep the diagram concise, the appli-
cation consists of only one controller of each type and
some parts (e.g. interface controller and component
controller) are not even shown at all.
Additionally there is a big storage containing sev-
eral smaller storages. As it was already mentioned,
every controller has its own context, in this case the
view controller context and the custom controller con-
text. Moreover the view layout contains the proper-
ties of the user interface elements, while the structure
of the model is depicted in 3.4. Pointed out by the
gure, the big unnamed storage is fragmented by the
four smaller storages. Accordingly the imagination
3
Web Dynpro Application
Model
Custom Controller
Context
View Controller
Context
View Layout
View
Controller
Custom
Controller
Model
Agent
Web Dynpro Runtime
to backend system
to
presentation
server
10
6 5
1
8 9
Data Binding Context Mapping Model Binding
Annotation:
2
7
3 4
Figure 3. Overview of Dataows
4
of multiple interfaces, used to access the big storage,
is appropriate. Several numbered storage elements
are available in more than one storage hence the four
named storages overlap in some areas. Concerning
the dataows these are the interesting parts, that will
be introduced in the following sections.
3.2. Data Binding
The rst dataow to discuss is the Data Binding in-
volving the view layout and the view controller con-
text. Data Binding allows the use of context attributes
of the view controller as properties of user interface
(ui) elements. Referring to gure 3 the storage ele-
ments with the number 2, 3 and 4 participate in the
Data Binding, while the storages with the number 1
and 5 are ui element properties, respectively context
elements that have not been bound. On account of the
binding any user change to the ui element properties,
e.g. the text property of an edit eld, is immediately
visible in the context. Due to the assignment of the
same data storage, there is no necessity of data trans-
port.
U Element
U Element
Property
Context Attribute
Value Attribute
Node Attribute
is bound to
consists of
Figure 4. Data Binding
As it is shown in gure 4 the Data Binding can
be dened with value attributes as well as model at-
tributes if the attributes type is a Java Dictionary Type.
In the specic case that the ui element property is a
eld of values (e.g. the entries in a table) the parent
node of the bound attribute has to be a multiple node,
regarding 2.3. If a single property value is bound to
an attribute of a multiple node, the leadSelection high-
lights the value that has to be shown.
3.3. Context Mapping
The mechanism used to pass data from one context
to another is called Context Mapping. As context ele-
ments are in general only visible for the controller the
context belongs to, they can be regarded as local vari-
ables. After a Context Mapping has been dened be-
tween two context elements located in different con-
texts, one and the same context element is visible in
both contexts. Similar to the Data Binding a Context
Mapping does not require any data transport, because
the same storage is assigned for mapped elements. In
gure 3 the Context Mapping involves the view con-
troller context and the custom controller context. The
storage elements with the number 5 and 8 are context
elements that have not been mapped. In contrast, the
elements with the number 3, 4, 6 and 7 are mapped,
whereas the elements 3 and 4 are also bound with a
Data Binding as it is described in 3.2.
Node
consists
of
Value Node
Model Node
is mapped to
Attribute
Value Attribute
Model Attribute
is mapped to
is mapped to
is mapped to
consists
of
Figure 5. Context Mapping
The gure 5 shows that a Context Mapping on the
one hand can be dened either between value nodes
or between model nodes, but not between a single
value node and a single model node. On the other
hand value attributes can be mapped only to value at-
tributes. For model attributes the same rule is applied.
Additionally the following constraint has to be satis-
ed: a mapping between the parent nodes of two at-
tributes is a precondition for a mapping between these
attributes.
Moreover Context Mapping is a directive relation.
Although the direction has no impact on data changes,
because it is irrelevant in which context the changes
5
are made, modications of the mapping relation have
to be done at the context in which the mapping rela-
tion starts. Consequently the context that is mapped
does not even have any knowledge about the map-
ping at all.
Nonetheless it is necessary to dene a usage rela-
tion between the controllers, whose contexts should
participate in a Context Mapping.
3.4. Web Dynpro Model
Model Element
Model Class
- name
Non Executable
Model Class
Executable
Model Class
Model
belongs
to
Model Property
- name
- type
consists
of
Figure 6. Web Dynpro Model
Before the focus turns to the third type of dataow,
the Model Binding, the Web Dynpro model itself
should be discussed. The model is a data structure
that represents the data and the functionality of the
backend, for instance a web service provider or a
ABAP
4
backend server. As it can be seen in g-
ure 6, the model consists of model classes which on
their part contain other model classes and model at-
tributes. The model classes are Java classes which can
be grouped in executable and non-executable classes.
Nevertheless they all have to implement the Common
Model Interface (CMI), an interface that affects mainly
data management and event handling [8].
If the structure of the model is already known at
design time, the CMI implementing model classes
contain typed getter- and setter-methods similar to
Java Beans
5
. Therefore a typed access to the classes
is provided. The availability of information about
the model structure allows it to declaratively dene
a Model Binding in the way it is described in 3.5.
4
Advanced Business Application Programming (ABAP) is a pro-
gramming language created by SAP, which is positioned as the lan-
guage for programming SAPs Web Application Server.
5
Java Beans are reusable software components, for which a spec-
ication have been dened by Sun Microsystems.
In the probable case that structure information are
available not until runtime, it is also possible to dene
the Model Binding dynamically at runtime. Therefore
the access to the model classes is gained via generic
methods, so that the identication of model elements
is exclusively based on their names.
3.5. Model Binding
The Model Binding is used to access the model and
for that reason it links the model with a controller con-
text. In the example application shown in gure 3 on
page 4, the Model Binding is dened between the cus-
tom controller context and the model. Thus the stor-
age elements with the number 4, 7 and 9 participate
in the Model Binding. In contrast, the storage with
the number 8 is a context element, that has not been
bound, while the storage with the number 10 is an un-
bound model element. As it was already discussed
for the Data Binding and Context Mapping the assign-
ment of one storage address for both bound elements
redundantizes any data transport.
Model Element Context Element
Model Class
Model Attribute
Context
Model Attribute
Context
Model Node
is bound to
Model
consists of
Figure 7. Model Binding
Regarding gure 7, on the one hand context model
attributes can be bound to attributes of the model. On
the other hand context model nodes can be bound to
model classes. Similar to the Context Mapping, it is
necessary to state a Model Binding relation between
the parent node of a context model attribute and the
parent model class of the model attribute to bind the
attributes.
6
3.6. Model Import and Connections to the Model
As it was already mentioned in 3.4, all model
classes have to implement the CMI. Usually the model
classes are generated by an import wizard, on account
of this the developer does not have to care about the
correct implementation of the CMI. Depending on the
type of the used backend system, the import wizard
can create the model classes out of different model de-
scriptions.
mport Wizard
Model Agent
R
Model
Data
to Web
Dynpro
Runtime
Models
Webservice Model
(WSDL)
UML Web Dynpro
Model (XM)
Java Bean Model
RFC Model
Model
Meta Data
Figure 8. Model Import
In gure 6 the four possible import types are
shown. If the Web Dynpro application should use a
web service, the model classes will be created out of
the WSDL
6
description. Concerning the case the de-
veloper wants to use existing Web Dynpro UML mod-
els a description in the XMI
7
format has to be avail-
able, while a RFC
8
model is needed to call RFCs di-
rectly in an ABAP system. The source code of Java
Beans is directly parsed by the import wizard due to
the similar structure of Java Beans and model classes
implementing the CMI.
On account of the two avours of the Web Dyn-
pro Runtime the possibilities to communicate with the
model at runtime are potentially restricted. Figure 9 il-
lustrates the conceivable communication ow for the
6
The Web Service Description Language (WSDL) is an XML for-
mat published by the World Wide Web Consortium (W3C) for de-
scribing web services.
7
XML Metadata Interchange (XMI) is an OMG (Object Manage-
ment Group) standard for exchanging metadata information via
XML.
8
Remote Function Calls (RFCs) are a standardized mechanism
for communication between applications on SAP systems as well as
non-SAP systems.
J2EE based Web Dynpro Runtime [9]. To call proce-
dures from a J2EE backend server, Remote Method
Invocation (RMI) is used. The data transfer to a web
service is done via SOAP, which is described in detail
in [10]. Moreover a ABAP backend server can not be
accessed directly. For that reason a middleware com-
ponent named SAP Java Connector (JCo) is required
to generate RFCs out of Java calls and vice versa.
Model
Agent
Webservice Provider
J2EE Backend Server
ABAP Backend Server
R
(RM)
R
(SOAP)
R
(SAP Java
Connector)
J2EE Web
Dynpro
Runtime
R
Backend
Data
Backend
Data
Backend
Data
Model Data
Figure 9. Connection to Model (J2EE based)
Model
Agent
Webservice Provider
ABAP Backend Server
R
(SOAP)
R
(RFC, BAP)
ABAP Web
Dynpro
Runtime
R
Backend
Data
Backend
Data
Model Data
Figure 10. Connection to Model (ABAPbased)
In contrast to the J2EE avour, the ABAP avour
of the Web Dynpro Runtime is restricted in its com-
munication to web service providers and ABAP back-
end servers [9]. While the data exchange with web
services works in the same manner as with the J2EE
avour, the ABAP backend system can now be ac-
cessed directly. Therefore the Business Application
Programming Interfaces (BAPIs), which are standard-
ized methods to gain access to SAP Business Objects,
can be called via RFCs.
4. Summary
In conclusion the contexts are the main concept for
the storage, handling and management of data in Web
Dynpro. As contexts describe entities and their re-
lations, they dene the structure, the data model, in
7
which all values will be stored. Advanced design
mechanism, for instance singleton nodes, allow cre-
ating complex data structures according to the project
domain. Although much of the data modelling can
be done declaratively, the data structure can also be
modied by context programming at runtime.
In addition, there are three possibilities to realize
dataows in Web Dynpro. Data Binding creates the
link between the properties of user interfaces and con-
troller contexts, that can be connected to another con-
text via Context Mapping. The data and functionality
of the backend system, represented by the Web Dyn-
pro model, can be accessed by dening a Model Bind-
ing. Hence the employed backend system can be a
J2EE server, an ABAP server or a web service provider,
an import wizard automatically creates the suitable
model that abstracts the type of the backend system.
Due to this, the discussed data management con-
cepts are the basis for the whole Web Dynpro technol-
ogy.
References
[1] Introduction to Web Dynpro. SAP Developer Network.
www.sdn.sap.com.
[2] Web Dynpro Architecture. SAP Library.
www.help.sap.com.
[3] Business Application Programming Interfaces.
tse - technologieberatung und systemen-
twicklung, Hamburg, 2005. http://www.tse-
hamburg.de/Papers/SAP/sapBAPI.html.
[4] A. Fahle. SAP Web Dynpro: berblick. 2005.
[5] C. Holz. Web Dynpro: Navigation and Komponentenori-
entierung. 2005.
[6] T. Horn. Application Server, Web Application Server,
Web Services, SOAP, Java. 2005. http://www.torsten-
horn.de/techdocs/applicationserver.htm.
[7] T. Horn. SAP BAPI und SAP JCo. 2005.
http://www.torsten-horn.de/techdocs/sap-
bapi.htm.
[8] K. Kessler, P. Tillert, and P. Dobrikov. Java Program-
mierung mit dem SAP Web Application Server. Galileo
Press, 2005.
[9] P. McNulty. Web Dynpro Overview. SAP AG, 2003.
[10] J. Nicolai. Web Services im WebAS. 2005.
[11] P. Tillert. Wiederverwendbare Software (Web Dynpro).
2004. www.sap.info.
[12] P. Tillert. The Basic Facts About Web Dynpro. SAP AG,
2005.
[13] Winkler. The new face of SAP - Web Dynpro.
2004. http://www.oio.de/web-dynpro-the-new-sap-
face.htm.
8