ABAP Webdynpro Feb2012

Web Dynpro ABAP
People matter, results count.

Target Group
Audience
Developers and consultants who want to create applications
based on the Web Dynpro for ABAP programming model
Prerequisites
ABAP
ABAP Objects
Duration: 2 days
People matter, results count. 2

Course Goals
At the conclusion of this course, you will be able

to:
Develop a Basic Web Dynpro Application

Create and implement a UI using Views and
Windows
Create and implement programming logic using Web
Dynpro controllers

Content (1)
Unit 1 : Overview of ABAP object oriented programming

Unit 2: Web Dynpro Controllers
Unit 3: The Context at Design Time
Unit 4: UI Elements
Unit 5: Controller and Context Programming
Unit 6: OTR and Messages
Unit 7: Generic UI Services
Unit 8: Dynamic Modifications at Runtime

Content (2)
Unit 9: Component Usage
Unit 10: ALV for Web Dynpro

What is Object Orientation?

What is Object Orientation?
In the past, information systems used to be defined primarily

by their functionality: Data and functions were kept
separate and linked together by means of input and output
relations.
The object-oriented approach, however, focuses on

objects that represent abstract or concrete things of the
real world. These objects are first defined by their
character and their properties, which are represented by
their internal structure and their attributes (data). The
behavior of these objects is described by methods
(functionality).

Comparison between Procedural and Object Oriented Programming
Features Procedure Oriented approach Object Oriented approach
Emphasis Emphasis on tasks Emphasis on things that does those

tasks.
Modularization Programs are divided into smaller Programs are organized into classes and
programs known as functions objects and the functionalities are
embedded into methods of a class.
Data security Most of the functions share global Data can be hidden and cannot be
data accessed by external sources.
Extensibility Relatively more time consuming to New data and functions can be easily
modify for extending existing added whenever necessary
functionality.

Key features of Object Oriented Approach
Better Programming Structure.

Real world entity can be modeled very well.
Stress on data security and access.
Reduction in code redundancy.
Data encapsulation and abstraction

The Context At Design Time
Contents:
The structure of the context
Context mapping
Internal mapping

Terms Continued..
Encapsulation:
Objects restrict the visibility of their resources (attributes and
methods) to other users. Every object has an interface, which
determines how other objects can interact with it. The
implementation of the object is encapsulated, that is, invisible
outside the object itself.

Terms Continued..
Classes:
Classes describe objects. From a technical point of view, objects
are runtime instances of a class. In theory, you can create any
number of objects based on a single class. Each instance (object)
of a class has a unique identity and its own set of values for its
attributes.

Terms Continued..
Object References:
In a program, you identify and address objects using unique
object references. Object references allow you to access the
attributes and methods of an object.
In object-oriented programming, objects usually have the following
properties:

Terms Continued..
Inheritance:
You can use an existing class to derive a new class. Derived
classes inherit the data and methods of the superclass. However,
they can overwrite existing methods, and also add new ones.

Terms Continued..
Polymorphism:
Identical (identically-named) methods behave differently in
different classes. In ABAP Objects, polymorphism is
implemented by redefining methods during inheritance and
by using constructs called interfaces.he structure of the
context

Terms in Object Oriented Programming
Objects:
Objects are instances of classes. They contain data and provides
services. The data forms the attributes of the object. The services
are known as methods (also known as operations or functions).
Typically, methods operate on private data (the attributes, or state
of the object), which is only visible to the methods of the object.
Thus the attributes of an object cannot be changed directly by the
user, but only by the methods of the object. This guarantees the
internal consistency of the object.

Methods
Public Methods can be called from anywhere

Private methods can only be called within the class

Instance and Static Methods
Instance methods :
Can use both static and instance components
in their implementation part
Can be called using an instance
Static methods :
Can only use static components in their implementation
Part
Can be called using the class

Instance Attributes and Static Attributes
Instance Attributes:
One per instance
Statement :DATA
Static Attributes:
One per class
Statement: CLASS-DATA
Also known as class attributes

Visibility
Public Attributes:
Can be viewed and changed by all users and in all
methods
Direct access

Visibility continued
Private Attributes:
Can only be viewed and changed from within the class
No direct access from outside the class

Instance and Static Methods
Instance methods :
Can use both static and instance components
in their implementation part
Can be called using an instance
Static methods :
Can only use static components in their implementation
Part
Can be called using the class

Creating Objects
Objects are created using CREATE OBJECT statement

Objects can only be created and addressed using
reference
DATA : r_vehicle TYPE REF TO
CREATE OBJECT r_vehicle

Model View Controller (MVC)

The Context - The Heart of a Controller
Controller Other WD
Required
Controllers Controllers
Implementation
Standard Controller Custom
Context Interface Controller
Hook
Root Node
Methods
Instance Business
Methods Logic
(Models)
Component Other WD
Usage Components
Created by explicit declaration or coding Created by the Web Dynpro Framework (WDF)

Changing the Context
1) Open a controller (view or

custom) using the Change 2) Choose the Context
option in the context menu tab.
3) Display the Property by

selecting the CONTEXT node

Context Structure Design Time (1)
Node
Attribute
Context Root
Node Context menu on the Context Root
Node
Context Node:
Are arranged hierarchically and are permitted to have children
Children of a node may be entities known as other nodes or attributes
Metadata description declared manually or derived from a Dictionary
Structure
Context Attribute:
Stores runtime data or references to runtime data
Based on DDIC Types
Context Structure Design Time (2)
Context Metadata
Node Metadata (c=cardinality, s=singleton)
Context Root (c=1..1, s=true)
IF_WD_CONTEXT_NODE_INFO (interface)
FLIGHTS (c=0..n, s=true) Attribute Metadata (data type)
BOOKINGS (c=0..n, s=false) WDR_CONTEXT_ATTRIBUTE_INFO (structure)
BOOKID A node collection
CUSTOMID
CLASS
All context nodes are collections.
PASSNAME
A node collection is composed of
CARRID
elements, where an element is an
CONNID
aggregation of the nodes immediate
FLDATE children (attributes and/or other nodes).
PRICE The cardinality property controls the
number of elements a node collection
may hold at runtime.
Design time
Context Structure Runtime (1)
All independent nodes are forced to be singletons. This is
because the context root node has one and only one element.
Context Root Node
c=1..1, s=true
= Element created by an application at runtime
Default 1 = Element created by the WDF at context initialisation time
Element
c=1..1, s=true
Node collection contains a default
Default 1
Element element.
Can contain a maximum of one
c=0..1, s=true Independent Node element.
1 Node collection is initially empty.
Can contain a maximum of one
element.
Independent Node

