NET313 Floorplan Manager For Web Dynpro PDF

NET313
Floorplan Manager for Web Dynpro

ABAP
SAP NetWeaver Application Server - ABAP
Date
Training Center
Instructors
Education Website
Participant Handbook
Course Version: 91
Course Duration: 3 Day(s)
Material Number: 50094991
An SAP course - use it to learn, reference it for work

Copyright
Copyright 2009 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP AG. The information contained herein may be changed
without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software
components of other software vendors.
Trademarks
Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are
registered trademarks of Microsoft Corporation.
IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX,
S/390, AS/400, OS/390, and OS/400 are registered trademarks of IBM Corporation.
ORACLE is a registered trademark of ORACLE Corporation.
INFORMIX-OnLine for SAP and INFORMIX Dynamic ServerTM are registered
trademarks of Informix Software Incorporated.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame,
VideoFrame, MultiWin and other Citrix product names referenced herein are trademarks
of Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World
Wide Web Consortium, Massachusetts Institute of Technology.
JAVA is a registered trademark of Sun Microsystems, Inc.
JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for
technology invented and implemented by Netscape.
SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP
EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com
are trademarks or registered trademarks of SAP AG in Germany and in several other countries
all over the world. All other products mentioned are trademarks or registered trademarks of
their respective companies.
Disclaimer
THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY
DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING
WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE,
INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS
CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT,
INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY
KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST
PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDED
SOFTWARE COMPONENTS.
g2009112114144
About This Handbook
This handbook is intended to complement the instructor-led presentation of this
course, and serve as a source of reference. It is not suitable for self-study.
Typographic Conventions
American English is the standard used in this handbook. The following
typographic conventions are also used.
Type Style Description
Example text Words or characters that appear on the screen. These

include field names, screen titles, pushbuttons as well
as menu names, paths, and options.
Also used for cross-references to other documentation
both internal and external.
Example text Emphasized words or phrases in body text, titles of

graphics, and tables
EXAMPLE TEXT Names of elements in the system. These include

report names, program names, transaction codes, table
names, and individual key words of a programming
language, when surrounded by body text, for example
SELECT and INCLUDE.
Example text Screen output. This includes file and directory names
and their paths, messages, names of variables and
parameters, and passages of the source text of a
program.
Example text Exact user entry. These are words and characters that
you enter in the system exactly as they appear in the
documentation.
<Example text> Variable user entry. Pointed brackets indicate that you
replace these words and characters with appropriate
entries.
2009/91 2009 SAP AG. All rights reserved. iii

About This Handbook NET313
Icons in Body Text

The following icons are used in this handbook.
Icon Meaning
For more information, tips, or background
Note or further explanation of previous point
Exception or caution
Procedures
Indicates that the item is displayed in the instructor's

presentation.
iv 2009 SAP AG. All rights reserved. 2009/91

Contents
Course Overview ......................................................... vii
Course Goals ...........................................................vii
Course Objectives .....................................................vii
Unit 1: Introduction........................................................ 1
Web Dynpro ABAP Fundamentals ...................................2
Floorplan Manager - Overview ...................................... 36
Unit 2: Developing FPM Applications ............................... 55

Configuring FPM Components ...................................... 56
FPM Programming - Basics ........................................100
Unit 3: Generic UI Building Blocks (GUIBBs) .................... 159

Generic UI Building Blocks - general Aspects ...................160
The FORM GUIBB ...................................................167
The LIST GUIBB .....................................................201
Index ....................................................................... 233
2009/91 2009 SAP AG. All rights reserved. v

Contents NET313
vi 2009 SAP AG. All rights reserved. 2009/91

Course Overview
This course deals with the creation and configuration of Web Dynpro for ABAP
applications that are based on the Floorplan Manager (FPM) framework.
Target Audience
This course is intended for the following audiences:
Developers of Web Dynpro ABAP applications based on the FPM

framework.
Course Prerequisites
Required Knowledge
NET310 - Fundamentals of Web Dynpro for ABAP
Course Goals
This course will prepare you to:
Understand the architecture of Web Dynpro applications based on the FPM

framework
Create Web Dynpro applications based on the Object Instance Floorplan
(OIF) and the Guided Activity Floorplan (GAF)
Course Objectives
After completing this course, you will be able to:
Configure FPM components statically

Define toolbar buttons and handle toolbar events
Add initial screens and confirmation dialogs to the floorplans
Understand the FPM phase model basically
Define messages making use of the FPM message manager
Define forms and lists by means of generic UI building blocks (GUIBBs)
Provide data to be displayed by GUIBBs by means of feeder classes
2009/91 2009 SAP AG. All rights reserved. vii

Course Overview NET313
viii 2009 SAP AG. All rights reserved. 2009/91

Unit 1
Introduction
Unit Overview
In the first lesson of this unit, Web Dynpro fundamentals are repeated. Especially
the topics Component Reuse and Personalization are discussed since the FPM
framework is based on these techniques.
The second lesson provides a brief introduction into the FPM topic. The
architecture of FPM based Web Dynpro applications is compared to the
architecture of Web Dynpro applications not making use of the FPM framework.
The two important floorplans Guided Activity Floorplan (GAF) and Object
Instance Floorplan (OIF) are introduced. This includes a discussion of the
mandatory and optional functionality.
Unit Objectives
After completing this unit, you will be able to:
Describe, how Web Dynpro components can be reused

Describe the adaptation of Web Dynpro components via implicit and explicit
configuration.
Describe what floorplans are
List the advantages of developing Web Dynpro ABAP applications using
the FPM framework
Unit Contents
Lesson: Web Dynpro ABAP Fundamentals ....................................2
Lesson: Floorplan Manager - Overview....................................... 36
Exercise 1: Create Package and copy template Components ........ 47
2009/91 2009 SAP AG. All rights reserved. 1

Unit 1: Introduction NET313
Lesson: Web Dynpro ABAP Fundamentals
Lesson Overview
The Floorplan Manager for Web Dynpro ABAP is a framework that allows to
embed multiple Web Dynpro components by a common highly configurable
component (floorplan component). The prerequisite to understand the functionality
of the Floorplan Manager (FPM) framework is a deep comprehension of the Web
Dynpro features component reuse and adaptation via configuration.
These features - already explained in class NET310 - will be summarized in this
lesson.
Lesson Objectives
After completing this lesson, you will be able to:
configuration.
Business Example
The prerequisite to understand the functionality of the Floorplan Manager (FPM)
framework is a deep comprehension of the Web Dynpro features component reuse
and adaptation via configuration. Thus you have to recapitulate what you have
learned in class NET310 you have (hopefully) attended before.
Web Dynpro Architecture

A Web Dynpro application refers to a Web Dynpro component, which serves as a
container for entities which are related to the user interface or which are related to
the control flow. The component entities and their dependencies are summed up in
the following section.
Internally visible Component Entities

Views are the basic entities from which the user interface (UI) is derived. Views
allow to define a rectangular part of the UI (Layout tab) by means of predefined UI
elements. UI element properties can be defined statically or they can be bound
to the view's context. This allows to influence the element properties from the
source code of the view's controller (data binding). In addition, the view controller
methods encapsulate the code for checking the user input, to trigger the navigation
via firing outbound plugs and to handle a navigation request via inbound plugs.
2 2009 SAP AG. All rights reserved. 2009/91

NET313 Lesson: Web Dynpro ABAP Fundamentals
Views are embedded in windows. Windows allow to define which views may be
visible for a certain application connected to this window. If combinations of
multiple views are to be displayed, these views are combined in the window (view
assembly). Windows are used to define the visual flow by creating navigation
links between the outbound plugs and the inbound plugs of embedded views.
The control flow of a Web Dynpro component is defined in the component
controller. From the component controller methods, the database of the local
system or the functionality of a back-end system is accessed. This is mainly done
by calling methods of a globally defined class (model) encapsulating the related
source code. These methods preferably encapsulate ABAP Open-SQL statements
(local DB access), the call of a Web service or the call of a function module in a
back-end system. The data interchanged between the controller and the model
can be stored in the model (if this global class is instantiated), in the component
controller's attributes, or in the component controller's context.
For modularization reasons, custom controllers may be created. These serve as
sub controllers of the component controller.
Certain parts of a controller's functionality are potentially visible to other
controllers. This is true for all controllers besides the view controller (MVC
principle). The controller that needs to access to functionality has to declare the
usage of the controller providing the functionality. Then, the complete context, all
ordinary methods, and all events are visible to the consumer controller. Context
mapping simplifies accessing the context of a used controller by the consumer
controller.
Figure 1: Component entities

Externally visible Component Entities

From each window a so called interface view is derived. The interface view of a
given window may be embedded in a window of a consumer component as if it
was just a simple view of the consumer component itself.
To allow the navigation between a view and an embedded interface view, the
related window needs to have Inbound plugs and outbound plugs exposed to the
interface. Externally visible inbound plugs may also be of type startup. In this
case, the inbound plugs may be used to enter the Web Dynpro component by
sending a HTTP request having the correct URL. The URL is assigned to a startup
plug of an interface view via a Web Dynpro application. The related service to
call the WD application is defined automatically. This service can be edited and
viewed using the transaction SICF.
Functionality of a Web Dynpro component may be offered to other Web Dynpro
components by means of the component's interface controller. This controller is
an interface of the component controller. Methods, events, and context nodes of
the component controller may be declared in a way (flag interface) that they are
visible in the components interface controller.
Navigation
Navigation from one view (assembly) to another view (assembly) is typically
triggered by a client side user action (e.g. clicking a button, selecting a table line).
This client side event can be related to the processing of a special method in the
related view controller by means of an action.
To define which views will make up the next view assembly, one or more outbound
plugs can be fired. A view's outbound plug can only be fired from a method of the
corresponding view controller. Plugs allow to pass data via export parameters.

Figure 2: Navigation: Principle
Outbound plugs and inbound plugs of different views are connected in the window
via navigation links. One outbound plug can be connected to multiple inbound
plugs. This is meaningful if each inbound plug belongs to a different view and
all views together belong to the next view assembly. On the other side, multiple
outbound plugs may be connected to the same inbound plug.
Controller Methods
Each of the Web Dynpro controller types contains a set of predefined methods
which are called by the Web Dynpro runtime. In addition to these so called hook
methods, additional methods can be defined by the developer. These may be
ordinary methods, event handler methods, or supply functions. Ordinary methods
are the only methods that can be called from other methods of the same controller
or even from other controllers (not valid for view controllers). Supply functions
are connected to a context node. They are used to fill the context. Supply functions
are called by the Web Dynpro framework is the data is needed (data display or
functional access) and this data is not available in the context.

Figure 3: Controller methods
All controllers contain the hook methods WDDOINIT() and WDDOEXIT(). These
are the first and the last method processed in a controllers lifetime, respectively.
Window controllers contain in addition the two methods WDDOONOPEN() and
WDDOONCLOSE(), which are called when opening or closing the window as a
dialog box, respectively.
View controllers contain in addition the methods WDDOBEFOREACTION(),
WDDOAFTERACTION(), WDDOONCONTEXTMENU(), and
WDDOMODIFYVIEW(). WDDOBEFOREACTION() is called before any action
handler method (as a result of a client side event) is processed. This method is
typically used to check the user input. WDDOAFTERACTION() is called after any
action handler method (as a result of a client side event) is processed. This method
can be used for modularization reasons. WDDOMODIFYVIEW() is used for
dynamic changes of the UI element hierarchy while WDDOONCONTEXTMENU()
allows to assign and change context menus dynamically.
Custom controllers do not contain additional hook methods.
The component controller contains the additional hook methods
WDDOBEFORENAVIGATION() and WDDOPOSTPROCESSING().
WDDOBEFORENAVIGATION() is called after the action handling is finished
and just before the Web Dynpro framework processes the methods of all views
belonging to the next view assembly. WDDOPOSTPROCESSING() is the last
hook method processed before the response is send back to the client.

Figure 4: Standard hook methods: Order of processing
Controller Attributes
Each controller contains the predefined attributes WD_THIS and WD_CONTEXT
which are used to access the controller's functionality and its context information,
respectively.
If the component controller is defined as a used controller for another controller,
the attribute WD_COMP_CONTROLLER will be added to the attribute list of the
controller declaring the usage. This attribute is used to access the functionality of
the component controller object at runtime.
If an assistance class is related to a Web Dynpro component, each controller of
this component will contain an additional attribute WD_ASSIST. This allows to
access the functionality of the assistance class instance at runtime.
In addition to these standard attributes, the developer may define an arbitrary
number of additional attributes. These serve as the controller's globally visible
variables. In contrast to the information kept in the controller context, attributes
can not be bound to UI element properties, nor they can be mapped between
controllers. In addition, there is lot of meta information related to context nodes
and context attributes (cardinality, selection cardinality, singleton property, related
supply function ...) not available for controller attributes.

Figure 5: Controller attributes
Controller Events
Component controller and custom controllers can raise events which may be
handled by event handler methods defined in other controllers. Subscribing an
event handler method to an event can be performed statically at design time or
dynamically at runtime. An event handler method can belong to any controller
located in the same component or even in another component. Exporting
parameters related to the controller events allow to pass data to the handler method.
Figure 6: Controller events

Component Reuse
Web Dynpro components are reusable modules. This allows to build Web Dynpro
applications that consist of different components. From within a component,
an interface enables you to use the data and functions of another component.
Creating generic components is meaningful since they may be used by different
developers in different contexts.
Figure 7: Component interface
Preparing Component Reuse

To be able to use any component from another (consumer) component, the
consumer component has to declare a usage of this component.

Figure 8: Declaring the usage of a component
Next, the component usage has to be instantiated. Technically, this can be done
from any method of any controller belonging to the consumer component. As a
prerequisite, the name of the component usage has to be entered in the list of used
components/controllers that can be found on the Properties tab of the controller.

Figure 9: Instantiating a component usage
Embedding Interface Views

Having instantiated the component usage, any interface view of the component
usage may be embedded in a window of the consumer component. Navigation
links between inbound and outbound plugs that belong to embedded views or
embedded interface views can be created.

Figure 10: Embedding interface views
Accessing the Interface Controller of a Component Usage

To be able to access the functionality of a component usage from a controller of
the consumer component, this controller has to declare the usage of the component
usage's interface controller. Then, methods, events and context nodes visible in
the interface controller of the component usage can be accessed by the controller
in the consumer component.

Figure 11: Calling methods defined in the interface controller
Figure 12: Accessing the interface controller of a component usage

Figure 13: Handling events fired in the interface controller
Figure 14: Handling event fired in component usage

Cross Component Context Mapping

There are two possibilities to define the mapping between the context node in
the interface controller and an appropriate context node in a controller of the
consumer component:
Normal context mapping:
If the used component has its data stored in a context node defined in the interface
controller, each controller of the consumer component may map this context node.
To do so, the controller of the consumer component has to declare the interface
controller of the component usage as a used controller. The context structure can
be copied and the context node can be mapped as if the interface controller was
a controller of the same component (drag & drop).
Figure 15: Normal context mapping: Principle

Figure 16: Normal context mapping: Realization
External context mapping:

More often, data stored in the component controller or a custom controller of
the consumer component has to be accessed by the component usage (e.g.
usage of SAP List Viewer component). In this case, the interface controller of
the component usage has to map a context node located in a controller of the
consumer component. However, it is not possible to change the functionality of
the interface controller of a component usage. Thus, the context nodes of the
used component have to be defined in a very generic manner to allow reusing
the component in different contexts (e.g. display arbitrary tables by the SAP
List Viewer component). To define the context mapping between the interface
controller of a certain component usage and the controller of the consumer
component keeping the data, the interface controller of the component usage has
to be edited (see drawing below). Next the controller containing the context node
to be mapped has to be declared as a used controller for the interface controller
usage. Finally the context mapping between the controllers can be established.

Figure 17: External context mapping: Principle
Figure 18: External context mapping: Realization (1)

Figure 19: External context mapping: Realization (2)

Phase Model
Component reuse has a significant impact on the phase model. The hook
methods of the main component controllers and the hook methods of the direct
sub component controllers are processed in a sequence that can be described as
follows:
First, the action handling is conducted:
The WDDOBEFOREACTION( ) method is processed for all views
being part of the last view assembly.
The action handler ONACTION<ACTION>( ) is processed.
The WDDOAFTERACTION( ) method is processed for all views being
part of the last view assembly.
Next, the component controller method WDDOBEFORENAVIGATION( ) is
processed for all components instantiated so far.
Now the rendering of the next view assembly takes place.
For all controllers not instantiated so far, controller objects will be
created (method WDDOINIT( ) ).
The inbound plug handler methods (method HANDLE<PLUG>( ) )
will be processed according to the outbound plugs that have been fired
and the navigation links related to these plugs.
The WDDOMODIFYVIEW( ) method is processed for all views being
part of the next view assembly.
Finally, the component controller method WDDOPOSTPROCESSING( ) is
processed for all components instantiated so far.

Figure 20: Component reuse - phase model
Adaptation
There are three techniques available to adapt Web Dynpro applications:
Configuration, customizing, and personalization. Intrinsically, all concepts allow
to change predefined property values of UI elements used in any of the views of
this component. However, these concepts can be extended to allow all changes
that are guided by changing the values of context attributes.
Configuration is performed by a developer. First, at least one component
configuration has to be created for every Web Dynpro component that has to be
adapted.
At runtime, one component configuration can be loaded for each component in
order to adapt this component. It is possible to load the component configuration
data programmatically. However, it is also possible to define statically which
component configuration is used for which component. This assignment is defined
by an application configuration. Application configurations have to be created by
a developer.
Configuration takes place at design time. This kind of application adjustment
is visible for everybody in the system.
In contrast to configuration, personalization is a function that is available to
the user of an application and provides him or her with the option of adjusting
the application to suit his or her own personal requirements or preferences. The
framework for variation options within personalization is less far-reaching than

that in configuration; personal settings in the UI must never limit the running
ability of an application. Personalization of an application is performed directly
by a user from within the current application.
It is possible to maintain application settings in a uniform manner for all users
working in the same client (customizing or user-independent personalization).
A system administrator can process personalization settings on the basis of
his or her extended authorization, provided the respective application runs in
so-called configuration mode. Customizing allows to change a lot more settings
then personalization does.
Personalization and customizing are always executed at runtime of an application.
Adaptation Hierarchy
The concepts of configuration, customizing, and personalization can be combined
to define the final adaptation. Here, the changes defined by personalization
overwrite the changes defined by customizing, and customizing overwrites
the configuration adaptation. On the other side, the parameters available for
configuration can be set final so they cannot be changed using customizing or
personalization. Parameters available for customizing can be set final so they
cannot be changed using personalization.

Figure 21: Adaptation possibilities: Configuration, customizing, and

personalization
Hint: Customizing and personalizing is always related to the used

component configuration. That means, that for each component
configuration a separate customizing data set per client and a separate
personalization data set for every user may exist.
For this technical reason a default configuration data set exists for every
component. If customizing or personalization is applied to a component
that has not been configured yet, then the personalization / customizing
data sets are related to this default component configuration.
Implicit / Explicit Adaptation

Web Dynpro ABAP offers configuration, customizing, and personalization out of
the box. This means that adapting a Web Dynpro application is possible without
any programming effort. This kind of adaptation is called implicit adaptation.
If the possibility provided by the implicit adaptation techniques are not sufficient,
these concepts can be extended. This means, that additional adaptation
possibilities can be planned by the developer of the component.

Figure 22: Implicit / explicit adaptation of Web Dynpro components
Technically, the developer has to define a data interface that can be used
to pass adaptable data values to the component when instantiating it. This
concept is called explicit adaptation and can be implemented by configuration,
customizing and personalization. The data interface is the context of a special
custom controller (configuration controller) that is instantiated even before the
component controller of the related Web Dynpro component is instantiated. The
Web Dynpro framework reads the adapted data values and fills the context of the
configuration controller automatically when instantiating the related component.
Thus, the adapted data values are loaded before the first hook method of any other
controller defined in this component is processed. All other controllers can access
the adaptation data by mapping the corresponding nodes of the configuration
controller.
The developer has to decide which attributes should be defined in the configuration
controller and how changing these attributes will influence the functionality and
the UI of this component.

The single steps of creating a configuration controller are as follows:

First a new custom controller has to be created. The context of the custom
controller has to contain all attributes that should be adaptable by explicit
adaptation.
The related context nodes of the custom controller have to be mapped to all
controllers that need to access the attribute values at runtime. The source
code acting on the attribute values has to be defined or the attributes can be
bound directly to properties of UI elements.
In order to make the custom controller attributes accessible by configuration,
customizing, or personalization, the custom controller has to be declared as
the component's configuration controller. This is done from the context menu
of the custom controller ((Re)Set as Config. Controller).
Hint: Only one configuration controller may exist for each Web Dynpro
component.
Configuration
Configuration is a concept that lets the developer create configuration data sets
containing values for UI element properties or context attributes (typically bound
to UI element properties). This allows to overwrite many of the statically defined
UI element properties, resulting in a different look and feel of the application
(UI elements may be set to invisible, tables may have an alternating row color,
and so on).
Configuration data sets are related to components or they are related to
applications. Component configurations allow you to change properties of
UI elements defined in any view of a single component. For each component,
an arbitrary number of component configurations can be defined. Application
configurations are bound to Web Dynpro applications. They define which
component configuration is used for which component in this application. For
each application, an arbitrary number of application configurations can be created.
Application changes related to configuration affect every user of this application
in every client.

Figure 23: Configuration: Concept
Defining a Component Configuration

Defining a component configuration is started from the context menu
of the related Web Dynpro component (Create/Change Configuration).
The configuration tool is implemented by the Web Dynpro application
CONFIGURE_COMPONENT.

Figure 24: Creating / changing a component configuration (1)
Figure 25: Creating / changing a component configuration (2)

Figure 26: Explicit component configuration
Hint: Properties that are configured may be overwritten by customizing /

personalization (if they are not set final).

The single steps of creating a new component configuration are as follows:

1. On the first screen, enter the id of the component configuration to be created.
This id has to be unique (not only in respect to the component it is created
for but in respect to all Web Dynpro components).
Caution: In a customer system, you may only choose names in the

customer name space (beginning with Z or Y).
2. Click on the button having the text Create. This will open a dialog box.
Enter a description and a package name and click on the OK button.
3. A new dialog box appears. Enter the transport task the component
configuration is to be assigned to and click on the OK button. If the
component configuration is defined as a local object, this dialog box will
not appear.
4. Now a new screen is displayed. A tab strip allows to display the
administrative information related to the component configuration on the
first tab.
5. The second tab labeled Component-Defined can only be selected if a
configuration controller exists for this component. In this case, the values
of all attributes defined in the context of the configuration controller can be
changed on this tab (explicit configuration).
6. On the tab labeled Web Dynpro Built-In, all views are displayed by a table. If
a view is marked, the UI element hierarchy of this view will be displayed.
Choose any UI element you want to manipulate (implicit configuration).
Change the property values and set the Final flag if you do not want this
property to be changed by customizing or by personalization.
7. Click on the button with the text Save. This will store the configuration data
set on the data base.
8. Close the browser. In the ABAP Workbench, refresh the object list. The
component configuration can be found as a sub-element of the Web Dynpro
component.
Using the same configuration tool, existing component configurations can be
displayed, changed, deleted, copied, renamed or they may be assigned to another
Web Dynpro component.
Hint: Existing component configuration data sets for any component

can be displayed or deleted using the Web Dynpro application
WD_ANALYZE_CONFIG_COMP. In addition, this application displays
the explicit and implicit configuration data.

Defining an application configuration is started from the context menu

of an existing Web Dynpro application (Create/Change Configuration).
The configuration tool is also implemented by a Web Dynpro application
(CONFIGURE_APPLICATION). The single steps of creating an application
configuration are as follows:
Figure 27: Creating / changing an application configuration (1)


Figure 28: Creating / changing an application configuration (2)
1. On the first screen, enter the id of the application configuration to be created.

This id has to be unique (not only in respect to the application it is created
for but in respect to all Web Dynpro applications).
Caution: In a customer system, you may only choose names in the

customer name space (beginning with Z or Y).
2. Click on the button having the text Create. This will open a dialog box.
Enter a description and a package name and click on the OK button.
3. A new dialog box appears. Enter the transport task the application
configuration is to be assigned to and click on the OK button. If the
application configuration is defined as a local object, this dialog box will
not appear.
4. On the next screen, a tab strip allows to display the administrative
information related to the application configuration (first tab).
5. In the second tab labeled Structure the main component and all statically
defined component usages are displayed by a table. Use the value help
related to the column Configuration to define which component configuration
is to be loaded for which component (usage).
6. Application parameters can also be adapted by an application configuration.
On the third tab labeled Application Parameters all application parameters
are listed and their values can be modified.
7. Finally, click the Save button. This will save the application configuration
on the data base.
8. Close the browser. In the ABAP Workbench, refresh the object list. The
application configuration can be found as a sub-element of the Web Dynpro
application.
Using the same configuration tool, existing application configurations can be
displayed, changed, deleted, copied, renamed, or they may be assigned to another
Web Dynpro application.
Hint: Existing application configuration data sets can be

displayed, changed, or deleted using the Web Dynpro application
WD_ANALYZE_CONFIG_APPL. In addition, this application displays
the application configuration data.
Implicit Customizing / Personalization

To start customizing, the Web Dynpro application has to be started having added
the query string sap-config-mode=X to the URL. If the right mouse button is
clicked anywhere in on the browser page and the authorization of the actual user
is sufficient (authorization for object S_DEVELOP or at least authorization for

object S_WDR_P13N is assigned to user), then a context menu pops up having

the entry Settings for Current Configuration. If this menu item is selected, the
dialog for customizing the actual view is started (implicit options only). All UI
element that are defined in this view can be selected in a tree that reflects the UI
element hierarchy of this view. For each UI element the values of a predefined
set of properties can be altered and saved. Elements (or element properties)
that are excluded from customizing by the underlying configuration are not
available. Selecting the Final check box for any property excludes this property
from personalization.
Every user starting the application in the same client and with the same underlying
configuration will now see the customized version.
Hint: If a user has changed a customized UI element property via

personalization and this property is not excluded from personalization via
customizing (flag final), then the personalized version of this property is
used at runtime.
Figure 29: Implicit customizing: Dialog

Personalization of a Web Dynpro application (started without the query string

sap-config-mode=X) is performed by positioning the mouse cursor on any UI
element followed by clicking the right mouse button. The context menu that
pops up has an entry User Settings. Clicking this entry will bring up a submenu.
The following functionality is offered:
The UI element the user has clicked on can be hidden.
Editable form fields: The access key can be activated / deactivated. If the
access key is activated, the first character (FC) of the label related to this
form field will be underlined. If the user presses the key combination ALT +
FC on the keyboard, the cursor will be positioned in the form field and the
form field will get the focus.
Editable input fields: The actual value can be saved as the new default
value. Default values defined this way can be deleted again by selecting the
corresponding entry in the submenu.
The entry More... displays all personalization options for this UI element
(for tables, there are more options). In addition, all personalization settings
for the entire application can be discarded.
In general, personalization settings are saved automatically (hiding columns of a
table from the More... dialog requires that the user clicks a Save button). Elements
(or element properties) that are excluded from personalization by customizing or
configuration are not available. The personalization data sets are user dependent.
Hint: The visibility of UI elements that have been hidden by

