You are on page 1of 66

Web Dynpro for ABAP Web Dynpro for ABAP

ABAP Web Dynpro Course Contents - 1
Description : Ìn this course you will explore the various concepts and practical
examples related to ABAP Web Dynpro
Course Contents :
ModuIe 1 - Theory
ABAP Web Dynpro Architecture
Technical Features
Main Benefits
ModuIe 2 - Introduction
Web Dynpro Development
Web Dynpro Component Architecture
Web Dynpro Components
Views Windows and UÌ Elements
Defining View Layout
Layout Types
UÌ Element Categories
ModuIe 2a - Exercise
Ìntroductory example
ModuIe 3
Controller and Context
Controller Types
Controller Entities
ModuIe 4
View Controller and View Context
Context Node Elements
Component Controller
ModuIe 4a - Exercise
Populating "Table¨ control
ModuIe 5
Node Cardinality
ModuIe 5a - Exercise
Node Cardinality
ModuIe 6
Context mapping between views
Navigation
Context Node at Design Time
ModuIe 6a - Exercise
Navigation
ABAP Web Dynpro Course Contents - 2
ModuIe 7
$upply Function of a Context Node
ModuIe 7a - Exercise
$upply Function
ModuIe 8 - Exercise
Messages and Error Handling
ModuIe 9
Dynamic Programming
ModuIe 9a - Exercise
Dynamic Programming
Adding UÌ elements
Changing properties of UÌ elements
ModuIe 10
Web Dynpro Component Ìnterface
ModuIe 10a - Exercise
Creating a Web Dynpro Component
Ìnterface Definition
ModuIe 11
Adaptation of Web Dynpro Applications
ModuIe 11a - Exercise
Adaptation of Web Dynpro Applications - Configuration Controllers
ModuIe 12 - Exercise
Window Controllers
ModuIe 13 - Exercise
Ìntegrating a PDF Form in a Web Dynpro Component
ModuIe 14 ModuIe 14 ModuIe 14 - - - Exercise Exercise Exercise
Working with Dialog Boxes Working with Dialog Boxes Working with Dialog Boxes
ModuIe 15 ModuIe 15 ModuIe 15 - - - Exercise Exercise Exercise
Ìnput Help Ìnput Help Ìnput Help
ModuIe 16 ModuIe 16 ModuIe 16 - - - Exercise Exercise Exercise
Portal Ìntegration Portal Ìntegration Portal Ìntegration
ModuIe 17 ModuIe 17 ModuIe 17 - - - Exercise Exercise Exercise
Business Graphs Business Graphs Business Graphs
ABAP Web Dynpro Web Dynpro Architecture
Definition
Web Dynpro is the $AP NetWeaver programming model for user interfaces (UÌs).
The Web Dynpro model is based on the ModeI View ControIIer 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's main goal is to enable application developers to create powerful web
applications with minimum effort using descriptive tools in a structured design
process.
Web Dynpro uses a declarative, language-neutral meta model for defining a user
interface.
ABAP Web Dynpro TechnicaI Features
Web Dynpro provides technical features for
·Ìnternationalization
·Flicker-free interaction
·Clean separation of business logic and the UÌ. This is achieved through a modified
implementation of the Model View Controller (MVC) design paradigm.
ABAP Web Dynpro Main Benefits - 1
ABAP Web Dynpro Main Benefits - 2
ABAP Web Dynpro Web Dynpro DeveIopment
ABAP Web Dynpro Web Dynpro Component Architecture
ABAP Web Dynpro Web Dynpro Components
ABAP Web Dynpro Views Windows and UI EIements
ABAP Web Dynpro Defining View Layout
ABAP Web Dynpro Layout Types
Flow Layout Left to right, across the screen
Grid Layout Arranged by number of columns (e.g.
colCount = 4)
Matrix Layout Number of columns not fixed. Each
element can be specified for which row
and which column.
Need to specify new row items.
(MatrixHeadData)
Row Layout Row by row.
Need to specify new row items.
(RowHeadData)
ABAP Web Dynpro UI EIement Categories
ABAP Web Dynpro Exercise
Introductory ExampIe
Learn to create views, and familiarize yourself with various UÌ elements
ABAP Web Dynpro ControIIer and Context
ABAP Web Dynpro ControIIer Types
Component ControIIer
·There is only 1 component controller per Web Dynpro component.
·The component controller drives the functionality of the entire component.
·This controller has no visual interface.
Custom ControIIers
·These are optional.
·They have to be defined at design time.
·Multiple custom controllers can be defined in a component
Configuration ControIIer
·This is a special custom controller, used for configuration and personalization functionality.
View ControIIers
·Each view consists of the layout part and exactly 1 view controller.
·This controller cares for view-specific logic, like checking user input and handling user actions
Window ControIIers
·Each window has exactly 1 window controller
·This controller can be used to care for the data passed via the inbound plugs
·Methods of this controller can be called from the inbound plug methods of the window.
ABAP Web Dynpro ControIIer Entities - 1
Common ControIIer Entities
1. Methods
1. Standard Hook methods - For all controllers, there exist methods that are
called in a predefined order by the Web Dynpro framework.
2. Instance methods - Can be defined using the Methods tab
2. Attributes not related to the value or property of UÌ elements can be declared
using the Attributes tab. These attributes are then visible in all methods of this
controller.
There are 2 predefined attributes:
WD_THÌ$ ÷ Used to access functionality of the controller
WD_CONTEXT - Used to access functionality of the context
3. Properties For information to be shared between different controllers, one
controller must declare the use of another controller.
ABAP Web Dynpro ControIIer Entities - 2
SpeciaI Entities of Component/Custom ControIIers
· Events can be defined with arbitrary parameters. Any method of any
controller can register to these events if this method is defined as an event
handler method.
SpeciaI Entities of View ControIIers
· Navigation PIugs - For navigation to take place between different Web
Dynpro view controllers, special navigation events and navigation event
handlers have been created. These are called Navigation Plugs.
A navigation event is raised when an outbound plug is fired.
An inbound plug is the navigation event handler that can be registered to a
navigation request.
SpeciaI Entities of Window ControIIers
· Navigation PIugs
ABAP Web Dynpro Hook Methods
Method Name AppIicabIe To Function
WDDOÌNÌT Component
Controller and View
Controller
Ìnitialization Method of Controller
WDDOPO$TPROCE$$ÌN
G
Component
Controller
Prepare Output
WDDOBEFORENAVÌGATÌ
ON
Component
Controller
Error Handling Before Navigation
Through Application
WDDOAPPLÌCATÌON$TA
TECHANGE
Component
Controller
Handling for $uspending and
Resuming an Application
WDDOBEFOREACTÌON View Controller Method for Validation of User
Ìnput
WDDOMODÌFYVÌEW View Controller Method for Modifying the View
Before Rendering (Refresh)
WDDOEXÌT Component
Controller and View
Controller
Cleanup Method of Controller
ABAP Web Dynpro Process FIow during data transfer
ABAP Web Dynpro Process FIow of event handIing
ABAP Web Dynpro Component ControIIer-1
ABAP Web Dynpro Component ControIIer-2
·Each component has its own Component Controller
·The Component Controller has its own context
·Context nodes of the component controller can be mapped to nodes with similar
structure of other controller contexts e.g. view controllers
·This allows the distribution of data between different views and controllers
·Mapped nodes automatically contain the same data without copying because they
hold references to one source
·The Component Controller also contains methods for central tasks of the
component, for example methods which encapsulate all interaction to the underlying
business logic
·The model which represents the business logic can be a APÌ based on ABAP
Objects, BAPÌs, RF$ or function modules
·Ìf an application consists of several WD components the interaction of one WD
component to a used sub component is also done via the Component Controller
ABAP Web Dynpro Component ControIIer-3
·Ìn a typical example the Component Controller contains a method to retrieve data
from the model and context nodes which are filled by these methods
·The context nodes of the Component Controller are mapped to the context nodes
of the view controller which are bound to visible UÌ elements
ABAP Web Dynpro Component ControIIer-4
The component controller provides data and processing logic that it should be
possible to display or change for all views of a component.
Ìt has three interfaces:
· Interface IF_<controIIer_name> for coding within the controller
· Interface IG_<controIIer_name> for cross-controller coding within the current
component.
· Interface IWCI_<component_name> for cross-component coding. On the ABAP
language level it represents the interface controller
ABAP Web Dynpro View ControIIer and View Context
·The view controller contains the event handlers which steer the behavior of the
view, for example:
·Ìnitialization events which are called when a view is displayed for the first time
·Action handlers which are triggered by UÌ elements like a button click or drop
down list box selection
·Ìn general the coding of the controller methods access the context data and not the
UÌ elements directly.
·Each view has its own view controller
·The view controller has its context for
the data which is used by the view
·Context nodes and attributes can be
bound to UÌ elements
ABAP Web Dynpro Context Node EIements
ABAP Web Dynpro Exercise
PopuIate "TabIe" ControI
Problem: Create a table control and populate it with data for the carrier specified in the input
field.
ABAP Web Dynpro Node CardinaIity
The number of elements in a node collection can be controlled using the property known
as cardinality.
This property is actually the combination of two values that, taken together, define the
maximum and minimum number of elements the node collection may contain at runtime.
The two values are the:
· Cardinality Minimum: 0 or 1
· Cardinality Maximum: 1 or n
There are four permutations for these values (specified as <min>..<max>):
For those nodes that have their cardinality minimum set to 1, then the node collection will
be instantiated such that it already contains a single, empty element. This element is
known as the default element.
For those nodes however, that have their cardinality minimum set to 0, the node will be
instantiated with an empty collection. The Web Dynpro developer must write the code to
first create and then insert the first element into the collection.
0..1 ero or one elements permitted
0..n ero or more elements permitted
1..1 One and only one element permitted
1..n One or more elements permitted
ABAP Web Dynpro Exercise
Node CardinaIity
Ìn the example above, for the node
1. Change the cardinality to 0..n and do not write any code to fill the table
2. Change the cardinality to 1..n and do not write any code to fill the table
3. Change the cardinality to 0..1 and do not write any code to fill the table
4. Change the cardinality to 1..1 and do not write any code to fill the table
5. Change the cardinality to 0..n and write code to fill the table
6. Change the cardinality to 0..1 and write code to fill the table
ABAP Web Dynpro Attributes
Attribute Reference to Reference VariabIe of type
WD_CONTEXT controller context ÌF_WD_CONTEXT_NODE
WD_THÌ$ local interface · ÌF_COMPONENTCONTROLLER
· ÌF_<MY_CU$TOM_CONTROLLER>
· ÌF_<MY_VÌEW>
· ÌF_<MY_WÌNDOW>
WD_COMP_CONTROLLER View Controller ÌG_COMPONENTCONTROLLER
ABAP Web Dynpro Context mapping between views
·The mapping of context nodes can also be used to transport data from one view
controller to another view controller.
·Ìn this case the context nodes of both view controllers are mapped to the same
context node of the component controller.
ABAP Web Dynpro Navigation between views-1
ABAP Web Dynpro Navigation between views-2
Outbound PIugs
·Calling an outbound plug method causes a navigation event to be raised.
·Navigation events are special, asynchronous events that are placed into a
navigation queue.
Only when all the outbound plugs have been called by all the views in the current view
assembly, will the Web Dynpro Framework enter its navigation processing phase.
·Outbound plugs should be named according to the action that caused navigation away
from the current view.
Inbound PIugs
·Ìnbound plugs are special event handler methods that subscribe to navigation events
raised when outbound plugs are fired.
·Ìnbound plug methods are called only when the navigation queue is processed.
·This will only take place once all 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.
·Ìnbound plugs should be named according to the reason for which the view being
displayed.
Links
Outbound and inbound plugs are joined together using navigation links.
ABAP Web Dynpro PIugs and Navigation
ABAP Web Dynpro Exercise
Navigation
Navigate back and forth between 2 views. Also, pass values between the 2 views.
ABAP Web Dynpro SuppIy Function of a Context Node
ABAP Web Dynpro SuppIy Function of a Context Node
SuppIy Function
Ìf the lead selection of a parent node changes, the content of sub nodes has to be
changed or filled dependent of the new content of the lead selection.
This can be done with the $upply Function which is called automatically by the
framework.
Each context node of a controller can be assigned a supply function.
This supply function is called by the runtime when the data of the context node is
used.
This is the case when a UÌ element is to be displayed for the first time with the data of
the corresponding context, for example.
Ìn general, the supply function is called when one or more elements of a context node
are accessed and when
· the context node is not filled yet or is initial, or
· the context node has been invalidated in a previous step.
ABAP Web Dynpro SingIeton
Unlike the cardinality of a node, which describes the number of possible elements
within the node, the "singleton¨ property determines whether or not these elements
are set for all elements of the parent node (non-singleton) or for exactly one
element of the parent node (singleton).
The singleton property of a context node describes the relationship between a child
node and its immediate parent.
The current contents of a sub node can be kept or deleted if the lead selection of
the parent node changes. This is steered by the $ingleton property of the sub node.
Ìf the sub node is declared as $ingleton the old node content is deleted and the sub
node is filled freshly via the supply function every time the lead selection of the
parent node changes, even if it changes to an element which has had the lead
selection a few clicks before.
Ìf the sub node is declared as non-$ingleton the old sub node data is kept and
reused if the lead selection switches to the same element again without calling the
supply function again.
ABAP Web Dynpro Lead SeIection
At runtime, every child node set as a singleton contains the elements for exactly
one element of the parent node. For this purpose, one element from the set of
possible elements of the parent node must be highlighted. This is achieved by
initializing lead selection.
For each newly created context node, lead selection is initialized automatically, but
this setting can also be deactivated. However, lead selection must generally be
initialized for every context node.
» Using the preset automatic initialization of lead selection:
Ìn this case, the first eIement of a node is always assigned the lead selection
property.
» Manual initialization of lead selection:
Ìf the automatic initialization was deactivated, the lead selection must be
programmed manually. Ìn this case it is possible to assign this property to an
element other than the first element of a node.
ABAP Web Dynpro Exercise
$upply Function
Use supply function to refresh the contents of a table depending upon the input from another
table.
ABAP Web Dynpro Exercise
Messages and Error Handling
Display a suitable message if the user enters invalid data
ABAP Web Dynpro Exercise
Custom Controllers
1. ALV
Display data in an ALV
2. Custom Controllers
ABAP Web Dynpro Dynamic Programming - 1
· Dynamic programming mostly accesses objects of a component at runtime.
· You can change the layout of a view within method wdDoModifyView, since the view is the
owner of the layout of a certain screen area.
· For this purpose, the interface of method wdDoModifyView provides a parameter called
VÌEW, which is a reference to an object of type ÌF_WD_VÌEW representing the instance of
a view at runtime
The following interfaces are public and can be used to modify objects:
ÌF_WD_APPLÌCATÌON
ÌF_WD_ACTÌON
ÌF_WD_COMPONENT
ÌF_WD_COMPONENT_U$AGE
ÌF_WD_COMPONENT_U$AGE_GROUP
ÌF_WD_CONTEXT
ÌF_WD_CONTROLLER
ÌF_WD_EVENT
ÌF_WD_ME$$AGE_MANAGER
ÌF_WD_OV$
ÌF_WD_PORTAL_ÌNTEGRATÌON
ÌF_WD_VÌEW
ÌF_WD_VÌEW_CONTROLLER
ÌF_WD_WÌNDOW
ÌF_WD_WÌNDOW_MANAGER
ABAP Web Dynpro Dynamic Programming - 2
Ìn addition to the all those different interfaces, you can also call static methods on certain public
classes:
CL_WD_UTÌLÌTY
CL_WD_DYNAMÌC_TOOL
CL_WD_RUNTÌME_$ERVÌCE$
ABAP Web Dynpro Dynamic Programming - 3
The names of the classes that represent the above mentioned ViewElements are as follows:
ViewElement -> CL_WDR_VÌEW_ELEMENT
UÌElement -> CL_WD_UÌ_ELEMENT
UÌElementContainer -> CL_WD_UÌ_ELEMENT_CONTAÌNER
Layout -> CL_WD_LAYOUT
LayoutData -> CL_WD_LAYOUT_DATA
The above classes are abstract.
$ince everything that can be placed on screen, is derived from one of those five classes, it also
offers you the opportunity to work with generic typed pointers.
Ìf you are uncertain about the type of an UÌ element, use the least generic typed pointer.
e.g.Ìf you want to use a button, the class in question will be CL_WD_BUTTON
ABAP Web Dynpro Dynamic Programming - 4
Accessing an Existing ViewElement
Ìn order to change an existing ViewElement, a pointer can be obtained by calling the method
GET_ELEMENT of interface ÌF_WD_VÌEW.
$uch a typed pointer is available within method wdDoModifyView (available within any
ViewController), as a parameter called VÌEW.
The following source code shows how one can obtain a pointer to the
RootUÌElementContainer.
data: lr_container type ref to cl_wd_transparent_container.
lr_container ?= view->get_element( `ROOTUÌELEMENTCONTAÌNER` ).
ABAP Web Dynpro Dynamic Programming - 5
Creating a ViewElement
· Every ViewElement contains a method, which starts with NEW_ followed by the name of
the class without the CL_WD_.
· $o for a button, the name of this method would be NEW_BUTTON.
· Calling this method creates a new instance of this ViewElement.
· Depending on if the current ViewElement is a Layout, LayoutData or other ViewElement,
this method has a slightly different signature.
For every Layout the interface of this method always contains at least the following parameters:
importing
id type string optional "id of the Layout
container type ref to cl_wd_uielement_container "UÌElementContainer to which the Layout
should be assigned
returning
control type ref to cl_wd_<name of the Layout> "the newly created Layout
ABAP Web Dynpro Dynamic Programming - 6
For every LayoutData the interface of this method always contains at least the following
parameters:
importing
id type string optional "id of the Layout
data element type ref to cl_wd_uielement "UÌElement to which the LayoutData
should be assigned
returning
control type ref to cl_wd_<name of the LayoutData> "the newly created LayoutData
For all other ViewElements the interface of this method always contains at least the following
parameters:
importing
id type string optional "id of the ViewElement
view type ref to if_wd_view optional "pointer to the view
returning
control type ref to cl_wd_<name of the ViewElement> "the newly created ViewElement
ABAP Web Dynpro Dynamic Programming - 7
All other parameters are optional and allow you to specify the following aspects of a
ViewElement upon its creation:
The values of all attributes that are not bound. For each attribute, there is a parameter that has
the same name. Ìf an attribute is not specified, its default value will be applied.
The binding paths of all bindable attributes. They have the prefix BÌND_ in front of the name of
the attribute. Only meta paths are supported, which means you can not use any form of
index to node elements within such a path.
The action to which an event of this ViewElement is bound. All events have the prefix ON_.
ABAP Web Dynpro Exercise
Dynamic Programming
Adding UÌ elements
Add "n¨ buttons to a view dynamically.
Changing Attributes Dynamically
Toggle the visibility of the table control.
ABAP Web Dynpro Web Dynpro Component Interface
·Component interface definitions allow you to generically define a uniform
interface structure and later use it in a variety of application components.
·The advantage of this procedure lies in the fact that in a distributed development
the interfaces of all components that use the interface definition reliably contain a
particular set of controller elements (methods, context elements, etc.) and
interface views, which can be addressed by the developers of using
components.
·The developer of a using component does not need to know which actual
implementation of the interface is used ÷ this can be determined dynamically at
runtime.
·You use the Object Navigator to create and edit component interface definitions
analogous to components.
ABAP Web Dynpro Web Dynpro Component Interface
Ìnterface Controller of a Component
Interface Definition
Ìnterface Controller of a Component
The controller can be edited The controller can be displayed but not
edited.
Methods can be defined in the editor, but
they cannot be programmed there.
The methods are programmed only after
the impIementation of the component
interface definition in a Web Dynpro
component.
The methods can be created in the
editor of the related component
controller (see above) and then be
programmed in the ABAP editor.
The interface controller of a component interface definition and the interface
controller of a component differ in two items:
Ìn addition to the mandatory interface controller you can add any number of
interface views to a component interface definition.
ABAP Web Dynpro Web Dynpro Component Interface
ImpIementing Component
Interface Definitions
These separately defined
component interfaces can now
be added to the implemented
interface of a component. With
the implementation of a
component interface definition in
a component, the elements of
the separately defined interface
controller are added to the
component controller of the
implemented component.
Within this implemented component, the
methods of the interface controller that have
only been defined so far can be programmed
component-specifically.
For large programming projects, this results
in a higher reusability of the interface
structures.
ABAP Web Dynpro Web Dynpro Component Interface
Besides the interface controller a
component interface definition can
contain interface views.
When implementing a
component interface
definition, these interface
views are added to the
existing views in the interface
folder of the implemented
component. The related
windows are generated and
stored in the respective folder
of the object list. They are
empty and can now be laid
out especially for the
embedding component.
ABAP Web Dynpro Web Dynpro Component Interface
The faceIess Component
Ìt is possible to create a Web Dynpro component that has no visual interface. i.e. a
component with zero views and zero windows.
$uch a component is known as a "faceless¨ component and is useful when a
complex unit of functionality requiring no direct user interface needs to be
encapsulated.
A good example of a faceless component is the creation of something called a
model component. This is not actually a specific Web Dynpro component type;
rather it is a standard Web Dynpro component that has been written specifically for
the task of interacting with a model object.
Very often, though not exclusively, a model component will have no visual interface,
thus also making it a faceless component.
Often, a model object could have large or complex interface. $ince model objects
are completely reusable, it does not make sense to have to re-implement the
functionality required to interact with the model object every time it is reused.
Therefore, $AP recommends that when a model object's interface requires any type
of additional processing or simplification, that the model object be encapsulated
within a component in order to be able to reuse the associated interface coding.
ABAP Web Dynpro Web Dynpro Component Ìnterface
Create a Web Dynpro Component Ìnterface Definition
Ìmplement the above created Ìnterface in a Web Dynpro Component
ABAP Web Dynpro Adaptation of Web Dynpro AppIications
The UÌ of applications defined with ABAP Web Dynpro can be adapted in different ways and by
different user groups
There are 2 categories of application adaptation:
Configuration and Personalization
ABAP Web Dynpro Configuration
Configuration is a process by which the deveIoper can create configuration data sets
containing values for UÌ element properties. This allows the developer to overwrite many of
the statically defined UÌ element properties, resulting in a different look and feel of the
application.
e.g.
· UÌ elements may be set to invisible
· Tables may have an alternating row color
Component configuration allows you to change properties of UÌ elements defined in any view
of a single component.
AppIication configurations are bound to Web Dynpro applications. They define which
component configuration is used for which component in this application.
Application changes related to configuration affect every user in every client.
ABAP Web Dynpro PersonaIization
PersonaIization allows any user of the application to change the UÌ element properties at
runtime.
These changes are very restricted.
e.g.
· Ìn case of simple UÌ elements like TextView, only the visibility can be changed
· For the Table element, the order of the columns can also be altered
Personalization is user dependent.
Customizing is the ability to personalize Web Dynpro applications for all users in a client.
$pecial authorizations are required.
ABAP Web Dynpro Adaptation Hierarchy
Configuration, Customizing and Personalization can be combined to define the final adaptation.
· Changes defined by personalization overwrite the changes defined by customizing and
· Changes defined by customizing overwrites the configuration adaptation
· The parameters available for configuration can be set to final so that they cannot be
changed by customizing or personalization
· Parameters available for customizing can be set to final so that they cannot be changed
using personalization.
ABAP Web Dynpro Adaptation Hierarchy
ABAP Web Dynpro Exercise
Adaptation of Web Dynpro Applications Configuration Controllers
1. Define Configuration for your Web Dynpro Component and Web Dynpro App to show
10 rows in the table control instead of the default 5
2. Customize your Web Dynpro App to change the label of any button
3. Personalize your Web Dynpro App to hide one of the Table control fields
ABAP Web Dynpro Exercise
Window Controllers
Depending upon the value of the parameter "p¨ in the query string of the application URL,
either view V11 or V12 should be triggered.
ABAP Web Dynpro Exercise
Integrating a PDF Form in a Web Dynpro Component
Ìntegrate an interactive PDF form in a Web Dynpro component