Web Dynpro for ABAP

ABAP Web Dynpro

Course Contents - 1
Module 4 View Controller and View Context Context Node Elements Component Controller Module 4a - Exercise Populating Table control Module 5 Node Cardinality Module 5a Exercise Node Cardinality Module 6 Context mapping between views Navigation Context Node at Design Time Module 6a - Exercise Navigation

Description : In this course you will explore the various concepts and practical examples related to ABAP Web Dynpro
Course Contents : Module 1 - Theory ABAP Web Dynpro Architecture Technical Features Main Benefits Module 2 - Introduction Web Dynpro Development Web Dynpro Component Architecture Web Dynpro Components Views Windows and UI Elements Defining View Layout Layout Types UI Element Categories Module 2a - Exercise Introductory example Module 3 Controller and Context Controller Types Controller Entities

ABAP Web Dynpro

Course Contents - 2
Module 11a Exercise Adaptation of Web Dynpro Applications - Configuration Controllers Module 12 Exercise Window Controllers Module 13 Exercise Integrating a PDF Form in a Web Dynpro Component Module 14 Exercise Working with Dialog Boxes Module 15 Exercise Input Help Module 16 Exercise Portal Integration Module 17 Exercise Business Graphs

Module 7 Supply Function of a Context Node Module 7a Exercise Supply Function Module 8 Exercise Messages and Error Handling Module 9 Dynamic Programming Module 9a - Exercise Dynamic Programming Adding UI elements Changing properties of UI elements Module 10 Web Dynpro Component Interface Module 10a - Exercise Creating a Web Dynpro Component Interface Definition Module 11 Adaptation of Web Dynpro Applications

ABAP Web Dynpro

Web Dynpro Architecture

Definition Web Dynpro is the SAP NetWeaver programming model for user interfaces (UIs). The Web Dynpro model is based on the Model View Controller paradigm, and has the following features that build on the classic dynpro model: Clear separation of business logic and display logic Uniform metamodel for all types of user interfaces Execution on a number of client platforms Extensive platform independence of interfaces Web Dynpros 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

Technical Features

Web Dynpro provides technical features for Internationalization Flicker-free interaction Clean separation of business logic and the UI. 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 Development

ABAP Web Dynpro

Web Dynpro Component Architecture

ABAP Web Dynpro

Web Dynpro Components

ABAP Web Dynpro

Views Windows and UI Elements

ABAP Web Dynpro

Defining View Layout

ABAP Web Dynpro

Layout Types
Flow Layout Grid Layout Left to right, across the screen 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 Element Categories

ABAP Web Dynpro

Introductory Example

Exercise

Learn to create views, and familiarize yourself with various UI elements

ABAP Web Dynpro

Controller and Context

ABAP Web Dynpro

Component Controller

Controller Types

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 Controllers These are optional. They have to be defined at design time. Multiple custom controllers can be defined in a component Configuration Controller This is a special custom controller, used for configuration and personalization functionality. View Controllers 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 Controllers 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

Controller Entities - 1

Common Controller 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 UI 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_THIS 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

Controller Entities - 2

Special Entities of Component/Custom Controllers 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.

Special Entities of View Controllers Navigation Plugs 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. Special Entities of Window Controllers Navigation Plugs

ABAP Web Dynpro

Method Name WDDOINIT

Hook Methods
Applicable To Component Controller and View Controller Function Initialization Method of Controller

WDDOPOSTPROCESSIN Component G Controller WDDOBEFORENAVIGATI Component ON Controller WDDOAPPLICATIONSTA TECHANGE WDDOBEFOREACTION WDDOMODIFYVIEW WDDOEXIT Component Controller View Controller View Controller Component Controller and View Controller

Prepare Output Error Handling Before Navigation Through Application Handling for Suspending and Resuming an Application Method for Validation of User Input Method for Modifying the View Before Rendering (Refresh) Cleanup Method of Controller

ABAP Web Dynpro

Process Flow during data transfer

ABAP Web Dynpro

Process Flow of event handling

ABAP Web Dynpro

Component Controller-1

ABAP Web Dynpro

Component Controller-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 API based on ABAP Objects, BAPIs, RFS or function modules If 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 Controller-3

In 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 UI elements

ABAP Web Dynpro

Component Controller-4

The component controller provides data and processing logic that it should be possible to display or change for all views of a component. It has three interfaces: Interface IF_<controller_name> for coding within the controller Interface IG_<controller_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 Controller and View Context

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 UI elements

The view controller contains the event handlers which steer the behavior of the view, for example: Initialization events which are called when a view is displayed for the first time Action handlers which are triggered by UI elements like a button click or drop down list box selection In general the coding of the controller methods access the context data and not the UI elements directly.

ABAP Web Dynpro

Context Node Elements

ABAP Web Dynpro

Populate Table Control

Exercise

Problem: Create a table control and populate it with data for the carrier specified in the input field.

ABAP Web Dynpro

Node Cardinality

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>):

0..1 0..n 1..1 1..n

Zero or one elements permitted Zero or more elements permitted One and only one element permitted One or more elements permitted

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.

ABAP Web Dynpro

Node Cardinality
In the example above, for the node

Exercise

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

Attribute
WD_CONTEXT WD_THIS