personalization can be restored by clicking the right mouse button
anywhere on the browser display. Choosing the menu entries User
Settings Invisible Elements in the context menu will open a submenu
with an entry for all invisible elements, respectively. Clicking on an entry
will restore the related UI element.
Hint: Customizing and personalization data sets can be displayed,

deleted, and transported using the Web Dynpro application
WD_ANALYZE_CONFIG_USER.
Hint: The possibility to start the personalization dialog from the

context menu displayed when the user right mouse clicks on a
UI element can be omitted by setting the application parameter
WDDISABLEUSERPERSONALIZATION to X.

Figure 30: Implicit Personalization: Dialog
Explicit Customizing / Personalization

Attributes defined in the configuration controller of a component are not available
automatically for customizing and personalization. The developer has to create
the dialog that will be used at runtime to access these attributes. This dialog can
be used for customizing and for personalization. If the application is started in
customizing mode (adding query string sap-config-mode=X to URL) the data
entered by the user will be saved as customizing data. If the application is started in
normal mode, the adaptation data will be saved user dependent (personalization).
Typically, the customizing / personalization dialog is implemented as a modal
dialog box that is send when the user of the application clicks on a certain UI
element (button, link).

Lesson Summary
You should now be able to:
configuration.

Lesson: Floorplan Manager - Overview
Lesson Overview
This lesson gives an overview over the Floorplan Manager (FPM) for Web
Dynpro ABAP. First, the advantages of using this framework is sketched. Next,
the different floorplans available in Web Dynpro ABAP are introduced. Finally,
the basic features of the floorplans Guided Activity Floorplan (GAF) and Object
Instance Floorplan (OIF) are summarized.
Lesson Objectives
the FPM framework
Business Example
You would like to know what floorplans are and how floorplans can be put into
practice when developing Web Dynpro ABAP applications.
Floorplans and Floorplan Manager (FPM) for Web

Dynpro ABAP
Floorplans are design templates for applications. Thus, using floorplans improves
the uniformity and the usability of applications.
In the Web Dynpro ABAP context, floorplans follow the SAP user interface design
standards. They are implemented as separate, highly configurable Web Dynpro
components that serve as main components in the WD application.
The Floorplan Manager (FPM) for Web Dynpro ABAP is a framework
consisting of these highly configurable Web Dynpro components and an editor
(Configuration Editor) that is used to configure these components. This allows
to combine multiple interface views of one or more Web Dynpro components to a
new Floorplan Manager application. In this context, an interface view of a Web
Dynpro component is referred to as a UI Building Block (UIBB).

NET313 Lesson: Floorplan Manager - Overview
Advantages of creating Web Dynpro Application

based on the FPM
Creating a Web Dynpro application based on the FPM has the following
advantages:
Using the FPM ensures that user interfaces behave the same way in all
applications.
The design of all cross-application entities of a user interface (e.g. toolbar
with toolbar buttons, page header, roadmap steps, or horizontal contextual
panel) is defined by the FPM.
The design follows the SAP user interface design guidelines.
Thus, users of such applications benefit from a high level of recognition,
which enables them to quickly and easily familiarize themselves with new
applications.
Time-consuming user interface programming is greatly reduced.
Simple applications are adjusted by configuring the underlying Web Dynpro
components and not by additional programming.
Adjustments that you make to the user interfaces of applications using the
FPM configuration editor are modification-free changes (FPM uses the Web
Dynpro adjustment concept).

Floorplans in Web Dynpro ABAP

The FPM allows to implement Web Dynpro ABAP applications which are based
on the following floorplans:
Object Instance Floorplan (OIF):

The OIF allows users to create, delete, view, and edit attributes and
associations of a business object (e.g. a purchase order). The OIF typically
shows multiple view tabs, whose content is determined by a defined business
object type and the distinctive tasks a user has to perform with those.
Quick Activity Floorplan (QAF):
The QAF allows the user to quickly perform a specific task. This can be
self-contained or a short sub-task within the context of a larger task (e.g. a
quick create). To implement a QAF in the FPM, use an OIF with only one
view tab and one sub view.
Guided Activity Floorplan (GAF):
The GAF is a floorplan for an activity that can be divided in a logical
sequence of steps. It consists of a series of screens that guide the user
through an activity to achieve a specific goal. A roadmap provides a visual
representation of the whole activity to the user. The GAF can be used to
create a business object regardless which floorplan is used to review and
edit this business object later.
Figure 31: Example: Object Instance Floorplan (OIF)

In the examples above, upper case letters mark different parts of the floorplan.
These are as follows:
A - Application title and window title:

The application title is configured as part of the identification region (IDR).
The window title is defined by the description of the WD application.
Application title and window title should contain the name of the business
object and the unique id of the business object. The order of these two parts
is switched between application and window title.
B - Extended identification Region (optional):
The extended identification region is part of the IDR. It displays relevant
information to identify the business object instance. It may contain the ticket
area (left of a separator line) and the items area (right of a separator line).
The ticket area can be configured, while the items area can only be accessed
programmatically.
C - Message Region:
In this region, messages are displayed.
D - Toolbar:
This mandatory part of the contextual navigation region (CNR) contains
action and navigation buttons. The order of the buttons (if used) is predefined.
E - View and Sub View:
Tabs and links related to each tab are used to switch between different
screens displayed by the OIF. The screen related to a link is called a sub
view. UIBBs are always related to sub views. The active sub view can be
set when the OIF is opened. The links and thus the related sub views can
also be hidden by default. Technically, an HorizontalContextualPanel UI
element is used to implement this navigation element.
F - Content Area:
This mandatory part consists of one or multiple UIBBs per sub view.
G - Bottom Toolbar (optional):
If vertical scrolling is necessary to reach all parts of the content area, a
bottom toolbar should be displayed.
In addition, the OIF may have an initial screen (used to collect missing parameters
when starting the application) and a confirmation screen.

Figure 32: Example: Quick Activity Floorplan (QAF)
The QAF is a specialization of the OIF. Thus this floorplan consists of the same
constituents as the OIF. However, the QAF does not display the horizontal
contextual panel, because only one sub view is defined.
In the drawing above, the content area is labeled with the letter E, while the
optional bottom toolbar is labeled with the letter F.
Figure 33: Example: Guided Activity Floorplan (GAF)

The GAF contains the following constituents:
A - Application title and window title:

The application title is configured as part of the identification region (IDR).
The window title is defined by the description of the WD application. Both
titles should clearly name the activity related to the process step.
B - Extended identification Region (optional):
The extended identification region is part of the IDR. It displays relevant
information to identify the actual step. It may contain the items area but no
ticket area. The content displayed by the items element may change from
one step to another. The items area need to be accessed programmatically.
C - Message Region:
In this region, messages are displayed.
D - Roadmap:
The roadmap element visualized the single steps involved in the activity.
The roadmap element may also contain sub-steps.
E - Toolbar:
This part of the contextual navigation region (CNR) contains action and
navigation buttons. The order of the buttons (if used) is predefined. Each
roadmap step may be assigned a different toolbar.
F - Content Area:
This mandatory part consists of one or multiple UIBBs per roadmap step.
G - Bottom Toolbar (optional):
If vertical scrolling is necessary to reach all parts of the content area, a
bottom toolbar should be displayed.
In addition, the GAF may have an initial screen (used to collect missing
parameters when starting the application) and a confirmation screen.

Architecture of Web Dynpro Applications based

on the FPM Framework
Web Dynpro application making use of the FPM framework are structured as
follows:
A Web Dynpro application allows to start the business application. This
application points on the FPM component being part of the FPM framework
delivered by SAP.
Depending on the floorplan to be implemented, the component
FPM_OIF_COMPONENT (OIF and QAF), or the component
FPM_GAF_COMPONENT (GAF) is used.
Both of these FPM components reuse the IDR component
FPM_IDR_COMPONENT statically. This component is used to define the
application title and the ticket area.
Each FPM component and the IDR component have a configuration
controller, containing numerousness context nodes and context attributes to
configure all variable parts of the applications. In particular, these explicit
configuration options allow to define which other components (and which
interface views of these sub components = UIBBs) are to be reused by the
FPM component.
Thus, a component configuration has to be created for the FPM component
in order to define the single roadmap steps (GAF) or the single tabs and sub
views (OIF) and the related UIBBs. In addition, the toolbar buttons, the
initial screen, and the confirmation screen are configured this way.
To create forms and lists, special highly configurable WD components
exist. These WD components are part of the FPM framework. They are
called Generic UI Building Blocks (GUIBBs). These UIBBs need to be
configured before they can be reused.
A component configuration is also used to configure the IDR component.
This allows to define the application title and the ticket area.
Finally, an application configuration defines which component configuration
is used for the FPM component and which component configuration is used
for the IDR component, respectively.

Figure 34: FPM based Web Dynpro ABAP applications: Architecture (1)
Figure 35: FPM based Web Dynpro ABAP applications: Architecture (2)

As described above, the FPM component serves as the main component in FPM
based WD applications. However, this component is part of the FPM framework
and can not be edited by the application developer. On the other side, it is
necessary for the FPM component to interact with its sub components. This
drawback can be overcome as follows:
All sub components related to the embedded UIBBs can implement the Web
Dynpro component interface IF_FPM_UI_BUILDING_BLOCK. At runtime, the
methods defined in the component interface are triggered by the FPM component
at predefined points of the phase model. Thus, the phase model of each sub
component is extended by the methods defined in the implemented component
interface.
Figure 36: Methods of the component interface IF_FPM_UI_BUILD-

ING_BLOCK

Figure 37: Phase model - UIBBs belong to same component
Figure 38: Phase model - UIBBs belong to different components

Figure 39: Phase model - differences between classical component reuse

and component reuse in FPM context
If classical component reuse and component reuse in the FPM context are
compared, the changes in respect to the phase model can be summarized as
follows:
The action handling is modified significantly since the corresponding
methods of the FPM component may not be edited.
For the components related to the last visible UIBBs, the methods
FLUSH( ), NEEDS_CONFIRMATION( ), and PROCESS_EVENT( )
are processed.
Then, the components related to the next visible UIBBs are instantiated.
This will also instantiate the corresponding component controllers.
Finally the method PROCESS_BEFORE_OUTPUT( ) is processed for
all UIBBs related to the next screen.
For details about the phase model modifications related to GUIBBs please refer to
the corresponding lesson in this handbook.
To share date and functionality between UIBBs that do not belong to the same
component, a simple global class can be used (Central Data Model). This class
has to be instantiated as a singleton by one of the sub components.

Exercise 1: Create Package and copy

template Components
Exercise Objectives
After completing this exercise, you will be able to:
Create components containing the UI Building Blocks (UIBBs) to be
embedded in your floorplans.
Implement the interface IF_FPM_UI_BUILDING_BLOCK by components
providing the UIBBs.
Business Example
You would like to create two WD components. These components will supply the
UIBBs that are embedded by the Floorplan Manager (FPM) component later on.
Template Components:
NET313_BOOKING_T
NET313_CUSTOMER_T
Solution Components:
NET313_BOOKING_S1
NET313_CUSTOMER_S1
Task 1:
Create a package that will contain all the Repository objects you are going to
develop.
1. Create the package ZNET313_## (replace ## by your group number).
Assign the application component BC-WD, the software component HOME,
and a short description.
A transport request has been created by your trainer.
Task 2:
Copy the template components. Store the copies in your package.
1. Copy the template component NET313_BOOKING_T. Name the copy
ZNET313_##_BOOKING_S1. Assign the package ZNET313_## and
a description (e.g. Cancel bookings) to your component. Activate your
component.
Continued on next page

2. Copy the template component NET313_CUSTOMER_T. Name the copy

ZNET313_##_CUSTOMER_S1. Assign the package ZNET313_## and a
description (e.g. Display / change customer) to your component.
Task 3:
Implement the interface IF_FPM_UI_BUILDING_BLOCK by both components
you have created in the last task.
1. Implement the interface IF_FPM_UI_BUILDING_BLOCK by your
component ZNET313_##_BOOKING_S1.
component ZNET313_##_CUSTOMER_S1.
Task 4:
Activate your components.
1. Activate the components ZNET313_##_BOOKING_S1 and
ZNET313_##_CUSTOMER_S1.
Task 5:
Start the template solutions to find out what you should develop in this class.
Check out the architecture of your components to identify the coding sections
needed to implement this solution.
1. Start the template solution for the booking scenario. Start the
application NET313_BOOKING_S5 using the application configuration
NET313_BOOKING_S5_AC1.
2. Take a look at the component controller methods of your component
ZNET313_##_BOOKING_S1. In addition check out the method
ONACTIONGET_CUSTOMER( ) of view CUSTOMER_VIEW.
3. Start the template solution for the booking scenario. Start the application
NET313_CUSTOMER_S6 using the application configuration
NET313_CUSTOMER_S6_AC1.
4. Take a look at the component controller methods of component

Solution 1: Create Package and copy

template Components
Task 1:
Create a package that will contain all the Repository objects you are going to
develop.
1. Create the package ZNET313_## (replace ## by your group number).
Assign the application component BC-WD, the software component HOME,
and a short description.
A transport request has been created by your trainer.
a) Perform this step like you (hopefully) have done often before.
Task 2:
Copy the template components. Store the copies in your package.
1. Copy the template component NET313_BOOKING_T. Name the copy
ZNET313_##_BOOKING_S1. Assign the package ZNET313_## and
a description (e.g. Cancel bookings) to your component. Activate your
component.
Hint: The template component is stored in package NET313.

Copying a WD component is conducted by selecting the item
Copy... from the component's context menu.
2. Copy the template component NET313_CUSTOMER_T. Name the copy

ZNET313_##_CUSTOMER_S1. Assign the package ZNET313_## and a
description (e.g. Display / change customer) to your component.
Hint: The template component is stored in package NET313.

Copying a WD component is conducted by selecting the item
Copy... from the component's context menu.

Task 3:
Implement the interface IF_FPM_UI_BUILDING_BLOCK by both components
you have created in the last task.
component ZNET313_##_BOOKING_S1.
a) Display your component ZNET313_##_BOOKING_S1 by double
clicking on the component's name in the object tree. Switch to the
edit mode.
b) Click on the tab labeled Implemented Interfaces.
c) Enter the interface name in the column labeled Name and confirm
your input.
d) Click the button labeled Reimplement which is displayed right of the
interface name. This will implement the interface methods.
component ZNET313_##_CUSTOMER_S1.
a) Repeat the last step for component ZNET313_##_CUSTOMER_S1.
Task 4:
Activate your components.
1. Activate the components ZNET313_##_BOOKING_S1 and
Task 5:
Start the template solutions to find out what you should develop in this class.
Check out the architecture of your components to identify the coding sections
needed to implement this solution.
1. Start the template solution for the booking scenario. Start the
application NET313_BOOKING_S5 using the application configuration
NET313_BOOKING_S5_AC1.
a) In the object tree of the Object Navigator, display the package NET313.
b) Open the branch Web Dynpro > Web Dynpro Applicat..
c) Open the branch related to the application NET313_BOOKING_S5
until the application configuration is displayed.
d) From the context menu of the application configuration choose Test.

2. Take a look at the component controller methods of your component

ZNET313_##_BOOKING_S1. In addition check out the method
ONACTIONGET_CUSTOMER( ) of view CUSTOMER_VIEW.
a) CANCEL_BOOKINGS( ) will be used to cancel selected bookings on
the data base table SBOOK.
CHECK_BOOKINGS_SELECTED( ) will be used to find out how
many bookings are selected by the user.
DEFINE_CUSTOMER_VS( ) is called from the method WDDOINIT( ).
It is used to define a fixed value list related to customers.
GET_BOOKINGS( ) will be used to read all bookings for selected
flights and a given customer.
GET_CUSTOMER( ) is called from the method WDDOINIT( ). It is
used to read customer details for a given customer number. At startup
the customer number equals '1' since the default value of the context
attribute CUSTOMER.ID is set accordingly.
GET_FLIGHTS( ) will be used to read all flights a given customer has
booked on.
GET_SELECTED_BOOKINGS( ) will be used to read all bookings
selected by the user from one context node and store these bookings
in another node.
SET_INTRO_TEXT( ) is called from the method WDDOINIT( ). It is
used to get a SAP Script text from the data base and display it on the
view INTRO_VIEW.
WDDOINIT( ) encapsulates to calls of the methods
DEFINE_CUSTOMER_VS( ), SET_INTRO_TEXT( ), and
GET_CUSTOMER( ).
ONACTIONGET_CUSTOMER( ). This view controller method is
processed if a new customer is selected via the drop down box defined
in the layout of this view. As a result, the component controller method
GET_CUSTOMER( ) is called to actualize the customer data.
Hint: All other methods of all other controllers do not contain

any code.

3. Start the template solution for the booking scenario. Start the application
NET313_CUSTOMER_S6 using the application configuration
NET313_CUSTOMER_S6_AC1.
a) In the object tree of the Object Navigator, display the package NET313.
b) Open the branch Web Dynpro > Web Dynpro Applicat..
c) Open the branch related to the application NET313_CUSTOMER_S6
until the application configuration is displayed.
d) From the context menu of the application configuration choose Test.
4. Take a look at the component controller methods of component
a) GET_BOOKINGS( ) will be used to read all bookings for a given
customer. Two internal tables containing cancelled bookings and
non-cancelled bookings are defined and bound to the context nodes
BOOKINGS_C and BOOKINGS_N, respectively.
GET_CUSTOMER( ) will be used to read customer details for a
given customer number. The default value of the context attribute
CUSTOMER_ID.ID is set to '1'.
SET_INTRO_TEXT( ) is called from the method WDDOINIT( ). It is
used to get a SAP Script text from the data base and display it on the
view INTRO_VIEW.
TOGGLE_EDIT_MODE( ) will be used to toggle the editability of form
fields for the form displaying customer details.
UPDATE_CUSTOMER( ) will be used to store the changes of customer
details on the data base.
WDDOINIT( ) encapsulated to call of the method SET_INTRO_TEXT(
). In addition, the controller attribute GO_CONTEXT is set. This
reference to the context object is used to access the context change log.
This log file contains all changes of context attribute values resulting
from a user input. This will be used to find out, if data needs to be
updated on the data base.
Hint: All other methods of all other controllers do not contain

any code.

Lesson Summary
the FPM framework

Unit Summary NET313
Unit Summary
configuration.
the FPM framework
Related Information
Additional information about FPM ABAP can be found in the SDN
discussion forum at https://www.sdn.sap.com/irj/scn/forum?forumID=296
Online help for the FPM ABAP can be found at http://help.sap.com. Open
the SAP NetWeaver 7.0 EhP1 documentation and enter the search term
Floorplan Manager for Web Dynpro ABAP.

Unit 2
Developing FPM Applications
Unit Overview
Developing FPM applications consists of the configuration of the underlaying
FPM components and of the development of source code sections to interact with
the FPM framework at runtime. This unit explains the configuration of the OIF,
the GAF, and the IDR component. In addition, basic programming techniques that
are needed to implement an FPM application are discussed.
Unit Objectives
Display UIBBs in floorplans of type OIF, QAF and GAF

Configure the IDR
Configure the toolbar
Configure the primary help
Configure initial screen and confirmation screen
Handle FPM-Events
Fire FPM-Events from the application source code
Access the FPM toolbar and the IDR at runtime
Use the FPM message manager
Unit Contents
Lesson: Configuring FPM Components....................................... 56
Exercise 2: Create FPM Applications..................................... 81
Exercise 3: Define Initial Screen and Confirmation Screen............ 91
Exercise 4: Configure Toolbar and Explanation Texts .................. 95
Lesson: FPM Programming - Basics .........................................100
Exercise 5: Implement Methods of FPM-Interface .....................123
Exercise 6: Access the Toolbar at Runtime .............................131
Exercise 7: Access the IDR at Runtime .................................135
Exercise 8: Use the FPM Message manager...........................147

Unit 2: Developing FPM Applications NET313
Lesson: Configuring FPM Components
Lesson Overview
This lesson deals with the configuration of FPM components. This includes a
discussion of the configuration editor for FPM components. The section about
configuring the IDR component includes the definition of application title an
ticket area. The section about configuring the OIF component and of the GAF
component includes the definition of the floorplans (embedding UIBBs), the
configuration of the toolbar, the configuration of explanation texts, and the
definition of initial and confirmation screen.
Lesson Objectives
Configure the IDR
Business Example
You know the architecture of Web Dynpro applications based on the FPM
framework. Now you would like to create your first applications. One application
should allow to display and edit details related to a flight customer. The second
application should permit the cancellation of bookings for a certain flight customer.
Definition of UI Building Blocks (UIBBs)

Before the configuration process of the FPM component can start, the UIBBs
have to be defined. Technically, each UIBB is the interface view of a component
which will be reused by the FPM component dynamically. An interface view
is the external view on the corresponding window of the component. Interface
views being used in the FPM context should only contain one view (or multiple
views making up one view assembly). Multiple UIBBs embedded by the FPM
component may origin from different windows of the same component or from
windows belonging to different components. UIBBs originating from different
windows of the same component can share their data via the common component
controller using standard context mapping. UIBBs originating from windows of
different components may share their data via a singleton instance of a global
class (central data model). This class may also encapsulate functionality used in
multiple components.

NET313 Lesson: Configuring FPM Components
Figure 40: Defining UIBBs
Creating simple FPM applications

The development process of an FPM application starts with the creation of a new
Web Dynpro application. This can be done in the Object Navigator by choosing
Create Web Dynpro Web Dynpro Application from the context menu of a
package. On the Properties screen of the application, set the parameters as follows:
Component = FPM_OIF_COMPONENT (for OIF or QAF)
Component = FPM_GAF_COMPONENT (for GAF)
Interface View = FPM_WINDOW
Plug Name = DEFAULT

Figure 41: Create FPM application
Next, an application configuration has to be created for the FPM application.

The creation process is started by choosing Create/Change Configuration from
the context menu of the FPM application. A browser window opens and the
application configuration editor is displayed.
On the first screen, you have to enter the name of the application configuration
in the field labeled Configuration ID. To create this application configuration
press the button labeled Create.
On the following popups, enter a description, the name of the package the
application configuration should be assigned to, and the key of the transport
request.

Figure 42: Create application configuration for FPM application (1)
Hint: The name of an application configuration is unique across all Web

Dynpro applications. Thus, you may construct the name of the application
configuration from the name of the FPM application (e.g. by adding a
suffix). This allows to find out easily which application configurations
belong to which WD application.
On the next screen, the main component (FPM_OIF_COMPONENT or

FPM_GAF_COMPONENT) and the statically assigned sub component
FPM_IDR_COMPONENT are displayed in a table. The last column allows to
assign a component configuration to each of these components. These component
configurations have not been created yet. However, enter the name of the
component configuration you would like to create later on in the corresponding
field.
Hint: The name of a component configuration is unique across all Web

Dynpro components. Thus, you may construct the name of the component
configuration from the name of the FPM application (e.g. by adding a
suffix). This allows to find out easily which component configurations
belong to which WD component.

In order to start the creation process of the component configurations for the FPM
component and for the IDR component, mark the corresponding table line and
click the button labeled Go to Component Configuration. This will open a new
browser window and the component configuration editor will be displayed.
Figure 43: Create application configuration for FPM application (2)
On the first screen, you have to enter the name of the component configuration
in the field labeled Configuration ID. To create this component configuration
press the button labeled Create.
On the following popups, enter a description, the name of the package the
component configuration should be assigned to, and the key of the transport
request.

Figure 44: Create component configuration for FPM or IDR component
The Configuration Editor for FPM components

After having finished the creation process of a component configuration, the
configuration editor is displayed. Via a drop down box (located on top of the page
and labeled with View) you can choose what part of the configuration data you
would like to display or edit. If you select Attributes, meta data of the component
configuration are displayed. If you select Web Dynpro Built In, then the implicit
configuration options can be edited. However, if you select Component Defined,
then the explicit configuration options are displayed.
For non FPM components, the context tree of the configuration controller is
displayed on the left side. If a context node is selected, a form is generated on
the right side of the view containing an editable field for each context attribute
belonging to the selected node. This way, the actual configuration data can be
displayed, edited, and saved again.
For the FPM components, the IDR component and the components related to
GUIBBs, the explicit configuration options are formatted differently. An improved
display allows to identify easily, which context attributes are related to which UI
elements. The result of adding context elements to context nodes or changing
attribute values is visualized in a WYSIWYG mode. In the following sections
the utilization of the configuration editor is described for FPM components and
for the IDR component.

Configuration editor for the OIF component

The screenshot below displays the UI of the configuration editor for the OIF
component FPM_OIF_COMPONENT. After having created a new component
configuration, only the main screen containing the horizontal contextual panel
with one tab and one link exists.
Figure 45: Configuration editor for the OIF component
Screen area 1:
An initial screen and a confirmation screen can be added (button Add) and deleted
again (button Delete). Multiple variants may be created. Each variant defines a
separate version of the main screen and of the confirmation screen. The concept of
configuration variants is well known from the SAP List Viewer for Web Dynpro
ABAP. Each configuration variant represents a complete set of configuration data.
At runtime, the application can decide which of the configuration variants is to
be used. The screen to configure is defined by selecting the corresponding radio
button and choosing the variant.
Screen area 2:
In the left lower corner, the single parts of the layout are represented by list entries.
On the first hierarchy level, an entry is displayed for each tab of the horizontal
contextual panel (main view). An additional entry represents the toolbar.
If a main view node is expanded, the dependent sub views related to the links are
displayed on the second hierarchy level. If a sub view node is expanded, the
UIBBs embedded by this sub view are displayed on the third hierarchy level.
UIBBs are always related to sub views. If only one sub view is defined, the related
link below the tab is not displayed at runtime. If only one main view and one sub
view is defined, the complete horizontal contextual panel is suppressed.

If the toolbar node is expanded, the toolbar elements are displayed on the second
hierarchy level.
Screen area 3:
To change the properties of any element displayed in the hierarchy, the
corresponding element has to be selected. This will also mark the table line. The
related attributes will be displayed below the preview in screen area 3 using
appropriate UI elements (e.g. check boxes, input fields, drop down boxes, tables).
Screen area 4:
This is the preview area. Toolbar and horizontal contextual panel are displayed as
they will appear at runtime. For the UIBBs, placeholders are displayed below the
horizontal contextual panel. The IDR is only displayed with a dummy title.
Screen area 5:
This area contains buttons which can be used to create new main views, new sub
views, new toolbar elements, or an explanation text. Moreover, additional UIBBs
can be embedded on a sub view.
Configuration editor for the GAF component

The screenshot below displays the UI of the configuration editor for the GAF
component FPM_GAF_COMPONENT. After having created a new component
configuration, only the main screen containing the roadmap element with one
main step exists.
Figure 46: Configuration editor for the GAF component
Screen area 1:

No changes in respect to the configuration editor for the OIF component.

