Welcome to Java WebDynpro Tutorials. The objective of these tutorials is to provide in depth understand of Java WebDynpro.

In addition to free Java WebDynpro Tutorials, we will cover common interview questions, issues and how to’s of Java WebDynpro.

Introduction

The Java variant of Web Dynpro experienced limited commercial success, and as of 2010, has been placed in maintenance. This means that the existing product is supported to the extent that any bugs are fixed; however, no new functionality will be added. SAP's development effort is now focused on the ABAP variant of Web Dynpro.

WebDynpro for ABAP (WD4A, WDA) is the SAP standard UI ( user interface) technology for developing Web applications in the ABAP language. It consists of a runtime environment and a graphical development environment with special Web Dynpro tools that are integrated in the ABAP Workbench (SE80).

Web Dynpro offers the following advantages for application developers:

-The use of declarative and graphical tools significantly reduces the implementation effort

-Web Dynpro supports a structured design process

-Strict separation between layout and business data

-Reuse and better maintainability by using components

-The layout and navigation is easily changed using the Web Dynpro tools

-Stateful applications are supported – that is, if the page is changed and the required data remains intact so that you can access it at any time through out the entire application context. Note that stateless applications are not possible.

-Automatic data transport using data binding

-Automatic input check

-User interface accessibility is supported

-Full integration in the reliable ABAP development environment.

Web Dynpro Architecture

Web Dynpro components allow structuring complex Web applications and developing reusable, interacting entities. This enables the nesting of large application sections. Web Dynpro components are containers for other entities related to the UI and the Web Dynpro program. Entities related to the UI are windows and views . The layout of a view represents a rectangular part of a page displayed by the client (for example, a browser). The view contains UI elements such as input fields and buttons. The complete page sent to the client can be set up by only one view, but can also be a combination of multiple views. The possible combinations of views and flow between the views is defined in a window. A window can contain an arbitrary number of views. A view can be embedded in an arbitrary number of windows. The Web Dynpro source code is located in Web Dynpro controllers .The hierarchical storage for the global variables of controllers is called the context . Web Dynpro components can be addressed in three different ways:

-Using a Web Dynpro application, a Web Dynpro component can be related to a URL, which can be called from a Web browser or another Web Dynpro client.

-When reusing a Web Dynpro component as a sub-component, the visual interface of a Web Dynpro component can be combined with the visual entities of the main component to form the UI.

-When reusing a Web Dynpro component as a sub-component, all methods and data defined in the programming interface can be accessed by the main component.

Web Dynpro Application

A Web Dynpro application defines a URL that acts as the client’s entry point into the functionality contained within a Web Dynpro Component. That is, a URL is created which points to one of the visual interfaces supplied by a Web Dynpro Component.

For those readers familiar with the ABAP coding environment, the following analogy is useful. In the same way that an SAP transaction code is an entry point into a particular screen of a particular ABAP Module Pool, so a Web Dynpro Application is a URL entry point into a particular visual interface available from a Web Dynpro Component.

The Web Dynpro component is the unit of functionality that acts as the application’s entry point. Any component9 can act as an application entry point, and which ever component has been nominated for this task is known as the root component. The root component should be thought of as being responsible for controlling all further processing that takes place within the application.

A Web Dynpro application cannot exist without there first being at least one Web Dynpro component. In Figure 2 above, the application is shown to contain three components and a model object.

Web Dynpro Model

Caveat Due to the fact that Web Dynpro for Java programs executed by the SAP Java Server typically need to access remote systems in order to obtain business data and functionality, model objects are required in order to encapsulate the communication functionality. This however, is not the case for a Web Dynpro for ABAP program. Calls to RFC enabled function modules or Web Services appear simply as particular ABAP statements within your controller coding. The SAP system itself performs all the necessary communication with external systems. It is superfluous therefore, for an ABAP based Web Dynpro program to make use an extra abstraction layer (a model object) between its own coding and the required business data and functionality. Consequently, the concept of distinct model objects described in this document is only relevant for Java based Web Dynpro applications. The only similarity between the Java and ABAP implementations of Web Dynpro in respect of model objects, is that it is possible (and often beneficial) to write model components in both environments. As stated above, the purpose of a model component is firstly to simplify, and then to reuse, complex functionality required to access business data.

A model object encapsulates access to business data and functionality that typically resides in some remote backend system. Since a Java based Web Dynpro application will be executed in a different runtime environment from the backend business functionality, it will be highly dependent upon the use of model objects to act as proxies between the Java Web Dynpro environment and the remote system. In the Java environment, a model object is used to encapsulate access to:

-Remote enabled function modules (RFMs) in SAP systems

-Enterprise Services Models

-Web services

-Enterprise Java Beans

From the Java perspective, a model object hides the technical communication layer needed to access data from a remote system, and simply provides an interface with a set of methods sufficient for obtaining the required data. Only in certain specialised cases will the Web Dynpro developer need to be concerned with the details of the underlying communication layer.

In the ABAP environment, the encapsulation of functionality into distinct model components is possible, but not necessarily required. However, access is still possible to:

-Any function module in the local SAP system

-Any other ABAP based Web Dynpro component in the local SAP system

-Remote enabled function modules in other SAP systems

-Enterprise Services Models in SAP systems (local or remote).

-Web services

-Enterprise Java Beans