Overview of the Web Dynpro Concept and Definition
Web Dynpro is SAP's programming model for developing user interfaces (UIs) for professional business applications. It is based on the flexible Model View Controller, which ensures that the UI (the presentation layer, that is) is separated from the business logic of the backend system. This architecture is already evident in the SAP NetWeaver Developer Studio - an integrated development environment.

Fig. 1: SAP NetWeaver Developer Studio - Web Dynpro Perspective
The Eclipse-based SAP NetWeaver Developer Studio offers intuitive, graphic tools for developing client applications and UIs. These tools visually support model-based development. This model-driven approach minimizes the number of lines of code that need to be written, and enables easy reuse of the UI components.

Web Dynpro's objective is to ensure that most of the UI consists of references to existing components instead of being programmed from scratch, especially since manual programming is time-intensive and it also increases the likelihood of errors. Web Dynpro is nevertheless not a magic box that can guess what is on the developer's mind. And, for complex applications, it will certainly be necessary to make adjustments and changes to the generated source code. Developers can make these changes at any time during the development process. The broad graphic support, however, keeps the required effort to a minimum. One of SAP NetWeaver Developer Studio's main tasks is to support the model-based and code-based approach during the entire programming process, depending on the skills of the developer and the complexity of the application. The move from a declarative method to coding is not a one-way street; both directions are possible.

A platform-independent meta-model is created when the UI is programmed. Java classes are generated from this model and then executed in the J2EE Engine of the application server at runtime.Web Dynpro also supports the development of applications for clients as well as for mobile devices. The developer can use the same development tools and the same UI elements (such as buttons, TextView, TextEdit, and input fields) as are used to develop standard applications that run on the desktop. The UI elements contain information pertaining to how they should behave on the different devices and browsers. Together with the device and browser recognition function of the application server, developers can program mobile applications that can run on different mobile devices.

Model View Controller With Web Dynpro, a Web UI gets divided into three layers: View - The Presentation Views define the layout of an application. They contain the layout and properties of the UI elements and define the connection between the UI elements and the controllers. Controller - The Interaction The controllers are responsible for the interaction (such as event handling, error handling and navigation). Controllers contain: Event handlers that react to certain events, for example if a view is initialized, closed or called, or if a certain action is performed on a UI element Methods that the controller provides for other controllers Model - Binding to Data Sources and Services The data model defines the binding. Web Dynpro supports different models, for example: Adaptive RFC model for binding to SAP systems Web Service model for using Web and enterprise services Enterprise Java Beans model (for binding to SAP and external systems)

Web Dynpro Zoom-In
Up to this point, Web Dynpro might not seem really new to an experienced developer; some other UI programming models also provide similar services. For instance, Java Server Pages (JSPs) also enable us to program dynamic Web applications. With the combination of JSP and tag libraries, we can even separate the presentation from the logic. However, the use of HTML tags, JSP tags, and Scriptlet code demand great discipline, otherwise, the advantages of separating the presentation from the logic quickly disappear.

Like Web Dynpro, Sun's new UI Framework Java Server Faces comes with a complete set of tools for building interfaces. The Struts framework, which is easy to learn, also simplifies the development of Java-based applications. Web Dynpro, however, goes a few steps further in UI programming.

Screen management and screen flow
Screen management and flow can be defined on the abstract layer. Web Dynpro supports the embedding of views in views (nested views), so that a typical Web Dynpro application appears to the user as a sequence of visible views. Further, as and when necessary, pop-up windows are also supported.

In the Developer Studio, the definition of nested views is supported graphically by the Navigation Modeler (see Fig. 2). With this tool, developers not only define the nesting of the individual windows, but also the navigation between the windows.

The concept of data context and automatic data transport between them
Each view and controller has its own context. A context is a local store that can store hierarchical structures. The data used in the component or in the view are stored here. Relevant controllers can access this data for reading or writing.Each context has a root node below which the individual data fields (attributes) are stored in a tree structure. The developer creates this tree structure in accordance with the structure of the application.

Fig. 2: Hierarchical Context Structure
Within the Web Dynpro architecture, the contexts of the different controllers can be bound in different ways:

• UI elements of the view can be bound to context elements of the corresponding controller (context binding)
• Mapping can be defined between two contexts of global controllers or from one view context to a global controller context (context mapping)
• The context of a global controller can be bound to attributes of a model

Fig. 3 illustrates this concept.

Fig. 3: Mapping of Abstract Data Binding
Web Dynpro generates the code for automatic data flow (along the connections) between the UI, the UI elements, the controller, and the model. Changes made to a context element are automatically passed on to all the elements that are bound to this context. Since all the data in the context elements is referenced, the entire data transport automatically works in both directions.

