Floorplan Manager for Web Dynpro
ABAP
SAP NetWeaver Application Server - ABAP
Date Training Center Instructors Education Website
Participant Handbook
Course Version: 91Course Duration: 3 Day(s) Material Number: 50094991
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
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.
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.
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
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
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
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:
• Describe, how Web Dynpro components can be reused
• Describe the adaptation of Web Dynpro components via implicit and explicit 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
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.
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 aWeb 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
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
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
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 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
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.
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
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
Figure 26: Explicit component configuration
Hint: Properties that are configured may be overwritten by customizing /
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
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 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.
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
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:
• Describe, how Web Dynpro components can be reused
• Describe the adaptation of Web Dynpro components via implicit and explicit 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
After completing this lesson, you will be able to: • Describe what floorplans are
• List the advantages of developing Web Dynpro ABAP applications using 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).
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.
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.
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)
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 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.
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.
2. Implement the interface IF_FPM_UI_BUILDING_BLOCK by your 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.
a) Perform this step like you (hopefully) have done often before.
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. a) Perform this step like you (hopefully) have done often before.
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.
1. Implement the interface IF_FPM_UI_BUILDING_BLOCK by your 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.
2. Implement the interface IF_FPM_UI_BUILDING_BLOCK by your 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
ZNET313_##_CUSTOMER_S1.
a) Perform this step like you (hopefully) have done often before.
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..
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
ZNET313_##_CUSTOMER_S1.
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
Lesson Summary
You should now be able to: • Describe what floorplans are
• List the advantages of developing Web Dynpro ABAP applications using the FPM framework
Unit Summary
You should now 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
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
After completing this unit, you will be able to:
• 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
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
After completing this lesson, you will be able to:
• 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
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
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
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.