Context Structure Runtime (2)
All independent nodes are forced to be singletons. This is
because the context root node has one and only one element.
Context Root Node
c=1..1, s=true
= Element created by an application at runtime
Default 1 = Element created by the WDF at context initialisation time
Element = Element at the lead selection
c=1..n, s=true
Node collection contains a default
..n element.
2
c=0..n, s=true Default 1 Can contain as many elements as
Element required.
..n
2
1 Independent Node
Node collection is initially empty.
Can contain as many elements as
Independent Node required.
Context Structure Runtime (3) Context Root
Default
The runtime structure of the
Context Metadata Element 0
context if node BOOKINGS is a
non-singleton.
FLIGHTS (c=0..n, s=true) FLIGHTS
BOOKINGS (c=0..n, s=false) CARRID ..n
CARRID
CONNID
2
BOOKID
CARRID
CONNID 1
CUSTOMID
CONNID
CLASS FLDATE
PASSNAME
BOOKINGS
CARRID
BOOKINGS BOOKID ..n
CONNID BOOKID 2
BOOKINGS CUSTOMID
BOOKID ..n
FLDATE BOOKID
BOOKID 2CUSTOMID
1
BOOKID ..nCUSTOMID
PRICE BOOKID BOOKID
2 1CUSTOMID
CUSTOMID
CUSTOMID
BOOKID 1 CUSTOMID
CUSTOMID
CUSTOMID
Design Time Runtime

Context Structure Runtime (4) Context Root
Default
The runtime structure of the
Context Metadata Element 0
context if node BOOKINGS is a
singleton.
FLIGHTS (c=0..n, s=true) FLIGHTS
BOOKINGS (c=0..n, s=true) CARRID ..n
CARRID
CONNID
2
BOOKID
CARRID
CONNID 1
CUSTOMID
CONNID
CLASS FLDATE
PASSNAME
CARRID
CONNID
BOOKINGS
FLDATE
BOOKID ..n
PRICE BOOKID 2
CUSTOMID
BOOKID
CUSTOMID
1
CUSTOMID
Design Time Runtime

Context Structure Why Singleton nodes? Context Root
Default
Element 0
Q: Why do singleton nodes exist? FLIGHTS

CARRID ..n
A: Efficiency! CARRID
CONNID
2
CARRID
CONNID 1
CONNID
FLDATE
This design of context structure both copies BOOKINGS

the way users handle business data, and
BOOKID ..n
causes the Web Dynpro application to BOOKID 2
CUSTOMID
consume significantly less memory. BOOKID
CUSTOMID
1
CUSTOMID

Supply Function
Context Root
Context node can be assigned a supply

function
FLIGHTS
CARRID
This supply function is called by the runtime
..n
CARRID
CONNID
2
CARRID
CONNID 1 when the data of the context node is required
CONNID
FLDATE
Especially useful in combination with singleton
nodes
BOOKINGS
BOOKID ..n Supply function
BOOKID
CUSTOMID
2
BOOKI
CUSTOMID
BOOKINGS_READ
1
D
CUSTOMID

Context Mapping
Context mapping is the primary mechanism for
sharing data between different controllers.
Advantages:
Data is automatically available to all

controllers using the mapping relationship
Only one copy of the data is ever maintained
Data can be mapped selectively, thus reducing

the amount of data in a controllers context to
the minimal set required to fulfil a task

Context Mapping
After the mapping the

mapped structure appears in
the target context
Drag and drop structure

or create a node and
define the mapping
In the property of the node the mapping path is visible

Context Mapping: Internal Mapping
View Controller Component Controller
Context Root Context Root

FLIGHTS FLIGHTS
BOOKINGS BOOKINGS
BOOKID Controller BOOKID

Usage
CUSTID Declaration CUSTID
CLASS CLASS
PASSN PASSN
CARRID CARRID
CONNID CONNID
FLDATE FLDATE
PRICE PRICE
Web Dynpro Component
Mapped node collection Node collection of mapping origin

Mapping Relationship
UI Elements
Contents:
Introduction to UI elements
Putting data on the screen: Context binding
Controlling the behaviour of UI elements using context binding
Using a basic composite UI element

What is a UI element?
A UI element is any graphical entity that occupies a position within a
view layout.
Group UI Element
TextView UI Element
Label UI Element
InputField UI Element
How are UI elements arranged?
All view layouts are composed from a hierarchy of UI elements.
The root node is always of type TransparentContainer, and is

always called RootUIElementContainer. You cannot change
this, it is hard coded!
Hard coded RootUIElementContainer

UI Element categories
Various categories of UI elements are supported
e.g. Button, InputField, Gantt, Network

Label
InteractiveForm
BusinessGraphics,
GeoMap
e.g. DateNavigator,
Table, Tree
BI Application Frame
OfficeControl
e.g.
TransparentContainer, MessageArea
Tray
Each UI element object is represented as an abstract class that is

independent of any client presentation layer.

Using the View Editor
1. Choose
Change from
the context
menu of a
view
View Editor
2. The Layout view 3a. UI elements can be added by
will be selected drag and drop from the
by default toolbar
1. Choose
Change from
the context
menu of
3b.a In the hierarchical representation - UI 5. Properties of the
view elements can also be added by UI elements can
selecting Insert Element via context
People matter, results count. be changed 43
Context Binding (1)
Context Binding is the association of a UI element property with a node or attribute in a
view controllers context.
The UI element property then uses the context node or attribute as it data source. If the
UI element property can be updated by the user, then new value replaces the value in the
context.
UI Layout
Context
Root Node

Context Binding (2)
Context Binding decouples the UI element object from the application
coding.
Application
Coding
Implementation UI Layout
Standard
Context
Hook
Root Node
Methods
Instance
Methods
Actions
Navigation
Plugs

Context Binding (3)
In order to control the behaviour of UI elements, you should
manipulate the context nodes or attributes to which the UI elements
are bound.
Implementation UI Layout
Standard
Context
Hook
Root Node
Methods
Instance
Updates
Methods
Actions
Navigation
Plugs

Putting data on the screen (1)
1) Declare
context
attribute
2) Create UI
element 1) Declare
on layout context
attribute
3) Bind UI element
to context
2) Create UI
attribute
element 1) Declare
on layout context
attribute
3) Bind UI element
to context
2) Create UI
attribute
element 1) Declare
on layout context
attribute
The order of attributes within a node has no influence on the order in which
the data they hold is displayed.
Notice that all the arrows

