Webdynpro ABAP

Unit 1 :
Introduction to Webdynpro ABAP
 1.1 Introduction to webdynpro ABAP -1-
Webdynpro ABAP is SAP Standard UI technology for
developing web applications in ABAP Environment.
Advantages:
1. Reduces implementation effort.
2. Separation of layout and business data.
3. Reusability of components.
4. Automatic data transfer using context binding.
5. Support Stateful applications. i.e. Even when the pages
change the data in the previous page still remains.
Webdynpro Architecture:
It is based on MVC Architecture and supports:
1. Clear separation of business and display logic.
2. Meta-model Concept.
3. Execution on number of client platforms.
4. Extensive Platform Independence of interfaces.
 1.1 Introduction to webdynpro ABAP -2-
MVC Architecture : The Model View Controller (MVC) design pattern
contains a clear distinction between processing control, data model and
displaying the data in the interface.
Model : The model is used as an application object of the application data
administration. It responds to information requests about its status, which
usually come from the view, as well as to statements for status changes,
which are usually sent by the controller. In this way, only the model is used
to process data internally, without making reference to the application and
its user interface. There can be different views for a model, which can be
implemented using different view pages.
View : The view handles the graphical and textual output at the interface
and therefore represents the input and output data in each interface
element, such as pushbuttons, menus, dialog boxes and so on. The view
takes of visualization. To visualize the status, the view queries the model, or
the model informs the view about possible status changes.
Controller : The controller interprets and monitors the data that is input
by the user using the mouse and the keyboard, causing the model or the
view later to change if necessary. Input data is forwarded and changes to
the model data are initiated. The controller uses the model methods to
change the internal status and then informs the view about this. This is how
the controller determines reactions to the user input and controls
processing.
1.1 Introduction to webdynpro ABAP -3-
 1.2 Different types of controller in
Webdynpro ABAP
The different types of controllers in webdynpro abap are:
1. Component controller
2. Custom controller
3. Interface controller
4. View Controller
5. Window Controller
Before learning about the Controllers let us know something about different types
of interfaces that are created at the time of creation of the component. These
interfaces are as below.
1. IF_<ControllerName>
2. IG_<ControllerName>
3. IWCI_<ComponentName>
The interface begin with the prefix IF is local and can be used for coding only within
that controller.
The interface begin with the prefix IG is used for cross controller
communication.(E.g View controller to component controller)
The interface begin with the prefix IWCI is used for cross component
communication. (E.g. ComponentA to ComponentB)
 1.2.1 Component Controller -1-
There is only one component controller per
webdynpro component and it is global. i.e Component
controller consist of data and processing logic that is
available to all the views in the component.
This controller does not have any visual interface.
The life time of the component controller is the life
time of the component.
Components of Component:
 1.2.1 Component Controller -2-
Properties:
In the properties tab of the component controller we
can declare the component usage of the other
component so that the interface methods of that
component can be accessed by the methods of the
component controller.
 1.2.1 Component Controller -3-
Context:
Context is a hierarchial form of storage of data which we will
breifly study about it in the upcoming posts. And for now
context is a place where you declare the data.
The Nodes declared here can be mapped to any number of
views and can be accessed from there hence making the data
of the component controller global.
 1.2.1 Component Controller -4-
Attributes:
The attributes required by the Component controller are declared
in the attributes and are accessible to the methods of the
component controller using the handle provided for the
component controller(WD_THIS). These attributes can also
be accessed from different controllers using the handle provided
for the component controller(WD_COMP_CONTROLLER)
in the respective controller.
The attribute WD_THIS declared in any controller refers to the
interface of the current controller and the attribute WD_CONTEXT
declared referes to the corresponding context of the controller.
 1.2.1 Component Controller -5-
Events:
Events can be created in component and custom controller.
Events created in the component controller are visible only within the component
which means it can only be triggered by the methods of the component
controller. But it can be handled in different contollers.
Thus Events are used to communicate between the controllers and enable one
controller to trigger the event and handler the event in different controller.
Events can also implement cross component communication provided that the
interface check box is checked.
 1.2.1 Component Controller -6-
Methods:
Component controller consist of number of predefined methods called
hook up methods which are executed in a pre-defined manner. We will
study about these hook up methods in the later posts.
We can also created the methods on our own and the methods which we
created can be called from any controller using the handle for the
component controller(WD_COMP_CONTROLLER).
 1.2.2 Custom Controller -1-
Custom controllers can be additionally created in the component and they
are exactly similar to the component controller in terms of functionality.
This means it is visible to all the elements in the component and life time of
the controller is the lifetime of the component. Any number of custom
controller can be created in the component and it provides the option of
structuring the data and functions. It only make sense to create a custom
controller if certain function and data are to be associated with the specific
set of views.