Attributes
Reference to
controller context local interface

Reference Variable of type

IF_WD_CONTEXT_NODE IF_COMPONENTCONTROLLER IF_<MY_CUSTOM_CONTROLLER> IF_<MY_VIEW> IF_<MY_WINDOW>

WD_COMP_CONTROLLER View Controller

IG_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. In 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 Plugs 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 Plugs Inbound plugs are special event handler methods that subscribe to navigation events raised when outbound plugs are fired. Inbound plug methods are called only when the navigation queue is processed. This will only take place once 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. Inbound 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

Plugs and Navigation

ABAP Web Dynpro

Navigation

Exercise

Navigate back and forth between 2 views. Also, pass values between the 2 views.

ABAP Web Dynpro Supply Function of a Context Node

ABAP Web Dynpro Supply Function of a Context Node

Supply Function If 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 Supply 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 UI element is to be displayed for the first time with the data of the corresponding context, for example. In 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

Singleton

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 Singleton property of the sub node. If the sub node is declared as Singleton 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. If the sub node is declared as non-Singleton 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 Selection

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: In this case, the first element of a node is always assigned the lead selection property. Manual initialization of lead selection: If the automatic initialization was deactivated, the lead selection must be programmed manually. In this case it is possible to assign this property to an element other than the first element of a node.

ABAP Web Dynpro

Supply Function

Exercise

Use supply function to refresh the contents of a table depending upon the input from another table.

ABAP Web Dynpro

Messages and Error Handling

Exercise

Display a suitable message if the user enters invalid data

ABAP Web Dynpro

Custom Controllers

Exercise

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 VIEW, which is a reference to an object of type IF_WD_VIEW representing the instance of a view at runtime

The following interfaces are public and can be used to modify objects: IF_WD_APPLICATION IF_WD_ACTION IF_WD_COMPONENT IF_WD_COMPONENT_USAGE IF_WD_COMPONENT_USAGE_GROUP IF_WD_CONTEXT IF_WD_CONTROLLER IF_WD_EVENT IF_WD_MESSAGE_MANAGER IF_WD_OVS IF_WD_PORTAL_INTEGRATION IF_WD_VIEW IF_WD_VIEW_CONTROLLER IF_WD_WINDOW IF_WD_WINDOW_MANAGER

ABAP Web Dynpro

Dynamic Programming - 2

In addition to the all those different interfaces, you can also call static methods on certain public classes: CL_WD_UTILITY CL_WD_DYNAMIC_TOOL CL_WD_RUNTIME_SERVICES

ABAP Web Dynpro

Dynamic Programming - 3

The names of the classes that represent the above mentioned ViewElements are as follows: ViewElement -> CL_WDR_VIEW_ELEMENT UIElement -> CL_WD_UI_ELEMENT UIElementContainer -> CL_WD_UI_ELEMENT_CONTAINER Layout -> CL_WD_LAYOUT LayoutData -> CL_WD_LAYOUT_DATA The above classes are abstract. Since 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. If you are uncertain about the type of an UI element, use the least generic typed pointer. e.g.If 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

In order to change an existing ViewElement, a pointer can be obtained by calling the method GET_ELEMENT of interface IF_WD_VIEW. Such a typed pointer is available within method wdDoModifyView (available within any ViewController), as a parameter called VIEW. The following source code shows how one can obtain a pointer to the RootUIElementContainer. data: lr_container type ref to cl_wd_transparent_container. lr_container ?= view->get_element( `ROOTUIELEMENTCONTAINER` ).

ABAP Web Dynpro

Creating a ViewElement

Dynamic Programming - 5

Every ViewElement contains a method, which starts with NEW_ followed by the name of the class without the CL_WD_. So 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 "UIElementContainer 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 "UIElement 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. If an attribute is not specified, its default value will be applied. The binding paths of all bindable attributes. They have the prefix BIND_ 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

Dynamic Programming

Exercise

Adding UI 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

The interface controller of a component interface definition and the interface controller of a component differ in two items: Interface Controller of a Component Interface Definition The controller can be edited Methods can be defined in the editor, but they cannot be programmed there. The methods are programmed only after the implementation of the component interface definition in a Web Dynpro component. Interface Controller of a Component The controller can be displayed but not edited. The methods can be created in the editor of the related component controller (see above) and then be programmed in the ABAP editor.

In 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

Implementing 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 faceless Component It is possible to create a Web Dynpro component that has no visual interface. i.e. a component with zero views and zero windows. Such 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. Since 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, SAP recommends that when a model objects 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 Interface

Create a Web Dynpro Component Interface Definition Implement the above created Interface in a Web Dynpro Component

ABAP Web Dynpro Adaptation of Web Dynpro Applications

The UI 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 developer can create configuration data sets containing values for UI element properties. This allows the developer to overwrite many of the statically defined UI element properties, resulting in a different look and feel of the application. e.g. UI elements may be set to invisible Tables may have an alternating row color

Component configuration allows you to change properties of UI elements defined in any view of a single component. Application 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

Personalization

Personalization allows any user of the application to change the UI element properties at runtime. These changes are very restricted. e.g. In case of simple UI 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. Special 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

Window Controllers

Exercise

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

Integrate an interactive PDF form in a Web Dynpro component