are double headed!
The binding between a UI element and a context attribute is a two-way

relationship:
Data from the context is transported to the client during screen
rendering
Data entered by the user is transported back to the context when the
HTTP round-trip is processed.
Setting the UI element behaviour
1.Since the value for the readOnly
property is hard coded and not
flexible
2.The
corresponding
input field will
always be open
for input.
A hard coded UI element property value

gives the UI element a fixed behaviour.
This arrangement does not lend itself to good

UI design and should be avoided!

Controlling UI element behaviour (1)
By creating a new attribute, you can control the property of
one or more UI elements.
2.For the UI element

are according data
types available.
3.The value of the attribute The readOnly UI
can be set by default or element property
in a appropriate method can be controlled
accessing the attribute by an attribute of
1.A new attribute has during runtime type
been created that is of WDY_BOOLEAN
the correct data type to ('X' == True, ' ==
control the readOnly People matter, results count. False) 53
Controlling UI element behaviour (2)
1.The readOnly property can now
2.The input field will now
be bound to a boolean context only be open for input if
attribute. the context attribute is
set to == true.
Binding UI element properties to

suitable context attributes is a very
much better, and more flexible
technique for UI design.

Test Page for UI Elements
The Test WD application wdr_test_ui_elements allows you to investigate
and checkout the function of the available UI elements.
UI element
appearance
Available
Properties
Possible UI Events

Introduction to Composite UI Elements (1)
A composite UI element is any UI element that
requires child UI elements.
Examples: The Table and Tree UI elements.
Rendered tree
UI element
Rendered table UI elements

Introduction to Composite UI Elements (2)
Composite UI elements are incapable of displaying information on
their own.
They must have child UI elements in order to function correctly.
Composite Table UI Element.
Child UI Elements. The

TableColumn elements are
also composite UI elements.
hierarchical representation of
a Table UI element
The Table UI element
The Table is an example of a composite UI element.
A Tables child elements are also composite.
Composite TableColumn UI
Element.
Each TableColumn UI Element

has a Caption and TextView UI
element as its children.
hierarchical representation of
a Table UI element
Binding a Table UI element to the context
The UI elements making up a Table
Context Metadata hierarchy require several context
bindings in order to function correctly.
Context Root
FLIGHTS (c=0..n)
BOOKINGS (c=0..n)
BOOKID
CUSTOMID
CLASS
PASSNAME
CARRID
View layout
CONNID
The Table UI element must have its
FLDATE
dataSource property bound to a
PRICE
context node of cardinality 0..n or 1..n
Design Time Runtime

Binding TableColumn UI elements to the context
TableColumn UI elements must be
Context Metadata bound to child attributes of the same
node to which the parent Table UI
Context Root element is bound.
FLIGHTS (c=0..n)
BOOKINGS (c=0..n)
BOOKID
Each context attribute is
CUSTOMID a potential candidate for
CLASS becoming a
TableColumn.
PASSNAME
CARRID
CONNID
FLDATE View layout

PRICE
Design Time Runtime

Defining child UI elements for a TableColumn
A TableColumn UI element must
Context Metadata have a UI element nominated to act as
the table cell editor. The column
Context Root header caption is optional.
FLIGHTS (c=0..n)
BOOKINGS (c=0..n)
Optional column
BOOKID
header (Caption UI
CUSTOMID element)
CLASS
PASSNAME
CARRID Mandatory table

cell editor UI
CONNID
element
FLDATE
View layout
PRICE
Design Time Runtime

Table row selection
Each element in the node
Context Root
Context Metadata Default
collection becomes a table
Element 0
row
Context Root
FLIGHTS (c=0..n) FLIGHTS
BOOKINGS (c=0..n) CARRID ..n
BOOKID CARRID
CONNID
2
CARRID
CONNID 1
CUSTOMID
CONNID
CLASS
FLDATE
PASSNAME
CARRID
Runtime data View layout
CONNID
FLDATE Selecting a row on the screen causes

PRICE
the nodes lead selection to be
altered
Design Time Runtime
Selecting multiple rows from a table
Define the nodes
Context Metadata selection cardinality
Context Root
FLIGHTS (c=0..n)
BOOKINGS (c=0..n)
BOOKID
CUSTOMID
CLASS
PASSNAME
CARRID
View layout
CONNID A nodes selection cardinality controls how
FLDATE many elements may be selected
PRICE simultaneously within the element collection.
0..1 is the default.
Design Time Runtime
Controller and Context Programming
Contents:
The Context At Runtime
Understand the controller methods that are available to
you for application coding
The Context API

The Context API: Topic Objectives
After completing this topic, you will be able to:

Understand how to access nodes and attributes in the
context using the context API.

Common Controller Features:
Standard Controller Hook Methods
Controller Other WD
Required
Implementation
Hook
Root Node
Methods
Instance Business
Methods Logic
(Models)
Component Other WD
Usage Components

Standard Hook Methods for all controllers
method WDDOINIT. method WDDOEXIT.

endmethod. endmethod.
All controllers have these two standard hook methods.

The method will only be called during the controllers lifecycle if they
contain coding.

Common Controller Features: Controller Instance Methods
Controller Other WD Required
Implementation
Hook
Root Node
Methods
Instance Business
Methods Logic
(Models)
Component Other WD
Usage Components

Controller Attributes and Utility methods
Attributes for the controller can be created (public or private)
Arbitrary methods can be created - .

Standard Controller Attributes WD_CONTEXT and WD_THIS
WD_CONTEXT and WD_THIS

present in any WD controller (excepted interface and interface view
controller).
WD_THIS - self reference of the local interface, type depends on the
controller type.
WD_CONTEXT - reference to the context of associated controller.

Standard Controller Attribute WD_COMP_CONTROLLER
WD_COMP_CONTROLLER
present in any WD controller.
reference to the component controller with access to all public methods
and attributes.
Attribute will automatically assigned to all view controllers when a view
is created.
For all other controller the WD_COMP_CONTROLLER attribute will
be assigned, when the properties of the controller the component
controller is used.

Standard Hook Methods Component Controller
WDDOBEFORENAVIGATION
It is executed before the navigation stack is processed
WDDOPOSTPROCESSING
Data from multiple components can be validated before the next step is
execute
Note: Only a component controller has these hook methods.

Access to Attribute of Node Element I
Context Root
Flights
Default 0 CARRID ..n Note: Node and attribute
Element
CONNID
CARRID 2 names must be
CONNID
CARRID 1 used in upper case
CONNID
data: Node_Flights type ref to If_Wd_Context_Node.
* navigate from <CONTEXT> to <FLIGHTS> via lead selection