The first three components Properties, Context and Attributes are similary
to that of component controller and the only differ in the events and
method properties
 1.2.2 Custom Controller -2-
Events:
Events are created and implement in a similar way to
the component controller except that they cannot
implement cross component communication. It can be
handled only within the component.
 1.2.2 Custom Controller -3-
Methods:
Unlike component controller the custom controller does not
contain a number of hook up methods. We can create own
methods in the custom controller and these methods can be
used by any views provided that the custom controller is
added to the used controller in the properties tab of the view.
 1.2.3 Interface Controller -1-
Interface controller is used for cross component
communication.
Interface controller does not contain any implementation.
Interface controller is the point of contact of communication
for other component to use this component. Only nodes,
methods and events marked as interfaces can be used by
other components.
Components of interface:
 1.2.3 Interface Controller -2-
Properties:
In the Properties tab you will be able to see the
administration data and Interface that was created
for the external communication(IWCI).
 1.2.3 Interface Controller -3-
Context:
In the context tab you will be able to see the
context nodes of the component controller which
is marked as interface node in the node properties
of the component controller.
 1.2.3 Interface Controller -4-
Events:
In the events tab you will be able to see the events
which are marked as interface events for cross
component implementation.
 1.2.3 Interface Controller -5-
Methods:
In the methods tab, you will be able to see the
interface methods that can be accessed by the
other components.
 1.2.4 View Controller -1-
Each view exactly consist of one view controller.
Number of view controllers in a component depends upon the
number of views.
The view controller cares about the view specific flow logic like
checking user input, handling user actions etc. The lifetime of the
view controller is restricted to the life time of the view.
Components of view:
 1.2.4 View Controller -2-
Properties:
The properties tab of the view controller consist of the admin data as well
as the option to add the used controllers for the view.

In this example I have added the custom controller of the same component
as the used component so that the methods of the custom controllers can
be accessed in this view.
 1.2.4 View Controller -3-
Layout:
Layout tab of the view controller provides the
option for placing the UI element. It is WYSIWYG
type of editor. (What You See Is What You Get).
 1.2.4 View Controller -4-
Inbound Plugs:
Plugs are required for the navigation between the views.
Inbound plugs consist plugs which is pointing into the view.
Unlike outbound plug the inbound plug consist of event
handler method which will be executed before displaying
the view.
 1.2.4 View Controller -5-
Outbound Plug:
Outbound plugs consist plugs which is pointing away
from the view. This does not contain any event handler
method and the outbound plug can be fired using
following syntax.
WD_THIS->FIRE_<Plugname>_PLG.
 1.2.4 View Controller -6-
Context:
Context as mention earlier is a hierarchical form of data
storage and the context node declared in the view can be
used only in that corresponding view and it cannot be
accessed in any other views. The node created in the view
context does not provide the option for interface node.
 1.2.4 View Controller -7-
Attributes:
Attributes are similar to the attribute tab discussed in the component controller.
Here in the view controller you will be able to see the handler to the component
controller with reference to the interface of the type :
IG_(Cross controller).
Using this handler the attributes and methods of the component controller can be
accessed.
 1.2.4 View Controller -8-
Actions:
Actions tab consist of the onaction events created
for the UI elements.
 1.2.4 View Controller -9-
Methods:
In the methods tab you will be able to see the set of
hook methods specific to the view controller and
event handler methods created for the UI element
actions and own defined methods.
 1.2.5 Window Controller -1-
Each window in a webdynpro component consist of
a window controller.
It is visible throughout the component and behaves
like component or custom controller.
Components of window controller:
 1.2.5 Window Controller -2-
Properties:
Properties tab of the window controller is similar to
that of the view controller.
 1.2.5 Window Controller -3-
Window:
In the window tab we will be able to see the views that are
embedded in the window, inbound and outbound plug of
each view and the view that is marked as default.
Here we can also specify the navigation link between the
views using the view plugs.
 1.2.5 Window Controller -4-
Inbound Plug:
The properties of a windows inbound plug differ from a views inbound plugs by
the characteristics Interface and Startup or Resume that can be maintained:
Interface:
The interface check box determines whether the inbound plug is used only for
navigation within the component or cross component navigation.
Startup:
If the plug type is selected as start up then webdynpro application can be started
using this plug. When creating an webdynpro application only the interface view
inbound plug can be used. All other type of plugs can only be used for navigation in
an already running application. Window inbound plug also has the event handler
method. The Plug type suspend and resume are used for portal navigation and will
be discussed in later posts.
 1.2.5 Window Controller -5-
Outbound plug:
Outbound plugs consist of interfaces, Exit and Suspend
characteristics.

Context attributes and methods tab are simliar to that of the

view controller except that the method of the window
controller has different set of Hook methods.
Note : At run time all the controller instances are singleton.
 1.2.6 Context in Webdynpro ABAP -1-