Screen area 2:
On the first hierarchy level, an entry is displayed for each step of the roadmap
element. An additional entry represents the toolbar.
If a roadmap step node is expanded, the related UIBBs are displayed on the second
hierarchy level. Sub steps for a roadmap step are displayed as children of the main
step. The related UIBBs are displayed as children of the sub step.
If the toolbar is opened, the toolbar elements are displayed on the second hierarchy
level.
Screen area 3:
No changes in respect to the configuration editor for the OIF component.
Screen area 4:
In the preview area, the toolbar and the roadmap element are displayed as they will
appear at runtime. For the UIBBs, placeholders are displayed below the roadmap
element. The IDR is only displayed with a dummy title.
Screen area 5:
This area contains buttons which can be used to create new radmap steps, new sub
steps, new toolbar elements, or an explanation text. Moreover, additional UIBBs
can be embedded assigned to a main step or to a sub step of the roadmap element.
Configuration editor for the IDR component

The screenshot below displays the UI of the configuration editor for the IDR
component FPM_IDR_COMPONENT. After having created a new component
configuration, only the basic IDR exists, allowing to set the application title and
the title's tooltip.
Figure 47: Configuration editor for the IDR component

Screen area 1:
In the hierarchical view two elements may be displayed: An entry for the basic
IDR and an entry for the extended IDR.
Screen area 2:
To change the properties of the basic IDR or the extended IDR, the corresponding
element in the hierarchy has to be selected. This will also mark the table line.
The related attributes will be displayed below the preview in screen area 2 using
appropriate UI elements (e.g. check boxes, input fields).
Hint: The items area can only be accessed from the application's source
code.
Screen area 3:
In the preview area, the application title and the ticket element are displayed as
they will appear at runtime.
Screen area 4:
A button allows to add the extended IDR.
Embedding UI Building Blocks

In the following section, the basic configuration of the OIF and of the GAF
component is described in detail. This includes the definition of main views and
sub views (OIF), the definition of roadmap steps and sub steps (GAF), and the
assignment of UIBBs to the single sub views or roadmap elements, respectively.

Basic Configuration of the OIF Component

After having finished the creation process, a component configuration for the
OIF component contains only one main view and one sub view. As long as no
additional views are defined, the complete horizontal contextual panel will be
suppressed at runtime. This is the case if you would like to implement a QAF.
Use the buttons labeled Add Main View and Add Subview to add tabs and
links to the horizontal contextual panel, respectively.
Edit the attributes of the main views and the sub views: Assign a different
ID to each of the views and define the name to be displayed on the tabs
and links, respectively.
To assign a UIBB to a sub view, expand the corresponding node in the
hierarchy view and click on the dependent sub element labeled with UIBB:
.... This will display the explicit configuration options for the UIBB below
the preview area.
Enter the name of the component and the name of the interface view
(serving as the UIBB) in the fields Component and View, respectively. If
this component has been configured, you can also select the component
configuration to be used.
To assign additional UIBBs to a sub view, mark the sub view and click
on the button Add UIBB located on the right side of the screen. Edit the
attributes as described above.
Save your settings.
Figure 48: Basic configuration of the OIF component

Basic Configuration of the GAF Component

After having finished the creation process, a component configuration for
the GAF component contains only one main step.
Use the buttons labeled Add Mainstep and Add Substep to add the
corresponding roadmap elements.
Edit the attributes of the main steps and the sub steps: Assign a different
ID to each of the steps and define the name to be displayed below the
steps, respectively. You can also deactivate single steps by marking the
corresponding check box.
To assign a UIBB to a roadmap step, expand the corresponding node in the
hierarchy view and click on the dependent sub element labeled with UIBB:
.... This will display the explicit configuration options for the UIBB below
the preview area.
Enter the name of the component and the name of the interface view
(serving as the UIBB) in the fields Component and View, respectively. If
this component has been configured, you can also select the component
configuration to be used.
To assign additional UIBBs to a roadmap step, mark the step and click on the
button Add UIBB located on the right side of the screen. Edit the attributes as
described above.
Save your settings.
Figure 49: Basic configuration of the GAF component

Basic Configuration of the IDR Component

Click on the entry IDR Baisc in the hierarchy view to edit the application
title and the title's tooltip.
Use the button labeled Add IDR Extended to add the ticket area to the
IDR. This allows to add two lines (Ticket top / Ticket bottom) below the
application title.
Hint: The ticket area is not displayed if used with the GAF
component.
Hint: The ticket area can be accessed from the application's source
code. It is not necessary to configure the extended IDR statically to
be able to access this area at runtime.
Hint: The items area can only be accessed from the application's
source code.
Save your settings.
Figure 50: Basic configuration of the IDR component
Initial Screen and Confirmation Screen

Optionally, an initial screen and a confirmation screen can be added to the OIF
and to the GAF.
Initial screens are typically used to collect missing parameters to start an
application. In well-designed scenarios, those parameters are exposed to the user
as work lists in work centers, or as contextual navigation links in You Can Also
menus or What Do You Want To Do Next link lists. However, there are use cases
that do lead to the need for an initial screen.

An initial screen is added to a floorplan by clicking the button-choice Add and

selecting the Initial Screen menu item. The initial screen for the OIF already
embeds a UIBB, while the initial screen for the GAF is created without an
embedded UIBB. In both cases, UIBBs and toolbar elements can be added to the
initial screen by clicking on the corresponding button located on the right side of
the configuration editor screen.
Hint: Leaving the initial screen can also be triggered from the application.
Details can be found in the section Toolbar and FPM-Events
Figure 51: Initial screen
It is recommended that a GAF has a confirmation screen displayed as the last

step. The purpose of this confirmation step is threefold:
Provide a non-editable confirmation of the activity accomplished in the GAF
Provide success or other processing messages
Display a link list of typical follow-up applications

For the OIF, a confirmation screen should only be displayed if the object currently
processed by the application has been deleted. This can be triggered by clicking
the standard button Delete Object. As a result, the confirmation screen will be
displayed in place of the main screen.
Hint: Deleting the current object and thus navigating to the confirmation
screen can also be triggered from the application. Details can be found in
the section Toolbar and FPM-Events
A confirmation screen is added to a floorplan by clicking the button-choice Add

and selecting the Confirmation Screen menu item. The confirmation screen already
embeds a UIBB. Supplementary UIBBs can be added to the screen by clicking
on the corresponding button located on the right side of the configuration editor
screen. Toolbar buttons cannot be added.
Figure 52: Confirmation screen
Configure the Toolbar

The FPM toolbar contains a configurable set of standard and application specific
toolbar elements. These may be buttons, button-choices, or links. The sequence of
the standard toolbar elements and the location of the application defined toolbar
elements in respect to the standard elements is predefined. Only the sequence of
the application specific toolbar elements can chosen arbitrarily.

Depending on the floorplan and the screen (initial screen, main screen,
confirmation screen), different sets of standard toolbar elements are offered. The
confirmation screen toolbar only contains the Close button (and for the GAF the
navigation buttons). Additional toolbar elements cannot be defined on this screen.
The Close button can not be deleted for any of the screens. However, this button
can be hidden dynamically.
Hint: Some of the toolbar functions are offered as standard buttons and
as button-choices. If both toolbar elements are added to the toolbar, the
button-choice will be suppressed.
Hint: Application specific toolbar elements (Activation Function,

Alternate Function, Other Function) may be added to the toolbar multiple
times while standard toolbar elements may be added only once.
Hint: Toolbar elements of type Activation Function are displayed right

of the initial toolbar elements. They should be used to trigger the most
important application specific functions.
Toolbar elements of type Alternate Function are displayed right of the
elements of type Activation Function.
Toolbar elements of type Other Function are displayed right of all
standard toolbar elements (only the button Delete Object in the OIF
toolbar is displayed right of this button).
The Initial Screen Toolbar

The initial screen toolbars for the OIF and for the GAF are identical. By default,
these toolbars contains the Start and the Close button. None of these buttons can
be deleted. However, the Start button can be declared as the default button for
the initial screen of the OIF.

Figure 53: Initial screen toolbar
For all toolbar elements, the property Visibility can be set. In the following, the
element-specific attributes are listed for all toolbar elements:
Toolbar Elements
Element Explana- En- Tooltip Label Sequence FPM
tion abled Index EventID
Create X
Undo X
Redo X
Load Draft X
Save Draft X
Other X X X X X X
Function
Other X and X X and X per item
Function per item per
(Choice) item
The sequence index is used to define the sequence of the application defined
toolbar elements. Elements with a lower index are positioned left of elements with
a higher index. The FPM-Event ID attribute allows to define the value (ID) of
the FPM-Event for application defined toolbar elements. For further details about
handling FPM-Events, please refer to the next lesson.

The OIF Toolbar

By default, the OIF toolbar contains the Save and the Close button. The Close
button can not be configured. However, the Save button can be deleted or the
button's attributes (including the FPM-Event ID) can be altered.
Figure 54: Toolbar for OIF component
For all toolbar elements, the properties Visibility and Enabled can be set. In the
following, the element-specific attributes are listed for all toolbar elements:
Toolbar Buttons
Element Explana- Tooltip La- De- Ele- Se- FPM
tion bel fault ment quence Even-
ID Index tID
Previous X X X
Object
Next X X X
Object
Activa- X X X X X
tion Func-
tion

Alternate X X X X X
Function
Edit X X
Read X X
Only
Save As X
Save X
Draft
Load X
Draft
Print X
Preview
Print X
Send X
Start Over X
Refresh X
Undo X
Redo X
Check X X X X
New X
Other X X X X X X
Function
Delete X X X
Object
Toolbar Button-Choices
Element Tooltip Label En- Element Se- FPM
abled ID quence EventID
Index
Print per X and per item
Preview item per item
Print per X and per item
item per item

Send per X and pre item

item per item
New per X and per item
item per item
Other X X and X and X X per item
Function per per item
item
Sequence index and FPM-Event ID are explained in the section about the initial
screen toolbar. The element ID can be used to access the application defined
toolbar elements from the application's source code.
The GAF Toolbar

For each roadmap step, the toolbar may be configured differently. By default, the
GAF toolbar contains the Previous button, the Next button, and the Close button.
The Close button can not be configured. However, the Next button may be deleted
and it may be declared as the default button (property Default).
Final action:
If a confirmation screen is configured, a special FPM-Event ID and a
special label can be assigned to the Next button of the last main step.
If this button is clicked at runtime, the methods related to the interface
IF_FPM_UI_BUILDING_BLOCK are triggered twice. In the first cycle, the
FPM-Event ID related to the final action is fired. In the second cycle, the
standard event related to the Next button is fired.
Finish button:
This button can only be configured for a main step toolbar. If this button is
pressed, the roadmap is processed sequentially. This means navigation to the
next step is performed automatically as often as possible. This processing
will stop when the last main step is reached or when an error occurs.
Exit to Main Step button:
This button can only be configured for a sub step toolbar. If this button is
clicked, the navigation to the actual main step (which is related to this sub
step) will be performed.

Figure 55: Toolbar for GAF component
For all toolbar elements, the property Visibility can be set. In the following, the
element-specific attributes are listed for all toolbar elements:
Toolbar Elements
Element Explana- En- Tooltip La- Ele- Se- FPM
tion abled bel ment quence Even-
ID Index tID
Finish X X
Save X X
Draft
Other X X X X X X X
Function
Other X and X X X X per
Function per and item
(Choice) item per
item
Exit to X X
Main
Step

Sequence index, element ID, and FPM-Event ID are explained in the section
about the OIF toolbar.
Configure Explanation Texts

The FPM framework allows to assign explanation texts to the screens displayed to
the user (initial screen and main screen). The visibility of these texts can be toggled
from the context menu which is displayed, if the user right mouse clicks anywhere
on the screen (menu item Display Quick Help or Hide Quick Help, respectively).
For the OIF, explanation texts are related to the main views, for the GAF,
explanation texts are related to the single steps (main step or sub step). Each
explanation text may be a simple text or a SAP Script document defined by
transaction SE61 and being of document class General Text.
In order to assign explanation texts to a screen, edit the corresponding component
configuration. Select the main view (OIF) or step (GAF) in the hierarchy. Now
click on the button labeled Add Explanation. The explanation will then be
displayed in the hierarchy as a sub element of the main view (OIF) or step (GAF).
Now you can assign a simple text (field labeled Text) or a SAP Script document
(field labeled Docu. Object).
Figure 56: Defining explanations (1)

Figure 57: Defining explanations (2)
Figure 58: Using SAPScript texts as explanations

Figure 59: Display / hide explanations at runtime


Exercise 2: Create FPM Applications

Exercise Objectives
Create a WD application pointing on the FPM component FPM_OIF_COM-
PONENT or on the FPM component FPM_GAF_COMPONENT.
Define an Object Instance Floorplan (OIF) by assigning UIBBs to the sub
view via configuration.
Define a Guided Activity Floorplan (GAF) by assigning UIBBs to the
roadmap steps via configuration.
Business Example
You would like to create FPM applications embedding the interface views of your
components ZNET313_##_BOOKING_S1 and ZNET313_##_CUSTOMER_S1,
respectively. The UIBBs of your first component should define the screens of
a GAF, while the UIBBs related to your second component should define the
screens of an OIF.
Solution Applications:
NET313_BOOKING_S1
NET313_CUSTOMER_S1
Solution Application Configurations:
NET313_BOOKING_S1_AC1
NET313_CUSTOMER_S1_AC1
Solution Component Configurations:
NET313_BOOKING_S1_CC1
NET313_BOOKING_S1_IDR
NET313_CUSTOMER_S1_CC1
NET313_CUSTOMER_S1_IDR
Task 1:
Create an application pointing on the FPM component FPM_OIF_COMPONENT.
Name this application ZNET313_##_CUSTOMER_S1.
Create a second application pointing on the FPM component
FPM_GAF_COMPONENT. Name this application ZNET313_##_BOOKING_S1
1. Create an application pointing on the FPM component FPM_OIF_COMPO-
NENT. Name this application ZNET313_##_CUSTOMER_S1.

2. Create an application pointing on the FPM component FPM_GAF_COMPO-

NENT. Name this application ZNET313_##_BOOKING_S1.
Task 2:
For each of the applications, create an application configuration having the name
of the component plus a suffix _AC1.
1. For the application ZNET313_##_CUSTOMER_S1, create the application
configuration ZNET313_##_CUSTOMER_S1_AC1.
2. For the application ZNET313_##_BOOKING_S1, create the application
configuration ZNET313_##_BOOKING_S1_AC1.
Task 3:
For each of the application configurations define, which component configuration
is used to configure the FPM component and the IDR component, respectively.
The name of the FPM component configuration should equal the application name
plus the suffix _CC1. The name of the IDR component configuration should equal
the application name plus the suffix _IDR. Create the component configurations.
1. For the application configuration ZNET313_##_CUSTOMER_S1_AC1,
assign a component configuration to each of the components. Name the
component configurations ZNET313_##_CUSTOMER_S1_CC1 and
ZNET313_##_CUSTOMER_S1_IDR, respectively.
2. Create the component configurations.
3. For the application configuration ZNET313_##_BOOKING_S1_AC1,
assign a component configuration to each of the components. Name
the component configurations ZNET313_##_BOOKING_S1_CC1 and
ZNET313_##_BOOKING_S1_IDR, respectively.
Task 4:
The OIF should display UIBBs related to component ZNET313_##_CUS-
TOMER_S1. On the first tab, the interface view CUSTOMER_WINDOW
(customer details) should be displayed. The second tab should display two sub
views. On the first sub view, the interface view BOOKINGS_N_WINDOW
(non-cancelled bookings) should be embedded, while on the second sub view the
interface view BOOKINGS_C_WINDOW (cancelled bookings) is to be displayed.
1. Edit the component configuration ZNET313_##_CUSTOMER_S1_CC1.

2. Define an OIF consisting of two tabs and (on the second tab) two sub views.
Display the texts Customer (first tab), Bookings (second tab), not cancelled
(first link related to second tab), and cancelled (second link related to second
tab).
3. Assign the UIBBs to the sub views.
Task 5:
The GAF should display UIBBs of component ZNET313_##_BOOKING_S1. The
first roadmap step should be related to the interface view CUSTOMER_WINDOW
(customer details). The next main steps should display related flights (IF
FLIGHTS_WINDOW), bookings (IF BOOKINGS_WINDOW), and again the
bookings selected by the user (IF CHECK_WINDOW).
1. Edit the component configuration ZNET313_##_BOOKING_S1_CC1.
2. Define a roadmap consisting of four roadmap steps. Display the texts Select
customer (first step), Select flights (second step), Select bookings (third step),
and Check data (last step).
3. Assign the UIBBs to the roadmap steps.
Task 6:
The IDR of the OIF application should display the application title NET313:
Customer details, while the IDR of the GAF application should display the text
NET313: Cancel bookings.
1. Define the IDR of the OIF application.
2. Define the IDR of the GAF application.
Task 7:
Test your FPM applications.
1. Start the FPM application displaying the OIF.
2. Start the FPM application displaying the GAF.

Solution 2: Create FPM Applications

Task 1:
Create an application pointing on the FPM component FPM_OIF_COMPONENT.
Name this application ZNET313_##_CUSTOMER_S1.
Create a second application pointing on the FPM component
FPM_GAF_COMPONENT. Name this application ZNET313_##_BOOKING_S1
1. Create an application pointing on the FPM component FPM_OIF_COMPO-
NENT. Name this application ZNET313_##_CUSTOMER_S1.
a) From the context menu of the branch ZNET313_## > Web Dynpro
select the menu item Create > Web Dynpro Application.
b) Enter the name of the application (ZNET313_##_CUSTOMER_S1) and
a description (e.g. Display / change customer). Click Enter.
c) Enter FPM_OIF_COMPONENT in the field labeled Component.
Enter FPM_WINDOW in the field labeled Interface View.
Enter DEFAULT in the field labeled Plug Name.
Save.
2. Create an application pointing on the FPM component FPM_GAF_COMPO-
NENT. Name this application ZNET313_##_BOOKING_S1.
a) Proceed as described in the last step. However, enter
FPM_GAF_COMPONENT in the field labeled Component.
Task 2:
For each of the applications, create an application configuration having the name
of the component plus a suffix _AC1.
1. For the application ZNET313_##_CUSTOMER_S1, create the application
configuration ZNET313_##_CUSTOMER_S1_AC1.
a) From the context menu of the application, choose Create / Change
Configuration.
b) In the browser application, enter ZNET313_##_CUSTOMER_S1_AC1
in the field labeled Configuration ID. Click the button labeled Create.
c) In the following popup, enter a description (e.g. Display / change
customer) and the package name ZNET313_##. Click OK.
d) On the next popup confirm the transport request number and click OK.

2. For the application ZNET313_##_BOOKING_S1, create the application

configuration ZNET313_##_BOOKING_S1_AC1.
a) Proceed as described in the previous step.
Task 3:
For each of the application configurations define, which component configuration
is used to configure the FPM component and the IDR component, respectively.
The name of the FPM component configuration should equal the application name
plus the suffix _CC1. The name of the IDR component configuration should equal
the application name plus the suffix _IDR. Create the component configurations.
1. For the application configuration ZNET313_##_CUSTOMER_S1_AC1,
assign a component configuration to each of the components. Name the
component configurations ZNET313_##_CUSTOMER_S1_CC1 and
ZNET313_##_CUSTOMER_S1_IDR, respectively.
a) Edit your application configuration. Double clicking the application
configuration in the object tree of transaction SE80 will display the
item in the object area. Clicking the button Start Configurator will
open the browser based application configuration editor.
b) In the browser application click the button labeled Change.
c) Enter ZNET313_##_CUSTOMER_S1_CC1 in the column labeled
Configuration for the component FPM_OIF_COMPONENT.
d) Enter ZNET313_##_CUSTOMER_S1_IDR in the column labeled
Configuration for the component FPM_IDR_COMPONENT.
e) Save (ignore the warnings).
a) Mark the first line of the table and click on the button labeled Go to
Component Configuration. This will open the component configuration
editor.
b) Click on the button labeled Create. On the following popups enter a
description and the package ZNET313_## and confirm the transport
request number.
c) Go back to your application configuration. Mark the second line of the
table and click on the button labeled Go to Component Configuration.
d) Click on the button labeled Create. On the following popups enter a
description and the package ZNET313_## and confirm the transport
request number.

3. For the application configuration ZNET313_##_BOOKING_S1_AC1,

assign a component configuration to each of the components. Name
the component configurations ZNET313_##_BOOKING_S1_CC1 and
ZNET313_##_BOOKING_S1_IDR, respectively.
a) Proceed as described in the first step of this task.
a) Proceed as described in the second step of this task.
Task 4:
The OIF should display UIBBs related to component ZNET313_##_CUS-
TOMER_S1. On the first tab, the interface view CUSTOMER_WINDOW
(customer details) should be displayed. The second tab should display two sub
views. On the first sub view, the interface view BOOKINGS_N_WINDOW
(non-cancelled bookings) should be embedded, while on the second sub view the
interface view BOOKINGS_C_WINDOW (cancelled bookings) is to be displayed.
1. Edit the component configuration ZNET313_##_CUSTOMER_S1_CC1.
a) Double click the corresponding item in the object tree of the Object
Navigator. This will display the configuration's meta data in the object
area.
b) Click on the button labeled Start Configurator. This will open the
component configuration editor.
c) Click the button Change in the component configuration editor.

2. Define an OIF consisting of two tabs and (on the second tab) two sub views.
Display the texts Customer (first tab), Bookings (second tab), not cancelled
(first link related to second tab), and cancelled (second link related to second
tab).
a) Click on the button labeled Add Main View in order to define a second
tab.
b) Mark the second tab in the hierarchy.
c) Click the button labeled Add Subview. This will add a second sub view
to the second tab.
d) Mark the first tab. The attributes related to this tab will be displayed
below the preview area.
e) Enter the text Customer in the field labeled Mainview name.
f) Mark the second tab.
g) Enter the text Bookings in the field labeled Mainview name.
h) Mark the first sub view related to the Bookings tab.
i) Enter the text not cancelled in the field labeled Subview name.
j) Mark the second sub view related to the Bookings tab.
k) Enter the text cancelled in the field labeled Subview name.
3. Assign the UIBBs to the sub views.
a) Mark the first tab.
b) Click the button Attributes displayed in the preview area.
c) Enter ZNET313_##_CUSTOMER_S1 in the field labeled Component
and CUSTOMER_WINDOW in the field labeled View.
d) Mark the sub view related to non-cancelled bookings.
e) Click the button Attributes displayed in the preview area.
f) Enter ZNET313_##_CUSTOMER_S1 in the field labeled Component
and BOOKINGS_N_WINDOW in the field labeled View.
g) Mark the sub view related to cancelled bookings.
h) Click the button Attributes displayed in the preview area.
i) Enter ZNET313_##_CUSTOMER_S1 in the field labeled Component
and BOOKINGS_C_WINDOW in the field labeled View.
j) Save your changes.

Task 5:
The GAF should display UIBBs of component ZNET313_##_BOOKING_S1. The
first roadmap step should be related to the interface view CUSTOMER_WINDOW
(customer details). The next main steps should display related flights (IF
FLIGHTS_WINDOW), bookings (IF BOOKINGS_WINDOW), and again the
bookings selected by the user (IF CHECK_WINDOW).
1. Edit the component configuration ZNET313_##_BOOKING_S1_CC1.
a) Proceed as described in the last task.
2. Define a roadmap consisting of four roadmap steps. Display the texts Select
customer (first step), Select flights (second step), Select bookings (third step),
and Check data (last step).
a) Click three times on the button labeled Add Main Step in order to define
three additional roadmap steps.
b) Mark each roadmap step in the hierarchy in order to edit its attributes.
c) For each roadmap step, enter the name to be displayed in the field
labeled Mainstep name.
3. Assign the UIBBs to the roadmap steps.
a) Mark the first roadmap step.
b) Click the button Attributes displayed in the preview area.
c) Enter ZNET313_##_BOOKING_S1 in the field labeled Component and
CUSTOMER_WINDOW in the field labeled View.
d) Repeat this procedure for the second roadmap step (FLIGHTS_WIN-
DOW), the third roadmap step (BOOKINGS_WINDOW), and the last
roadmap step (CHECK_WINDOW).
e) Save your changes.

Task 6:
The IDR of the OIF application should display the application title NET313:
Customer details, while the IDR of the GAF application should display the text
NET313: Cancel bookings.
1. Define the IDR of the OIF application.
a) Edit the IDR component configuration ZNET313_##_CUS-
TOMER_S1_IDR used in the application configuration
ZNET313_##_CUSTOMER_S1_AC1.
b) Select the item IDR Basic in the hierarchy.
c) Enter the application title in the field labeled Application title.
d) Save.
2. Define the IDR of the GAF application.
a) Edit the IDR component configuration ZNET313_##_BOOK-
ING_S1_IDR used in the application configuration
ZNET313_##_BOOKING_S1_AC1.
b) Select the item IDR Basic in the hierarchy.
c) Enter the application title in the field labeled Application title.
d) Save.
Task 7:
a) From the context menu of your application configuration
ZNET313_##_CUSTOMER_S1_AC1, select Test to start the related
FPM application.
ZNET313_##_BOOKING_S1_AC1, select Test to start the related FPM
application.


Exercise 3: Define Initial Screen and

Confirmation Screen
Exercise Objectives
Add an initial screen to the OIF and to the GAF.
Add a confirmation screen to the GAF.
Business Example
You would like to add initial screens to both of your FPM applications and a
confirmation screen to your FPM application implementing a GAF.
Solution Component Configurations:
Task 1:
For both FPM applications add an initial screen to the floorplan. Embed the UIBB
INTRO_WINDOW available in both of your WD components.
1. Add an initial screen to your FPM application ZNET313_##_BOOKING_S1.
2. Add an initial screen to your FPM application ZNET313_##_CUSTOMER_S1.
Task 2:
For the GAF application, add a confirmation screen to the floorplan. This
confirmation screen should display the interface view CONFIRMATION_WINDOW
of the component ZNET313_##_BOOKING_S1.
1. Add the confirmation screen to your GAF application.
Task 3:

Solution 3: Define Initial Screen and

Confirmation Screen
Task 1:
For both FPM applications add an initial screen to the floorplan. Embed the UIBB
INTRO_WINDOW available in both of your WD components.
1. Add an initial screen to your FPM application ZNET313_##_BOOKING_S1.
a) Display your component configuration ZNET313_##_BOOK-
ING_S1_CC1 by the component configuration editor.
b) Click the button Change.
c) On the next screen, click the button choice Add located above the
hierarchy. Select the item Initial Screen. This will mark the radio button
labeled Initial Screen in the radio button group above the button choice.
d) Click the button labeled Add UIBB to add a UIBB to the initial screen.
e) Edit the attributes of the UIBB. Set Component = ZNET313_##_BOOK-
ING_S1 and View = INTRO_WINDOW
f) Save.
2. Add an initial screen to your FPM application ZNET313_##_CUSTOMER_S1.
a) Proceed as described in the last step of this task.
b) The component configuration to edit has the name ZNET313_##_CUS-
TOMER_S1_CC1.
c) You do not need to assign an extra UIBB to the initial screen.
d) The interface view INTRO_WINDOW you have to embed is related to
the component ZNET313_##_CUSTOMER_S1.
e) Save.

