Web Dynpro:Context Mapping and Model Binding

Matthias WeidlichSeminar System Modeling 2005

Hasso-Plattner-Institute for Software Systems Engineeringmatthias.weidlich@hpi.uni-potsdam.de

Abstract

In this paper the main concepts and basic technologiesconcerning data management in Web Dynpro are described.After the context concept has been explained, the focusturns to the different types of dataflows in a Web Dynproapplication. Therefore the mechanisms Data Binding, Con-text Mapping and Model Binding will be discussed. Com-pleting the given impression of the link between frontendsystem and backend system, the import of models and theirconnections at runtime will be characterized.

1. Introduction

With the launch of the NetWeaver platform, SAPintroduces a new framework for developing browserbased user interfaces, Web Dynpro. As it claimsto be the user interface technology for all applica-tions within the scope of NetWeaver, it comprisesmany complex concepts, such as a generic, platform-independent meta model oriented on the Model ViewController (MVC) design pattern. An introductioninto these general concepts can be found in [9, 12].

Referring to [5], Web Dynpro allows the separationof 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, mentionedin the title, are two mechanism for data passing in WebDynpro. Nevertheless this paper focuses not only onthese issues, but also explains the basic principles con-cerning data management. That is why the article isdivided 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 thestructure including the most important properties will

be explained. The first part ends with a short descrip-tion of the approaches for context programming.

In the second part the focus will turn to thedataflows in a Web Dynpro application. Therefore thethree different dataflow types, Data Binding, ContextMapping 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 dataflows in WebDynpro 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 ora custom controller, has its own context. Although alldata used by the controller or views is stored in thecorresponding context, another aspect is even moreimportant. Contexts are used as interfaces to pass datafrom the frontend, the user interface, to the backendsystem 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, consistingof nodes (the non-leafs) and attributes (the leafs), as itis shown in the Entity Relation Model in figure 1 onthe following page. Each context has a root node,underneath the data fields are stored. Although thename implies something different, the root node is nota usual node, but a pointer that simply defines the en-try point into the tree. That is why the cardinality isunchangeable, set to 1..1 (see also 2.3). Both types ofcontext elements, subnodes and node attributes, exists

1

�������������

�� ����� ���

� ����������

� ��������

� ��������

����������� �����������������

���������� �����������

���������� �������

�������

���������� ���� ���

� �������

���������� ���� ��������

� �� �

���������� ���

��������

�!

��������

�!

Figure 1. Context Structure

in two flavours: a model and a value flavour. The dif-ference is not only a varying set of properties. In addi-tion value nodes have no binding to the Web Dynpromodel (the model will be explained in 3.4), the typicalservices existing for a model node, like data transferto the model, are not available for the value node. Thesame term is endowed for value attributes and modelattributes.

Since it is not possible to discuss all properties ofcontext elements within the scope of this article, in thenext part the focus will be laid on the most importantones.

The property name should be self-explanatory, itcontains the name of the context element that have tobe unique in the whole project. As type declares thedata type of a value attribute it can be a Java NativeType. Nevertheless Java Dictionary Types1 are evenbetter to use as attribute types, due to the possibilityto attend a Data Binding.

2.3. Cardinality and LeadSelection

Causing the fact that the context is a data modelthat describes entities and relations, each node repre-

1The Java Dictionary contains central, platform- and source codeindependent type descriptions, including meta data for databaseobjects and user interfaces.

sents either an individual instance2 of an object typeor a list of instances at runtime [2]. This propertyof a node is called cardinality, which is specified via“minimal appearance .. maximal appearance” andcan take on four values:

• 0..1The node contains only one element instance,which have not to be instanced.

• 1..1Again the node contains only one element in-stance, but this time it has to be instanced.

• 0..nThe node is called multiple node and can containseveral element instances, of which none have tobe instanced.

• 1..nAgain the node is a multiple node and can containseveral element instances, of which at least onehave to be instanced.

