Web Dynpro and the Model View Controller Design  

As an initial starting point, the well established Model View Controller (MVC) design paradigm was used to provide the architectural foundation for Web Dynpro. However, it became apparent that the concepts of MVC would have to be implemented in an SAP specific manner, and include certain extensions in order to create a framework that met all of SAP’s requirements.

This document will lay out both the structural concepts found within a Web Dynpro Component, and how they have been derived from the core principles found in the MVC design paradigm.

Much literature has already been devoted to the importance of separating data processing from data presentation. However, this principle is based on a much more fundamental one in which those parts of the program that generate data are separated from those parts of the program that consume data. Whilst not explicitly stated in the original MVC design, this is one of its inherent, underlying principles.

SAP’s Implementation of the MVC Paradigm

The MVC paradigm separates those parts of a program responsible for generating data, from those parts of the program that consume the generated data. In reality however, you will often find that this division is too simplistic, because certain parts of a program will need to act as both generators and consumers of data.

This extra complication does not negate the usefulness of either the data generator/consumer separation concept, or the MVC paradigm. Rather it just means that procedures must be put in place that allow for the existence of this duality during implementation.

Within a Web Dynpro component, SAP has implemented the principle of separating data generation from data consumption in a variety of situations, and on a variety of scales. Consequently, some units of a Web Dynpro component are permitted to act only as consumers of data, whereas other units are permitted to act as both generators and consumers.

In spite of the various technical implementations, the principle of separating data generators from data consumers remains the common foundation. The basic elements of a Web Dynpro application are the following:

●      Model

A model object encapsulates the interface to some back end system. Its purpose is to act as a proxy that detaches the Web Dynpro application from the data and functionality found in the remote system. In other words, the Web Dynpro application doesn’t need to concern with the specific communication technology required to interact with the back end system.

●      View

A view is used to define a client neutral visualization of the business data.

●      Controller

In the original MVC paradigm, a controller was responsible for managing the interaction of view and model, formatting the model data to be displayed in a view, and calculating which view was to be displayed next. However, in Web Dynpro this concept has been changed so that there are now – broadly speaking – two categories of controller; the differences between which will be described later in this document.

The Metamodel Concept

Since SAP uses both ABAP and Java as languages for the delivery of its application software, any development framework used by SAP must be able to accommodate both the requirements and the characteristics of these languages. It made little sense to have one design methodology for ABAP based applications and another for Java; therefore, a common structural concept was developed for all Web Dynpro development. This common structural foundation is known as the Web Dynpro Metamodel, and acts as a language neutral specification for both the visual appearance and development structure of a Web Dynpro program.

Using the Web Dynpro tools, you are able to design the main structural and visual parts of a business application in a manner that is largely independent of the implementation language. Much of this design takes place using declarative programming techniques.

Once the metamodel has been defined, a significant proportion of the application coding can be generated by the Web Dynpro toolset. What remains for the application developer to do, is write the coding that responds to user interaction from the front end, and subsequently interacts with some backend system.

Graphical Development Tools

Since a large part of the Web Dynpro design process uses declarative programming techniques, this type of programming is best supported using graphical tools. The SAP NetWeaver Developer Studio (NWDS) contains a range of graphical Web Dynpro tools that allow you to define the following details:

●      Data flow between the front end and back end

●      Layout of the user interface

●      Properties of user interface elements

●      Navigation from one view to another

Execution of Web Dynpro Applications

In order to execute the unit of coding, a server side environment known as the Web Dynpro framework is needed. Without this runtime environment, it is not possible to execute a Web Dynpro application. The Web Dynpro framework is supplied as a deployed service in a NetWeaver Java Server.

The Web Dynpro framework service deployed on the SAP NetWeaver Java Server cannot function correctly without other deployed SAP services such as the Java Dictionary, Web Services, and the JCo service. Therefore, Web Dynpro applications are only supported for execution on an SAP Java Server and not a third party Java Server such as JBoss™ or WebSphere™.