Node_Flights = wd_Context->get_Child_Node( Name = `FLIGHTS` ).
* @TODO handle not set lead selection

if ( Node_Flights is initial ).
endif.

Access to Attribute of Node Element II
Context Root
Flights
Default 0 CARRID ..n
Element
CONNID
CARRID 2
CONNID
CARRID 1
CONNID
data: Node_Flights type ref to If_Wd_Context_Node,

Elem_Flights type ref to If_Wd_Context_Element.

* get element via lead selection

Elem_Flights = Node_Flights->get_Element( ).

if ( Elem_Flights is initial ).
endif.

Access to Attribute of Node Element III
Context Root
Flights
Element
CONNID
CARRID 2
CONNID
CARRID 1
CONNID

Elem_Flights type ref to If_Wd_Context_Element,
Item_CARRID like Stru_Flights-CARRID.


* get single attribute

Elem_Flights->get_Attribute(
exporting
Name = `CARRID`
importing
Value = Item_Carrid ).
Access to all Static Attributes of a Node Element
Context Root
Flights
Element
CONNID
CARRID 2
CONNID
CARRID 1
CONNID

Stru_Flights type If_Componentcontroller=>Element_Flights.


* get all declared attributes

Elem_Flights->get_Static_Attributes(
importing
Static_Attributes = Stru_Flights ).

Access to all Elements of a Node
Context Root
Flights
Element
CONNID
CARRID 2
Itab
CONNID
CARRID 1
CONNID

lt_Flights type If_Main_View=>Elements_Flights .


if ( Node_Flights is initial ).
endif.
* get all node element

Node_Flights->GET_STATIC_ATTRIBUTES_TABLE( importing
table = lt_Flights ).

Binding of an Element to a Node I
Context Root
FLIGHTS
Default 0
Element
data:
Node_Flights type ref to If_Wd_Context_Node.

node_flights = wd_context->get_child_node( Name = 'FLIGHTS' ).

Binding of an Element to a Node II
Context Root
FLIGHTS
Default 0
Element
data:
Node_Flights type ref to If_Wd_Context_Node,
First_flight_Elem type ref to If_Wd_Context_Element.

* create new element for node FLIGHTS

First_flight_Elem = Node_Flights->create_element( ).

Binding of an Element to a Node III
Context Root
FLIGHTS
Default 0
Element
CARRID
CONNID
data:


* set attributes
First_flight_Elem->set_attribute( name = 'CARRID' value = 'LH' ).
First_flight_Elem->set_attribute( name = 'CONNID' value = '400' ).

Binding of an Element to a Node IV
Context Root
FLIGHTS
Default 0
Element
CARRID 1
CONNID
data:


* set attributes
First_flight_Elem->set_attribute( name = 'CARRID' value = 'LH' ).
First_flight_Elem->set_attribute( name = 'CONNID' value = '400' ).
* bind first element to node

Node_Flights->bind_element( new_item = First_flight_Elem
SET_INITIAL_ELEMENTS = abap_false ). count.
People matter, results 81
Static Attributes and Binding of a Element to a Node
data:
Stru_flights type If_Componentcontroller=>Element_flights.

* set values to node->attributes

Stru_flights-carrid = 'AA'.
Stru_flights-connid = '017'.
* bind new element to node

Node_flights->bind_structure( new_item = Stru_flights
SET_INITIAL_ELEMENTS = abap_false ).

Binding of a Table to a Node
Context Root
FLIGHTS
Default 0
Element CARRID
Itab
CARRID 1
CONNID
data:
lt_flights type If_Componentcontroller=>Elements_flights,
Stru_flights like line of lt_flights.
* append values to local table

Stru_flights-carrid = 'LH'.
append Stru_flights to lt_flights.
Stru_flights-carrid = 'AA'.
append Stru_flights to lt_flights.
* get node reference

Node_Flights = wd_context->get_child_node( 'FLIGHTS' ).
* bind local table

Node_Flights->bind_table(
People lt_flights ).
matter, results count. 83
Controller and Context Programming: Unit Summary
You should now be able to:

Understand how to access nodes and attributes in the
context using the context API

Online Text Repository (OTR) and Messages
Contents:
Introduction to internationalization
Online Text Repository
Message handling

Messages and Error Handling: Unit Objectives
After completing this unit, you will be able to:

Understand ABAP WD support for Online Text
Repository
Report messages to the user using the
IF_WD_MESSAGE_MANAGER interface

Internationalization
The process by which language specific text is detached from the program code that uses it
is known as Internationalization.
This allows the same program to operate in multiple languages without needing different
versions of the code for each language.

Internationalization (I18N) Support
During runtime UI elements bound to an context node/attribute which is
based on a DDIC table/structure/type will get the text in appropriate
language.
Text properties of UI elements can be bound directly to DDIC text.
Is a text literal entered in a text fields of UI elements a corresponding
OTR text will be created.
Existing OTR texts (alias) can be assigned to a properties of a UI
element.
List of existing
OTR texts
Enter a text or assign an existing OTR text

Using the Online Text Repository
The class CL_WD_UTILITIES provide the method
GET_OTR_TEXT_BY_ALIAS to get text from OTR.
Use the WD code wizard to select

the proper OTR text and generate
the coding.
data:
... ...
OTR_text type string.
OTR_text = CL_WD_UTILITIES=>GET_OTR_TEXT_BY_ALIAS(
'SOTR_VOCABULARY_BASIC/MATERIAL_MASTER' ).
... ...
* set single attribute

Elem_Lable_Text->set_Attribute(
exporting
Name = `TF_LABLE_3`
Value = OTR_TEXT ).

Using the Component Assistence Class
A comonent assistence class can be associated to every WD component

Attribute wd_Assist is available in every controller of the component for accessing texts with
method get_text

Web Dynpro Messages and Error Handling
All messages will be displayed in a dedicated message area.
By default the message area appears at the top of the page.
The message are can be moved like a UI element in a view. You find
a UI element (Message Area) in the UI library Pattern. Messages
will be placed in this area, if it is available.
Messages can be displayed in a

dedicated message area
By default messages will be
displayed at the top of page
Message area can be moved
* Note: feature released with SP1

Handling of Message
The handling of messages can be controlled in the WD application
Messages area only visible if a message

thrown
Messages area always visible
Messages NOT listed in the message area box

- Messages are listed in a sequence
Note: feature released with SP1