Reusability of Web Dynpro components
More complex development units can be built and reused with Web Dynpro. These reusable units are called components. A Web Dynpro component can be made up of any combination of the views and controllers. In addition to the context, methods, and events, navigation between the views and controllers is also encapsulated, so that the behavior of a component (which is defined by the navigation) is packed into the Web Dynpro component in addition to the layout (which is defined by the views). It can then be bound into another Web Dynpro application and reused.

Dynamic programming
Web Dynpro allows for dynamic adjustment of components at runtime. For example, the appearance of views can be changed dynamically, context elements can be added dynamically, and the navigation between the views can be changed dynamically.

Web Dynpro patterns
Web Dynpro goes a step further with the pattern-based method. At runtime, the configuration data of a complete application is edited dynamically. With patterns, components having a clear semantic task can be reused in a number of applications, for example, to search for objects (like customers, material, and tasks) and their detailed view. Application developers configure the components and patterns, thus creating a floor plan that comprise of a number of these patterns.

Development of a Simple Web Dynpro Application Using the Graphical Tools of the SAP NetWeaver Developer StudioIn this section, we will detail a simple example of a Web Dynpro application - a credit limit check, which can be used by a company wanting to check the credit limit of a customer who placed an order, for example. The application uses a Web service that was published on the Internet -- it can be called from there as the data model.

What is a Web Service? A Web service is a Web application that can be used in a program. The scope of these applications range from simple queries to complex business processes that, when bound to backend systems, are called enterprise services. Once a Web service has been implemented, it can be called from any application. Web services use different standards like Web Service Description Language (WSDL) and SOAP (Simple Access Object Protocol). SAP supports all these standards. SAP also works in a number of different organizations (such as Web Services Interoperability WS-I) to improve the quality of the standards for customers (the security mechanisms, for example). Web services are published on the Internet in a kind of Yellow Pages: Universal Description, Discovery and Integration (UDDI).

Back to the example for Web Dynpro and Web Service - as mentioned earlier, Web Dynpro is a set of tools containing graphical development tools, wizards and templates that support the entire development process. They are shown and explained using the example for checking the credit limit:

1. Data Modeler
The Data Modeler is a graphic tool that is included in the set of Web Dynpro tools. By using the Data Modeler, we get efficient support for a number of central development tasks, like creating a view, defining a controller, declaring a model for the component, nesting components, creating data links, and also for working with the wizards for forms, tables, and buttons.

Fig. 4: Selection of the Web Dynpro Model
Using the set of icons visible at the left, the application developer can combine the appropriate elements (model, view, controller) and link them with Drag and Drop. In the view area you can see two views: the input view and the output view. As mentioned earlier, this application uses a Web service as the data model, and the Web Service used in this case is called Credit Limit Service (CLService). The CLServiceController controls the flow of data between the UI and the model. We can select the appropriate icon, for adding a new data model, from the available set of icons. After specifying the data model (CLService), a URL or a local file containing the WSDL must be entered.

Fig. 5: Entry of the WSDL URL or File
For the credit limit example, the Data Modeler has the following appearance:

Fig. 6: Data Modeler for Checking the Credit Limit
2. Navigation Modeler
The Navigation Modeler supports the design of the views and the navigation between the views:

Fig. 7: Navigation Modeler for Checking the Credit Limit
A set of views containing the input window (CLInputView) and output window (CLOutputView) as well as the corresponding outbound and inbound plugs for the navigation can be seen in the figure. Inbound plugs define the possible entry points of a view, and outbound plugs permit us to leave it with a different view. Plugs are always assigned to one view.

3. View Designer
The View Designer graphically supports the creation and implementation of the interface layout of a Web Dynpro application. In the credit limit example, a wizard that greatly simplifies the development process was used because reusable, complex UI elements are provided:

Fig. 8: Template Wizard
Several templates are offered for selection. The template form can be used to define attributes for a PDF document that is part of the view. While the wizard for the table properties support the definition of the data binding for the tables created in the view, the ActionButton wizard allows to define the properties for a button. These templates enable us to create the views to check the credit limit without any manual programming.

Fig. 9: CLInputView in the View Designer

Fig. 10: CLOutputView in the View Designer
Users of this application enter the partner number and credit segment in the input fields of the application and press the button:

Fig. 11: Input View of End User
As a result, the credit limit is displayed in the appropriate currency:

Fig. 12: Output View of End User
Please note that, up to this point, there has been no need to write any code - the application has been created using wizards and the flexible set of Web Dynpro tools.Design of a Complex Web Dynpro Application: Top-Down ApproachSpecial design models are provided for designing Web Dynpro applications for the various abstraction layers. These models can be used to design the application in greater detail.

Fig. 13: Top-Down Approach to the Design

Some Common Web Dynpro Terminology Development Components - a development component (DC) is a container for development objects and can contain further DCs. The visibility of the development objects is defined at DC level. A development object specifies a versioned file (for example, a Java class, a Web Dynpro view, a table definition, or a JSP page). A DC corresponds exactly to a project. Also, a project has one type or technology (Java, J2EE, Web Dynpro, Web Service, Dictionary). Web Dynpro Project - a Web Dynpro project includes all the Web Dynpro development objects. It consists of Web Dynpro components, Web Dynpro component interfaces, and models. It is used to organize files and packages, and also to maintain dictionary entries, settings, and properties for the applications. Web Dynpro Component - a Web Dynpro component is a reusable unit comprising of views and controllers. It can be reused in its entirety and also for structuring the application. Note that a DC next to other DCs can contain Web Dynpro project DCs, which in turn may contain any number of Web Dynpro components. A Web Dynpro component, however, may not contain a DC. Web Dynpro Window - a Web Dynpro window is a container in which we can embed any number of views and view sets. View sets are used to distribute the Web Dynpro window to individual sub-areas and can be nested as required. Both Web Dynpro windows and view sets may contain views. Views are only used for visualization.

Advantages of Web Dynpro
Following are the advantages of using Web Dynpro:

Minimize coding - Maximize design!

• Increased development productivity through the use of graphic and declarative development tools.
• Web Dynpro components based on the MVC development pattern improve the structure of the application, and can be reused.
• The application is decoupled from UI client technologies like the browser and JSP.
• A data dictionary is provided for the central definition of data types and database tables. It can be used for all layers of application development (the presentation, business, and persistence layers, that is).
• Generic services, like automatic data transport based on a defined data flow or automatic error handling of user input based on defined data binding, reduce development costs.
• Integration in a Java development infrastructure ensures automatic versioning, transport, and deployment to test and production systems; this is advantageous for team developments.

All of these advantages mean less implementation work, which leads to an increase in productivity when programming Web applications. The only exception to this is some very specific parts of the UI logic, like the event handler defined by the application developer, where it is not possible to generate code automatically; the developer must implement these parts. In addition to the standard events already provided by Web Dynpro (doInit and doExit, for example), developers can define application-specific events themselves.

Integration of Web Dynpro Applications in the Portal
Web Dynpro is SAP's strategy for developing Web applications, and is therefore the strategic approach for developing content for SAP's Enterprise Portal.

Web Dynpro applications can be integrated in the portal quickly and easily. A Web Dynpro application that runs in the portal can use the portal services that are available, without writing a single line of code. The applications running in the portal are called iViews. iViews communicate with one another using portal eventing - that is, they can send and receive events from other iViews on the same portal page, whether they are based on Web Dynpro or not.

Web Dynpro UI elements are based on Unified Rendering. Therefore, if a company needs to use their own logos and colors (called themes), simply pressing a button can change the appearance of the application. Web Dynpro applications can be adjusted using the style sheet editor of the portal. For example, the colors in the tables are adjusted and automatically used in all applications. Other integration features include the use of unified user management, session management, and WorkProtect mode. The integration of Web Dynpro applications in the portal will be intensified in future releases of the SAP NetWeaver application and integration platform.

The following figure shows an Employee Self Services Web Dynpro application (within ERP 1.0), which was integrated in the SAP Enterprise Portal:

Fig. 14: ESS in SAP Enterprise Portal

Eat your own dog food
SAP application developers use Java and Web Dynpro to develop new applications. The SAP Developer Network (SDN) is another excellent example for the use of homemade technologies. The application and integration platform of the SDN is SAP NetWeaver - based on the SAP Enterprise Portal, Knowledge Management, and J2EE Engine.

Summary
SAP has applied its experience from ABAP development to the Java development world. This process began with a carefully planned development project that was implemented by experienced developers. After some initial pilot phases, SAP is now ready to provide a programming model that significantly simplifies the development processes, both internally at SAP and at customer and partner sites. And that brings us back to Highway 101 -- passing the gorgeous scenery of the Pacific on a road linking two of the most beautiful cities of the world. Try it yourself - Download the Sneak Preview II with exercises and coding examples from the SAP Developer Network!

Links and Literature

• sdn.sap.com for downloading the Sneak Preview II and discussion forums