According to the possibility to define multiple nodes,a mechanism to mark a specific element instance inthe list is necessary. For that reason each element in aninstance list belonging to a value node has a booleanproperty called leadSelection. This property can be settrue for only one element of the list at one time. Ifnothing else is specified, the first element of the list isautomatically assigned the lead selection property.

2.4. Calculated Attributes

A special type of value attributes are the calculatedattributes. Hence these attributes are not stored asmemory objects at runtime, they are automatically cal-culated by the Web Dynpro Runtime on demand. Thisdemand can be triggered by the Web Dynpro Runtimeor some controller coding by accessing the attribute.After setting the property calculated true, the body ofa 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 canbe seen on figure 2. It shows how a full name of aperson can be calculated by simply combining the firstname and the last name.

2To be accurate it has to be said that the individual instance isalso embedded in a singleton list.

2

���������������� �� ������� ��

����� ����� ����� ����� � �� � � ��

�

���� ���

��� � � ��� ������ ���!�"�"

!� � � ��� #����� ��$

���� �%

&

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 inmodel nodes. Unlike the cardinality of a node, whichdescribes the number of possible elements withinthe node, the singleton property determines whetherthese elements are set for all elements of the parentnode3 (non-singleton) or for exactly one element of theparent node (singleton) [2]. The affiliation of these sin-gleton elements is realized in the following way: thesingleton 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 ofthe lead selection in the element list of the parent nodemakes it necessary to update the data in the singletonelements.

For that reason a special type of controller meth-ods for filling value nodes with elements exists, theSupply Functions. These functions are called by theWeb Dynpro Runtime whenever the element list ofthe associated node is accessed. Although each nodecan have a Supply Function they are mainly used inconnection with singleton elements. The data originsused to fill the singleton elements can be various, forinstance 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 tobe the possibility to change the structure of the con-text by programming. On account of this Web Dynproprovides two different types of Application Program-ming Interfaces (APIs).

The first one is the set of generic APIs which areneeded for the dynamic creation of new context ele-ments at runtime. Examples for generic APIs are theglobal interfaces IWDContext (to gain access to a spe-

3A parent node of a context element is the node, which is locateddirectly above the element in the hierarchical structure.

cific context) and IWDNode (to modify, respectivelycreate a context node).

The typecasted APIs, the second type of providedAPIs, are generated automatically for all statically de-fined context elements. These interfaces are type-casted, meaning that the signatures of the methodsalready contain the corresponding object types re-spectively Java Dictionary Types. The typecasted in-terfaces, for instance IContextNode (the interface tomodify a specific node) or IContextElement (to mod-ify a specific node element), are derived from theglobal interfaces.

3. Web Dynpro Dataflows

3.1. Overview

In this chapter the three types of dataflows in a WebDynpro application, the Data Binding, the ContextMapping and the Model Binding, will be explained.

Before the focus turns to the structural details therelevance of these dataflows should be motivated. Onthe 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 thedata persistent, due to the limited lifetime of view con-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 withthe model that represents the backend system (see also3.4).

Furthermore it is necessary to envision the struc-ture of a typical application which is shown in theblock diagram in figure 3. The Web Dynpro Runtimeembeds the application, which consists of agents, forinstance a view controller, a custom controller and amodel agent. To keep the diagram concise, the appli-cation consists of only one controller of each type andsome parts (e.g. interface controller and componentcontroller) 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 theview controller context and the custom controller con-text. Moreover the view layout contains the proper-ties of the user interface elements, while the structureof the model is depicted in 3.4. Pointed out by thefigure, the big unnamed storage is fragmented by thefour smaller storages. Accordingly the imagination

3

������������� ��� �

����

������������

������

� ���������

������

� ��������

� ���

������

������

������

�����

�����

������������� ���

����������������

��

�������� ��

����

�

!"

�

# $

�����% �� �� ����������� �� �����% �� ��

������ �&

'

(

) *

Figure 3. Overview of Dataflows

4

of multiple interfaces, used to access the big storage,is appropriate. Several numbered storage elementsare available in more than one storage hence the fournamed storages overlap in some areas. Concerningthe dataflows these are the interesting parts, that willbe introduced in the following sections.