Task 2:
For the GAF application, add a confirmation screen to the floorplan. This
confirmation screen should display the interface view CONFIRMATION_WINDOW
of the component ZNET313_##_BOOKING_S1.
1. Add the confirmation screen to your GAF application.
ING_S1_CC1 by the configuration configuration editor.
c) On the next screen, click the button choice Add located above the
hierarchy. Select the item Confirmation Screen. This will mark the
radio button labeled Confirmation Screen in the radio button group
above the button choice.
d) Edit the attributes of the UIBB. Set Component = ZNET313_##_BOOK-
ING_S1 and Window = CONFIRMATION_WINDOW.
e) Save.
Task 3:
FPM application.
b) This application should display an initial screen but no confirmation
screen.
application.
b) This application should display an initial screen and (related to the last
roadmap step) the confirmation screen.


Exercise 4: Configure Toolbar and

Explanation Texts
Exercise Objectives
Configure the toolbar of FPM applications.
Configure explanation texts displayed with the UIBBs.
Business Example
You would like to adapt the toolbar of your FPM application via configuration. In
addition, you would like to display explanation texts on each screen displayed to
the user.
Solution Component Configurations::
Task 1:
Add a button to the toobar of the OIF application. This button will be used to
toggle the edit mode of the form fields displayed on the first tab (customer details).
Make sure that the toolbar is displayed above and below the tabs.
1. Add a button to the toolbar of the FPM application ZNET313_##_CUS-
TOMER_S1. This button should display the text Display/Change Customer.
In addition, choose FPM-Event ID = EDIT_TOGGLE and Element ID =
CUSTOMER_TOGGLE.
2. Make sure, that the toolbar is displayed above and below the tabs.
Task 2:
Add explanation texts to each roadmap step of your GAF application. The
explanation texts should describe what the user has to do on the related screen.
1. Add explanation texts to each roadmap step of the GAF application. Assign
texts to the attribute Text of each explanation element.
Task 3:

Hint: Explanation texts can be displayed or hidden from the context

menu (item Display Quick Help / Hide Quick Help, respectively).

Solution 4: Configure Toolbar and

Explanation Texts
Task 1:
Add a button to the toobar of the OIF application. This button will be used to
toggle the edit mode of the form fields displayed on the first tab (customer details).
Make sure that the toolbar is displayed above and below the tabs.
1. Add a button to the toolbar of the FPM application ZNET313_##_CUS-
TOMER_S1. This button should display the text Display/Change Customer.
In addition, choose FPM-Event ID = EDIT_TOGGLE and Element ID =
CUSTOMER_TOGGLE.
a) Display your component configuration ZNET313_##_CUS-
TOMER_S1_CC1 by the component configuration editor.
b) Click the button Change. This will start the component configuration
editor.
c) Click the button Add Toolbar Element. A dialog box will pop up.
d) Select a button of type Other Function.
e) Set Label = Display/Change customer, Button Design =
emphasized, FPMEventId = EDIT_TOGGLE, and Element ID =
CUSTOMER_TOGGLE.
f) Save.
2. Make sure, that the toolbar is displayed above and below the tabs.
a) Go on changing your component configuration ZNET313_##_CUS-
TOMER_S1_CC1.
b) Mark the toolbar element in the hierarchy.
c) Mark the check box labeled Duplicate toolbar.
d) Save.

Task 2:
Add explanation texts to each roadmap step of your GAF application. The
explanation texts should describe what the user has to do on the related screen.
1. Add explanation texts to each roadmap step of the GAF application. Assign
texts to the attribute Text of each explanation element.
ING_S1_CC1 by the component configuration editor.
c) On the next screen, mark the first roadmap step in the hierarchy. Click
the button Add Explanation to assign an explanation step to the first
roadmap step. Assign a meaningful text to the attribute Text of the
explanation element.
d) Repeat this procedure for all roadmap steps.
e) Save.
Task 3:
FPM application.
b) This application should now display an additional button in the toolbar.
Hint: Explanation texts can be displayed or hidden from the context

menu (item Display Quick Help / Hide Quick Help, respectively).

application.
b) Navigate to the screen displaying the customer form.
c) Display the explanation text by selecting Display Quick Help from the
right mouse menu.
d) Check the texts on the following screens.

Lesson Summary
Configure the IDR

Lesson: FPM Programming - Basics
Lesson Overview
This lesson discusses the basic FPM programming techniques. This includes
the handling of FPM-Events (triggered by clicking toolbar elements), the firing
of FPM-Events from the application source code, the manipulation of the
FPM toolbar at runtime, the activation of roadmap sub steps for the GAF, the
manipulation of the IDR, and the usage of the FPM message manager to send
messages.
Lesson Objectives
Handle FPM-Events
Business Example
You need to learn more about the FPM framework since you would like to react
on toolbar elements clicked by the user, and you would like to manipulate the
FPM toolbar and the page header at runtime. In addition you would like to send
messages using the FPM message manager.
Toolbar and FPM-Events

At runtime, clicking on a toolbar element will lead to a roundtrip. The FPM
component informs the UIBBs about the user action as follows:
All UIBBs have to implement the component interface IF_FPM_UI_BUILD-
ING_BLOCK. The methods contained by this interface and the signature of theses
methods are summarized in the following table.
Methods defined in the Interface IF_FPM_UI_BUILDING_BLOCK

Method IO_EVENT IT_INTER- addi-
FACE_VIEWS tional
Param-
eter
FLUSH X
NEEDS_CONFIRMATION X X X

NET313 Lesson: FPM Programming - Basics
PROCESS_EVENT X X X
AFTER_FAILED_EVENT X X X
PROCESS_BEFORE_OUT- X X
PUT
The signature of all methods contains the importing parameter

IT_INTERFACE_VIEWS. This parameter is an internal table having the line
type STRING. Each line contains the name of one interface view (UIBB). For
the first three methods listed above, the resulting list contains the names of all
UIBBs of the previous screen. For the method PROCESS_BEFORE_OUTPUT(
), this list contains the names of the UIBBs embedded by the next screen to be
displayed to the user.
All methods but the method FLUSH( ) contain the importing parameter
IO_EVENT being the reference to on object of class CL_FPM_EVENT. The FPM
component sets this importing parameter according to the toolbar element selected
by the user (FPM-Event). The public attribute IO_EVENT->MV_EVENT_ID
will then contain a text literal (FPM-Event) which can be used to identify the
toolbar element.
For application defined toolbar elements and for the menu button items, the
value of the FPM-Event has to be defined by the application. For the standard
toolbar elements of type button, the value of the FPM-Event is hard coded.
Corresponding constants can be found in the class CL_FPM_EVENT or in the
interface IF_FPM_CONSTANTS:
Toolbar element:
<TE> (e.g. SEND)
Value of IO_EVENT->MV_EVENT_ID (FPM-Event ID):
'FPM_<TE>' (e.g. 'FPM_SEND')
Constant containing this value:
CL_FPM_EVENT=>GC_EVENT_<TE> (e.g.
CL_FPM_EVENT=>GC_EVENT_SEND)
Exceptions from this Rule
START on the initial screen. Here the FPM-Event ID is set to
FPM_LEAVE_INITIAL_SCREEN.
DELETE OBJECT may be displayed in the OIF toolbar. Here the
FPM-Event ID is set to FPM_DELETE_CURRENT_OBJECT.

Most of the FPM-Events have to be handled by the application. Only the Start
button on the initial screen, the navigation buttons for the GAF component and
the Close button are handled by the FPM component.
Hint: The signature of some of the methods may contain an additional

parameter (see next section).

Reacting on FPM-Events
The methods provided by the interface IF_FPM_UI_BUILDING_BLOCK are
used in the following context:
FLUSH( ):
This method is triggered for all UIBBs that have been displayed on the
previous screen. In this method, data of different UIBBs may be transported
to a central data model. For UIBBs belonging to the same component,
context mapping is used to store the data in the common component
controller. In this case, this method is not used.
NEEDS_CONFIRMATION( ):
This method is processed directly after the method FLUSH( ) for
all UIBBs displayed on the previous screen . Each UIBB can
request a data-loss popup to be displayed. This can be triggered
from the source code of this method by evaluating the exporting
parameter EO_CONFIRMATION_REQUEST with the constant
CL_FPM_CONFIRMATION_REQUEST=>GO_DATA_LOSS.
PROCESS_EVENT( ):
In this method which is processed for all UIBBs displayed on the previous
screen, actions specific to the FPM-Event are performed (e.g. printing,
checking, saving). Depending on the result, the exporting parameter
EV_RESULT should be set as follows:
IF_FPM_CONSTANTS=>GC_EVENT_RESULT-OK (successful - this
is the default, thus setting this value is optional)
IF_FPM_CONSTANTS=>GC_EVENT_RESULT-FAILED (not
successful)
IF_FPM_CONSTANTS=>GC_EVENT_RESULT-DEFER (not
successful - further user input required)
In the later two cases, the method AFTER_FAILED_EVENT( ) is triggered
afterwards.
AFTER_FAILED_EVENT( ):
This method should contain the code to rollback the actual UIBB to the
last consistent state if event processing was not successful. This method
may also be triggered if the actual UIBB was processed successfully, but
processing of another UIBB was not successful. This is indicated by the
importing parameter IV_REVERT.
PROCESS_BEFORE_OUTPUT( ):
This method is processed for the UIBBs embedded on the next screen
displayed to the user. Here, corresponding data should be read.

Figure 60: Source code pattern for method NEEDS_CONFIRMATION
Figure 61: Source code pattern for method PROCESS_EVENT

Figure 62: Source code pattern for method PROCESS_BEFORE_OUTPUT
Triggering FPM-Events from the Application

There might be scenarios where a standard event needs to be triggered from within
an application specific UI building block as well.
Example: The initial screen of a floorplan should be skipped since all startup
parameters have already been provided as URL parameters.

Triggering an FPM-Event consist of three steps:

Get a reference to a singleton FPM service object, which allows to access the
functionality of the FPM component. The interface of this service object is
described by the interface IF_FPM.
Event parameters are not used:
Call method RAISE_EVENT_BY_ID( ) for the FPM service object. Here,
the FPM-Event is defined by the interface parameter IV_EVENT_ID.
Event parameters are used:
Create action object, by calling the static method
CL_FPM_EVENT=>CREATE_BY_ID( ). This will return
an instance of the class CL_FPM_EVENT. An arbitrary event ID has to
be passed to the method using the parameter IV_EVENT_ID.
Add event parameters by calling the method MO_EVENT_DATA-
>SET_DATA( ) for the event object.
Finally, call the method RAISE_EVENT( ) for the FPM service
object. Pass the event object to this method via the interface parameter
IO_EVENT.
Figure 63: Trigger FPM-Event from application source code

Accessing the FPM Toolbar at Runtime

It is also possible to add elements to the toolbar, to change the properties of
existing toolbar elements, or to get a list of all toolbar buttons and button choices
at runtime.
The toolbar can be accessed by methods that are defined in a floorplan specific
toolbar service object. The reference to this toolbar service object can be obtained
by calling the method GET_SERVICE( ) of the FPM service object. Depending
on the floorplan, the importing parameter IV_SERVICE_KEY has to be evaluated
as follows:
OIF: IV_SERVICE_KEY = CL_FPM_SERVICE_MAN-
AGER=>GC_KEY_CNR_OIF
GAF: IV_SERVICE_KEY = CL_FPM_SERVICE_MAN-
AGER=>GC_KEY_CNR_GAF
The returned service objects are described by the interfaces IF_FPM_CNR_OIF
(OIF) and IF_FPM_CNR_GAF (GAF), respectively.

The methods of the toolbar service object can be classified as follows:

Methods acting on toolbar buttons:
DEFINE_BUTTON( ) - creates or changes a toolbar button.
GET_BUTTONS( ) - returns a list of all toolbar buttons.
Methods acting on toolbar button choices:
DEFINE_BUTTON_CHOICE( ) - creates or changes a toolbar button
choice.
GET_BUTTON_CHOICES( ) - returns a list of all toolbar button
choices.
Methods acting on separators:
CREATE_SEPARATOR( ) - creates a separator between application
specific toolbar buttons and button choices.
GET_SEPARATORS( ) - returns the positions (sequence IDs) of
application specific separators.
REMOVE_SEPARATOR( ) - deletes an application specific separator
Methods acting on You can also menu bar:
DEFINE_YOU_CAN_ALSO( ) - defines the content of the You can
also menu bar.
GET_YOU_CAN_ALSO( ) - returns the content of the You can also
menu bar.
Methods acting on Related Links menu bar:
DEFINE_RELATED_LINKS( ) - defines the content of the Related
Links menu bar.
GET_RELATED_LINKS( ) - returns the content of the Related
Links menu bar.
Other methods:
SET_DUPLICATE_TOOLBAR( ) - allows to toggle the visibility of
the toolbar duplicate.
SET_VIEW_SWITCH_ENABLED( ) - allows to toggle the enabled
property of sub views in the OIF
Hint: This method is only available in toolbar service object

for the OIF.
In the following, defining new buttons and button choices for the OIF is displayed
exemplarily:

Figure 64: OIF toolbar: Create button dynamically
Figure 65: OIF toolbar: Create button choice dynamically (1)

Figure 66: OIF toolbar: Create button choice dynamically (2)

In order to identify a standard button, constants defined in the interface

IF_FPM_CONSTANTS can be used:
Toolbar element:
<TE> (e.g. SEND)
Constant to identify the toolbar element:
IF_FPM_CONSTANT=>GC_BUTTON-<TE>, if <TE> is a button.
IF_FPM_CONSTANT=>GC_BUTTON_CHOICE-<TE>, if <TE>
is a button choice.
(e.g. IF_FPM_CONSTANT=>GC_BUTTON-SEND)
Exceptions from this Rule
SAVE in the OIF toolbar. This is a predefined button of type Activation
Function. Thus the constant IF_FPM_CONSTANT=>GC_BUTTON-
ACTIVATION_FUNCTION has to be used to access this button. In
addition, the element ID has to be provided since multiple activation
functions may exist.
DELETE OBJECT in the OIF toolbar. Here the constant
IF_FPM_CONSTANT=>GC_BUTTON-DELETE has to be used to
access the button.
Hint: The methods DEFINE_BUTTON( ) and DEFINE_BUT-

TON_CHOICE( ) can also be used to change the properties of existing
toolbar buttons and toolbar button choices. In this case only the properties
that should be changed have to be exported to the method. In order to
identify application specific toolbar buttons, the property Element ID has
to be supplied using the exporting parameter IV_ELEMENT_ID.
Hint: The parameter IV_FUNCTION is obligatory.
Hint: The parameter IV_VARIANT_ID is optional (as of SAP NetWeaver

7.0 EhP1 SAP_ABA SPS 2). If this parameter is not supplied, the toolbar
of the current variant is accessed.
Hint: The ID of each variant can be defined in the Configuration Editor

as follows: First, the variant has to be selected from the drop down box
located above the hierarchy. Next, the menu item Variant Parameters has
to be selected from the button choice Change. A popup will open. The ID
of the variant can then be entered in the field labeled Variant ID.

For the GAF, each main step and each sub step has its own toolbar. In addition,
for each main step multiple sub step variants may be defined. Thus, the methods
to create new buttons and new button choices in the toolbar of the GAF contain
three additional importing parameters:
IV_MAINSTEP_ID:
ID of the main step, the toolbar is related to. This parameter is optional (as of
SAP NetWeaver 7.0 EhP1 SAP_ABA SPS 2). If this optional parameter is
not supplied, the toolbar of the current main step will be accessed.
IV_SUBTEP_ID:
ID of the sub step, the toolbar is related to. If this optional parameter is not
supplied, the toolbar of the current main step will be accessed.
IV_SUBVARIANT_ID:
ID of the substep variant, the toolbar is related to. If this optional parameter
is not supplied, but the parameter IV_SUBTEP_ID is supplied, all changes
will be conducted for the current substep variant.
Hint: The ID of each sub step variant can be defined in the Configuration
Editor as follows: First, the sub step variant has to be marked in the
hierarchy displayed on the left side. Next, the menu item Substep Variant
Parameters has to be selected from the button choice Change. A popup
will open. The ID of the sub step variant can then be entered in the field
labeled Substep Variant ID.
In the following, defining new buttons for the GAF is described exemplarily.
Creating button choices for the GAF is not displayed.

Figure 67: GAF main step toolbar: Create button dynamically
Figure 68: GAF sub step toolbar: Create button dynamically

Activation of Roadmap Sub Steps

Sub steps belong to a certain sub step variant. Sub steps are not displayed
automatically by the FPM application. This is because it may depend on
programmatic boundary conditions which sub step variant is to be displayed or if
sub steps are to be displayed at all. The source code necessary to display a sub
step variant consists of the following parts:
First, an event object being an instance of class CL_FPM_EVENT has to be
created by calling the static method CL_FPM_EVENT=>CREATE_BY_ID(
). The importing parameter IV_EVENT_ID has to be evaluated with the
constant CL_FPM_EVENT=>GC_EVENT_CHANGE_STEP.
Next, event parameters have to be defined by calling the event object's
method MO_EVENT_DATA->SET_VALUE( ). The following parameters
need to be supplied:
CL_FPM_EVENT=>GC_EVENT_PARAM_MAINSTEP_ID = ID of
main step, the sub steps to be displayed are related to
CL_FPM_EVENT=>GC_EVENT_PARAM_SUBSTEP_ID = ID of sub
step, to be displayed as next active step
CL_FPM_EVENT=>GC_EVENT_PARAM_SUBVARIANT_ID = ID of
sub step variant , to be displayed next
Finally, the event created in the last two steps has to be fired. This is done
by calling the method RAISE_EVENT( ) related to the FPM service object.
The event object is exported via the parameter IO_EVENT.
Hint: Displaying sub steps is typically initiated by the user who

clicks an appropriate toolbar button. However, it is also possible that
the application initiates this change by triggering the FPM-Event
related to this toolbar button.

Figure 69: GAF: Activation of roadmap sub steps
Accessing the IDR at Runtime

The IDR may consist of the header area (text displayed by PageHeader UI
element on top), the ticket area (displaying a maximum of two texts in two lines
below the header area on the left side), and an item area (displaying an arbitrary
number of items below the header area on the right side).
Hint: GAF applications can not display the ticket area.

Figure 70: IDR constituents
The header area and the ticket area can be configured statically. However, the
item area can not be defined statically. In order to define the content of the
item area and to change the content of the header area and the ticket area at
runtime, methods of the IDR service object have to be used. A reference to
this object can be obtained by calling the method GET_SERVICE( ) for the
FPM service object. This method is also used to access the toolbar service
objects for the OIF and for the GAF. However, in order to access the IDR, the
importing parameter IV_SERVICE_KEY has to be evaluated with the constant
CL_FPM_SERVICE_MANAGER=>GC_KEY_IDR. The returned object is
described by the interface IF_FPM_IDR.
The methods of the IDR service object can be classified as follows:
Methods acting on the header area:
GET_APPLICATION_TITLE( ) - get text and tooltip of application
title.
SET_APPLICATION_TITLE( ) - change text and tooltip of
application title.
SET_HEADER_VISIBILITY( ) - change visibility of application title.
Methods acting on the ticket area:
GET_TICKET( ) - get texts and tooltips displayed in ticket area (top
and bottom).
SET_TICKET( ) - change texts and tooltips displayed in ticket area
(top and bottom).

SET_TICKET_VISIBILITY( ) - change visibility of ticket area.

Methods acting on images displayed in item area:
ADD_IMAGE_ITEM( ) - add new label / image pair to item area.
Each label / image pair occupies an own item group.
CHANGE_IMAGE_ITEM( ) - change label / image pair in item area.
Hint: An image should always display a related explanation text.
Methods acting on label / text pairs displayed in item area:

ADD_ITEM_GROUP_BY_VAL( ) - add multiple label / text pairs to
item area. These label / text pair occupy one item group.
ADD_ITEM_GROUP_BY_REF( ) - identical to previous method.
However, the texts are related to context attributes.
Note: Using this method instead of
ADD_ITEM_GROUP_BY_VAL( ) has the following
advantages:
Changing the values of the context attributes will automatically
change the item values in the extended IDR.
The values displayed in the extended IDR are automatically
formatted according to the context attribute type.
CHANGE_ITEM_GROUP_BY_VAL( ) - change texts of items related

to item group defined by the method ADD_ITEM_GROUP_BY_VAL( ).
Hint: In order to store item group information in the context, a

two level context hierarchy should be defined. At runtime, the
non-singleton node on the first hierarchy level (<item_group_node>)
contains as many elements as item groups are to be displayed.
Then, for each item group, a separate instance of the second level
node (<itmes_node>) may be created. Each of these second level
hierarchy node objects will contains as many elements as items are
to be displayed for the related items group.
For each item, the path information to the attribute <attribute>
containing the item value has to be passed to the method
ADD_ITEM_GROUP_BY_VAL( ). This path is constructed as
follows:<item_group_node>.<element_index>.<itmes_node>.<el-
ement_index>.<attribute>.
Methods acting on navigation items displayed in item area:

ADD_NAVIGATION_ITEM( ) - adds a navigation item displaying

one or multiple navigation links to item area. Each navigation item
occupies an own item group.
CHANGE_NAVIGATION_ITEM( ) - change label and text of
navigation item in item area.
Navigation links are not discussed here.
Methods acting on any kind of item displayed in item area:
CONTAINS_ITEM_GROUP( ) - checks, whether given item group
exists. Item groups are identified by a numerical key.
REMOVE_ITEM_GROUP( ) - delete an image, text items, or
navigation links from the IDR by removing related item group.
INITIALIZE_ITEMS( ) - clear all items in all item groups.
In the following, changing the application title, changing the ticket area, adding
images to the items, adding texts to the items area, and removing items from
the item area is displayed exemplarily.
Figure 71: IDR - changing the application title

Figure 72: IDR - changing texts displayed in the ticket area
Figure 73: IDR - adding images to the items area / delete item groups

Figure 74: IDR - adding label/text pairs to the items area
Using the FPM Message Manager

In order to guarantee a consistent and guidelines complient message handling in
FPM applications, the FPM frameworks provides an own message manager. This
should be used instead of the generic Web Dynpro message manager.
The reference to the FPM message manager object is stored in the public attribute
MO_MESSAGE_MANAGER of the FPM service object. Optionally, this
reference can be copied to a public component controller attribute.
Alike the generic Web Dynpro message manager, the FPM message manager
is capable of sending messages that are based on simple text literals, on texts
stored in the database table T100, and on texts contained in exception objects. In
addition, data structures of type BAPIRET2 can utilized by the FPM message
manager to generate a corresponding message.

The methods of the FPM message manager object can be classified as follows:
Methods used to report messages:
REPORT_MESSAGE( ) - report message based on simple text literal.
Message text is mandatory.
REPORT_T100_MESSAGE( ) - report message based on T100
database content. Message class and number are mandatory.
REPORT_BAPIRET2_MESSAGE( ) - report message based on return
structure of BAPI call. This structure is mandatory.
REPORT_OBJECT_MESSAGE( ) - report message based on an
exception object. Exception object is mandatory.
Methods used to raise the exception CX_FPM_EXCEPTION. This will
create a dump:
RAISE_EXCEPTION( ) - exception text is based on an arbitrary text
literal (if supplied).
RAISE_T100_EXCEPTION( ) - exception text is based on T100
database content. Message class and number are mandatory.
RAISE_BAPIRET2_EXCEPTION( ) - exception text is based on
return structure of BAPI call. This structure is mandatory.
RAISE_CX_ROOT_EXCEPTION( ) - exception text is based on
exception object inheriting from CX_ROOT or subclass. Exception
object is mandatory.
Other methods:
CLEAR_MESSAGES( ) - remove messages from message stack.
Interface parameters allow to exclude messages according to their type
and component relation.

In the following, the main differences between the standard WD message manager
and the FPM message manager are summarized:
For each text category (simple text, T100 text, text from exception objects),
only one method exists to send this text as a message of type error, warning,
or success.
The message type (SUC, WRN, ERR) and an optional binding to a single
attribute or to multiple attributes of the same context element is defined via
parameters of this method.
For error messages, the navigation is cancelled automatically (if send in the
hook method WDDOBEFORENAVIGATION( ) or in a method processed
before). There is no differentiation between fatal errors, errors, and errors
related to context attributes.
The BAPI returning structure (type BAPIRET2) can be passed directly to a
corresponding method of the FPM message manager.
Clearing the messages stored in the message manager can be restricted to
certain message types.
The lifetime and visibility of messages is handled according to the UI
guidelines. Instead of the parameters CONTROLLER_PERMANENT_MSG,
IS_PERMANENT and SCOPE_PERMANENT_MSG (generic WD message
manager), the parameters IO_COMPONENT, IO_CONTROLLER, and
IV_LIFETIME are used.
Figure 75: FPM message manager - reporting text messages

Exercise 5: Implement Methods of

FPM-Interface
Exercise Objectives
Implement the source code of the methods originating from the interface
IF_FPM_UI_BUILDING_BLOCK.
Business Example
You would like to implement the application logic. This includes the handling of
FPM-Events, the identification of UIBBs displayed to the user on the previous
and on the next screen, cancelling the navigation to the next UIBB if necessary,
or sending data loss popups if needed.
Thus you need to put your code in the methods related to the interface
IF_FPM_UI_BUILDING_BLOCK
NET313_BOOKING_S4
NET313_CUSTOMER_S3
Task 1:
Implement the source code of your GAF application.
1. Go on edit the component ZNET313_##_BOOKING_S1. Implement the
source code of the component controller method PROCESS_EVENT( ).
Process the source code of this method only, if the user clicked the button
labeled Next Step. Check the name of the last UIBB displayed to the user.
If this name equals CUSTOMER_WINDOW, get the flights the customer
booked.
If this name equals FLIGHTS_WINDOW, get the booking information
for the flights the customer booked.
If this name equals BOOKINGS_WINDOW, get the bookings selected by
the user.
If this name equals CHECK_WINDOW, cancel the selected bookings.
For all four steps, a corresponding controller method has to be called. All
methods return the information if proceeding the method was successful
via the returning parameter RV_RESULT. If proceeding the method was
not successful, cancel the navigation.

Task 2:
Implement the source code of the OIF application.
1. Implement the source code of the component controller method
PROCESS_EVENT( ). Process the source code of this method only, if the
user clicked the button labeled Save or the button labeled Display/Change
Customer.
If the user clicked the button labeled Display/Change Customer, toggle the
editability of the customer form fields.
If the user clicked the Save button, update the customer data.
If updating the customer data was successful, reset the context change log.
Hint: The reference to the context service object is stored in the

component controller attribute GO_CONTEXT.
2. Implement the source code of component controller method

NEEDS_CONFIRMATION( ).
Check if the user clicked the button labeled Close. In this case, check if the
context change log is empty. If the log is not empty (which means that data
have been changed by the user, but these changes have not been written to
the data base yet), display a data loss popup.

3. Implement the source code of method WDDOINIT( ) of the view