Categories of Messages
Arbitrary text can be
used as a message Text
text
ABAP OO
exceptions can be EXCEPTION ATTRIBUTE Parameter
used
Reuse of existing Dedicated field will be Parameters can

T100 message ID, T100 marked in red color be assigned to
No.
the message
Example
* report message
CALL METHOD l_message_manager->REPORT_ATTRIBUTE_ERROR_MESSAGE
EXPORTING
MESSAGE_TEXT = '&V2 is not a valid date'
ELEMENT = Elem_Flights
ATTRIBUTE_NAME = 'FLDATE'
PARAMS = lt_messages.

Kind of Messages
Text
REPORT_ATTRIBUTE_ERROR_MESSAGE Reports a WD Exception for a Context Attribute
REPORT_SUCCESS Reports a Success Message
REPORT_WARNING Reports a Warning
REPORT_ERROR_MESSAGE Reports a Web Dynpro Message with Optional Parameters
REPORT_FATAL_ERROR_MESSAGE Reports a Fatal Web Dynpro Message with Optional Parameters
REPORT_ATTRIBUTE_EXCEPTION Reports a WD Exception for a Context Attribute

EXCEPTION
REPORT_EXCEPTION Reports a Web Dynpro Exception (May Return)
REPORT_FATAL_EXCEPTION Reports a Fatal Web Dynpro Message
REPORT_T100_MESSAGE Reports a Message Using a T100 Entry

REPORT_ATTRIBUTE_T100_MESSAGE Reports a WD Exception for a Context Attribute
T100

Create a message
Use the WD code wizard to create the
required coding to report a message.
* get message manager

data: l_current_controller type ref to if_wd_controller,
l_message_manager type ref to if_wd_message_manager.
l_current_controller ?= wd_This->Wd_Get_Api( ).
CALL METHOD l_current_controller->GET_MESSAGE_MANAGER

RECEIVING
MESSAGE_MANAGER = l_message_manager
* report message
CALL METHOD l_message_manager->REPORT_ATTRIBUTE_ERROR_MESSAGE
EXPORTING
MESSAGE_TEXT = 'REPORT_ATTRIBUTE_ERROR_MESSAGE'
ELEMENT = Elem_Flights
ATTRIBUTE_NAME = 'CITYFROM'.

Create a T100 message
Existing message classes can be reused to create messages
Use the WD code wizard to create the required coding to report a

T100 message.
* get message manager

data: l_current_controller type ref to if_wd_controller,
l_message_manager type ref to if_wd_message_manager.
l_current_controller ?= wd_This->Wd_Get_Api( ).
CALL METHOD l_current_controller->GET_MESSAGE_MANAGER

RECEIVING
MESSAGE_MANAGER = l_message_manager
* report message
CALL METHOD l_message_manager->REPORT_T100_MESSAGE
EXPORTING
MSGID = 'E1'
MSGNO = '360'
MSGTY = 'S'
P1 = ' -> REPORT_T100_MESSAGE'.
Standard Hook Method View controller
Only a view controller has these hook methods.
The method WDDOBEFOREACTION before an action performed, can

be used for data validation.

Messages and Error Handling: Unit Summary

Understand ABAP WD support for Online Text
Repository
Report messages to the user using the
IF_WD_MESSAGE_MANAGER interface

Generic UI Services
Contents:
Value Selector
Populating a DropDownByKey UI element
Value Help
Reuse of existing Value Helps
Object Value Selector (OVS)
Programmer-definable Value Help

Generic UI Services: Unit Objectives

Explain the difference between Value Selector and
Value Help
Reuse Value of existing Value Helps from the classical
ABAP programming

Overview Value Selector - Value Help
Value help is based on input fields
Input fields are bound to Context attributes
Value Selector - UI elements with limited value

selection (no server roundtrip)
DropDownByKey
DropDownByIndex
ItemListBox
RadioButton
Value Help based on UI InputField

element (server roundtrip required)
Values will be retrieved during runtime
separated pop-up

Value Selector Example - DropDownBox
Drop Down Box displays the valid input
values
Context attribute bound to a

DropDownByKey UI element
Context attribute
based on DDIC domain

(with fixed values or table)
assigned values during runtime
Suitable for small sets of values (< 30)

Dynamic Value Selector
Code sample
data:
lr_node_info type ref to if_wd_context_node_info,
lt_value_set TYPE wdy_key_value_table,
value_set_item TYPE wdy_key_value.
* get object referent of root node metadata

lr_node_info = wd_context->get_node_info( ).
* fill values into table of type wdy_key_value_table
value_set_item-key = 'X'.
value_set_item-value = 'Charter'.
insert value_set_item into table lt_value_set.
value_set_item-key = 'P'.
value_set_item-value = 'Private'.
insert value_set_item into table lt_value_set.
* set values (table) to context attribute

lr_node_info->set_attribute_value_set( NAME = 'FLIGHT_TYPE_DYN'
VALUE_SET = lt_value_set ).

Value Help
Input field provide a Input Help icon
Rendered as a pop-up table
Context attribute bound to a InputField UI

element
Input Help Mode
automatic
Dictionary search help
Object Value Selector
frei programmiert

Reuse of existing DDIC Value Help
Set Input Help Mode to Web Dynpro
automatic
Assign the type of the context Properties

attribute to an data element
The appropriate value help is

assigned to the context attribute
and is available during runtime
Field
Priority of search help
Search help
SPFLI-
search help
CARRID
check table Check table
domain fixed values Data element
S_CARR_ID
Domain
S_CARR_ID Value Range

People matter, results count.
DDIC105
Different Types of ValueDomain
Helpsfixed values
Check table
Domain fixed value range
Date picker
Arbitrary Search Help
Set Input Help Mode to Dictionary
Value Help
An arbitrary Search Help can be

assigned to an context attribute

Generic UI Services: Unit Summary

Use Value Selector with a DropDownByKey UI element
Reuse existing Value Helps

Dynamic Modifications at Runtime
Contents:
Introduction
Modifying the context structure at runtime
Modifying the UI Element hierarchy at runtime
The use of dynamic actions

Dynamic Modifications at Runtime: Unit Objectives

Understand what is dynamic programming
Dynamically modify and create UI elements
Dynamically create context elements
Dynamically bind UI element values to context elements
Dynamically create actions

Dynamic Runtime Modifications
What is type of dynamic modifications can be made at
runtime?
Dynamic Context Manipulation
The creation, modification and deletion of context nodes and
attributes
Dynamic UI Manipulation
The creation, modification and deletion of UI elements
Dynamic Assignment of Actions to UI Elements

