Welcome to SAP ABAP Interview Questions. SAP WebDynpro ABAP Architecture Entities, Concepts, Context Mapping, Data Binding and Navigation between Views for webdynpro interview preparation .
SAP ABAP Web Dynpro components allow structuring complex Web applications and developing reusable, interacting entities in SAP applications. These SAP ABAP Web Dynpro notes and tutorials will help you to face interviews on SAP ABAP Webdynpro.
SAP ABAP WebDynpro Architecture : Entities and Concepts
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 WebDynpro program.
SAP WebDynpro Component
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 are 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 Dynprocontrollers. 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
Context Mapping and Data Binding
The
variables defined in a WebDynpro Controller context can be referenced from
other Web Dynpro controllers. This is called context mapping. This
allows to sharing common attributes between different controllers, so copying
these attributes between the controller contexts is not necessary.
Context and Data Transport
The
values of UI elements, that allow a user input, have to be connected to context
attributes of the corresponding controller. This is called data binding.
Through data binding, an automatic data transport between the UI elements and
the context attributes is established. Combining these two concepts, the data
transport between UI elements located in different views can be defined in a
purely declarative way.
Context Mapping in SAP Webdynpro ABAP
Context mapping allows
a context node in one controller to be supplied automatically with data from a
corresponding context node in another controller. This is the primary mechanism
for sharing data between controllers. When two controllers within the same component
share data through a mapping relationship, it is known as internal mapping.
The
context node that acts as the data source is known as the mapping origin
node, and the context node that is mapped is known as the mapped node .
The
mapping between controller contexts located in different WebDynpro components
is known as external mapping.
For
a mapping relationship to be established, the following steps must first be performed:
•
A node must exist in the context of the controller acting as the mapping origin.
This node need not have any declared child nodes or attributes.
•
The mapping origin controller must not be a view controller.
•
The controller containing the mapped node must declare the use of the mapping
origin controller as a used controller.
Putting Data on the Screen: Data Binding in SAP Webdynpro
Data binding is
the means by which data is automatically transported from a view controller’s
context to a UI element in its layout, and vice versa You may not bind UI
elements to context nodes or attributes defined in some other controller. UI
elements are private to the view controller within which they are declared.
The
data binding process decouples the UI element object from the application code within
the view controller. Therefore, in order to manipulate UI element properties,
the application code in the view controller needs only to manipulate the values
of context nodes and attributes to which the UI elements are bound.
The
Web Dynpro framework then manages the following two tasks:
•
The transport of data from the context attribute to the UI element during the
screen rendering process.
•
Repopulating the context attribute from the UI element after data has been
entered by the user and the next server round trip is initiated. Hereby, the
values entered by the user are automatically converted and checked for type
conformity. If an error occurs, a message is displayed.
Databinding is powerful, since not only the value of a UI element can be bound to a
context attribute, but other UI properties like visibility can also be bound.
This way, UI element properties can be manipulated from the view controller by
acting on context attributes.
Navigation Between Views in SAP Webdynpro ABAP
Navigation
between views is triggered by firing outbound plugs . Firing an outbound
plug causes a navigation event to be raised. Navigation events are special
asynchronous events that are placed into a navigation queue. Multiple outbound
plugs can be fired from one view. This can be used to define the next UI,
consisting of multiple views.
Navigation Between Views
The
navigation queue is processed at a certain point of time in the WebDynproprocessing phase. Up to this point of time, the navigation stack can be
extended by firing additional outbound plugs, or the complete navigation stack
can be deleted. Outbound plugs should be named according to the action that
caused navigation away from the current view.
Inbound plugs are
special event handler methods that subscribe to navigation events raised when
outbound plugs are fired. Inbound plug methods are called only when the navigation
queue is processed. This will only take place once the views in the current view
assembly have fired their outbound plugs and no validation errors have occurred
that would cause navigation to be cancelled.
Inbound
plugs should be named according to the reason for which the view being
displayed. Outbound and inbound plugs are joined together using navigation
links.
Technically,
linking an inbound plug to an outbound plug means registering the inbound plug
event handler method to the navigation event, called by firing an outbound
plug. Outbound plugs and event handler methods related to the inbound plug can
have parameters, allowing you to pass data between the views.