CUSTOMER_VIEW.
Read the complete customer data set.
4. Implement the source code of method WDDOINIT( ) of the views
BOOKINGS_N_VIEW and BOOKINGS_C_VIEW.
Read the bookings.
Task 3:

Solution 5: Implement Methods of

FPM-Interface
Task 1:
Implement the source code of your GAF application.
1. Go on edit the component ZNET313_##_BOOKING_S1. Implement the
source code of the component controller method PROCESS_EVENT( ).
Process the source code of this method only, if the user clicked the button
labeled Next Step. Check the name of the last UIBB displayed to the user.
If this name equals CUSTOMER_WINDOW, get the flights the customer
booked.
If this name equals FLIGHTS_WINDOW, get the booking information
for the flights the customer booked.
If this name equals BOOKINGS_WINDOW, get the bookings selected by
the user.
If this name equals CHECK_WINDOW, cancel the selected bookings.
For all four steps, a corresponding controller method has to be called. All
methods return the information if proceeding the method was successful
via the returning parameter RV_RESULT. If proceeding the method was
not successful, cancel the navigation.
a) The name of the FPM-Event related to the client side event is available
from the interface parameter IO_EVENT
b) The name of the last UIBB displayed to the user can be read from the
interface parameter IT_INTERFACE_VIEWS. Because only one UIBB
is displayed at the same time, the first line of this internal table will
contain the interface view's name.
c) Use the component controller methods GET_FLIGHTS( ),
GET_BOOKINGS( ), GET_SELECTED_BOOKINGS( ), and
CANCEL_BOOKINGS( ), respectively.
d) Please find the source code at the end of this exercise.
Task 2:
Implement the source code of the OIF application.
PROCESS_EVENT( ). Process the source code of this method only, if the
user clicked the button labeled Save or the button labeled Display/Change
Customer.

If the user clicked the button labeled Display/Change Customer, toggle the
editability of the customer form fields.
If the user clicked the Save button, update the customer data.
If updating the customer data was successful, reset the context change log.

the interface parameter IO_EVENT
b) Use the component controller methods TOGGLE_EDIT_MODE( ),
and UPDATE_CUSTOMER( ), respectively.
c) The context change log is cleared if the method RESET_CON-
TEXT_CHANGE_LOG( ) of the component controller attribute
GO_CONTEXT is called.
2. Implement the source code of component controller method
NEEDS_CONFIRMATION( ).
Check if the user clicked the button labeled Close. In this case, check if the
context change log is empty. If the log is not empty (which means that data
have been changed by the user, but these changes have not been written to
the data base yet), display a data loss popup.

the interface parameter IO_EVENT
b) The content of the context change log is accessible via the method
GET_CONTEXT_CHANGE_LOG( ) related to the component
controller attribute GO_CONTEXT.
Hint: Set the importing parameter AND_RESET =

ABAP_FALSE, otherwise the change log is automatically
cleared!
c) Please find the source code at the end of this exercise.

3. Implement the source code of method WDDOINIT( ) of the view

CUSTOMER_VIEW.
Read the complete customer data set.
a) Use the component controller methods GET_CUSTOMER( ) to read
all customer details.
b) Please find the source code at the end of this exercise.
4. Implement the source code of method WDDOINIT( ) of the views
BOOKINGS_N_VIEW and BOOKINGS_C_VIEW.
Read the bookings.
a) Use the component controller methods GET_BOOKINGS( ) to read
all bookings.
b) Please find the source code at the end of this exercise.
Task 3:
FPM application.
b) Try to close your application after having changed customer data. A
data loss popup should appear.
c) Try to close your application not having changed customer data. No
data loss popup should appear.
d) Try to close your application after having changed customer data and
saved the data. No data loss popup should appear.
e) The cancelled and the non-cancelled bookings should be displayed on
the second tab.
application.
b) If no flights are selected, the navigation should be cancelled. If flights
are selected, the corresponding bookings should be displayed on the
next page.

c) If no bookings are selected, the navigation should be cancelled. If

bookings are selected, the selected bookings should be displayed again
on the next page.
d) Check, whether the selected bookings are really cancelled by restarting
your application.
Result
GAF: Component Controller - PROCESS_EVENT( )
METHOD process_event.
DATA lv_interface_view TYPE string.

DATA lv_result TYPE wdy_boolean.
* event processing only if user selected NEXT STEP

IF NOT io_event->mv_event_id = cl_fpm_event=>gc_event_next_step.
RETURN.
ENDIF.
* check which interface view has been displayed on last view

READ TABLE it_interface_views INTO lv_interface_view INDEX 1.
CASE lv_interface_view.
* if interface view was CUSTOMER_WINDOW, read flights for customer
* stay on page if no flights could be read
WHEN 'CUSTOMER_WINDOW'.
lv_result = wd_this->get_flights( ).
IF lv_result = abap_false.
ev_result = if_fpm_constants=>gc_event_result-failed.
ENDIF.
* if interface view was FLIGHTS_WINDOW, read bookings for on flights
* stay on page if no bookings could be read
WHEN 'FLIGHTS_WINDOW'.
lv_result = wd_this->get_bookings( ).
ENDIF.
* if interface view was BOOKINGS_WINDOW, check for selected bookings
* stay on page if no bookings were selected
WHEN 'BOOKINGS_WINDOW'.
lv_result = wd_this->get_selected_bookings( ).
ENDIF.
* if interface view was CHECK_WINDOW, try to cancel bookings on DB

* stay on page if cancelling bookings was not successful

WHEN 'CHECK_WINDOW'.
lv_result = wd_this->cancel_bookings( ).
ENDIF.
ENDCASE.
ENDMETHOD.
OIF: Component Controller - PROCESS_EVENT( )

METHOD process_event .
CASE io_event->mv_event_id.
* if EDIT_TOGGLE was selected, toggle edit mode
WHEN 'EDIT_TOGGLE'.
wd_this->toggle_edit_mode( ).
* if SAVE was selected, update customer data
WHEN cl_fpm_event=>gc_event_save.
lv_result = wd_this->update_customer( ).
ELSE.
* if update was successful, clear context change log
wd_this->go_context->reset_context_change_log( ).
ENDIF.
ENDCASE.
ENDMETHOD.
OIF: Component Controller - NEEDS_CONFIRMATION( )

METHOD needs_confirmation .
DATA lt_change_log TYPE wdr_context_change_list.
* if CLOSE was selected
WHEN cl_fpm_event=>gc_event_close.
* get context change log (internal table)
lt_change_log = wd_this->go_context->get_context_change_log(
and_reset = abap_false ).
IF lt_change_log IS NOT INITIAL.

* if context change log contains any data, send data loss popup
eo_confirmation_request = cl_fpm_confirmation_request=>go_data_loss.
ENDIF.
ENDCASE.
ENDMETHOD.
OIF: View Controller CUSTOMER_VIEW - WDDOINIT( )

METHOD wddoinit .
DATA lo_componentcontroller TYPE REF TO ig_componentcontroller .
lo_componentcontroller = wd_this->get_componentcontroller_ctr( ).
lo_componentcontroller->get_customer( ).
ENDMETHOD.
OIF: View Controllers BOOKINGS_N_VIEW / BOOKINGS_C_VIEW

- WDDOINIT( )
METHOD wddoinit .
lo_componentcontroller->get_bookings( ).
ENDMETHOD.

Exercise 6: Access the Toolbar at Runtime

Exercise Objectives
Add new toolbar elements or change the properties of existing toolbar
elements
Business Example
Depending on the screen displayed to the user, you would like to adapt the
properties of a toolbar button displayed by your OIF component.
Solution Component:
NET313_CUSTOMER_S4
Task:
Check, which information will be displayed to the user on the next screen. If
the customer form will be displayed, enable the button labeled Display/Change
Customer. If bookings will be displayed to the user, disable this button.
1. Get the reference to the FPM service object and to the OIF service object and
store these reference in attributes of the component controller. Encapsulate
the code in the hook method WDDOINIT( ).
PROCESS_BEFORE_OUTPUT( ). Check the name of the next UIBB
displayed to the user. If this name equals CUSTOMER_WINDOW, enable
the toolbar button labeled Display/Change Customer. For all other cases,
disable the toolbar button.

Solution 6: Access the Toolbar at Runtime

Task:
Check, which information will be displayed to the user on the next screen. If
the customer form will be displayed, enable the button labeled Display/Change
Customer. If bookings will be displayed to the user, disable this button.
1. Get the reference to the FPM service object and to the OIF service object and
store these reference in attributes of the component controller. Encapsulate
the code in the hook method WDDOINIT( ).
a) Edit the component controller of your component ZNET313_##_CUS-
TOMER_S1.
b) Define a new attribute of reference type IF_FPM. Name this attribute
GO_FPM.
c) Define a new attribute of reference type IF_FPM_CNR_OIF. Name
this attribute GO_FPM_OIF.
d) Now edit the component controller method WDDOINIT( ).
e) Call the method CL_FPM_FACTORY=>GET_INSTANCE( ) to get
the reference to the FPM service object. Store this reference in the
controller attribute GO_FPM.
f) Next, call the method GET_SERVICE( ) for the FPM service object.
Evaluate the importing parameter IV_SERVICE_KEY with the constant
CL_FPM_SERVICE_MANAGER=>GC_KEY_CNR_OIF. This will
return the reference to the OIF service object. Store this reference in
the controller attribute GO_FPM_OIF.
g) Please find the source code at the end of this exercise.
PROCESS_BEFORE_OUTPUT( ). Check the name of the next UIBB
displayed to the user. If this name equals CUSTOMER_WINDOW, enable
the toolbar button labeled Display/Change Customer. For all other cases,
disable the toolbar button.
a) Read the first line of the interface parameter IT_INTERFACE_VIEWS
to find out the name of the next UIBB displayed to the user.
b) Call the method DEFINE_BUTTON( ) for the OIF service object
(GO_FPM_OIF) to access a button. Evaluate the interface parameters
as follows:
IV_FUNCTION = IF_FPM_CONSTANTS=>GC_BUTTON-
OTHER_FUNCTION
IV_ELEMENT_ID = 'CUSTOMER_TOGGLE'

IV_ENABLED = ABAP_TRUE or ABAP_FALSE

c) Please find the source code at the end of this exercise.
Result
OIF: Component Controller - WDDOINIT( )
METHOD wddoinit .
* get text displayed on introduction screen

wd_this->set_intro_text( ).
* get reference to context object.
* The context change log related to this object is used to find
* out any changes of the customer data
wd_this->go_context = wd_context->get_context( ).
* get reference to FPM service object

wd_this->go_fpm = cl_fpm_factory=>get_instance( ).
* get reference to OIF service object
wd_this->go_fpm_oif ?= wd_this->go_fpm->get_service(
iv_service_key = cl_fpm_service_manager=>gc_key_cnr_oif ).
ENDMETHOD.
OIF: Component Controller - PROCESS_BEFORE_OUTPUT( )

METHOD process_before_output .

DATA lt_buttons TYPE if_fpm_cnr_oif=>t_button.
* check for interface views displayed on next screen

IF sy-subrc <> 0.
RETURN.
ENDIF.
* if IF view is CUSTOMER_WINDOW, enable button with ID CUSTOMER_TOGGLE

IF lv_interface_view = 'CUSTOMER_WINDOW'.
wd_this->go_fpm_oif->define_button(
iv_function = if_fpm_constants=>gc_button-other_function
iv_element_id = 'CUSTOMER_TOGGLE'
iv_enabled = abap_true ).
* for any other IF view, disable button with ID CUSTOMER_TOGGLE
ELSE.

iv_enabled = abap_false ).
ENDIF.
ENDMETHOD.

Exercise 7: Access the IDR at Runtime

Exercise Objectives
Change the application title at runtime
Change the IDR ticket area at runtime
Change the IDR items area at runtime
Business Example
You would like to adapt the application title, the ticket area, and the items area
displayed by your OIF application at runtime.
Solution Component:
NET313_CUSTOMER_S5
Task 1:
When navigating from the initial screen to the customer form, the customer
data is read from the data base using the component controller method
GET_CUSTOMER( ). This method is called from the hook method WDDOINIT( )
of the view CUSTOMER_VIEW.
Create a new component controller method (name: INIT_IDR( )) encapsulating
the code to adapt the application title. Call this new method from the hook method
WDDOINIT( ) of the view CUSTOMER_VIEW. Position the call directly behind
the call of method GET_CUSTOMER( ).
Hint: The application title should read 'Customer <no>', where <no> is
the ID of the customer selected on the initial screen.
1. Get the reference to the IDR service object and store this reference in a
component controller attribute. Define the related source code in the hook
method WDDOINIT( ).
2. Create a new component controller method having the name INIT_IDR( ).
Call this method from the source code of the method WDDOINIT( ) related
to the view CUSTOMER_VIEW.
3. Implement the source code of method INIT_IDR( ):
Get the current customer data from the component controller context.

Then get the text with the symbol '006' from the assistance class.
Concatenate this text and the customer ID. This will define the application's
title.
Get the text with the symbol '007' from the assistance class. This will define
the tooltip of the application title.
Now you can set the new application title by calling the method
SET_APPLICATION_TITLE( ) of the IDR service object.
Task 2:
Optional part 1
Adapt the ticket area. Display the current customer name in line one and the city
in line two. If the customer data is changed by the user, these two lines need to
be synchronized with the current form field values.
1. Create a new component controller method having the name
SET_IDR_TICKET( ). This method should have an importing parameter
(name: IS_CUSTOMER, type: SCUSTOM). Call this method from the source
code of the component controller method INIT_IDR( ).
2. Edit the component controller method FLUSH( ). Check, if the context
change log contains any entries. If this is the case, read the current customer
data from the context. Then call the method SET_IDR_TICKET( ) and pass
the current customer data to this method.
3. Implement the source code of method SET_IDR_TICKET( ):
the tooltip of line one (ticket top).
the tooltip of line two (ticket bottom).
Call the method SET_TICKET( ) of the IDR service object to actualize the
ticket area. Display the customer name on the first line (ticket top) and the
city in the second line (ticket bottom).

Task 3:
Optional part 2
Adapt the items area. Display the current status of the customer data (unchanged /
changed but not saved / changed and saved).
SET_IDR_ITEMS( ). This method should have an importing parameter
(name: IV_STATE, type: C). Call this method from the source code of the
component controller method INIT_IDR( ). Pass the value 'I' (initial) to
the method.
2. Edit the component controller method FLUSH( ). In case that the user
changed any customer data, do not only call the method SET_IDR_TICKET(
) but also the method SET_IDR_ITEMS( ). Pass the value 'M' (modified) to
the method.
3. Edit the component controller method PROCESS_EVENT( ). If saving the
customer data was successful and the context log file was cleared, call the
method SET_IDR_ITEMS( ). Pass the value 'S' (saved) to the method.
4. Implement the source code of method SET_IDR_ITEMS( ):
Define an internal table of type IF_FPM_IDR=>T_ITEMS_VAL and a
corresponding work area. Define one item to be displayed in the item area by
adding one line to the internal table. Set the fields of the work area as follows:
VALUE: Depending on the status (importing parameter IV_STATE) of
the customer data, get a text to be displayed as the item's value from
the assistance class. Appropriate text symbols are '011' (initial), '012'
(modified), and '013' (saved).
VALUE_TOOLTIP: Get the text with the symbol '014' from the assistance
class.
LABEL_NAME and LABEL_TOOLTIP: Get the text with the symbol '010'
from the assistance class.
Call the method INITIALIZE_ITEMS( ) to delete all existing item groups.
Then call the method ADD_ITEM_GROUP_BY_VAL( ) to define a new
item group. Pass the internal table to this method.
Task 4:
Test your OIF application.

Solution 7: Access the IDR at Runtime

Task 1:
When navigating from the initial screen to the customer form, the customer
data is read from the data base using the component controller method
GET_CUSTOMER( ). This method is called from the hook method WDDOINIT( )
of the view CUSTOMER_VIEW.
Create a new component controller method (name: INIT_IDR( )) encapsulating
the code to adapt the application title. Call this new method from the hook method
WDDOINIT( ) of the view CUSTOMER_VIEW. Position the call directly behind
the call of method GET_CUSTOMER( ).
Hint: The application title should read 'Customer <no>', where <no> is
the ID of the customer selected on the initial screen.
1. Get the reference to the IDR service object and store this reference in a
component controller attribute. Define the related source code in the hook
method WDDOINIT( ).
a) Edit the component controller of your component ZNET313_##_CUS-
TOMER_S1.
b) Define a new attribute of reference type IF_FPM_IDR. Name this
attribute GO_FPM_IDR.
c) Now edit the component controller method WDDOINIT( ).
d) Call the method GET_SERVICE( ) for the FPM service object.
Evaluate the importing parameter IV_SERVICE_KEY with the constant
CL_FPM_SERVICE_MANAGER=>GC_KEY_IDR. This will return
the reference to the IDR service object. Store this reference in the
controller attribute GO_FPM_IDR.
e) Please find the source code at the end of this exercise.
2. Create a new component controller method having the name INIT_IDR( ).
Call this method from the source code of the method WDDOINIT( ) related
to the view CUSTOMER_VIEW.
a) Please find the source code at the end of this exercise.
3. Implement the source code of method INIT_IDR( ):
Get the current customer data from the component controller context.
Then get the text with the symbol '006' from the assistance class.
Concatenate this text and the customer ID. This will define the application's
title.

the tooltip of the application title.
Now you can set the new application title by calling the method
SET_APPLICATION_TITLE( ) of the IDR service object.
Task 2:
Optional part 1
Adapt the ticket area. Display the current customer name in line one and the city
in line two. If the customer data is changed by the user, these two lines need to
be synchronized with the current form field values.
SET_IDR_TICKET( ). This method should have an importing parameter
(name: IS_CUSTOMER, type: SCUSTOM). Call this method from the source
code of the component controller method INIT_IDR( ).
2. Edit the component controller method FLUSH( ). Check, if the context
change log contains any entries. If this is the case, read the current customer
data from the context. Then call the method SET_IDR_TICKET( ) and pass
the current customer data to this method.
3. Implement the source code of method SET_IDR_TICKET( ):
the tooltip of line one (ticket top).
the tooltip of line two (ticket bottom).
Call the method SET_TICKET( ) of the IDR service object to actualize the
ticket area. Display the customer name on the first line (ticket top) and the
city in the second line (ticket bottom).

Task 3:
Optional part 2
Adapt the items area. Display the current status of the customer data (unchanged /
changed but not saved / changed and saved).
SET_IDR_ITEMS( ). This method should have an importing parameter
(name: IV_STATE, type: C). Call this method from the source code of the
component controller method INIT_IDR( ). Pass the value 'I' (initial) to
the method.
2. Edit the component controller method FLUSH( ). In case that the user
changed any customer data, do not only call the method SET_IDR_TICKET(
) but also the method SET_IDR_ITEMS( ). Pass the value 'M' (modified) to
the method.
3. Edit the component controller method PROCESS_EVENT( ). If saving the
customer data was successful and the context log file was cleared, call the
method SET_IDR_ITEMS( ). Pass the value 'S' (saved) to the method.
4. Implement the source code of method SET_IDR_ITEMS( ):
Define an internal table of type IF_FPM_IDR=>T_ITEMS_VAL and a
corresponding work area. Define one item to be displayed in the item area by
adding one line to the internal table. Set the fields of the work area as follows:
VALUE: Depending on the status (importing parameter IV_STATE) of
the customer data, get a text to be displayed as the item's value from
the assistance class. Appropriate text symbols are '011' (initial), '012'
(modified), and '013' (saved).
VALUE_TOOLTIP: Get the text with the symbol '014' from the assistance
class.
LABEL_NAME and LABEL_TOOLTIP: Get the text with the symbol '010'
from the assistance class.
Call the method INITIALIZE_ITEMS( ) to delete all existing item groups.
Then call the method ADD_ITEM_GROUP_BY_VAL( ) to define a new
item group. Pass the internal table to this method.

Task 4:
Test your OIF application.
FPM application.
b) Check application title, ticket area and items area before you change
the customer data.
c) If you have finished the optional tasks, change the customer name and
the city and click on the Bookings tab to trigger a roundtrip. The ticket
area should be updated and the items area should indicate that data
has been changed.
d) Save the customer data. The items area should display the new status.
Result
OIF: View CUSTOMER_VIEW- WDDOINIT( )
METHOD wddoinit .
lo_componentcontroller->get_customer( ).
* set application title,

* ticket area (optional), and item area (optional) according to customer
lo_componentcontroller->init_idr( ).
ENDMETHOD.
OIF: Component Controller - INIT_IDR( )

METHOD init_idr .
DATA lo_nd_customer TYPE REF TO if_wd_context_node.

DATA lo_el_customer TYPE REF TO if_wd_context_element.
DATA ls_customer TYPE wd_this->element_customer.
DATA lv_app_title TYPE string.

DATA lv_app_title_tooltip TYPE string.
* get customer data

lo_nd_customer = wd_context->get_child_node( name = wd_this->wdctx_customer ).

lo_el_customer = lo_nd_customer->get_element( ).
lo_el_customer->get_static_attributes(
IMPORTING
static_attributes = ls_customer ).
* set application title and its tooltip

lv_app_title = wd_assist->get_text( '006' ).
CONCATENATE lv_app_title ls_customer-id
INTO lv_app_title
SEPARATED BY space.
lv_app_title_tooltip = wd_assist->get_text( '007' ).
wd_this->go_fpm_idr->set_application_title(
iv_title = lv_app_title
iv_title_tooltip = lv_app_title_tooltip ).
ENDMETHOD.
OPTIONAL PART 1: Component Controller - INIT_IDR( )

METHOD init_idr .
...
wd_this->go_fpm_idr->set_application_title(
iv_title = lv_app_title
iv_title_tooltip = lv_app_title_tooltip ).
* optional part: initialize ticket area

wd_this->set_idr_ticket( is_customer = ls_customer ).
ENDMETHOD.
OPTIONAL PART 1: Component Controller - FLUSH( )

METHOD flush .
DATA lt_change_log TYPE wdr_context_change_list.

* Optional parts **************************************************************
* Check if user has changed customer details
lt_change_log = wd_this->go_context->get_context_change_log(
and_reset = abap_false ).

* If user has changed any data...

IF lt_change_log IS NOT INITIAL.
lo_nd_customer = wd_context->get_child_node( name = wd_this->wdctx_customer ).
lo_el_customer->get_static_attributes(
IMPORTING
static_attributes = ls_customer ).
* refresh ticket area (display updated customer data)

ENDIF.
ENDMETHOD.
OPTIONAL PART 1: Component Controller - SET_IDR_TICKET( )

METHOD set_idr_ticket .
DATA lv_ticket_top TYPE string.

DATA lv_ticket_bot TYPE string.
DATA lv_ticket_top_tooltip TYPE string.
DATA lv_ticket_bot_tooltip TYPE string.
* set ticket area

lv_ticket_top_tooltip = wd_assist->get_text( '008' ).
lv_ticket_bot_tooltip = wd_assist->get_text( '009' ).
lv_ticket_top = is_customer-name.
lv_ticket_bot = is_customer-city.
TRY.
wd_this->go_fpm_idr->set_ticket(
iv_top = lv_ticket_top
iv_bottom = lv_ticket_bot
iv_top_tooltip = lv_ticket_top_tooltip
iv_bottom_tooltip = lv_ticket_bot_tooltip ).
CATCH cx_fpm_idr.
ENDTRY.
ENDMETHOD.
OPTIONAL PART 2: Component Controller - INIT_IDR( )

METHOD init_idr .
...

* optional part: initialize ticket area

* optional part: initialize items area

wd_this->set_idr_items( iv_state = 'I' ).
ENDMETHOD.
OPTIONAL PART 2: Component Controller - FLUSH( )

METHOD flush .
...
* Optional parts **************************************************************
...
* refresh ticket area (display updated customer data)
* refresh items area (display that customer data has been changed)
wd_this->set_idr_items( iv_state = 'M' ).
...
ENDMETHOD.
OPTIONAL PART 2: Component Controller - PROCESS_EVENT( )

...
* if update was successful, clear context change log
* Optional part: refresh items area (display, that changed data is saved)
wd_this->set_idr_items( iv_state = 'S' ).
...
ENDMETHOD.
OPTIONAL PART 2: Component Controller - SET_IDR_ITEMS( )

METHOD set_idr_items .
DATA lt_items TYPE if_fpm_idr=>t_items_val.

DATA ls_items TYPE if_fpm_idr=>s_items_val.
CASE iv_state.
WHEN 'I'. "Initial

ls_items-value = wd_assist->get_text( '011' ).

WHEN 'M'. "Modified
WHEN 'S'. "Saved
ENDCASE.
ls_items-label_name = wd_assist->get_text( '010' ).
ls_items-label_tooltip = wd_assist->get_text( '010' ).
ls_items-value_tooltip = wd_assist->get_text( '014' ).
APPEND ls_items TO lt_items.
wd_this->go_fpm_idr->initialize_items( ).
wd_this->go_fpm_idr->add_item_group_by_val(
EXPORTING
it_items = lt_items ).
ENDMETHOD.


Exercise 8: Use the FPM Message

manager
Exercise Objectives
Display messages by means of the FPM message manager
Business Example
You would like to display messages in your application to indicate if handling
FPM-Events was successful or not.
NET313_BOOKING_S5
NET313_CUSTOMER_S6
Task 1:
Adapt your GAF application ZNET313_##_BOOKING_S1. Display an error
message if any of the following situations occur:
No flights are found for the selected customer.
No bookings are found for the selected flights (also because no flights have been
selected).
No bookings have been selected by the user.
The cancellation of the selected bookings was not successful.
1. Get the reference to the FPM message manager and store this reference in a
new attribute (name: GO_MES_MAN) in the component controller of your
GAF component.
Hint: Storing the reference to the FPM message manager in an extra

controller attribute is optional, since this reference is available as a
public attribute of the FPM service object.
2. Edit the component controller method PROCESS_EVENT( ). Get appropriate

texts from the assistance class (text symbols '001', '002', and '003'). Replace
parameters contained in the message text if necessary. Report the error
messages.

3. An FPM error message defined in the method PROCESS_EVENT( ) will

automatically cancel the navigation in the GAF application. Thus you can
delete the coding lines that are related to setting the exporting parameter
EV_RESULT to ABAP_FALSE.
Task 2:
Adapt your OIF application ZNET313_##_CUSTOMER_S1. Display an error
message if the customer data could not be saved to the data base. Display a
success message, if storing the data was successful.
OIF component.


texts from the assistance class (text symbols '004' for the error message and
'005' for the success message). Report the messages.

Solution 8: Use the FPM Message manager

Task 1:
Adapt your GAF application ZNET313_##_BOOKING_S1. Display an error
message if any of the following situations occur:
No flights are found for the selected customer.
No bookings are found for the selected flights (also because no flights have been
selected).
No bookings have been selected by the user.
The cancellation of the selected bookings was not successful.
GAF component.

a) Edit the component controller of your GAF component