Dynamic Runtime Modifications
Under what circumstances should I write coding that
performs dynamic modifications?
There are several situations in which type of coding could be
required:
When the structure of your data is not known until runtime
When you want the behaviour of a screen to be generic and
therefore dynamic
When you are writing utility components that must function in
a generic manner
Etc

Dynamic Context Data Creation
Context Metadata to be Example of context metadata
created at runtime
to be created dynamically?
FLIGHTS (c=0..n, s=true)
BOOKINGS (c=0..n, s=false)
BOOKID
CUSTOMID
CLASS
PASSNAME
CARRID
CONNID
FLDATE
PRICE

Dynamic Node Creation (1)
Context Metadata to be Coding steps:
created at runtime Obtain a reference to the metadata of the context
node that will act as the new nodes parent. In this
Context Root (c=1..1, s=true) case, we are creating an independent node,
FLIGHTS (c=0..n, s=true) therefore we get a reference to the metadata of the
BOOKINGS (c=0..n, s=false) root node.
Call static method create_nodeinfo_from_struct( )
BOOKID
from helper class cl_wd_dynamic_tool
CUSTOMID A DDIC Structure can be used for the attribute
CLASS creation.
PASSNAME
CARRID
CONNID
FLDATE
PRICE
DDIC Structure
SFLIGHT People matter, results count. 114
Dynamic Node Creation related to a structure
Coding steps:
Obtain a reference to the metadata of the context node that will act as the new
nodes parent.
Call static method create_nodeinfo_from_struct( ) from helper class
cl_wd_dynamic_tool to create from a DDIC structure a node.
DATA: rootnode_info TYPE REF TO if_wd_context_node_info,

table_name type string value 'SFLIGHT',
node_name type string value 'CONNECTIONS'.
* get root node info of context

rootnode_info = wd_context->get_node_info( ).
* create node named CONNECTIONS of sflight

cl_wd_dynamic_tool=>create_nodeinfo_from_struct(
parent_info = rootnode_info
node_name = node_name
structure_name = table_name
is_multiple = abap_false Cardinality 11
is_mandatory = abap_true ).

Dynamic Sub Node Creation related to a structure
Coding steps:
FLIGHTS (c=0..n, s=true)
Obtain a reference to node and reference to the metadata BOOKINGS (c=0..n,s=false)
of the context node that will act as the new nodes parent BOOKID
Call static method create_nodeinfo_from_struct( ) to CUSTOMID
create from a DDIC structure a node CLASS
PASSNAME
CARRID
CONNID
DATA: dyn_node type ref to if_wd_context_node, StructureFLDATE
SBOOK
dyn_node_info TYPE REF TO if_wd_context_node_info, PRICE
node_name TYPE string value 'FLIGHTS',
. . .
dyn_node = wd_Context->get_Child_Node( Name = node_name ).
dyn_node_info = dyn_node->get_node_info( ).
* create sub node named BOOKINGS of sbook

parent_info = dyn_node_info
node_name = 'BOOKINGS'
structure_name = 'SBOOK'
is_multiple = abap_true
is_mandatory = abap_false ).
Add a Dynamic Attribute to a Node
Coding steps:
UI_ATTRIBUTES
Obtain a reference to the metadata of the parent node that BUTTON_VISIBILITY
will contain the attribute TEXT_VISIBILITY
Fill structure ( WDR_CONTEXT_ATTRIBUTE_INFO ) with

attribute properties
Add attribute to parent node
* add context attribute to node

data: Ui_Attributes_info type ref to If_Wd_Context_Node_info.
data: ls_att type WDR_CONTEXT_ATTRIBUTE_INFO.
* get node info of context

Ui_Attributes_info = Node_Ui_Attributes->get_node_info( ).
ls_att-name = `TEXT_VISIBILITY`.
ls_att-TYPE_NAME = 'WDUI_VISIBILITY'.
Ui_Attributes_info->add_attribute( ATTRIBUTE_INFO = ls_att ).

Standard Hook Method View controller
Only a view controller has these hook methods.
The method WDDOMODIFYVIEW will only be called if:
The view is part of the current view assembly and this is the first
time the view is required, or
The view is part of the current view assembly and an action

belonging to the same view controller has been processed.

Principles of UI element manipulation
The following coding principles must be adhered to during UI element
manipulation:
1. Only perform direct manipulation of UI element objects when it is not
possible to control their behaviour through context binding.
2. UI manipulation is only permitted within the wdDoModifyView()
method of a view controller.
3. wdDoModifyView() has a boolean parameter called firstTime.
Typically, you will only build a dynamic UI element hierarchy when
firstTime == true. This avoids rebuilding the UI element hierarchy
unnecessarily.
4. Do NOT implement any coding in wdDoModifyView() that modifies
the context! The context should be considered read-only during the
execution of this method.

Dynamic UI manipulation (1)
Context Metadata UI Element Hierarchy to

be created at runtime
Context Root RootUIElementContainer

Connections
CARRIDLabel
CARRID
CARRIDInput
CONNID
FLDATE CONNIDLabel
PRICE CONNIDInput
FLDATELabel
FLDATEInput
PRICELabel
PRICEInput

Context Metadata
Context Root
UI Element Hierarchy to Coding steps:
Connections Check that this is the
CARRID RootUIElementContainer first time the view has
CONNID been rendered
FLDATE Obtain a reference to

PRICE the root UI element
container
method WDDOMODIFYVIEW .
data: wd_container type ref to cl_wd_uielement_container,

. . .
* Check if first time

check first_time = abap_true.
wd_container ?= view->get_element( 'ROOTUIELEMENTCONTAINER' ).

Context Metadata UI Element Hierarchy to Coding steps:

