ABAP Webdynpro

ABAP Webdynpro 

Web Dynpro for ABAP (WD4A, WDA) is the SAP standard UI technology for developing Web
applications in the ABAP environment. 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
● 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 throughout the entire
application context.
Note that stateless applications are not possible.
● Automatic data transport using data binding
● Automatic input check
● Automatic operation of the Web Dynpro application using the keyboard
● User interface accessibility is supported

● Full integration in the reliable ABAP development environment

In Web Dynpro ABAP it is imperative that a client browser with a fully qualified domain name
(FQDN) has access to the AS-ABAP. For this reason the full URL must be assigned to a Web
Dynpro ABAP application when it is called. The URL must not be shortened (for instance, no
domain specification).

FQDN is necessary for the following reasons:
● One domain is required with which cookies can be set domain-wide, for instance,
SSO2 cookies.
Domain relaxation code is required for cross-frame JavaScript.
This is particularly important for Portal Integration

Web Dynpro is the SAP NetWeaver programming model for user interfaces (UIs).
The Web Dynpro model is based on the Model View Controller paradigm, and has the
following features that build on the classic dynpro model:
● Clear separation of business logic and display logic
● Uniform metamodel for all types of user interfaces
● Execution on a number of client platforms.
● Extensive platform independence of interfaces
Web Dynpro is available both in the Java and the ABAP development environment. Platformspecific
information is available under:

Web Dynpro provides support for developing Web representation of a business application.
You use specific tools to describe the properties of a Web Dynpro application in the form of
Web Dynpro metadata. The necessary source code is then generated automatically and
executed at runtime. In addition to the events offered by the framework, you can also define
your own events for a Web Dynpro application. However, the event handling must always be
programmed in separate source code areas which are executed automatically when the event
is triggered at runtime.

In Web Dynpro, each user interface is always made up of the same basic elements. These
elements of the metamodel can be statically declared using Web Dynpro tools.
It is also possible to implement elements of the metamodel at runtime and to change them or
reintegrate them at runtime. Using these implementations, you can make any changes or
enhancements to a user interface that has been created by declarative methods by
generating new interface structures at runtime.

Conversion of the Model-View-Controller Programming Model
Every Web Dynpro application is structured according to the Model View Controller
programming model:
● The model forms the interface to the back end system and thus enables the
Web Dynpro application access to data.
● The view  is responsible for the representation of the data in the browser.
● The controller  lies between the view and the model. The controller formats
the model data to be displayed in the view, processes the user entries made by the
user, and returns them to the model.

Web Dynpro Component

A Web Dynpro component is a reusable entity. It summarizes all components that are
required as part of this programming unit for an executable Web Dynpro application.

The Web Dynpro component concept offers a number of advantages:
● Structuring of the programming
● Creation of easily manageable application blocks
● Reusability of whole components
● Decoupling of software projects in both time and space

The Web Dynpro component contains any number of windows  and views and their corresponding controllers . Additional Web Dynpro components can also
be referenced.

The creation of a Web Dynpro component is always mandatory, since the existence of the
Web Dynpro window and the views and controllers that it contains is linked to the existence of
the component itself. Communication between the elements of two Web Dynpro components
and their call by a user is implemented using the component interfaces , so it does
not make sense to consider the individual parts of the component separately.

A Web Dynpro component can embed other Web Dynpro components, and correspondingly a
Web Dynpro component can be embedded in any other Web Dynpro components. This
communication also takes place over the component interfaces.


A view describes the layout and behavior of a rectangular area of a user interface.

Every Web Dynpro application has at least one view. The layout of a view is made up of
different user interface elements, which can be nested in each other. The positioning of
interface elements in one view is supported by the supplied layout variants.

In addition to the visible part, the layout, a view also contains a controller and a context. The
data to which the elements of the view can be bound are stored and managed in the view
context, enabling them to be represented or used on the screen. The view controller can
contain methods for data retrieval or for processing user input.

A view also has inbound and outbound plugs  so that views can connected with
each other, or so that a view can be linked with an interface view. These plugs can be linked
with each other using navigation links.

Empty View
The empty view is a special type of view. It is always generated automatically in a window or
a view set area, provided that no view has been embedded manually. It may also be
preferable to embed an empty view in a non-empty window as well. Just like a normal view,
the empty view occupies a certain area of a window at runtime and can be used to hide a
different view, for example, using specific controls.

When you create an empty view, an inbound plug with the default name ShowEmptyView is

Plugs and Navigation Links

Navigation between different views is enabled by plugs. These can be divided into inbound
and outbound plugs. While inbound plugs define the possible starting points of a view, the
outbound plugs of a view can be used to call a subsequent view. Plugs are part of the

controller of a view. They are always assigned to exactly one view.

• Several views are generally embedded in a Web Dynpro window. Therefore, it is
necessary to qualify one view as the view that is displayed first of all when a window is
called. This view is assigned the Default property. The subsequent navigation structure is
then created using this view.
• The entering of a view using an inbound plug always causes an event handler method
 to be called. This is why an event handler method (whose use is optional) is
automatically generated for every inbound plug. In this case, the inbound plug itself
represents the event to be handled.

To navigate from one view to another, each outbound plug from the first view must be linked
with an inbound plug of the second view with the help of a navigation link.