ZNET313_##_BOOKING_S1.
b) Define a new controller attribute (name: GO_FPM, reference type:
IF_FPM).
c) Define a new controller attribute (name: GO_MES_MAN, reference
type: IF_FPM_MESSAGE_MANAGER).
d) Now edit the hook method WDDOINIT( ). Get the reference to the
FPM service object. Store this reference in the controller attribute
GO_FPM. The reference to the FPM message manager is stored in
the public attribute MO_MESSAGE_MANAGER of the FPM service
object. Copy this reference to the controller attribute GO_MES_MAN.


texts from the assistance class (text symbols '001', '002', and '003'). Replace
parameters contained in the message text if necessary. Report the error
messages.
a) Edit the component controller method PROCESS_EVENT( ) of your
GAF component ZNET313_##_BOOKING_S1.
b) If an error situation occurs, get the appropriate text from the assistance
class and store it in a variable of type STRING.
c) Call the FPM message manager method REPORT_MESSAGE( ) to
define the error message. Pass the error text and the reference to the
current FPM service object (GO_FPM) to the method.
d) The text with the text symbol '001' contains a parameter to display
the customer number with the message. To replace this placeholder,
get the customer ID from the context. Define a parameter table of
type WDR_NAME_VALUE_LIST and a related work area for this
internal table. Add one line to the internal table containing the name
of the placeholder (field NAME) and the value displayed instead of the
placeholder (field VALUE). Pass this replacement information via the
parameter IV_PARAMETERS to the method REPORT_MESSAGE( ).
3. An FPM error message defined in the method PROCESS_EVENT( ) will
automatically cancel the navigation in the GAF application. Thus you can
delete the coding lines that are related to setting the exporting parameter
EV_RESULT to ABAP_FALSE.

Task 2:
Adapt your OIF application ZNET313_##_CUSTOMER_S1. Display an error
message if the customer data could not be saved to the data base. Display a
success message, if storing the data was successful.
OIF component.

a) Edit the component controller of your OIF component

b) Define a new controller attribute (name: GO_MES_MAN, reference
type: IF_FPM_MESSAGE_MANAGER).
c) Now edit the hook method WDDOINIT( ). The reference to
the FPM message manager is stored in the public attribute
MO_MESSAGE_MANAGER of the FPM service object. Copy this
reference to the controller attribute GO_MES_MAN.
texts from the assistance class (text symbols '004' for the error message and
'005' for the success message). Report the messages.
a) Edit the component controller method PROCESS_EVENT( ) of your
OIF component ZNET313_##_CUSTOMER_S1.
b) Depending on the result of calling the method UPDATE_CUSTOMER(
), get the appropriate text from the assistance class and store it in a
variable of type STRING.
c) Call the FPM message manager method REPORT_MESSAGE( ) to
define the message. Pass the error text and the reference to the current
FPM service object (GO_FPM) to the method.
Hint: To set the message type success, set the interface

parameter V_SEVERITY to IF_FPM_MESSAGE_MAN-
AGER=>GC_SEVERITY_SUCCESS.

Result
GAF: Component Controller - WDDOINIT( )
METHOD wddoinit .

* get reference to FPM message manager object
wd_this->go_mes_man = wd_this->go_fpm->mo_message_manager.
* define values to be displayed by drop down box for selecting customer ID

wd_this->define_customer_vs( ).
* get the text to be displayed on the initial screen
* get the complete customer data set for the initial customer ID
wd_this->get_customer( ).
ENDMETHOD.
GAF: Component Controller - PROCESS_EVENT( )

METHOD process_event.

DATA lv_text TYPE string.
DATA lt_parameters TYPE wdr_name_value_list.
DATA ls_parameters TYPE wdr_name_value.
DATA lv_id TYPE wd_this->element_customer-id.
...
CASE lv_interface_view.
* if interface view was CUSTOMER_WINDOW, read flights for customer
* report message with parameter if no flights could be read
WHEN 'CUSTOMER_WINDOW'.
lv_result = wd_this->get_flights( ).
* ev_result = if_fpm_constants=>gc_event_result-failed.
lv_text = wd_assist->get_text( '001' ).
lo_nd_customer = wd_context->get_child_node(
name = wd_this->wdctx_customer ).

lo_el_customer->get_attribute(
EXPORTING
name = `ID`
IMPORTING
value = lv_id ).
ls_parameters-name = '1'.
ls_parameters-value = lv_id.
APPEND ls_parameters TO lt_parameters.
wd_this->go_mes_man->report_message(
iv_message_text = lv_text
io_component = wd_this->go_fpm
iv_parameters = lt_parameters ).
ENDIF.
* if interface view was FLIGHTS_WINDOW, read bookings for on flights
* report message if no bookings could be read
WHEN 'FLIGHTS_WINDOW'.
lv_result = wd_this->get_bookings( ).
io_component = wd_this->go_fpm ).
ENDIF.
* if interface view was BOOKINGS_WINDOW, check for selected bookings
* report message if no bookings were selected
WHEN 'BOOKINGS_WINDOW'.
lv_result = wd_this->get_selected_bookings( ).
ENDIF.
* if interface view was CHECK_WINDOW, try to cancel bookings on DB
* report message if cancelling bookings was not successful
WHEN 'CHECK_WINDOW'.
lv_result = wd_this->cancel_bookings( ).

ENDIF.
ENDCASE.
ENDMETHOD.

METHOD wddoinit .
* get text displayed on introduction screen

* get reference to context object.
* The context change log related to this object is used to find
* out any changes of the customer data
wd_this->go_context = wd_context->get_context( ).

* get reference to OIF service object
* get reference to IDR service object
wd_this->go_fpm_idr ?= wd_this->go_fpm->get_service(
iv_service_key = cl_fpm_service_manager=>gc_key_idr ).
* get reference to FPM message manager object

ENDMETHOD.


DATA lv_text TYPE string.
* if EDIT_TOGGLE was selected, toggle edit mode
WHEN 'EDIT_TOGGLE'.
wd_this->toggle_edit_mode( ).
* if SAVE was selected, update customer data
WHEN cl_fpm_event=>gc_event_save.
lv_result = wd_this->update_customer( ).

* if update was not successful, send message

ELSE.
* if update was successful, clear context change log...
* ... and send success message
io_component = wd_this->go_fpm
iv_severity = if_fpm_message_manager=>gc_severity_success ).
* Optional part: refresh items area (display, that changed data is saved)
wd_this->set_idr_items( iv_state = 'S' ).
ENDIF.
ENDCASE.
ENDMETHOD.

Lesson Summary
Handle FPM-Events

NET313 Unit Summary
Unit Summary
Configure the IDR
Handle FPM-Events

Unit Summary NET313

Unit 3
Generic UI Building Blocks (GUIBBs)
Unit Overview
Forms and lists are used frequently on the UI of Web Dynpro applications. In the
FPM context, generic WD components exist to display a single data set by a form
(FORM GUIBB) or multiple data sets by a table (LIST GUIBBs).
In the first lesson of this unit, the general architecture of a WD application which
is based on the FPM framework and which is reusing generic UI building blocks
is discussed. In addition, the general aspects of special global classed (feeder
classes) that are used to provide the data displayed by the GUIBBs are covered.
The configuration of the FORM GUIBB and of the LIST GUIBB and the specific
aspects of the related feeder classes are explained in the two consecutive lessons.
Unit Objectives
Describe the architecture of FPM applications which are based on GUIBBs.

Describe the interaction between GUIBBs and feeder classes.
Create feeder classes.
Define a feeder class related to the FORM GUIBB.
Implement the most important methods of this feeder class
Configure the FORM GUIBB.
Define a feeder class related to the LIST GUIBB.
Configure the LIST GUIBB.
Unit Contents
Lesson: Generic UI Building Blocks - general Aspects ....................160
Lesson: The FORM GUIBB ...................................................167
Exercise 9: FORM GUIBB - Define Feeder Class, use Central Data
Model and configure the GUIBB ..........................................185
Lesson: The LIST GUIBB......................................................201
Exercise 10: LIST GUIBB - Define Feeder Class and configure
Component ..................................................................213

Unit 3: Generic UI Building Blocks (GUIBBs) NET313
Lesson: Generic UI Building Blocks - general Aspects
Lesson Overview
This lesson summarizes the architecture of FPM applications making use of
generic UI building blocks (GUIBBs). In addition, feeder classes are discussed.
Feeder classes are used to retrieve the data displayed by the GUIBB. In addition,
they control all variable aspects in respect to the configuration process and the
runtime behavior of GUIBBs.
Lesson Objectives
Business Example
You would like to assure, that all forms and lists displayed by your FPM
applications have a consistent look and feel.
Architecture
Generic UI Building Blocks (GUIBBs) allow to display data provided by special
classes (feeder classes) based on a predefined UI pattern. The layout of GUIBBs is
not designed freely by the application developer, but configured using the Web
Dynpro configuration editor. This reduces the degree of freedom in respect to:
the type of UI elements which can be used to define the layout
the positioning of the UI elements in the layout
the UI element properties that may be adjusted by the developer
Thus, using GUIBBs guarantees a consistent look and feel of floorplan
applications. In addition, the UI provided by GUIBBs can be adjusted via
component configuration and thus without any modification.
The following drawing summarizes the basic architecture of FPM applications.
The Web Dynpro application points on an FPM component which embeds the IDR
component (to display the page header) and one or multiple sub components. The
interface views of the embedded sub components (UIBBs) are embedded in the
window of the FPM component to implement the desired floorplan.

NET313 Lesson: Generic UI Building Blocks - general Aspects
To define which interface view of which sub component is related to which

floorplan element, standard Web Dynpro configuration is used. Thus, the FPM
component needs to be configured. An application configuration needs to be
created to define which component configuration is used for the FPM component
at runtime.
In general, UIBBs defined by the application developer (freestyle UIBBs) do not
need to be configured. However, it is possible to adapt UI element properties via
configuration, customizing, or personalization to change the layout of the UIBBs
without modifications.
Figure 76: FPM based Web Dynpro ABAP applications - architecture
GUIBBs are highly flexible UIBBs, that allow to define a pattern-based layout
(form, list, tab strip). The exact layout has to be configured. The information pool
available for the configuration process (design time) is controlled by a so called
feeder class. At runtime, this class will also supply the corresponding data and
care for events triggered by the user. Thus, multiple forms (or lists or tabs) can
be defined by assigning different feeder classes to the corresponding GUIBB
component via configuration. If an FPM application is based entirely on GUIBBs,
all coding related to the application is contained by the feeder classes or in other
global classes referenced by the feeder classes.

Feeder Classes
Figure 77: Feeder classes
Feeder classes are used to provide the application specific information necessary to
configure a GUIBB at design time and to display the application data and handle
the events triggered by the user at runtime. These classes need to implement a
predefined interface which depends on the type of the related GUIBB:
FORM GUIBB:
Component: FPM_FORM_UIBB
Feeder class needs to implement interface IF_FPM_GUIBB_FORM.
LIST GUIBB:
Component: FPM_LIST_UIBB
Feeder class needs to implement interface IF_FPM_GUIBB_LIST.
TABBED GUIBB:
Component: FPM_TABBED_UIBB
No feeder class necessary (statical assignment of UIBBs to tabs defined
by GUIBB).
The interfaces IF_FPM_GUIBB_FORM and IF_FPM_GUIBB_LIST embed the
interface IF_FPM_GUIBB.

Additional interfaces (IF_FPM_GUIBB_FORM_EXT and

IF_FPM_GUIBB_LIST_EXT) exist for the FORM GUIBB and the
LIST GUIBB, respectively. These interfaces encapsulate methods that are not
used as frequently as the methods of the main interfaces.
The following methods are of special interest:
Methods processed during initialization of the feeder class:

GET_PARAMETER_LIST( ):
Defines a list of parameters supported by the feeder class. These
parameters can be evaluated during the configuration process of the
GUIBB.
INITIALIZE( ):
Initializes attributes used in feeder: In addition, the current values of
the parameters as defined by configuration are supplied to this method
by the WD runtime.
GET_DEFINITION( ):
Provides the field catalog (list of fields that may be displayed together
with their properties) and the list of actions to be assigned to the UI
elements displayed by the GUIBB.
Methods processed each time a GUIBB is processed:
FLUSH( ):
Receives data changed by the user. If multiple UIBBs are used, the
current field values can be passed to a central data object at this point
of time.
PROCESS_EVENT( ):
Handles events triggered by the user.
GET_DATA( ):
Provides data to be displayed by the next GUIBB.
NEEDS_CONFIRMATION( ):
Sends data loss popup if needed.
Only the methods GET_DEFINITION( ) and GET_DATA( ) are mandatory.
However, all methods defined in the feeder class need at least empty
implementations.
All methods listed above but the method NEEDS_CONFIRMATION( ) are
contained in the interfaces IF_FPM_GUIBB_LIST and IF_FPM_GUIBB_FORM.
NEEDS_CONFIRMATION( ) is defined in the extended interface (suffix _EXT).

The signature of all methods but GET_PARAMETER_LIST( ), INITIALIZE( ) and

NEEDS_CONFIRMATION( ) depend on the interface they belong to.
Impact on the Phase Model

In general, an FPM application will be made up of freestyle UIBBs and GUIBBs.
The following screenshots illustrate how the phase model is influenced by the type
of UIBB. Only the editable methods of the freestyle UIBBs and of the feeder
classes are displayed.
Note: The method NEEDS_CONFIRMATION( ) is not included in the

screenshots.
If a GUIBB is the target of a navigation, then only the method GET_DATA( ) of

the related feeder class will be triggered. Here, the data to be displayed by the
next GUIBB has to be passed to this GUIBB. In addition, the GUIBB has to be
informed about all changes in respect to the UI element properties and in respect
to the usage of actions.
If the GUIBB has not been displayed before, the methods GET_PARAME-
TER_LIST( ), INITIALIZE( ), and GET_DEFINITION( ) of the related feeder class
are processed just before GET_DATA( ) is triggered.
If a GUIBB is the starting point of a navigation, then the methods FLUSH( )
and PROCESS_BEFORE_OUTPUT( ) of the related feeder class are triggered at
the beginning of the phase model. Afterwards, the methods related to the target
UIBB are triggered.
Figure 78: Phase model when navigating - replacing target UIBB by GUIBB

Figure 79: Phase model when navigating - replacing initial UIBB by GUIBB
Figure 80: Phase model - navigation between GUIBBs

Lesson Summary

NET313 Lesson: The FORM GUIBB
Lesson: The FORM GUIBB
Lesson Overview
This lesson explains how to configure the FORM GUIBB and how to implement
the methods in the related feeder class.
Lesson Objectives
Business Example
You would like to define UIBBs containing forms by using the corresponding
GUIBB provided by the Web Dynpro framework.
Component Configuration and GUIBB Method

Implementation
Typically, defining a component configuration for a GUIBB is conducted as
follows:
First, the component configuration of the FPM component (OIF or GAF) is
edited in the configuration editor for FPM components.
The UIBB component FPM_FORM_UIBB is assigned to a sub view (OIF)
or to a roadmap step (GAF) by entering the component's name in the field
with the label Component. Choose FORM_WINDOW as the name of the
interface view to embed (field with label View).
The GUIBB component needs to be configured. Thus enter the name of the
component configuration for the GUIBB component in the field with label
Configuration Name.
Start the configuration process of the GUIBB component by clicking
the button labeled Configure UIBB located in the preview region of the
configuration editor.

Figure 81: Start configuring the FORM GUIBB
The configuration editor for Web Dynpro will be opened in a new browser
window. Click Create to create the component configuration for the FORM
GUIBB. Complete the popups asking for description, package assignment,
and transport request.
Now, a dialog box pops up asking for the feeder class. Enter the
name of the corresponding feeder class. This class has to implement
the interface IF_FPM_GUIBB_FORM and optionally the interface
IF_FPM_GUIBB_FORM_EXT.
Click Edit Parameters.

Figure 82: Create component configuration and assign feeder class
If parameters have not been defined in the feeder class, a popup displaying a
success message will be displayed. In this case, finish the dialog.
If parameters have been defined in the feeder class, the value of each
parameter can be adjusted on the next popup. For each parameter, a label
/ input field pair will be displayed.
The type of each parameter will typically be defined by a data element
which is based on a domain having fixed values. In this case, the label will
originate from the long text of the data element, while the allowed values
will equal the domain fixed values.

Figure 83: Set parameter values
In order to define the parameter list, the feeder class method

GET_PARAMETER_LIST( ) needs to be edited. For each parameter, a line has
to be appended to the returning parameter RT_PARAMETER_DESCR . Each line
contains the parameter's name (field NAME) and the parameter's type (field TYPE).

Figure 84: Define parameters - feeder class method GET_PARAMETER_LIST(

)
Next, the view's layout needs to be structured. Here, one or multiple groups
may be used as container elements. All groups will be defined on the same
hierarchy level (groups may not be defined as children of existing groups).
For each group, the group's caption can be set. In addition, each group can
occupy the complete page width or only half of the page with. A group
occupying the complete page with can display its form fields in one column
or in two columns.
Melting groups (not discussed here) can be defined as sub elements of a
group. A melting group occupies the space of one form field. However,
multiple form fields can be contained by a melting group.

Figure 85: Defining groups and group properties
Form fields may be assigned to any group (or melting group). This group has
to be marked in the hierarchy view.
Then the button Configure Group (Configure Melting Group) has to be
clicked.
A dialog box pops up displaying a number of fields. An arbitrary number
of fields can be marked. Clicking the button Add Fields will add them to
the group.
Optionally, each field of the field selection may be assigned to a field group.
This is meaningful is the field selection contains a large number of field. In
this case a drop down box in the upper left corner of the popup allows to
select the field group. Then, only fields assigned to this field group will be
displayed by the left table.

Figure 86: Defining form fields
The field selection, the properties of each field, the field groups and the assignment
of each field to a field group has to be defined by the content of method
GET_DEFINITION( ):
The field selection has to be defined by a RTTI description of type
CL_ABAP_STRUCTDESCR which is returned to the framework via the exporting
parameter EO_FIELD_CATALOG.

Figure 87: Defining field catalog
For each of the fields contained in the field catalog, properties have to be set
and returned via the exporting parameter ET_FIELD_DESCRIPTION. If a field
should be available during the configuration process, its visibility has to be set to
CL_WD_UIELEMENT=>E_VISIBLE-VISIBLE. Other properties are defined in
the ABAP Dictionary structure FPMGB_S_FORMFIELD_DESCR.
Hint: Some of the properties set in the method GET_DEFINITION( ) may

be adjusted at runtime from the method GET_DATA( ) via the exporting
parameter CT_FIELD_USAGE. These properties - described by the
ABAP DDIC structure FPMGB_S_FIELDUSAGE - are: READ_ONLY,
MANDATORY, ENABLED, LABEL_TEXT, HELP_TEXT, LINK,
VISIBILITY, and FIXED_VALUES.

Figure 88: Setting form field properties (1)
Figure 89: Setting form field properties (2)

In order to assign the form fields to field groups, these field groups need to be
defined first. This is also done in method GET_DEFINITION( ). Here, the
exporting parameter ET_SPECIAL_GROUPS is used to inform the framework
about the internal group names and the names displayed in the configuration editor.
Figure 90: Defining field groups
After having defined which form fields are to be displayed in which group, the
form field properties can be configured:
The form field has to be marked in the hierarchy view.
The following properties can then be configured: The type of UI element
(Display Type), the visibility of the label (Label Visibility), and the label text
(Text - this will overwrite the text obtained from the ABAP DDIC).
Additional properties do depend on the type of UI element used to display
the form field.
If the client side event related to the form field should related to an action,
the button Assign Action has to be clicked. All bindable actions are displayed
by a dialog box popping up.

Figure 91: Configure form field properties
The actions displayed by the dialog box need to be defined in the method
GET_DEFINITION( ). Here, the exporting parameter ET_ACTION_DEFINITION
is used to inform the WD runtime.

Figure 92: Define list of actions that may be assigned to form fields
After having configured all form field properties, this component configuration
can be saved and the configuration process is finished.
Runtime Aspects: INITIALIZE( )

At runtime, the methods GET_PARAMETER_LIST( ), INITIALIZE( ), and
GET_DEFINITION( ) are processed once for each feeder class instance. Typically,
the method INITIALIZE( ) encapsulates the code to:
get the references to the FPM service object

get additional references to the IDR service object and the floorplan specific
service object
instantiate the central data object (or get the reference to the object if it has
been initialized before)
create an instantiate of the assistance class
initialize global attributes of the feeder class instance
store parameter values provided by the interface parameter IT_PARAMETER
as values of global attributes of the feeder class instance
Caution: The methods GET_PARAMETER_LIST( ), INITIALIZE( ), and

GET_DEFINITION( ) are also processed when configuring the FORM
GUIBB. However, during configuration, the FPM component is not

available and the references to the corresponding service objects can

not be determined. Thus, the related source code sections may only be
processed if the FPM service object can be determined.
Hint: Parameter values set via configuration can only be accessed in

the method INITIALIZE( ).
Figure 93: Method INITIALIZE( )
Runtime Aspects: FLUSH( )

The method FLUSH( ) is the first method processed for the GUIBB displayed
before navigation. The following aspects should be handled by this method:
check for changes of the form field values

actualize global data of feeder class instance and central data object.

Figure 94: Method FLUSH( )
Runtime Aspects: PROCESS_EVENT( )

The method PROCESS_EVENT( ) is the second method processed for the
GUIBB displayed before navigation. The following aspects should be handled by
this method:
identify the FPM-Event triggered by the user or by the application

programmatically
handle FPM-Event
inform WD runtime if event handling failed
send messages to inform user about success of event handling
If the event handling was not successful, the WD runtime can be informed by
setting the exporting parameter EV_RESULT accordingly. In this case, the method
AFTER_FAILED_EVENT( ) will be processed before navigation takes place.
Messages can be defined by calling the appropriate methods of the FPM message
manager. However, each message can also be defined by appending a structure
containing the message details to the exporting parameter ET_MESSAGES.

Figure 95: Method PROCESS_EVENT( )
Runtime Aspects: GET_DATA( )

The method GET_DATA( ) is the first method processed for the GUIBB displayed
after navigation. The following aspects should be handled by this method:
check if the data to be displayed by the form has been changed

programmatically
check if the properties of the form fields have to be modified
check if the action usage has to be adapted
in each of the cases inform the WD runtime about the changes
If the data to be displayed has been changed programmatically, the current data has
to be exported to the GUIBB via the changing parameter CS_DATA. In addition
the exporting parameter EV_DATA_CHANGED has to be set to ABAP_TRUE.

Figure 96: Method GET_DATA( ) - change form data
If the properties of the form fields have to be modified, the new form field properties
have to be exported to the GUIBB via the changing parameter CT_FIELD_USAGE.
In addition the exporting parameter EV_FIELD_USAGE_CHANGED has to be set
to ABAP_TRUE.

Figure 97: Method GET_DATA( ) - change form field properties
If the action usage has to be modified, the actualized action usage has to be
exported to the GUIBB via the changing parameter CT_ACTION_USAGE. In
addition the exporting parameter EV_ACTION_USAGE_CHANGED has to be set
to ABAP_TRUE.

Figure 98: Method GET_DATA( ) - change action usage
Runtime Aspects: NEEDS_CONFIRMATION( )

The method NEEDS_CONFIRMATION( ) is defined in the extension interface
IF_FPM_GUIBB_FORM_EXT. This method is processed if the user clicks the
CLOSE button. In this case, a data loss popup can be send to indicate that data
has not been saved yet. For details, please refer to the corresponding method
defined in the interface IF_FPM_UI_BUILDING_BLOCK. This is described in
the previous unit.

Exercise 9: FORM GUIBB - Define Feeder

Class, use Central Data Model and
configure the GUIBB
Exercise Objectives
Define the feeder class for the FORM GUIBB.
Implement the source code of the feeder class methods.
Use a central data model.
Business Example
You would like to define the customer form of your OIF application via
configuration of the corresponding generic UIBB. However, this also means that
you have to create the feeder class and you have to implement the methods of this
class. In addition, you need to exchange data between this feeder class and the
OIF component. Thus, you need to use a simple central data model.
Template Feeder Class:
CL_NET313_FORM_GUIBB_T
Solution Component:
NET313_CUSTOMER_S7
Solution Feeder Class:
CL_NET313_FORM_GUIBB
Central Data Model Class:
CL_NET313_CENTRAL_DATA
Solution Component Configuration:
NET313_CUSTOMER_S7_CC1 (FPM component)
NET313_CUSTOMER_S7_CC_FORM (FORM GUIBB)

Task 1:
OPTIONAL TASK:
Complete the feeder class to be used by the FORM GUIBB. Copy the template
CL_NET313_FORM_GUIBB_T. Name your copy ZCL_##_NET313_FORM.
The template contains the all methods and attributes needed to implement the
feeder class. You only need to complete the methods FLUSH( ), GET_DATA( ),
and GET_DEFINITION( ).
Implement the source code: The feeder class should not support parameters. All
fields of the DDIC structure SCUSTOM but the field MANDT should be available
for the configuration process. All fields should not be editable. The labels of the
fields and the lengths of the fields should be obtained from the DDIC description.
The feeder class should allow to replace the customer form of your application
by the FORM GUIBB.
1. Create the feeder class to be used by the FORM GUIBB by copying
the template CL_NET313_FORM_GUIBB_T. Name your class
ZCL_##_NET313_FORM.
2. Implement the source code of feeder class method GET_DEFINITION( ).
The source code consists of the following steps:
Get the RTTI description of the DDIC structure SCUSTOM (use method
CL_ABAP_TYPEDESCR=>DESCRIBE_BY_NAME( ) ).
Pass this description to the exporting parameter EO_FIELD_CATALOG.
Get the components from the RTTI description of the DDIC structure
SCUSTOM (use method GET_COMPONENTS( ) for RTTI structure
description).
Loop over the component list.
For each component, define a new line of the exporting parameter
ET_FIELD_DESCRIPTION.
Set NAME = name of structure component.
Set VISIBILITY = CL_WD_UIELEMENT=>E_VISIBLE-VISIBLE for
all structure components but the component MANDT. Set VISIBILITY =
CL_WD_UIELEMENT=>E_VISIBLE-NONE for the component MANDT.
Set READ_ONLY = ABAP_TRUE, LABEL_BY_DDIC = ABAP_TRUE, and
LENGTH_BY_DDIC = ABAP_TRUE for all structure components.
3. Complete the source code of feeder class method FLUSH( ). This consists
of the following steps:
Check if the user changed any form data during the last application
step. This is done by analyzing the content of the importing parameter
IT_CHANGE_LOG.