Create a new InputField UI
Context Root RootUIElementContainer element object (bind to
Connections context attribute
Label
CARRID Create a new Label UI
InputField element object
CONNID
FLDATE Set the Labels properties as

PRICE required
Add the Label object to the

UI element container
InputField Label
Set the InputFields
properties as required
bind
Add the InputField to the UI
add element container
* Create label and input field

** create a input field
wd_input_field = cl_wd_input_field=>new_input_field( view = view
bind_value = 'CONNECTIONS.CARRID').
** create a label for the input field
wd_label = cl_wd_label=>new_label( label_for = wd_input_field->id ).
** set matrix_head_data for the label

cl_wd_matrix_head_data=>new_matrix_head_data( element = wd_label ).
** add label to container

wd_container->add_child( wd_label ).
** set matrix_data for the input_field

cl_wd_matrix_data=>new_matrix_data( element = wd_input_field ).
** add input field to container

wd_container->add_child( wd_input_field ).

Dynamic Actions
Certain UI elements can trigger client-side events (e.g. pressing enter

in an InputField, toggling a CheckBox or selecting the row of a
table).
In order for the client-side event to trigger the execution of a server-

side method, Web Dynpro uses the concept of Actions.
Actions can either be assigned declaratively to UI element events at

design time, or dynamically at runtime.
Actions assigned dynamically can only refer to existing server-side

action handler methods. It is not possible to define the coding of an
action event handler dynamically; only to define which existing action
handler will be called when a client-side event is trapped.

Action Declaration
Declared action
Coding required
for dynamic
assigned action

Create a Dynamic Button
Context Metadata UI Element Hierarchy to Coding steps:

Context Root be created at runtime
Create a new Button UI
Connections
RootUIElementContainer element object (assign an
CARRID predefined action)
Label
CONNID
Set the Button properties as
FLDATE InputField required
PRICE Button
Add the Button to the UI
element container
Button
* Create button
** create button UI element
wd_button = cl_wd_button=>new_button( text = 'Show Flights'
on_action = 'SELECT_FLIGHTS' ).
** set matrix_head_data for the label
cl_wd_matrix_head_data=>new_matrix_head_data( element = wd_button ).
** add button to container
wd_container->add_child( wd_button ).

Was this a good approach?
Development Principle
Only if the required functionality of your application does not permit
design time declarations, then use a dynamic modification approach.
All context node/attribute and UI elements which can be created
during design time should be created during design time.

Example for Dynamic Programming
Display the content of ANY

table
Dynamic Context
Dynamic table UI element
Dynamic data retrieval

Example for Dynamic Programming I
DATA:
group_1 TYPE REF TO cl_wd_uielement_container,
new_tab TYPE REF TO cl_wd_table,
dyn_node TYPE REF TO if_wd_context_node,
tabname_node TYPE REF TO if_wd_context_node,
rootnode_info TYPE REF TO if_wd_context_node_info,
stru_tab TYPE REF TO data,
tablename TYPE string.
FIELD-SYMBOLS <tab> TYPE table.
* get node info of context root node

rootnode_info = wd_context->get_node_info( ).
* Get the name of the table to be created

tabname_node = wd_context->get_child_node( name = 'TABLE_DATA' ).
tabname_node->get_attribute( EXPORTING name = 'NAME' IMPORTING value =
tablename ).
translate tablename to upper case.
* create sub node of structure (tablename)

parent_info = rootnode_info
node_name = tablename
structure_name = tablename
is_multiple = abap_true ).
Example for Dynamic Programming II
* remove "old" table UI element from view , if necessary
group_1 ?= view->get_element( 'GROUP_1' ).
group_1->remove_child( id = 'TESTTAB' ).
* * get instance of new node

dyn_node = wd_context->get_child_node( name = tablename ).
DATA new_tab TYPE REF TO cl_wd_table.
* create new UI element table

new_tab = cl_wd_dynamic_tool=>create_table_from_node(
ui_parent = group_1
table_id = 'TESTTAB'
node = dyn_node ).
** fill context node with data

* create internal table of (tabletype)
CREATE DATA stru_tab TYPE TABLE OF (tablename).
ASSIGN stru_tab->* TO <tab>.
* Get table content

SELECT * FROM (tablename) INTO CORRESPONDING FIELDS OF TABLE <tab>.
* Bind internal table to context node

dyn_node->bind_table( <tab> ).
Web Dynpro Dynamic Programming: Unit Summary

Understand what is dynamic programming
Dynamically modify and create UI elements
Dynamically create context elements
Dynamically bind UI element values to context elements
Dynamically create actions

Component Usage
Contents:
Component Interface
External Mapping
Web Dynpro Component Usage

Web Dynpro Component Usage
Reuse of Web Dynpro Components
Real business applications usually
consist of several WD components
Reusable components for dedicated
often used tasks in different
applications
Customer address display
Order details

Generic components as part of the Web
Dynpro environment Comp A Comp Inter Comp B
Contr. face
ALV
Context Context
Select Options
Message Viewer
Method A Method B
Event E Event E

Web
Main Dynpro
Comp A Component
Main Comp B Usage Main Component
Sub Comp A Sub Comp B

Sub Component
Several main components need the Main component needs different
same functionality functionalities in a given view area
Functionality is developed once in View container provides place for sub
reusable component components
Main components declare Several Component Usages to
Component Usage of sub component different sub components with the
same Interface are defined
Sub component is instantiated in
each main component at runtime Which component is used is decided
at runtime

Web Dynpro Component Reuse
Component A Comp
Controller Interface Component B
Window Controller Window
View Context Context
Node Node
View View
Method A Method B
Event E Event E
Windows of an included component

Interface Component C
can be declared as Interface Views
Controller Window
Methods, events and context nodes Context
can be declared as part of the Interface Node
Access via Interface Controller with

View
Context node mapping Method C
Event E
Method call, Events raised
Embedding of Interface View

Component Interfaces
External access to a components functionality is provided by
interface controllers.
Each component has zero or more visual interface views, and exactly one
programmatic interface
The Interface controller is only ever
Interface Views are standard ABAP instantiated when the component is
interfaces implemented by all used as the child of another
Windows. component.
The interface view gives any The Web Dynpro Framework never
component window a generic interacts with a components
interface. interface controller.
Interface Interface
Interface viewview Controller
Internally M
Visible
Component Interface
Component
Controller
Window M
Window Controller Components
M
Component Usage from a Component Perspective
A usage definition on WD Components

Windows
component level enables
to:
Embed windows from
other WD components Windows
Component Interface
Windows Context Methods Events
Interface view Interface controller
Other WD Components
Component Usage from a Controller Perspective
A usage definition on WD Components

Windows
Controller level enables to:
Create a mapping to the Context Controller
context of the
corresponding interface Windows
controller
Call methods in the
corresponding interface
controller Component Interface
Fire Events in the
corresponding interface Windows Context Methods Events
controller
Interface view Interface controller
Other WD Components
Concepts: Component Interface
Interface
Component Controller Component
Controller
Interface Contr. Window
Context
Component Contr.
View View Controller
Root Node
Context
Root Node
Node 1 Context
Node 1 Root Node
Node 1
Method SET_AIRP.
Node 2
View Controller
Node 3
View
Label
Context
Interface View
method SET_AIRP Label Contexth
Root Node Root Node
Label
Node 1 Node 1
PressAttribut1
Attribut2
Method
ViewSORT_FLIGHT
Controller Node 2
View
Label
Context
Press
Attribut1
Label
Root Node
Attribut2
Node 2
Label1
Node
Node 2