3.2. Data Binding

The first dataflow to discuss is the Data Binding in-volving the view layout and the view controller con-text. Data Binding allows the use of context attributesof the view controller as properties of user interface(ui) elements. Referring to figure 3 the storage ele-ments with the number 2, 3 and 4 participate in theData Binding, while the storages with the number 1and 5 are ui element properties, respectively contextelements that have not been bound. On account of thebinding any user change to the ui element properties,e.g. the text property of an edit field, is immediatelyvisible in the context. Due to the assignment of thesame data storage, there is no necessity of data trans-port.

���������

���������

�� ���

������������

������������

���������������������

����������

Figure 4. Data Binding

As it is shown in figure 4 the Data Binding canbe defined with value attributes as well as model at-tributes if the attribute’s type is a Java Dictionary Type.In the specific case that the ui element property is afield of values (e.g. the entries in a table) the parentnode of the bound attribute has to be a multiple node,regarding 2.3. If a single property value is bound toan 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 contextto 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 defined be-tween two context elements located in different con-texts, one and the same context element is visible inboth contexts. Similar to the Data Binding a ContextMapping does not require any data transport, becausethe same storage is assigned for mapped elements. Infigure 3 the Context Mapping involves the view con-troller context and the custom controller context. Thestorage elements with the number 5 and 8 are contextelements that have not been mapped. In contrast, theelements with the number 3, 4, 6 and 7 are mapped,whereas the elements 3 and 4 are also bound with aData Binding as it is described in 3.2.

�����������

�

�� �������

���� �����

�����������

�������� ���������

���� �������

�����������

�����������

�����������

�������

�

Figure 5. Context Mapping

The figure 5 shows that a Context Mapping on theone hand can be defined either between value nodesor between model nodes, but not between a singlevalue node and a single model node. On the otherhand 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-fied: a mapping between the parent nodes of two at-tributes is a precondition for a mapping between theseattributes.

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, modifications of the mapping relation haveto be done at the context in which the mapping rela-tion starts. Consequently the context that is mappeddoes not even have any knowledge about the map-ping at all.

Nonetheless it is necessary to define a usage rela-tion between the controllers, whose contexts shouldparticipate in a Context Mapping.

3.4. Web Dynpro Model

�����������

��������� � ���

������������

���������

���������

���������

�����

�����

�

��������������� ���

� ���

�� �

��

Figure 6. Web Dynpro Model

Before the focus turns to the third type of dataflow,the Model Binding, the Web Dynpro model itselfshould be discussed. The model is a data structurethat represents the data and the functionality of thebackend, for instance a web service provider or aABAP 4 backend server. As it can be seen in fig-ure 6, the model consists of model classes which ontheir part contain other model classes and model at-tributes. The model classes are Java classes which canbe grouped in executable and non-executable classes.Nevertheless they all have to implement the CommonModel Interface (CMI), an interface that affects mainlydata management and event handling [8].

If the structure of the model is already known atdesign time, the CMI implementing model classescontain typed getter- and setter-methods similar toJava Beans5. Therefore a typed access to the classesis provided. The availability of information aboutthe model structure allows it to declaratively definea Model Binding in the way it is described in 3.5.

4Advanced Business Application Programming (ABAP) is a pro-gramming language created by SAP, which is positioned as the lan-guage for programming SAP’s Web Application Server.

5Java Beans are reusable software components, for which a spec-ification have been defined by Sun Microsystems.

In the probable case that structure information areavailable not until runtime, it is also possible to definethe Model Binding dynamically at runtime. Thereforethe access to the model classes is gained via genericmethods, so that the identification of model elementsis exclusively based on their names.

3.5. Model Binding

The Model Binding is used to access the model andfor that reason it links the model with a controller con-text. In the example application shown in figure 3 onpage 4, the Model Binding is defined between the cus-tom controller context and the model. Thus the stor-age elements with the number 4, 7 and 9 participatein the Model Binding. In contrast, the storage withthe number 8 is a context element, that has not beenbound, while the storage with the number 10 is an un-bound model element. As it was already discussedfor the Data Binding and Context Mapping the assign-ment of one storage address for both bound elementsredundantizes any data transport.