Context is a method of
storing a data in a
hierarchical manner.
The data used by the
component or a view
are stored in the form
of context.
We can read or write
data in the context
using the controller as
a starting point.
Structure of a Context
node:
 1.2.6 Context in Webdynpro ABAP -2-
If you look at the context tab of any controller you will
be able to see a thing called context. It is actually a
singleton root node under which we will be declaring
our nodes and attributes.

Each context has a node and a number of attributes

underneath a node. The attributes declared directly
will be coming under the root context node
CONTEXT.
 1.2.6 Context in Webdynpro ABAP -3-

Each node consists of data can be one of the two ways:

1. A individual instance
2. Table of Instance
We will discuss it when we come to the topic cardinality
of the context node.
 1.2.6 Context in Webdynpro ABAP -4-
Recursion Node:
Dynamic nesting of node is also
possible within the context
called recursion node.
1. The node which is used for
recursion should always be a
predecessor of new node. Here
in the above given example the
node2 is the recursion node and
the node1 is the predecessor
node.
2. The recursion node cannot be
processed separately.
3. You cannot use the root node
CONTEXT as a predecessor
node.
 1.2.6 Context in Webdynpro ABAP -5-
How to access the data in the context?
By default all the nodes which we are declaring will be
the child node of the root node CONTEXT.
The reference to this root context is available in the
Attributes tab of the Controller.

The interface consist of number of methods that will

help us play with the context.
 1.2.7 Properties of Context Node -1-
The properties of the context node are as below:
 1.2.7 Properties of Context Node -2-
Node Name: The node name specifies the Name of the context
node.
Interface Node: Interface node property of the context node
determines whether the node can be used for cross component
communication (One component to another Component) or not.
Say for example we have two components Component A and
Component B. When the component A to which contains a
context node STATUS is used in another component B then the
component B can access the node STATUS if it is interface node.
Interface nodes are mainly used for the purpose of transferring
data from one component to another component.
The context node in a component that is created in the view level
does not provide interface option and cannot be accessed in other
components.
Input Element (Ext.): Usually when we want a context node to be
used in the number of views we define it in the component
controller context and map it to the view required by dragging and
dropping the context node in the different view. We call it data
mapping ref to document data mapping.
 1.2.7 Properties of Context Node -3-
Dictionary Structure: Here we specify a dictionary object reference
as a structure to the context node. It can be either table or structure.
When the dictionary structure is referenced to the context node then
the attribute of the context node can only bear attributes belonging
to the structure or table specified. Also it is not necessary that all the
fields of the dictionary structure is to be used as the structure of the
context node, we can choose only the required fields from the
structure. Apart from the fields in the dictionary structure any
attribute other then the fields in the dictionary structure specified
cannot be added unless and until the dictionary structure reference is
removed.
Cardinality: Here we specify the cardinality of the context node. i.e.
the number of the records that the context node is subjected to have
at run time.
0..1 It can contain up to one record or nothing.
1..1 It can contain only one record. A record by default is
instantiated.
0..n It can Contain N no of records or nothing.
1..n It Contains one record instantiated by default or any No of
records.
 1.2.7 Properties of Context Node -4-
Selection: This selection specifies number of (Elements
or rows or leads) can selected by the user for
processing. The input is similar to that of the
cardinality.
Initialize lead selection: If the initial lead selection is
checked then one (Element or row or lead) will be
selected by default. It will be the first element of the
context node. For example when you display the data
in the context node using table UI element one row of
the table will be selected by default.
Supply Function: Supply function is a method assigned
to the context node which is being executed every time
the context node is being accessed. It is used for
initializing or invalidating the context node.
 1.2.7 Properties of Context Node -5-
Singleton: Singleton property is set to reduce the load of the context node.
Say for example when we have a parent child relationship between two
nodes, Node A (5 Elements) and Node B (10 elements). When the Node A is
accessed it loaded with all the elements of the Node A as well as all the
elements of the Node B when the singleton property is not set for node A.
The same when the singleton property is set for the Node A, then only the 5
elements of the Node A along with the records corresponding record of
1st record in the node A with Node B will be loaded.
To be precise, Assume that Parent node has 5 Sales order (1,2,3,4,5). When
a Sales order 1 is accessed the supply function method is triggered and
corresponding details of sales order 1 is stored in child node. When sales
order 2 is triggered supply function method is triggered and the details of
sales order 2 is stored in child node. Now if we dont have singleton option
in the node and if select the lead for sales order 1, this time the supply
function method will not be triggered as the element is already available in
the memory. The same if I have had the singled property selected, then
when I accessed the 2nd sales order the memory allocated for the first sales
order will be destroyed. Now if I choose the first sales order then once
again supply function method gets triggered and loads the data, this time it
clears the second element which is already available in the child node. This
way it ensures that only one element available in the child node.