Concepts: Component Interface
Interface Controller Interface
Component Controller Component
Controller
Interface Contr. Interface Contr. Window
Context Context
Component Contr.
Root Node Root Node
Context
Node 1 Root Node
Node 1 Context
Node 1 Root Node
Node 1
Method SET_AIRP. Method SET_AIRP.

Node 2
View Controller
Node 3
View
Label
Context
Interface View Interface View
method SET_AIRP Label Contexth
Root Node Root Node
Label
Node 1 Node 1
PressAttribut1
Attribut2
View Controller Method

ViewSORT_FLIGHT
Controller Node 2
View
Label
Context
Press
Attribut1
Label
Root Node
Attribut2
View
Label
Context
Press
Attribut1
Label
Root Node
Attribut2
Node 2
Label
Node 1 Label1
Node
Node 2 Node 2

Cross Component Context Mapping
Comp A Comp
Interface Comp B
Controller uses Controller
View
Context Context
Node Node
Direct Context Mapping

Component A uses data of component B
Comp A provides View, comp B provides data
Comp A Comp
Interface Comp B
Controller uses Controller
Context Context
Node Node
View
Reverse Context Mapping

Component A uses display feature of component B
Comp A provides data, comp B provides View
Dynamic Component Usage
Main Component
Main Component wants to use Main Comp

one (or several) components of a expects
special type Component
with special
Which component will be used is
Comp
not known at design time Interface
Developer declares Component ?
Interface
Main component uses reference
of this interface
Which component is used is
decided at runtime
Other components with this
interface can be developed and
Concrete Component
integrated later
Usage is determined at
runtime
Structure of WD Applications
Components Controller UI Component
UI components
Main Comp. Controller
Controller UIUIComponen
Componentt
Controller Context
contain the views, Context
Context
Node
Node
buttons, events,... Node
Model component
contains the
application logic and
Model Comp
data (shop with
Context
shopping basket, self Node
service,...)
Main component
instantiates UI and
model component
Model Layer accesses
Backend Business
backend functionality API (BAPI,
Business
Web Services)
Data

Component Usage: Unit Summary

Reuse Web Dynpro Component
Create External Mapping

ALV for Web Dynpro
Contents:
ALV integration in Web Dynpro
ALV Configuration Model

ALV in NetWeaver 2004s
ALV in Web Dynpro
Provide a more advanced
display component
compared to Table UI
element
Offer same functionality as
common ALV in ABAP
ALV realized as WD ALV Pattern Component
Component not as UI Web Dynpro ALV Component
element
Web Dynpro
More complex interface
UI elements
Included via Component
Usage
Data binding by reverse
context mapping

ALV in NetWeaver 04s
Web Dynpro ABAP based UI component
Provide an optional list-header and list-footer area for displaying
additional information
Offer set of generic functions
Choose columns which you want to display out of a set of columns
Interactive sorting by simple header click or by choosing multiple criteria
Interactive filtering by entering a filter-string in the edit field above the column
Aggregation on multiple key figures (total, min, max, average, count)
Sub-aggregation if group-level (defined by sort criteria) changes
Editability
Persistence of configurations (layouts)
Export to PDF
Offer interface to application to enhance set of generic functions with

application specific functions

WD ALV and Table Node
Most common application scenario:
Application has its data available as an internal table and would like to
display the data in an ALV as efficient as possible
Application ALV
Context Context
Node reverse context mapping Node
bind_table() ITAB' = get_static_attributes_table()
invalidate()
Local
ITAB bind_table(ITAB')

Overview ALV Configuration Model
ALV is steered by Configuration Model, which is kind of handle to manipulate
look, feel and behavior of ALV
Hierarchical class structure
CL_SALV_WD_CONFIG_TABLE
ALV creates a default configuration model at initialization
Application can modify configuration model at 2 points of time
WDDOINIT everything can be changed
WDDOMODIFY meaningful subset can be changed
ALV refresh method need to be called
ALV Config Model

Table Settings (# rows,)
Field Settings (filter, )
Column Settings (vis cols)
Function Settings

ALV for Web Dynpro: Unit Summary

Describe the ALV usage in Web dynpro
Use the ALV in Web Dynpro

References
SAP Online Help

SDN
Empower

Questions

ABAP Webdynpro Feb2012

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ABAP Webdynpro Feb2012

Uploaded by

Copyright:

Available Formats

Web Dynpro ABAP

People matter, results count.

People matter, results count. 2

At the conclusion of this course, you will be able

Develop a Basic Web Dynpro Application

People matter, results count. 3

Unit 1 : Overview of ABAP object oriented programming

People matter, results count. 4

Unit 9: Component Usage

Unit 10: ALV for Web Dynpro

People matter, results count. 5

People matter, results count. 6

In the past, information systems used to be defined primarily

The object-oriented approach, however, focuses on

People matter, results count. 7

Features Procedure Oriented approach Object Oriented approach

Emphasis Emphasis on tasks Emphasis on things that does those

People matter, results count. 8

Better Programming Structure.

People matter, results count. 9

People matter, results count. 10

People matter, results count. 11

People matter, results count. 12

People matter, results count. 13

People matter, results count. 14

People matter, results count. 15

People matter, results count. 16

Public Methods can be called from anywhere

People matter, results count. 17

People matter, results count. 18

People matter, results count. 19

People matter, results count. 20

People matter, results count. 21

People matter, results count. 22

Objects are created using CREATE OBJECT statement

People matter, results count. 23

People matter, results count. 24

People matter, results count. 25

1) Open a controller (view or

3) Display the Property by

People matter, results count. 26

Context Root Node

People matter, results count. 29

Context Root Node

Design Time Runtime

Design Time Runtime

Q: Why do singleton nodes exist? FLIGHTS

This design of context structure both copies BOOKINGS

People matter, results count. 33

Context node can be assigned a supply

People matter, results count. 34

Data is automatically available to all

Only one copy of the data is ever maintained

Data can be mapped selectively, thus reducing

People matter, results count. 35

After the mapping the

Drag and drop structure

In the property of the node the mapping path is visible

Context Root Context Root

BOOKID Controller BOOKID

Web Dynpro Component

Mapped node collection Node collection of mapping origin

People matter, results count. 38

The root node is always of type TransparentContainer, and is