If this internal table is not empty, proceed processing the method. Get the
current form data from the reference variable IS_DATA. De-reference this
data reference into a field symbol of type SCUSTOM. Store the customer
data in the feeder class attribute GS_CUSTOMER.
Store the information, that the customer data has been changed by the user: Set
the central data model attribute GO_CENTRAL_DATA->GV_SAVE_DATA
to ABAP_TRUE.
Call the methods SET_IDR_TICKET( ) and SET_IDR_ITEMS( ). Pass the
customer data set to the first method and the literal 'M' (modified) to the
second method.
4. Complete the source code of feeder class method GET_DATA( ). This
consists of the following steps:
Check, whether the value of the feeder class attribute GS_CUSTOMER
has been changed during the current dialog step (GV_DATA_CHANGED
= ABAP_TRUE).
In this case, set CS_DATA = GS_CUSTOMER and EV_DATA_CHANGED
= ABAP_TRUE. This will force the WD runtime to actualize the form
data displayed to the user. In addition set GV_DATA_CHANGED =
ABAP_FALSE.
Set the readOnly property of the form fields according to the current value of
the feeder class attribute GV_READ_ONLY:
Loop over the changing parameter CT_FIELD_USAGE. Modify the
value of the field READ_ONLY for each data set. In addition set
EV_FIELD_USAGE_CHANGED = ABAP_TRUE. This will force the WD
runtime to update the form field properties.
Enable the button labeled Display/Change Customer.
5. Save and activate your feeder class.

Task 2:
Adapt your OIF component assuming that the customer form is defined by the
FORM GUIBB:
Delete all WD entities which are not needed any more.
Delete all component controller methods, attributes, and context nodes that are
not needed any more.
Adapt the remaining component controller methods of your OIF component.
Work on attributes of the central data model (GO_CENTRAL_DATA-
>GV_SAVE_DATA, GO_CENTRAL_DATA->GV_CUSTOM_ID) instead of
component controller attributes.
Add a component controller attribute to store the reference to the central data
model. Set the value of this attribute in the controller method WDDOINIT( ).
Implement the component controller method FLUSH( ). If the last interface view
displayed to user was INTRO_WINDOW, pass the customer ID selected by the user
to the central data model attribute GO_CENTRAL_DATA->GV_CUSTOM_ID.
1. Delete the view CUSTOMER_VIEW and the window CUSTOMER_WIN-
DOW.
2. In the component controller context, delete the context node
UI_ELEM_PROPERTIES.
3. Delete the component controller attribute GO_CONTEXT. Delete all coding
sections referring to this attribute.
4. Delete the component controller methods INIT_IDR( ),
TOGGLE_EDIT_MODE( ), UPDATE_CUSTOMER( ),
GET_CUSTOMER( ) and - if you have created them in the related optional
exercise - SET_IDR_ITEMS( ) and SET_IDR_TICKET( ).
5. Create the controller attribute GO_CENTRAL_DATA of reference type
CL_NET313_CENTRAL_DATA. Get the reference to the central data model
in method WDDOINIT( ).
6. Implement the source code of the component controller method FLUSH( ).
Replace the existing source code as follows:
If the last interface view displayed to user was INTRO_WINDOW,
read the customer ID from the context (node CUSTOMER_ID).
Copy the customer ID to the central data model attribute
GO_CENTRAL_DATA->GV_CUSTOM_ID.

7. Adapt the source code of the component controller method

NEEDS_CONFIRMATION( ). Instead of checking the
context change log, check the central data model attribute
GO_CENTRAL_DATA->GV_SAVE_DATA in order to decide, if a data loss
popup is to be displayed.
PROCESS_BEFORE_OUTPUT( ). Disable the button labeled
Display/Change Customer (this method is not processed for the FORM
GUIBB). Delete all other code.
PROCESS_EVENT( ). Delete the complete source code.
10. Save and activate your OIF component.
Task 3:
Edit the component configuration of your OIF component. On the tab displaying
the customer form, replace the UIBB of your OIF component by the FORM
GUIBB. Use the feeder class defined in the last task or the template feeder class.
Copy the layout of the freestyle UIBB by configuring the FORM GUIBB.
1. Edit your component configuration ZNET313_##_CUSTOMER_S1_CC1.
2. On the first tab (Customer) replace the interface view CUSTOMER_WINDOW
of your OIF component by the interface view FORM_WINDOW of the
GUIBB component FPM_FORM_UIBB. Assign a component configuration
to the FORM GUIBB (name: ZNET313_##_CUSTOMER_S1_CC_FORM).
3. Create the component configuration for the FORM GUIBB. Use your feeder
class ZCL_##_NET313_FORM. If you have not created your own feeder
class, use feeder class CL_NET313_FORM_GUIBB.
4. Copy the layout of the freestyle UIBB by configuring the FORM GUIBB.
Output the form fields as input fields in a two column layout. Assign a
header text to the surrounding group.
Task 4:
Test your FPM application.
1. Start the FPM application displaying the OIF. Check the functionality of
your application (change customer data, save data, check if toolbar button
labeled Display/Change Customer is disabled if bookings are displayed ...).

Solution 9: FORM GUIBB - Define Feeder

Class, use Central Data Model and
configure the GUIBB
Task 1:
OPTIONAL TASK:
Complete the feeder class to be used by the FORM GUIBB. Copy the template
CL_NET313_FORM_GUIBB_T. Name your copy ZCL_##_NET313_FORM.
The template contains the all methods and attributes needed to implement the
feeder class. You only need to complete the methods FLUSH( ), GET_DATA( ),
and GET_DEFINITION( ).
Implement the source code: The feeder class should not support parameters. All
fields of the DDIC structure SCUSTOM but the field MANDT should be available
for the configuration process. All fields should not be editable. The labels of the
fields and the lengths of the fields should be obtained from the DDIC description.
The feeder class should allow to replace the customer form of your application
by the FORM GUIBB.
1. Create the feeder class to be used by the FORM GUIBB by copying
the template CL_NET313_FORM_GUIBB_T. Name your class
ZCL_##_NET313_FORM.
a) Copying a class should be known to you.
b) The following instance attributes are already defined in the class:
GO_FPM: Reference to FPM service object.
GO_FPM_IDR: Reference to IDR service object.
GO_FPM_OIF: Reference to OIF service object.
GO_MES_MAN. Reference to FPM message manager object.
GO_ASSIST: Reference to assistance object.
GO_CENTRAL_DATA of reference type CL_NET313_CEN-
TRAL_DATA: Reference to singleton instance of central data model.
GS_CUSTOMER: Complete customer data set.
GV_READ_ONLY: Information if form fields are to be displayed
read-only.
GV_DATA_CHANGED: Information if customer data have been
changed by the application.


Get the RTTI description of the DDIC structure SCUSTOM (use method
CL_ABAP_TYPEDESCR=>DESCRIBE_BY_NAME( ) ).
Pass this description to the exporting parameter EO_FIELD_CATALOG.
Get the components from the RTTI description of the DDIC structure
SCUSTOM (use method GET_COMPONENTS( ) for RTTI structure
description).
For each component, define a new line of the exporting parameter
ET_FIELD_DESCRIPTION.
Set NAME = name of structure component.
Set READ_ONLY = ABAP_TRUE, LABEL_BY_DDIC = ABAP_TRUE, and
LENGTH_BY_DDIC = ABAP_TRUE for all structure components.
3. Complete the source code of feeder class method FLUSH( ). This consists
of the following steps:
Check if the user changed any form data during the last application
step. This is done by analyzing the content of the importing parameter
IT_CHANGE_LOG.
If this internal table is not empty, proceed processing the method. Get the
current form data from the reference variable IS_DATA. De-reference this
data reference into a field symbol of type SCUSTOM. Store the customer
data in the feeder class attribute GS_CUSTOMER.
Store the information, that the customer data has been changed by the user: Set
the central data model attribute GO_CENTRAL_DATA->GV_SAVE_DATA
to ABAP_TRUE.
Call the methods SET_IDR_TICKET( ) and SET_IDR_ITEMS( ). Pass the
customer data set to the first method and the literal 'M' (modified) to the
second method.

Check, whether the value of the feeder class attribute GS_CUSTOMER

has been changed during the current dialog step (GV_DATA_CHANGED
= ABAP_TRUE).
In this case, set CS_DATA = GS_CUSTOMER and EV_DATA_CHANGED
= ABAP_TRUE. This will force the WD runtime to actualize the form
data displayed to the user. In addition set GV_DATA_CHANGED =
ABAP_FALSE.
Set the readOnly property of the form fields according to the current value of
the feeder class attribute GV_READ_ONLY:
Loop over the changing parameter CT_FIELD_USAGE. Modify the
value of the field READ_ONLY for each data set. In addition set
EV_FIELD_USAGE_CHANGED = ABAP_TRUE. This will force the WD
runtime to update the form field properties.
Enable the button labeled Display/Change Customer.
a) You know how to do this ...
Task 2:
Adapt your OIF component assuming that the customer form is defined by the
FORM GUIBB:
Adapt the remaining component controller methods of your OIF component.
Work on attributes of the central data model (GO_CENTRAL_DATA-
>GV_SAVE_DATA, GO_CENTRAL_DATA->GV_CUSTOM_ID) instead of
component controller attributes.
Add a component controller attribute to store the reference to the central data
model. Set the value of this attribute in the controller method WDDOINIT( ).
Implement the component controller method FLUSH( ). If the last interface view
displayed to user was INTRO_WINDOW, pass the customer ID selected by the user
to the central data model attribute GO_CENTRAL_DATA->GV_CUSTOM_ID.
1. Delete the view CUSTOMER_VIEW and the window CUSTOMER_WIN-
DOW.
a) Deleting should not be a problem ...

2. In the component controller context, delete the context node

UI_ELEM_PROPERTIES.
3. Delete the component controller attribute GO_CONTEXT. Delete all coding
sections referring to this attribute.
4. Delete the component controller methods INIT_IDR( ),
TOGGLE_EDIT_MODE( ), UPDATE_CUSTOMER( ),
GET_CUSTOMER( ) and - if you have created them in the related optional
exercise - SET_IDR_ITEMS( ) and SET_IDR_TICKET( ).
5. Create the controller attribute GO_CENTRAL_DATA of reference type
CL_NET313_CENTRAL_DATA. Get the reference to the central data model
in method WDDOINIT( ).
6. Implement the source code of the component controller method FLUSH( ).
Replace the existing source code as follows:
If the last interface view displayed to user was INTRO_WINDOW,
read the customer ID from the context (node CUSTOMER_ID).
Copy the customer ID to the central data model attribute
GO_CENTRAL_DATA->GV_CUSTOM_ID.
NEEDS_CONFIRMATION( ). Instead of checking the
context change log, check the central data model attribute
GO_CENTRAL_DATA->GV_SAVE_DATA in order to decide, if a data loss
popup is to be displayed.
PROCESS_BEFORE_OUTPUT( ). Disable the button labeled
Display/Change Customer (this method is not processed for the FORM
GUIBB). Delete all other code.
PROCESS_EVENT( ). Delete the complete source code.
a) Deleting is easy ...


Task 3:
the customer form, replace the UIBB of your OIF component by the FORM
GUIBB. Use the feeder class defined in the last task or the template feeder class.
Copy the layout of the freestyle UIBB by configuring the FORM GUIBB.
a) Edit the component configuration ZNET313_##_CUSTOMER_S1_CC1.
b) Double click the corresponding item in the object tree of the Object
area.
c) Click on the button labeled Start Configurator. This will open the
d) Click the button Change in the component configuration editor.
2. On the first tab (Customer) replace the interface view CUSTOMER_WINDOW
of your OIF component by the interface view FORM_WINDOW of the
GUIBB component FPM_FORM_UIBB. Assign a component configuration
to the FORM GUIBB (name: ZNET313_##_CUSTOMER_S1_CC_FORM).
a) Mark the UIBB related to the first tab in the hierarchy. The attributes
related to this UIBB will be displayed below the preview area.
b) Enter FPM_FORM_UIBB in the field labeled Component.
c) Enter FORM_WINDOW in the field labeled View.
d) Enter ZNET313_##_CUSTOMER_S1_CC_FORM in the field labeled
Configuration Name.
e) Save.

3. Create the component configuration for the FORM GUIBB. Use your feeder
class ZCL_##_NET313_FORM. If you have not created your own feeder
class, use feeder class CL_NET313_FORM_GUIBB.
a) Click the button Configure UIBB which is displayed in the preview
area for the FORM GUIBB.
b) On the next screen, click the button Create.
c) Enter a description, your package name and the key of your transport
request in the related fields of next two popups.
d) When being asked for the feeder class, enter the name of your feeder
class (ZCL_##_NET313_FORM) in the form field. If you have not
created your own feeder class, enter the name of the template solution
(CL_NET313_FORM_GUIBB). Click the button Edit Parameters. On
the next dialog, click OK.
4. Copy the layout of the freestyle UIBB by configuring the FORM GUIBB.
Output the form fields as input fields in a two column layout. Assign a
header text to the surrounding group.
a) Click the button labeled Add Group in order to create a new group.
b) Set the group's attributes as follows:
Text = Details for Customer, Group Type = F2 (full with, two columns).
c) Click the button Configure Group.
d) Mark the fields you would like to display in the table on the left side
(CTRL + left mouse click). Then click the button Add Fields.
Note: The fields having an odd index will be displayed in the
left column of the form, the fields having an even index will be
displayed on the right side. Click OK to finish the dialog.
e) Save.
Task 4:
1. Start the FPM application displaying the OIF. Check the functionality of
your application (change customer data, save data, check if toolbar button
labeled Display/Change Customer is disabled if bookings are displayed ...).
FPM application.

b) The customer form displayed on the first tab is now provided by the
FORM GUIBB.
Result
OPTIONAL TASK: CL_NET313_FORM_GUIBB -
IF_FPM_GUIBB~GET_DEFINITION( )
METHOD if_fpm_guibb_form~get_definition.
DATA lt_component_tab TYPE abap_component_tab.

DATA ls_component_tab LIKE LINE OF lt_component_tab.
DATA ls_action TYPE fpmgb_s_actiondef.
DATA ls_field_description TYPE fpmgb_s_formfield_descr.
* Get RTTI description of DDIC structure SCUSTOM

eo_field_catalog ?= cl_abap_typedescr=>describe_by_name( 'SCUSTOM' ).
* Get single components of structure

lt_component_tab = eo_field_catalog->get_components( ).
* Define component's properties

LOOP AT lt_component_tab INTO ls_component_tab.
* Name
ls_field_description-name = ls_component_tab-name.
* Visibility
IF ls_field_description-name = 'MANDT' .
ls_field_description-visibility = cl_wd_uielement=>e_visible-none.
ELSE.
ls_field_description-visibility = cl_wd_uielement=>e_visible-visible.
ENDIF.
* Read only mode
ls_field_description-read_only = abap_true.
* Label and length
ls_field_description-label_by_ddic = abap_true.
ls_field_description-length_by_ddic = abap_true.
APPEND ls_field_description TO et_field_description.
ENDLOOP.
ENDMETHOD.

IF_FPM_GUIBB_FORM~FLUSH( )
METHOD if_fpm_guibb_form~flush.
DATA ls_change_log TYPE fpmgb_s_changelog.

DATA lv_lines TYPE i.
FIELD-SYMBOLS <ls_customer> TYPE scustom.
* Any changes?
lv_lines = LINES( it_change_log ).
IF lv_lines = 0.
RETURN.
ENDIF.
* Overwrite old values with new values

ASSIGN is_data->* TO <ls_customer> CASTING.
gs_customer = <ls_customer>.
* Data have been changed by the user, but have not been written to database yet
go_central_data->gv_save_data = abap_true.
* Optional part: Actualize IDR

set_idr_items( iv_state = 'M' ).
set_idr_ticket( is_customer = gs_customer ).
ENDMETHOD.

IF_FPM_GUIBB_FORM~GET_DATA( )
METHOD if_fpm_guibb_form~get_data.
DATA ls_field_usage LIKE LINE OF ct_field_usage.

DATA ls_action_usage LIKE LINE OF ct_action_usage.
* Actualize data
IF gv_data_changed = abap_true.
cs_data = gs_customer.
ev_data_changed = gv_data_changed.
gv_data_changed = abap_false.
ENDIF.
* Actualize field properties

LOOP AT ct_field_usage INTO ls_field_usage.
CHECK NOT ls_field_usage-name = 'ID'.
ls_field_usage-read_only = gv_read_only.
MODIFY ct_field_usage FROM ls_field_usage.
ENDLOOP.
ev_field_usage_changed = abap_true.

* Actualize FPM button

go_fpm_oif->define_button(
iv_enabled = abap_true ).
ENDMETHOD.

METHOD wddoinit .
* wd_this->go_context = wd_context->get_context( ).
* get reference to central data object.
wd_this->go_central_data =
cl_net313_central_data=>get_instance( ).
wd_this->go_fpm_idr ?= wd_this->go_fpm->get_service(
ENDMETHOD.
OIF: Component Controller - FLUSH( )

METHOD flush.

DATA lo_nd_customer_id TYPE REF TO if_wd_context_node.
DATA lo_el_customer_id TYPE REF TO if_wd_context_element.
DATA lv_id TYPE wd_this->element_customer_id-id.
* check for name of IF view displayed on previous screen

IF sy-subrc <> 0.
RETURN.
ENDIF.
* if last IF was INTRO_WINDOW, pass customer-id to central data object

IF lv_interface_view = 'INTRO_WINDOW'.
lo_nd_customer_id = wd_context->get_child_node( name = wd_this->wdctx_customer_id ).
lo_el_customer_id = lo_nd_customer_id->get_element( ).
lo_el_customer_id->get_attribute(
EXPORTING
name = `ID`
IMPORTING
value = lv_id ).
wd_this->go_central_data->gv_custom_id = lv_id.
ENDIF.
ENDMETHOD.

WHEN cl_fpm_event=>gc_event_close.
IF wd_this->go_central_data->gv_save_data = abap_true.
eo_confirmation_request = cl_fpm_confirmation_request=>go_data_loss.
ENDIF.
ENDCASE.
ENDMETHOD.

ENDMETHOD.

ENDMETHOD.

Lesson Summary

NET313 Lesson: The LIST GUIBB
Lesson: The LIST GUIBB
Lesson Overview
This lesson explains how to configure the LIST GUIBB and how to implement
the methods in the related feeder class.
Lesson Objectives
Business Example
You would like to define UIBBs containing lists by using the corresponding
GUIBB provided by the Web Dynpro framework.
Configuration of the GUIBB and Implementation of the

Feeder Class
Typically, defining a component configuration for the LIST GUIBB is conducted
as follows:
First, the component configuration of the FPM component (OIF or GAF) is
edited in the configuration editor for FPM components.
The UIBB component FPM_LIST_UIBB is assigned to a sub view (OIF) or
to a roadmap step (GAF) by entering the component's name in the field with
the label Component. Choose LIST_WINDOW as the name of the interface
view to embed (field with label View).
The GUIBB component needs to be configured. Thus enter the name of the
component configuration for the GUIBB component in the field with label
Configuration Name.
Start the configuration process of the GUIBB component by clicking
the button labeled Configure UIBB located in the preview region of the
configuration editor.

Figure 99: Start configuring the LIST GUIBB
The configuration editor for Web Dynpro will be opened in a new browser
window. Click Create to create the component configuration for the LIST
GUIBB. Complete the popups asking for description, package assignment,
and transport request.
Now, a dialog box pops up asking for the feeder class. Enter the
name of the corresponding feeder class. This class has to implement
the interface IF_FPM_GUIBB_LIST and optionally the interface
IF_FPM_GUIBB_LIST_EXT.
Click Edit Parameters.
If parameters have not been defined in the feeder class, a popup displaying a
success message will be displayed. In this case, finish the dialog.
If parameters have been defined in the feeder class, the value of each
parameter can be adjusted on the next popup. For each parameter, a label
/ input field pair will be displayed.
The type of each parameter will typically be defined by a data element
which is based on a domain having fixed values. In this case, the label will
originate from the long text of the data element, while the allowed values
will equal the domain fixed values.

Figure 100: Create component configuration, assign feeder class, and

define parameter values
For details about defining parameters please refer to the corresponding section in
the lesson about the FORM GUIBB.
Next, the list's properties needs to be configured. After having selected
the List element in the hierarchy, the list header can be defined (attribute
Text). In addition, a special action can be assigned to the client side event
OnLeadSelect of the related Table UI element. All bindable actions are
displayed by a dialog box popping up.
Additional table settings can be adjusted if the Settings element in the
hierarchy is selected. The number of columns (Col count) and the number
of rows (Row count) can be fixed by assigning a positive integer value.
The attribute labeled Selection Mode corresponds to the Table property
selectionMode. The field labeled Selection Event allows to define which
clicks on the mark column will trigger the FPM-Event with the ID
FPM_GUIBB_LIST_ON_LEAD_SELECTI. Finally, the property labeled
Selection behavior allows to define, if clicking a the mark column will
automatically change the lead selection index accordingly.

Figure 101: Configuration of list settings
Actions that may be assigned to the client side event OnLeadSelect need to be
defined in the method GET_DEFINITION( ). For details please refer to the
corresponding section in the lesson about the FORM GUIBB.
Next, the columns displayed in the list need to be defined
Click the button Configure Columns.
A dialog box pops up displaying available columns. An arbitrary number of
columns can be marked. Clicking the button Add Columns will add them to
the list.
Optionally, each available column may be assigned to a field group. This is
meaningful is the number of available columns is large. In this case a drop
down box in the upper left corner of the popup allows to select the field
group. Then, only columns assigned to this field group will be displayed
in the left table.

Figure 102: Configure columns
The available columns, the properties of each column, the field groups and the
assignment of each available column to a field group has to be defined by the
content of method GET_DEFINITION( ):
The column selection has to be defined by a RTTI description of type
CL_ABAP_TABLEDESCR which is returned to the framework via the exporting
parameter EO_FIELD_CATALOG.

Figure 103: Defining field catalog
For each of the columns contained in the field catalog, properties have to be set
and returned via the exporting parameter ET_FIELD_DESCRIPTION. If a column
should be available during the configuration process, its visibility has to be set to
CL_WD_UIELEMENT=>E_VISIBLE-VISIBLE. Other properties are defined in
the ABAP Dictionary structure FPMGB_S_LISTFIELD_DESCR.
Hint: Some of the properties set in the method GET_DEFINITION( ) may

be adjusted at runtime from the method GET_DATA( ) via the exporting
parameter CT_FIELD_USAGE. These properties - described by the
ABAP DDIC structure FPMGB_S_FIELDUSAGE - are: READ_ONLY,
MANDATORY, ENABLED, LABEL_TEXT, HELP_TEXT, LINK,
VISIBILITY, and FIXED_VALUES.

Figure 104: Setting column properties (1)
Figure 105: Setting column properties (2)

In order to assign the form fields to field groups, these field groups need to be
defined first. For details please refer to the corresponding section in the lesson
about the FORM GUIBB.
After having defined which columns are to be displayed in which group, the
column properties can be configured:
The column has to be marked in the hierarchy view.
The following properties can then be configured: The type of UI element
used to display the column content (Display Type), the position of the
column (Index), and the header text (Column header - this will overwrite the
text obtained from the ABAP DDIC).
Additional properties do depend on the UI element used to display the
column content.
Figure 106: Configure column properties

In addition to the table columns, a toolbar can be defined. This toolbar

will be located on top of the list. For each action defined in the method
GET_DEFINITION( ) a toolbar button can be configured. For details how to
define actions please refer to the corresponding section in the lesson about the
FORM GUIBB.
Note: Actions can not be assigned to a column explicitly. However,

if the UI element used to display the column content (cell editor)
is able to fire a client side event (e.g. a drop down box, button)
and the cell editor is not disabled, then an action (FPM-Event
FPM_GUIBB_LIST_CELL_ACTION) is implicitly bound to the cell
editor of this column.
After having configured all list and column properties, this component
configuration can be saved and the configuration process is finished.
Runtime Aspects: INITIALIZE( )

At runtime, the methods GET_PARAMETER_LIST( ), INITIALIZE( ), and
GET_DEFINITION( ) are processed once for each feeder class instance. For
details about the typical coding encapsulated in the method INITIALIZE( ) please
refer to the corresponding section in the lesson about the FORM GUIBB.
Runtime Aspects: FLUSH( )

The method FLUSH( ) is the first method processed for the GUIBB displayed
before navigation. For details about the typical coding encapsulated in the method
FLUSH( ) please refer to the corresponding section in the lesson about the FORM
GUIBB.
Note: The current data displayed to the user is available from the
importing parameter IT_DATA. At runtime, this parameter will contain
the complete list.
Runtime Aspects: PROCESS_EVENT( )

The method PROCESS_EVENT( ) is the second method processed for the
GUIBB displayed before navigation. For details about the typical coding
encapsulated in the method FLUSH( ) please refer to the corresponding section in
the lesson about the FORM GUIBB.
If a button related to the toolbar of the list was clicked by the user, the ID of
related FPM-Event can be extracted from the interface parameter IO_EVENT. In
addition, the current lead selection index is provided by the importing parameter
IV_LEAD_INDEX and the indices of the selected list lines are provided by the
importing parameter IT_SELECTED_LINES.

If a clickable cell element was clicked by the user, additional information can be
extracted from the interface parameter IO_EVENT. This parameter contains the
public attribute MO_EVENT_DATA being an object described by the interface
IF_FPM_PARAMETER. Calling the getter method GET_VALUE( ), the following
information can be extracted:
The line index (parameter key FPM_GUIBB_LIST_INDEX).
The column name (parameter key FPM_GUIBB_LIST_COL_NAME).
The name of the feeder class (parameter key
FPM_GUIBB_LIST_FEEDER_NAME).
For each parameter of the feeder class the parameter value (parameter key as
defined in method GET_PARAMETER_LIST( ) ).
If the event handling was not successful, the WD runtime can be informed by
setting the exporting parameter EV_RESULT accordingly. In this case, the method
AFTER_FAILED_EVENT( ) will be processed before navigation takes place.
Figure 107: Interface parameters of method PROCESS_EVENT( )

Runtime Aspects: GET_DATA( )

The method GET_DATA( ) is the first method processed for the GUIBB displayed
after navigation. For details about the typical coding encapsulated in the method
GET_DATA( ) please refer to the corresponding section in the lesson about the
FORM GUIBB.
If the data to be displayed has been changed programmatically, the current data has
to be exported to the GUIBB via the changing parameter CT_DATA. In addition
the exporting parameter EV_DATA_CHANGED has to be set to ABAP_TRUE.
If the properties of the columns have to be modified, the actualized
column properties have to be exported to the GUIBB via the changing
parameter CT_FIELD_USAGE. In addition the exporting parameter
EV_FIELD_USAGE_CHANGED has to be set to ABAP_TRUE.
If the action usage has to be modified, the actualized action usage has to be
exported to the GUIBB via the changing parameter CT_ACTION_USAGE. In
addition the exporting parameter EV_ACTION_USAGE_CHANGED has to be set
to ABAP_TRUE.
To modify the lines that are selected and the line related to the lead selection
index, the values of the changing parameters CT_SELECTED_LINES and
CV_LEAD_INDEX have to be adapted. In addition the exporting parameter
EV_SELECTED_LINES_CHANGED has to be set to ABAP_TRUE.
Runtime Aspects: NEEDS_CONFIRMATION( )

The method NEEDS_CONFIRMATION( ) is defined in the extension interface
IF_FPM_GUIBB_LIST_EXT. For details, please refer to the corresponding
method defined in the interface IF_FPM_UI_BUILDING_BLOCK. This is
described in the previous unit.


Exercise 10: LIST GUIBB - Define Feeder

Class and configure Component
Exercise Objectives
Define the feeder class for the LIST GUIBB.
Implement the source code of the feeder class methods.
Use a central data model.
Business Example
You would like to define the booking lists of your OIF application via configuration
of the corresponding generic UIBB. However, this also means that you have to
create the feeder class and you have to implement the methods of this class. In
addition, you need to exchange data between this feeder class, the feeder class for
the FORM GUIBB, and the OIF component. Thus, you need to use a central
data model.
Template Feeder Class:
CL_NET313_LIST_GUIBB_T
Solution Component:
NET313_CUSTOMER_S8
Solution Feeder Class:
CL_NET313_LIST_GUIBB
Solution Component Configuration:
NET313_CUSTOMER_S8_CC1 (FPM component)
NET313_CUSTOMER_S8_CC_LIST1 (LIST GUIBB displaying
non-cancelled bookings)
NET313_CUSTOMER_S8_CC_LIST2 (LIST GUIBB displaying cancelled
bookings)

Task 1:
OPTIONAL TASK:
Complete the feeder class to be used by the LIST GUIBB. Copy the template
CL_NET313_LIST_GUIBB_T. Name your class ZCL_##_NET313_LIST.
The template contains the all methods and attributes needed to implement
the feeder class. You only need to complete the methods GET_DATA( ),
GET_DEFINITION( ), INITIALIZE( ), and GET_PARAMETER_LIST( ).
Implement the source code. The feeder class should support one parameter
defining if non-cancelled bookings or if cancelled bookings are to be displayed.
All fields of the DDIC structure SBOOK but the field MANDT should be available
for the configuration process. All fields should not be editable. The column
headers should be obtained from the DDIC description.
1. Create the feeder class to be used by the LIST GUIBB by copying the template
2. Implement the source code of feeder class method GET_PARAME-
TER_LIST( ). The source code consists of the following steps:
Define a work area for the returning parameter of this method.
Set the components of this structure as follows:
NAME = 'DATA_KIND' and TYPE = 'NET313_LIST_BOOKING_KIND'.
Append the work area to the returning parameter of the method
Note: 'NET313_LIST_BOOKING_KIND' is the name of a data

element providing the fixed values C (cancelled bookings) and N (
non-cancelled bookings).
3. Complete the source code of feeder class method INITIALIZE( ). This

At the end of the method, read the first line of the importing parameter
IT_PARAMETER. This will return a structure containing the value
of the parameter DATA_KIND as a data reference in the field
VALUE. De-reference the field VALUE into a field symbol of type
NET313_LIST_BOOKING_KIND. Then store this value in the feeder
class attribute GV_DATA_KIND. If the internal table is empty, set
GV_DATA_KIND = 'N'.

Get the RTTI description of the DDIC structure SBOOK (use method
CL_ABAP_TYPEDESCR=>DESCRIBE_BY_NAME( ) ). Then call the
method CL_ABAP_TABLEDESCR=>CREATE( ) to define an RTTI
description of an internal table which is based on the RTTI description of
the structure.
Pass this table description to the exporting parameter EO_FIELD_CATALOG.
Get the components from the RTTI description of the DDIC structure SBOOK
(use method GET_COMPONENTS( ) for RTTI structure description).
For each component, append a new line to the exporting parameter
ET_FIELD_DESCRIPTION containing the following information:
NAME = name of structure component.
READ_ONLY = ABAP_TRUE and HEADER_LABEL_BY_DDIC =
ABAP_TRUE for all structure components.
Note: Most of the coding can be copied from the corresponding

method of the feeder class related to the FORM GUIBB.

Check, whether the booking information stored by the feeder class
been changed during the current dialog step (GV_DATA_CHANGED =
ABAP_TRUE).
In this case check, whether cancelled bookings (GV_DATA_KIND = 'C') or
non-cancelled bookings (GV_DATA_KIND = 'N') are to be displayed. Set the
exporting parameter CT_DATA accordingly (export GT_BOOKINGS_C or
GT_BOOKINGS_N).
In addition, set EV_DATA_CHANGED = ABAP_TRUE. The will force the
WD runtime to actualize the form data displayed to the user.
Set GV_DATA_CHANGED = ABAP_FALSE to indicate, that the data stored
by the feeder class and the data displayed to the user are now synchronized.
Disable the button labeled Display/Change Customer.

Task 2:
Adapt your OIF component assuming that the booking lists are defined by the
LIST GUIBB:
Adapt the remaining component controller methods of your OIF component. Work
on attributes of the central data model (GO_CENTRAL_DATA->GV_SAVE_DATA,
GO_CENTRAL_DATA->GV_CUSTOM_ID) instead on component controller
attributes.
1. Delete the views BOOKINGS_C_VIEW and BOOKINGS_N_VIEW.
Delete the windows BOOKINGS_C_WINDOW and BOOKINGS_N_WIN-
DOW.
2. In the component controller context, delete the context nodes BOOKINGS_C,
BOOKINGS_N, and CUSTOMER.
3. Delete all component controller attributes but the ones beginning with WD_
and the attribute GO_CENTRAL_DATA.
4. Delete the component controller method GET_BOOKINGS( ).
5. Delete the complete source code of the methods NEEDS_CONFIRMATION(
) and PROCESS_BEFORE_OUTPUT( ).
6. Adapt the component controller method WDDOINIT( ). Delete the coding
used to determine the reference to the FMP service object, to the IDR service
object, to the OIF service object, and to the FPM message manager object.
Task 3:
bookings, replace the UIBBs of your OIF component by the LIST GUIBB. Use
the feeder class created during the last task or the template feeder class. Display
an arbitrary number of columns by the list. Display the cells of the columns
CANCELLED, INVOICE, RESERVED, or SMOKER as checkboxes. Each list
should display 10 data rows. A marking column should not be displayed.

2. On the sub view displaying the non-cancelled bookings, replace the

interface view BOOKINGS_N_WINDOW of your OIF component
by the interface view LIST_WINDOW of the GUIBB component
FPM_LIST_UIBB. Assign a component configuration to the LIST GUIBB
(name: ZNET313_##_CUSTOMER_S1_CC_LIST1).
3. Create the component configuration for the LIST GUIBB. Use
your feeder class ZCL_##_NET313_LIST or the template solution
CL_NET313_LIST_GUIBB. Select the correct parameter value to display
non-cancelled bookings.
4. Display an arbitrary number of columns by the list. Display the cells of the
columns CANCELLED, INVOICE, RESERVED, or SMOKER as checkboxes.
The list should display 10 data rows. A marking column should not be
displayed.
5. Repeat step 2, 3, and 4 of this task to replace the list displaying the
cancelled bookings by the LIST GUIBB. Name the component configuration
ZNET313_##_CUSTOMER_S1_CC_LIST2 and choose the feeder class
parameter value 'N' instead of 'C'.
Task 4:

Solution 10: LIST GUIBB - Define Feeder

Class and configure Component
Task 1:
OPTIONAL TASK:
Complete the feeder class to be used by the LIST GUIBB. Copy the template
The template contains the all methods and attributes needed to implement
the feeder class. You only need to complete the methods GET_DATA( ),
GET_DEFINITION( ), INITIALIZE( ), and GET_PARAMETER_LIST( ).
Implement the source code. The feeder class should support one parameter
defining if non-cancelled bookings or if cancelled bookings are to be displayed.
All fields of the DDIC structure SBOOK but the field MANDT should be available
for the configuration process. All fields should not be editable. The column
headers should be obtained from the DDIC description.
1. Create the feeder class to be used by the LIST GUIBB by copying the template
a) Copying a class should be known to you.
b) The following instance attributes are already defined in the class:
GO_FPM: Reference to FPM service object.
GO_FPM_IDR: Reference to IDR service object.
GO_FPM_OIF: Reference to OIF service object.
GO_MES_MAN. Reference to FPM message manager object.
GO_ASSIST: Reference to assistance object.
GO_CENTRAL_DATA of reference type CL_NET313_CEN-
TRAL_DATA: Reference to singleton instance of central data model.
GT_BOOKINGS_A: All bookings for customer.
GT_BOOKINGS_N: Non-cancelled bookings for customer.
GT_BOOKINGS_C: Cancelled bookings for customer.
GV_DATA_KIND: Information which bookings are to be displayed.
GV_DATA_CHANGED. Information if customer data have been
changed by the application.
2. Implement the source code of feeder class method GET_PARAME-
TER_LIST( ). The source code consists of the following steps:

Define a work area for the returning parameter of this method.

Set the components of this structure as follows:
NAME = 'DATA_KIND' and TYPE = 'NET313_LIST_BOOKING_KIND'.
Append the work area to the returning parameter of the method
Note: 'NET313_LIST_BOOKING_KIND' is the name of a data

element providing the fixed values C (cancelled bookings) and N (
non-cancelled bookings).

3. Complete the source code of feeder class method INITIALIZE( ). This
At the end of the method, read the first line of the importing parameter
IT_PARAMETER. This will return a structure containing the value
of the parameter DATA_KIND as a data reference in the field
VALUE. De-reference the field VALUE into a field symbol of type
NET313_LIST_BOOKING_KIND. Then store this value in the feeder
class attribute GV_DATA_KIND. If the internal table is empty, set
GV_DATA_KIND = 'N'.
Get the RTTI description of the DDIC structure SBOOK (use method
CL_ABAP_TYPEDESCR=>DESCRIBE_BY_NAME( ) ). Then call the
method CL_ABAP_TABLEDESCR=>CREATE( ) to define an RTTI
description of an internal table which is based on the RTTI description of
the structure.
Pass this table description to the exporting parameter EO_FIELD_CATALOG.
Get the components from the RTTI description of the DDIC structure SBOOK
(use method GET_COMPONENTS( ) for RTTI structure description).
For each component, append a new line to the exporting parameter
ET_FIELD_DESCRIPTION containing the following information:
NAME = name of structure component.

READ_ONLY = ABAP_TRUE and HEADER_LABEL_BY_DDIC =

ABAP_TRUE for all structure components.
Note: Most of the coding can be copied from the corresponding

method of the feeder class related to the FORM GUIBB.

Check, whether the booking information stored by the feeder class
been changed during the current dialog step (GV_DATA_CHANGED =
ABAP_TRUE).
In this case check, whether cancelled bookings (GV_DATA_KIND = 'C') or
non-cancelled bookings (GV_DATA_KIND = 'N') are to be displayed. Set the
exporting parameter CT_DATA accordingly (export GT_BOOKINGS_C or
GT_BOOKINGS_N).
In addition, set EV_DATA_CHANGED = ABAP_TRUE. The will force the
WD runtime to actualize the form data displayed to the user.
Set GV_DATA_CHANGED = ABAP_FALSE to indicate, that the data stored
by the feeder class and the data displayed to the user are now synchronized.
Disable the button labeled Display/Change Customer.
Task 2:
Adapt your OIF component assuming that the booking lists are defined by the
LIST GUIBB:
Adapt the remaining component controller methods of your OIF component. Work
on attributes of the central data model (GO_CENTRAL_DATA->GV_SAVE_DATA,
GO_CENTRAL_DATA->GV_CUSTOM_ID) instead on component controller
attributes.
1. Delete the views BOOKINGS_C_VIEW and BOOKINGS_N_VIEW.

Delete the windows BOOKINGS_C_WINDOW and BOOKINGS_N_WIN-

DOW.
2. In the component controller context, delete the context nodes BOOKINGS_C,
BOOKINGS_N, and CUSTOMER.
3. Delete all component controller attributes but the ones beginning with WD_
and the attribute GO_CENTRAL_DATA.
4. Delete the component controller method GET_BOOKINGS( ).
5. Delete the complete source code of the methods NEEDS_CONFIRMATION(
) and PROCESS_BEFORE_OUTPUT( ).
6. Adapt the component controller method WDDOINIT( ). Delete the coding
used to determine the reference to the FMP service object, to the IDR service
object, to the OIF service object, and to the FPM message manager object.

Task 3:
bookings, replace the UIBBs of your OIF component by the LIST GUIBB. Use
the feeder class created during the last task or the template feeder class. Display
an arbitrary number of columns by the list. Display the cells of the columns
CANCELLED, INVOICE, RESERVED, or SMOKER as checkboxes. Each list
should display 10 data rows. A marking column should not be displayed.
a) Edit the component configuration ZNET313_##_CUSTOMER_S1_CC1.
b) Double click the corresponding item in the object tree of the Object
area.
c) Click on the button labeled Start Configurator. This will open the
d) Click the button Change in the component configuration editor.
2. On the sub view displaying the non-cancelled bookings, replace the
interface view BOOKINGS_N_WINDOW of your OIF component
by the interface view LIST_WINDOW of the GUIBB component
FPM_LIST_UIBB. Assign a component configuration to the LIST GUIBB
(name: ZNET313_##_CUSTOMER_S1_CC_LIST1).
a) Mark the UIBB related to the sub view displaying the non-cancelled
bookings in the hierarchy. The attributes related to this UIBB will be
displayed below the preview area.
b) Enter FPM_LIST_UIBB in the field labeled Component.
c) Enter LIST_WINDOW in the field labeled View.
d) Enter ZNET313_##_CUSTOMER_S1_CC_LIST1 in the field labeled
Configuration Name.
e) Save.

3. Create the component configuration for the LIST GUIBB. Use

your feeder class ZCL_##_NET313_LIST or the template solution
CL_NET313_LIST_GUIBB. Select the correct parameter value to display
non-cancelled bookings.
a) Click the button Configure UIBB which is displayed in the preview
area for the LIST GUIBB.
b) On the next screen, click the button Create.
c) Enter a description, your package name and the key of your transport
request in the related fields of next two popups.
d) When being asked for the feeder class, enter the name of your feeder
class (ZCL_##_NET313_LIST) in the form field. If you have not
created your own feeder class, enter the name of the template solution
(CL_NET313_LIST_GUIBB). Click the button Edit Parameters.
e) On the next screen you have to define which kind of bookings are to be
displayed. Enter 'N' or use the value help to select the value. Click OK.
4. Display an arbitrary number of columns by the list. Display the cells of the
columns CANCELLED, INVOICE, RESERVED, or SMOKER as checkboxes.
The list should display 10 data rows. A marking column should not be
displayed.
a) Mark the item Settings in the hierarchy. This will display the list
attributes below the preview area.
b) Set Row Count = 10 and Selection Mode = none.
c) Click the button Configure Columns.
d) Mark the columns you would like to display in the table on the left
side (CTRL + left mouse click). Then click the button Add Columns.
Click OK.
e) To adjust the properties of a column, mark the column in the hierarchy.
This will display the column properties below the preview area. Adjust
the field type (Display Type).
f) Save.
5. Repeat step 2, 3, and 4 of this task to replace the list displaying the
cancelled bookings by the LIST GUIBB. Name the component configuration
ZNET313_##_CUSTOMER_S1_CC_LIST2 and choose the feeder class
parameter value 'N' instead of 'C'.
a)

Task 4:
FPM application.
b) The booking lists displayed on the second tab are now provided by the
LIST GUIBB.
Result
OPTIONAL TASK: CL_NET313_LIST_GUIBB -
IF_FPM_GUIBB~GET_PARAMETER_LIST( )
METHOD if_fpm_guibb~get_parameter_list.
DATA ls_parameter_descr TYPE fpmgb_s_param_descr.
ls_parameter_descr-name = 'DATA_KIND'.
ls_parameter_descr-type = 'NET313_LIST_BOOKINGS_KIND'.
APPEND ls_parameter_descr TO rt_parameter_descr.
ENDMETHOD.
OPTIONAL TASK: CL_NET313_LIST_GUIBB - IF_FPM_GUIBB~INI-

TIALIZE( )
METHOD if_fpm_guibb~initialize.
DATA ls_parameter LIKE LINE OF it_parameter.
FIELD-SYMBOLS <lv_value> TYPE net313_list_bookings_kind.
* get reference to central data object

go_central_data =

go_fpm = cl_fpm_factory=>get_instance( ).
* create assistence object

CREATE OBJECT go_assist.
* read bookings
get_bookings( ).

gv_data_changed = abap_true.
* get references to additional service objects (only at runtime)

IF go_fpm IS BOUND.
go_fpm_oif ?= go_fpm->get_service(
go_fpm_idr ?= go_fpm->get_service(
go_mes_man = go_fpm->mo_message_manager.
ENDIF.
* get parameter
READ TABLE it_parameter INTO ls_parameter WITH KEY name = 'DATA_KIND'.
IF sy-subrc <> 0.
gv_data_kind = 'N'.
ELSE.
ASSIGN ls_parameter-value->* TO <lv_value> CASTING.
gv_data_kind = <lv_value>.
ENDIF.
ENDMETHOD.

IF_FPM_GUIBB_LIST~GET_DEFINITION( )
METHOD if_fpm_guibb_list~get_definition.
DATA lo_structdescr TYPE REF TO cl_abap_structdescr.

DATA lt_component_tab TYPE abap_component_tab.
DATA ls_component_tab LIKE LINE OF lt_component_tab.
DATA ls_action TYPE fpmgb_s_actiondef.
DATA ls_field_description TYPE fpmgb_s_listfield_descr.
* Get RTTI description of table type based on DDIC structure SBOOK

lo_structdescr ?= cl_abap_typedescr=>describe_by_name( 'SBOOK' ).
eo_field_catalog = cl_abap_tabledescr=>create( lo_structdescr ).
* Get single components of structure

lt_component_tab = lo_structdescr->get_components( ).
* Define component's properties

LOOP AT lt_component_tab INTO ls_component_tab.
* Name
ls_field_description-name = ls_component_tab-name.
* Visibility

IF ls_field_description-name = 'MANDT' .
ls_field_description-visibility = cl_wd_uielement=>e_visible-none.
ELSE.
ls_field_description-visibility = cl_wd_uielement=>e_visible-visible.
ENDIF.
* Read only mode
ls_field_description-read_only = abap_true.
* Label
ls_field_description-header_label_by_ddic = abap_true.
APPEND ls_field_description TO et_field_description.

ENDLOOP.
ENDMETHOD.

IF_FPM_GUIBB_LIST~GET_DATA( )
METHOD if_fpm_guibb_list~get_data.
* Actualize data
IF gv_data_changed = abap_true.
CASE gv_data_kind.
WHEN 'C'.
ct_data = gt_bookings_c.
WHEN 'N'.
ct_data = gt_bookings_n.
ENDCASE.
ev_data_changed = gv_data_changed.
gv_data_changed = abap_false.
ENDIF.
* Actualize FPM button

go_fpm_oif->define_button(
ENDMETHOD.

ENDMETHOD.


ENDMETHOD.

METHOD wddoinit .
* wd_this->go_context = wd_context->get_context( ).
* get reference to central data object

wd_this->go_central_data =
ENDMETHOD.

Lesson Summary

NET313 Unit Summary
Unit Summary

Unit Summary NET313

NET313 Course Summary
Course Summary
Configure FPM components statically

Define toolbar buttons and handle toolbar events
Add initial screens and confirmation dialogs to the floorplans
Understand the FPM phase model basically
Define messages making use of the FPM message manager
Define forms and lists by means of generic UI building blocks (GUIBBs)
Provide data to be displayed by GUIBBs by means of feeder classes

Course Summary NET313

Index
A FPM, 36
adaptation, 20 application, 57
configuration, 24 application architecture,
configuration controller, 42
24 application configuration,
customizing, 31 58
explicit customizing central data model, 46
/personalization, 34 component configuration,
hierarchy, 21 59
implicit / explicit, 22 components, 42
personalization, 31 configuration editor, 61
application configuration, 58 GAF service object, 107
IDR service object, 116
C message manager, 120
central data model, 46 OIF service object, 107
component configuration, 59 phase model, 46
configuration, 24 service object, 106
configuration controller, 24 UIBB definition, 56
configuration editor, 61 FPM configuration
confirmation screen, 69 confirmation screen, 69
customizing, 31 define floorplan (GAF), 67
explicit, 34 define floorplan (OIF), 65
D explanation texts, 77
data loss popup, 103 IDR, 68
define floorplan (GAF), 67 initial screen, 68
define floorplan (OIF), 65 toolbar, 70
toolbar (GAF), 75
E toolbar (initial screen), 71
explanation texts, 77 toolbar (OIF), 73
FPM message manager, 120
F FPM-Events, 100
floorplan manager (see FPM), triggered by application,
36 105
floorplans, 36
guided activity floorplan G
(GAF), 41 GAF, 41
object instance floorplan roadmap sub steps, 114
(OIF), 39 service object, 107
quick activity floorplan toolbar, 75
(QAF), 40

Index NET313
toolbar access at runtime, IF_FPM, 106

112 IF_FPM_CNR_GAF, 107
generic user interface building IF_FPM_CNR_OIF, 107
block (see GUIBB), 42 IF_FPM_GUIBB, 162
GUIBB, 42 GET_PARAME-
architecture, 160 TER_LIST( ), 163
feeder class, 161 INITIALIZE( ), 163
FORM, 162 IF_FPM_GUIBB_FORM,
LIST, 162 162
phase model, 164 FLUSH( ), 163
TABBED, 162 GET_DATA( ), 163
GUIBB FORM GET_DEFINITION( ),
configuration, 167 163
define action usage, 177 PROCESS_EVENT( ),
define field catalog, 173 163
define field groups, 176 IF_FPM_GUIBB_FORM_EXT,
define field properties, 174 162
define parameter list, 170 NEEDS_CONFIRMA-
FLUSH( ), 179 TION( ), 163
GET_DATA( ), 181 IF_FPM_GUIBB_LIST, 162
INITIALIZE( ), 178 FLUSH( ), 163
NEEDS_CONFIRMA- GET_DATA( ), 163
TION( ), 184 GET_DEFINITION( ),
PROCESS_EVENT( ), 163
180 PROCESS_EVENT( ),
GUIBB LIST 163
configuration, 201 IF_FPM_GUIBB_LIST_EXT,
define available columns, 162
205 NEEDS_CONFIRMA-
define column properties, TION( ), 163
206 IF_FPM_GUIBB_TABBED,
define field groups, 208 162
define parameter list, 203 IF_FPM_IDR, 116
FLUSH( ), 209 IF_FPM_MESSAGE_MAN-
GET_DATA( ), 211 AGER, 120
INITIALIZE( ), 209 IF_FPM_UI_BUILD-
NEEDS_CONFIRMA- ING_BLOCK, 100
TION( ), 211 AF-
PROCESS_EVENT( ), TER_FAILED_EVENT(
209 ), 103
FLUSH( ), 103
I NEEDS_CONFIRMA-
IDR TION( ), 103
access at runtime, 115 PROCESS_BE-
component, 42 FORE_OUTPUT( ),
configuration, 68 103
service object, 116

NET313 Index
PROCESS_EVENT( ), application, 4
103 component, 2
initial screen, 68 component controller, 3
toolbar, 71 component interface, 9
component reuse, 9
O component reuse - call
OIF, 39 methods, 12
service object, 107 component reuse - context
toolbar, 73 mapping, 15
toolbar access at runtime, component reuse -
108 declaration, 9
P component reuse - embed
personalization, 31 interface view, 11
explicit, 34 component reuse - handle
events, 13
Q component reuse -
QAF, 40 instantiation, 10
T component reuse - phase
model, 19
toolbar, 70
context mapping, 3
access at runtime (GAF),
controller attributes, 7
112
controller events, 8
access at runtime (OIF),
controller methods, 5
108
controller methods - order
U of processing, 6
UIBB, 36 controller usage, 3
definition, 56 custom controller, 3
user interface building block data binding, 2
(see UIBB), 36 interface controller, 4
interface view, 4
W navigation, 4
Web Dynpro basics, 2 navigation link, 5
action, 4 phase model, 6
adaptation, 20 plugs, 4
adaptation - configuration, startup plug, 4
24 used controller, 3
adaptation - configuration user interface (UI), 2
controller, 24 view, 2
adaptation - customizing / window, 3
personalization, 31
adaptation - hierarchy, 21
adaptation - implicit /
explicit, 22

Index NET313

Feedback
SAP AG has made every effort in the preparation of this course to ensure the
accuracy and completeness of the materials. If you have any corrections or
suggestions for improvement, please record them in the appropriate place in the
course evaluation.

NET313 Floorplan Manager For Web Dynpro PDF

Uploaded by

Document Information

Original Title

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

NET313 Floorplan Manager For Web Dynpro PDF

Uploaded by

Copyright:

Available Formats

NET313

Floorplan Manager for Web Dynpro

An SAP course - use it to learn, reference it for work

Copyright 2009 SAP AG. All rights reserved.

Type Style Description

Example text Words or characters that appear on the screen. These

Example text Emphasized words or phrases in body text, titles of

EXAMPLE TEXT Names of elements in the system. These include

2009/91 2009 SAP AG. All rights reserved. iii

Icons in Body Text

For more information, tips, or background

Note or further explanation of previous point

Indicates that the item is displayed in the instructor's

iv 2009 SAP AG. All rights reserved. 2009/91

Unit 2: Developing FPM Applications ............................... 55

Unit 3: Generic UI Building Blocks (GUIBBs) .................... 159

Index ....................................................................... 233

2009/91 2009 SAP AG. All rights reserved. v

vi 2009 SAP AG. All rights reserved. 2009/91

Developers of Web Dynpro ABAP applications based on the FPM

Understand the architecture of Web Dynpro applications based on the FPM

Configure FPM components statically

2009/91 2009 SAP AG. All rights reserved. vii

viii 2009 SAP AG. All rights reserved. 2009/91

Describe, how Web Dynpro components can be reused

2009/91 2009 SAP AG. All rights reserved. 1

Lesson: Web Dynpro ABAP Fundamentals

Web Dynpro Architecture

Internally visible Component Entities

2 2009 SAP AG. All rights reserved. 2009/91

Figure 1: Component entities

2009/91 2009 SAP AG. All rights reserved. 3

Externally visible Component Entities

4 2009 SAP AG. All rights reserved. 2009/91

Figure 2: Navigation: Principle

2009/91 2009 SAP AG. All rights reserved. 5

Figure 3: Controller methods

6 2009 SAP AG. All rights reserved. 2009/91

Figure 4: Standard hook methods: Order of processing

2009/91 2009 SAP AG. All rights reserved. 7

Figure 5: Controller attributes

Figure 6: Controller events

8 2009 SAP AG. All rights reserved. 2009/91

Figure 7: Component interface

Preparing Component Reuse

2009/91 2009 SAP AG. All rights reserved. 9

Figure 8: Declaring the usage of a component

10 2009 SAP AG. All rights reserved. 2009/91

Figure 9: Instantiating a component usage

Embedding Interface Views

2009/91 2009 SAP AG. All rights reserved. 11

Figure 10: Embedding interface views

Accessing the Interface Controller of a Component Usage

12 2009 SAP AG. All rights reserved. 2009/91

Figure 11: Calling methods defined in the interface controller

Figure 12: Accessing the interface controller of a component usage

2009/91 2009 SAP AG. All rights reserved. 13

Figure 13: Handling events fired in the interface controller

Figure 14: Handling event fired in component usage

14 2009 SAP AG. All rights reserved. 2009/91

Cross Component Context Mapping

Figure 15: Normal context mapping: Principle

2009/91 2009 SAP AG. All rights reserved. 15