Exactly one navigation link can originate from one outbound plug, although this can lead
to a series of target views. The arrangement of these target views is not qualified, which
means that all target views are controlled at the same time.

Web Dynpro Window

A window is used to combine several Views  and View Sets  (the concept
of view sets is only offered in Web Dynpro for Java). A view can only be displayed by the
browser if it has been embedded in a window. A window always contains one or more views,
which are connected by navigation links . One of these views, or a view set, is

specified as the start view and is displayed the first time the window is called.

Plugs and Window Controller

Windows have inbound and outbound plugs. For more information, refer to Window Plugs.
A window controller is assigned to each Web Dynpro window. The window controller is a
global controller. It is visible by all other controllers within the component.

Interface View

Each window has a uniquely assigned interface view. This interface view represents the
outward view of the window. The interface view is linked with a Web Dynpro application so
that the window can be called using a URL.

Window Plugs

Inbound Plugs and Outbound Plugs
A window has one or several inbound or outbound plugs. Using these plugs, a window can be
included into a navigation chain. The concept of these plugs corresponds to the concept of
the plug for a view . Each plug of a window is visible within the entire window and
can be used for navigating within this window. In addition, one or several plugs can be made
accessible to the component interface so that they are visible even beyond the limits of the

component in question. They thus belong to the interface view of the relevant window.

The Plugs of the Interface View
If an existing plug of a window is added to the component interface, it is then part of the
interface view belonging to this window (see also Interface of a Component).
These interface plugs are required whenever
● A component window is embedded in a window of another component the display at
the screen is to navigate there.
● A Web Dynpro application is to be set so that it can be called.

● A Web Dynpro application is to be exited.

Outbound Plugs
Outbound plugs within a window lead from the window to the inbound plug of a view. Using
these outbound plugs, it is possible to start navigation within the window with different views instead of using a predefined start view. You set the control as to which outbound plug is
called using the event handler method  of the called interface inbound plug.

Inbound Plugs
Inbound plugs within a window lead from the outbound plug of a view to the embedding
window. Just like all other inbound plugs, they represent an event and thus call the event
handler assigned to them. In this way, it is possible to control – within the window controller –
which inner outbound plug is to be called next. In this way, you can dynamically define the
sequence of the views displayed in the window.


Controllers are the active parts of a Web Dynpro application. They define how the user can
interact with the Web Dynpro application. The data that a controller can access is defined in
the corresponding context . Different instances of controllers and contexts exist
within a Web Dynpro application. In addition to view controllers, which control the behavior of
an individual view, there are also global controllers that offer more general services for all the

views of a component

View Controller
Each view has exactly one view controller, which processes the actions performed by the user in the view.

A view also has exactly one view context, which contains the data required for the view.
A view controller and the corresponding context exist at least as long as the view is displayed
in the browser; if the view is replaced by a subsequent view, the local data is no longer
available. However, the lifetime can also be connected to the lifetime of the surrounding

Global Controllers
Each Web Dynpro component additionally contains at least one global controller that is visible
within the component for all other controllers. Once the data for this component controller
have been created the first time they are accessed, the lifetime extends to cover the whole
period during which the component is in use.
You can add additional global controllers in the form of custom controllers. These also last as
long as the component and the data they contain are available to all views of the component.
Every time there is a Web Dynpro window, a further global controller – the Window controller
– is added to the component.

Interface Controller
Each Web Dynpro component contains exactly one component controller. This controller is a
global controller that is visible also outside the component. It is thus part of the interface of a
Web Dynpro component.

Communication from one controller to the next is achieved by calling methods from a different
controller, or by triggering an event on which other controllers are already registered. You
define these controller uses when you create a controller.

Source Code
Each controller contains program areas in which you can insert your own source code.
Therefore, an Application Programming Interface (API) exists for the processing of context
nodes and their attributes and data. The necessary initialization of nodes can also
be executed using this API. There are further APIs available, for example, the server
abstraction layer for accessing the system environment, and the APIs for message handling
and dynamic programming.
Controllers can contain their own source code in the following areas:
● Event handlers  – these are executed when a view is initialized, ended, or
entered, when a user interface element of a view triggers an action, or when other
controllers trigger a registered event.
● Methods – these can be called by other controllers
● Supply functions – these are executed when necessary to initialize elements in the


The data used in the component or in the view are stored in the context. Read-write access to

this data is available using the controllers as a starting point.

The data from the contexts is managed in a hierarchical structure. Each context has a root
node, underneath which the individual data fields (attributes) are stored in a tree structure.
You create this tree structure according to the structure of your application.

Each node contains data fields that represent one of the following:
An individual instance of an object type
A table of instances.

Cardinality of a Context Node
When a node is created in the context of a Web Dynpro component, the cardinality of the
node is specified. The cardinality defines how often a node is to be instantiated at runtime –
that is, how many elements of this node are available at runtime.
● 1…1
Only one element is instantiated.
● 0…1
At runtime, no more than one element is instantiated, but it is also possible that no
element is instantiated.
● 1…n
n elements can be instantiated, but at least one element must be instantiated.
● 0…n
The number of instantiated elements of the context node can vary.

No comments:



All about contents or data or information taken from or other sap related web sites which are available on the Internet for this BLOG.
If you find any doubts or mistakes please refer the other SAP/ABAP related sites .