���������������������

�������� ��

����������������

������������

����

����������

���������

�����

���������

Figure 7. Model Binding

Regarding figure 7, on the one hand context modelattributes can be bound to attributes of the model. Onthe other hand context model nodes can be bound tomodel classes. Similar to the Context Mapping, it isnecessary to state a Model Binding relation betweenthe parent node of a context model attribute and theparent model class of the model attribute to bind theattributes.

6

3.6. Model Import and Connections to the Model

As it was already mentioned in 3.4, all modelclasses have to implement the CMI. Usually the modelclasses are generated by an import wizard, on accountof this the developer does not have to care about thecorrect implementation of the CMI. Depending on thetype of the used backend system, the import wizardcan create the model classes out of different model de-scriptions.

�����������

����������

�

����

����

�������

�������

������

�����

���������� ����

������

� �������������

������ ��!����"���� ����

�#$� ����

����

��������

Figure 8. Model Import

In figure 6 the four possible import types areshown. If the Web Dynpro application should use aweb service, the model classes will be created out ofthe WSDL6 description. Concerning the case the de-veloper wants to use existing Web Dynpro UML mod-els a description in the XMI 7format has to be avail-able, while a RFC8 model is needed to call RFCs di-rectly in an ABAP system. The source code of JavaBeans is directly parsed by the import wizard due tothe similar structure of Java Beans and model classesimplementing the CMI.

On account of the two flavours of the Web Dyn-pro Runtime the possibilities to communicate with themodel at runtime are potentially restricted. Figure 9 il-lustrates the conceivable communication flow for the

6The Web Service Description Language (WSDL) is an XML for-mat published by the World Wide Web Consortium (W3C) for de-scribing web services.

7XML Metadata Interchange (XMI) is an OMG (Object Manage-ment Group) standard for exchanging metadata information viaXML.

8Remote Function Calls (RFCs) are a standardized mechanismfor communication between applications on SAP systems as well asnon-SAP systems.

J2EE based Web Dynpro Runtime [9]. To call proce-dures from a J2EE backend server, Remote MethodInvocation (RMI) is used. The data transfer to a webservice is done via SOAP, which is described in detailin [10]. Moreover a ABAP backend server can not beaccessed directly. For that reason a middleware com-ponent named SAP Java Connector (JCo) is requiredto generate RFCs out of Java calls and vice versa.

������

���� �� ���������������

������������������

������������������

�

�����

�

������

�

����������

�������

������ ���

!"���

�#�$�

�

������

��

������

��

������

��

������ ��

Figure 9. Connection to Model (J2EE based)

������

���

� �� ���������������

������������������

�

������

�

�����������

������ ���

� !���

�"�#�

�

������

���

������

���

���������

Figure 10. Connection to Model (ABAP based)

In contrast to the J2EE flavour, the ABAP flavourof 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 webservices works in the same manner as with the J2EEflavour, the ABAP backend system can now be ac-cessed directly. Therefore the Business ApplicationProgramming 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 forthe storage, handling and management of data in WebDynpro. As contexts describe entities and their re-lations, they define the structure, the data model, in

7

which all values will be stored. Advanced designmechanism, for instance singleton nodes, allow cre-ating complex data structures according to the projectdomain. Although much of the data modelling canbe done declaratively, the data structure can also bemodified by context programming at runtime.

In addition, there are three possibilities to realizedataflows in Web Dynpro. Data Binding creates thelink between the properties of user interfaces and con-troller contexts, that can be connected to another con-text via Context Mapping. The data and functionalityof the backend system, represented by the Web Dyn-pro model, can be accessed by defining a Model Bind-ing. Hence the employed backend system can be aJ2EE server, an ABAP server or a web service provider,an import wizard automatically creates the suitablemodel 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. GalileoPress, 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