FPM Basics

PDF download from SAP Help Portal:

http://help.sap.com/saphelp_nw74/helpdata/en/5b/1c78ba21424fd9b84f4d09e370b5a1/content.htm
Created on January 22, 2016

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help
Portal.

Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.

2016 SAP SE or an SAP affiliate company. 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 SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP
SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are
provided by SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP
Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set
forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional
warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in
Germany and other countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Table of content

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 1 of 16

Table of content
1 FPM Basics
1.1 Structure of a Floorplan Manager Application
1.2 Floorplans
1.2.1 Floorplan for the Overview Page (OVP)
1.2.1.1 Stacking of UIBBs in a Column
1.2.2 Floorplan for Guided Activity (GAF)
1.2.3 Floorplan for Object Instances (OIF)
1.2.4 Floorplan for Quick Activity (QAF)
1.3 User Interface Building Blocks (UIBBs)
1.3.1 Interface: IF_FPM_UI_BUILDING_BLOCK
1.3.2 Generic User Interface Building Blocks (GUIBBs)
1.3.2.1 Feeder Class
1.3.3 Reuse User Interface Building Blocks (RUIBBs)
1.3.3.1 Attachment Component
1.3.3.2 Notes Component
1.4 FPM Event Loop
1.4.1 Raising Standard FPM Events
1.4.2 Triggering the FPM Event Loop
1.4.3 Triggering Application-Specific Events
1.4.4 Asynchronous Callback
1.4.5 Interaction with Web Dynpro Phase Model
1.4.6 Key Web Dynpro Methods used in FPM
1.4.7 Different Categories of Web Dynpro Interfaces
1.4.8 Triggering a Data-Loss Dialog Box in the FPM Event Loop
1.5 FPM/Web Dynpro ABAP Adjustment Concept

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 2 of 16

1 FPM Basics
An introduction to FPM concepts, and the essential components of an FPM application.

Related Information
Structure of a Floorplan Manager Application
Floorplans
User Interface Building Blocks (UIBBs)
FPM Event Loop
FPM/Web Dynpro ABAP Adjustment Concept

1.1 Structure of a Floorplan Manager Application

A Floorplan Manager (FPM) application is a Web Dynpro application that is assigned one of the following Web Dynpro components:
FPM_OVP_COMPONENT
FPM_GAF_COMPONENT
FPM_OIF_COMPONENT
Each of the above components provides the application with a different type of floorplan. Floorplans define the general layout and interaction of an
application. They are used for application composition and UI assembly. They are explained in detail in another section.
Using explicit configurations of the above components, you can assign additional Web Dynpro components as user-specific views to display your content.
These user-specific views are referred to as UI building blocks (UIBBs).

Note
There are different types of UIBBs:
Freestyle UIBBs
These components are created outside the FPM framework, in the Web Dynpro ABAP development environment, by application developers. FPM
has, therefore, little control over the layout of their content.
Generic User Interface Building Blocks (GUIBBs)
FPM makes life easier for application developers. To ensure that your application has a harmonized look and feel, and that there is consistency in
the UI screens, FPM provides you with templates, the GUIBBs, for displaying your content. For example, there are templates to display your content
in a form layout (Form GUIBB), and in a list layout (List GUIBB). When using a Form GUIBB, for example, you don't have to worry about aligning
input fields - the FPM GUIBB takes care of that. UIBBs and GUIBBs are explained in greater detail in another section.
By combining a configuration of a floorplan with configurations of the UIBBs, you can compile most of the common application user interfaces.
The interfaces can be changed afterwards by changing both the floorplan and the UIBB component configurations.
The figure below illustrates an FPM application, showing a floorplan configuration containing two GUIBBs (for form layout and tab page layout) and a single
freestyle UIBB. Note that the tabbed component is included only to show that it is a special kind of GUIBB that contains other GUIBBs.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 3 of 16

Figure 1: Example Structure of a Floorplan Manager Application

Related Information
Floorplans
User Interface Building Blocks (UIBBs)

1.2 Floorplans
Concept
To improve the uniformity of user interfaces of applications in the Web Dynpro ABAP environment, Floorplan Manager (FPM) lets you implement floorplans.
A floorplan is a template. It is a combination of user interface (UI) 'patterns' arranged in a specific order in an application that allows a user to accomplish a
certain activity, for example, searching for, identifying, and maintaining data for an object.
Each floorplan represents a different type of user activity and, therefore, floorplans form the basis of an application.
Each floorplan follows the SAP design standards for UI and is implemented as a separate Web Dynpro component.
The following list displays the floorplan types that are available and provides guidelines as to when to use them:
Floorplan for Guided Activities
Use this floorplan when the user carries out an activity for which he or she requires guidance, that is, an activity that is not regularly performed or is
unknown by the user. This floorplan provides a framework for breaking down the activity step by step.
Floorplan for Overview Page
Use this floorplan for activities that relate to managing business records, for example editing or deleting records. The overview page (OVP) floorplan
provides an overview of all important information regarding a single instance of an object (such as a sales order, an employee, or an account). The OVP
floorplan has highly flexible page layout possibilities and numerous user personalization features.
The OVP floorplan supersedes the Object Instance floorplan (see below).
Floorplan for Quick Activities
Use this floorplan when the user activity can be performed in one step and on one screen, that is, for a very simple activity.
Floorplan for Object Instances
Use this floorplan for activities that relate to managing business records or objects, for example, editing or deleting records.

Integration
Floorplans form the basis of an application's layout. The content for an application is supplied by the user interface building blocks (UIBBs) which are added to
the pages within a floorplan configuration.
You edit the floorplan component configuration of an application using the FPM configuration editor, FLUID.

Related Information
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 4 of 16

Related Information
Floorplan for the Overview Page (OVP)
Floorplan for Guided Activity (GAF)
Floorplan for Object Instances (OIF)
Floorplan for Quick Activity (QAF)
Working with Floorplans

1.2.1 Floorplan for the Overview Page (OVP)

A design template that dictates the structure and behavior of a user interface of an overview page (OVP).
You can use this floorplan to model an application interface that initially displays an overview of the most important data to users for a business object such
as an employee or a sales order. From there, users can navigate to various pages, for example, editing pages to add, change, or delete data. The OVP
floorplan has numerous layout possibilities at design-time and can be easily personalized at runtime.

Runtime Layout
At runtime, an OVP application consists of content displayed in a number of collapsible panels. Depending on the configuration of the application, these panels
can be moved around the UI, and even stacked upon each other to form a tab-strip. An OVP application may also display a Page Master panel (explanation
below). The following screenshots illustrate how an application based on an OVP floorplan might look at runtime:

Figure 1: OVP Floorplan

Structure of an OVP Application

The OVP floorplan consists of the following components:
Page
An OVP floorplan consists of at least one page (content area). There are various page types; for example, a page can be a main page (for displaying the
most important or top-level information), a sub-overview page (for displaying a certain subsection of information about a business object), a dialog box,
or a confirmation screen. If multiple pages exist, then one page is flagged as the default.
Section
Each page consists of one or more sections. These allow you to define the detailed structure of a page. Each section has its own layout, and can
contain numerous application-specific user interface building blocks (UIBBs). Various layouts are possible for a section, differing mainly in the number of
columns into which the section is divided. You can specify the position of a UIBB in a section using the Column , Row , and Sequence Index
attributes of the UIBB. At runtime, the individual sections can be recognized by the number of columns they contain and by their differing column
layouts. You assign the UIBBs and GUIBBs to the individual columns within a section. Section columns can be enabled for stacking; so that the UIBBs
may, at runtime, be moved on top of each other to form a stack (tab-strip) where each UIBB is represented as a tab. The system only displays the
section at runtime if you have assigned UIBBs to that section. However, if you remove the last UIBB from a section at runtime, the system shows an
empty section as a possible destination for a UIBB if the user moves the UIBB over that section again.
Assignment Blocks
A UIBB inside a section is rendered with a panel, or flat without a panel; if rendered as a panel, it is known as an assignment block. It's title is displayed
in the panel header. An assignment block may have its own toolbar. The toolbar elements are also rendered inside the panel header.
Page Master
This optional area appears on the left side, or on top of, the page at runtime in a non-collapsible, resizable panel. It allows an object selection that is
valid for all assignment blocks and UIBBs on the page, allowing you to find and select entries quickly within a large quantity of related objects. Selecting
an object in the panel triggers a refresh in the assignment blocks and UIBBs on that page, causing all UIBBs to display details relevant to the object
selected in the panel. Assignment blocks and UIBBs are connected to the Page Master by FPM events or by wiring. The Page Master can be created
and influenced by the OVP APIs at runtime.
Toolbars
An OVP application may have several toolbars specific to OVP components:
Global toolbar (specific to the whole page).

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 5 of 16

Assignment block (UIBB) toolbar

Page Master toolbar

OVP in Design-Time (FLUID)

You can view the design-time structure of an OVP application with the FPM configuration editor, FLUID.
In FLUID, the Overview Page Schema panel displays the following:
Pages
Choose the buttons in the Navigation panel to add, delete, and copy different pages in your application.
Sections
You can add and remove sections in this panel. You can specify attributes of each section of an OVP floorplan. For example, you can add and delete
sections, specify the layout of the individual sections, add UIBBs to a section, and choose to include a Page Master panel on a page.
Assignment Blocks and UIBBs
In this panel, you can add and remove UIBBs to and from a section. Amongst other things, you can specify the order in which several UIBBs within a
section appear and whether a particular UIBB should be visible or not. You can also specify how big the content area of an assignment block should be.
Page Master Area
In this panel, you can add and remove a Page Master to a page, and specify attributes such as its position.
Choose the Toolbar Schema panel to access the attributes of the individual toolbars and their elements within an application. Here you can add and remove
different toolbar elements such as buttons and button choices, and change the order they appear on the toolbar, as well as specifying attributes such as button
text and event attributes.
In the Attributes panel of Page Master and UIBB toolbars there is a Capture Actions field that enables the provision of extra action buttons on the toolbar.
These actions arise when a UIBB exposes actions at runtime (for example when the UIBB is based on a generic UIBB and the list of actions is provided by
the feeder class). If you select the Capture Actions field, FPM then uses the UIBB-API to determine the available toolbar actions at runtime, and the
resulting buttons are added to the toolbar alongside the configured buttons.
For more information about what you can configure in FLUID, see the field help for the individual attributes in the system.

1.2.1.1 Stacking of UIBBs in a Column

In an OVP application at runtime, UIBBs inside a column can be moved on top of each other to form a stack. Each UIBB is represented as a tab in a tab strip.
You can enable each section column for 'stacking'.
If stacking is enabled for a section column, the UIBBs can be dragged at runtime and dropped onto each other in that column, thus building a stack in which
each UIBB is represented by a tab. This is known as a stacked panel.
In the FPM configuration editor, FLUID, UIBBs can be stacked using appropriate values for the properties Column (= Location), Row , and Index (see figure
below):

There are two possible states for a stacked panel:

Expanded
In an expanded stacked panel there is exactly one UIBB that is expanded, that is, its property Collapsed is set to FALSE . All other UIBBs are
collapsed, that is, their property Collapsed is set to TRUE . The expanded UIBB is the active UIBB in the stacked panel. Its property Default In

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 6 of 16

Stack is set to TRUE .

Collapsed
In a collapsed stacked panel all UIBBs are collapsed, that is, their property Collapsed is set to TRUE . There is, though, exactly one UIBB in the
stacked panel with the property Default In Stack set to TRUE . If the stacked panel is expanded, this UIBB becomes the active UIBB.

1.2.2 Floorplan for Guided Activity (GAF)

A design template that dictates the structure and behavior of a user interface of a guided activity.
You can use this floorplan to model an application interface that guides the user through an activity step-by-step. The activity is one that is generally complex,
and not carried out by the user on a regular basis. A guided activity is divided into a series of logical steps, each of which can be broken down further into
substeps, and all of which represent tasks and subtasks of an activity.

Runtime Structure
The figure below shows the runtime UI of an application based on the GAF floorplan:

This floorplan contains a series of screens associated with the different steps of an activity. The content of the screens is determined by the business object
the floorplan is based on, or by the task that the user carries out with that business object.
The floorplan has the following schematic structure:
Page Title (formerly, the Identification Region (IDR))
The system displays the title and step of the current activity in this area.
Page Toolbar
The order and naming convention for the standard buttons are determined by the FPM framework.
Message Region (not shown in the above screenshot)
This area (above the roadmap) is only visible if at least one message has been generated by the system.
Roadmap
This area displays an interactive figure, depicting the individual steps, and substeps of the activity. The user navigates through the roadmap by clicking
the steps, or the toolbar buttons.
The last step of a guided activity is usually a confirmation screen; this is not displayed in the roadmap. When the user completes the last step in the
activity and presses the Next button (or what the developer of the application has defined the Final Action step to be), the confirmation screen
appears, and the roadmap disappears. Note that it is possible for a guided activity to consist of only one step, followed by a confirmation step. In this
case, the system displays just a single step in the roadmap.
Information Area (not shown in the above screenshot)
This optional area (below the page title), formerly known as the Extended Identification Region , displays all relevant information that more narrowly
specifies the activity. It is divided into the following elements:
Content Area
This area provides information that can be edited by the user. The content is provided by individual UI building blocks (UIBBs). In the screenshot above,
the content area contains a Form component.

Design-Time Structure (FLUID)

View the design-time structure of a GAF configuration with the FPM configuration editor, FLUID.
In FLUID, the Guided Activity Schema panel displays the following:
Steps
Each numbered step in a roadmap corresponds to one of the following types of steps displayed in the Guided Activity Schema panel in FLUID:
Main Step
Each main step represents one roadmap step, and, usually, one main activity.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 7 of 16

Substep
A substep is a step that appears between two main steps, and, represents a breaking-down of a main activity into smaller activities.
It is the UIBBs that provide the content in a step, and an FPM application must have at least one UIBB for each step. FLUID automatically provides
this, but you can add your own predefined UIBBs. Using the fields inside the Attributes panel, you can characterize each step.
Main steps and substeps are available on a Main Steps type of page.
IDR
To make changes to the page title and information area, choose the Configure IDR button in the Guided Activity Schema .
A GAF configuration may also contain an Initial Screen and/or Confirmation Screen .

Related Information
Initial Screen
Confirmation Screen
Identification Region (IDR) of GAF and OIF Applications

1.2.3 Floorplan for Object Instances (OIF)

A design template that dictates the structure and behavior of a user interface for processing a business object instance.
You can use this floorplan to model an application interface that allows the user to create, delete, display, and change the attributes and associations of
business objects (for example, an employee, or a purchase order).

Note
Although the OIF floorplan is still in use, it has been superseded by the Overview Page Floorplan (OVP) as it does not satisfy current UI guidelines.

Runtime Structure
An application configuration based on an OIF type floorplan typically shows multiple view tabs, whose content is determined by a defined business object, and
the related tasks a user must perform.
This floorplan has the following schematic structure:
Page Title (formerly, the Identification Region (IDR))
The system displays the title and step of the current activity in this area.
Page Toolbar
The toolbar contains action buttons and navigation options, and links to more detailed information.
Information Area
This optional area, formerly known as the Extended Identification Region , displays all relevant information that more narrowly specifies the activity.
Message Region
This area is only visible if at least one message has been generated by the system.
Contextual Navigation Region (CNR)
This area consists of view and subview tabs. Tabs are used for switching between different OIF views and subviews. They are implemented with the
Web Dynpro ABAP HorizontalContextualPatternControl control. This is conceptually, technically, and visually different from
TabStripControl and cannot be used outside of this navigation region of an OIF.

Note
If the OIF configuration has been defined with only one main layer with only one sub-layer, the tabs and sub-tabs are hidden at runtime.
Content Area
This area provides information that can be edited by the user. The content is provided by individual UI building blocks (UIBBs).
An OIF configuration may also contain an Initial Screen and/or Confirmation Screen .

Design-Time Structure (FLUID)

View the design-time structure of an OIF configuration with the FPM configuration editor, FLUID.
In FLUID, the Object Instance Schema panel displays the following:
Main Views and Subviews
Each main view or subview in the application configuration at runtime corresponds to one of the following types of views displayed in the Object
Instance Schema panel:
Main View
Each Main View in the hierarchy represents one main view tab at runtime. Each Main View must contain at least one subview (which are only
visible at runtime if there is more than one).
Subview
A Subview in the hierarchy represents a view tab that appears under a main view tab. Like a main view, subviews must have at least one UIBB.
It is the UIBBs that provide the content in a view, and an FPM application must have at least one UIBB for each view. FLUID automatically provides
this, but you can add your own predefined UIBBs. Using the fields inside the Attributes panel, you can characterize each view.
Main views and subviews are available on a Main Screens type of page.
IDR
To make changes to the page title and information area, choose the Configure IDR button in the Object Instance Schema .
An OIF configuration may also contain an Initial Screen and/or Confirmation Screen . Navigation to a confirmation screen is technically supported by the
floorplan.

Related Information
Initial Screen

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 8 of 16

Confirmation Screen
Identification Region (IDR) of GAF and OIF Applications
Floorplan for the Overview Page (OVP)

1.2.4 Floorplan for Quick Activity (QAF)

Definition
A design template that dictates the structure and behavior of a user interface of a quick activity.

Use
You can use this floorplan to model an application interface allowing the user to create, delete, display, and change the attributes and associations of business
objects. For quick activities, only the fields of a business object are shown that generally suffice for creating an object instance.
A quick activity is realized at design time by using the Object Instance Floorplan (OIF) component, FPM_OIF_COMPONENT with only one main view and one
subview available.

More Information
Floorplan for Object Instances (OIF)

1.3 User Interface Building Blocks (UIBBs)

UIBBs are used to display the content on your UI, for example, data in a table or form.
From an FPM perspective, UIBBs are the interface views of a Web Dynpro ABAP component (the Web Dynpro windows).
UIBBs can be divided into the following categories:
Freestyle UIBBs
These are UIBBs that are created by the external application. They cannot be configured by the FPM framework, and thus, FPM has limited control over
the layout and format of the content displayed by these building blocks.
Generic user interface building blocks (GUIBBs)
These are UIBBs that are provided by the FPM framework itself. GUIBBs ensure a consistent look and feel for the UI, and ensure that screens are SAP
UI-guideline compliant.
In order that FPM recognizes a UIBB, the Web Dynpro component that provides the UIBB must implement the IF_FPM_UI_BUILDING_BLOCK Web Dynpro
interface. This interface ensures that the Web Dynpro application can take part in the FPM Event Loop.

Related Information
Interface: IF_FPM_UI_BUILDING_BLOCK
Generic User Interface Building Blocks (GUIBBs)
Reuse User Interface Building Blocks (RUIBBs)

1.3.1 Interface: IF_FPM_UI_BUILDING_BLOCK

This Web Dynpro interface ensures that a Web Dynpro application and its UIBBs can take part in the FPM Event Loop.
The methods of this interface are described in the following table:
Table 1: Methods of Interface IF_FPM_UI_BUILDING_BLOCK
Method Name
FLUSH

Description
The first method called after the FPM event loop has been started.
In this method, the UIBB must transport all modified data from the views to other components that the UIBB wants to
communicate with later on.
Normally, this data transport is done automatically using Web Dynpro context mapping. Therefore, only create a specific
implementation of this method if you are not using this automatic mechanism.

NEEDS_CONFIRMATION

In this method, the UIBB requests that the subsequent event processing is stopped, and asks the user for confirmation by way
of a dialog box. Depending on the action the user takes in the dialog box, the event loop is continued or canceled.
For more details, refer to Triggering a Data Loss Dialog Box.

PROCESS_EVENT

In this method, the UIBB completes the following tasks:

Checks for local consistency (validation, missing data, and so on)
The local check is needed to inform the user of potential input errors as soon as possible. In accordance with UX
guidelines, checks are to be performed continually (as long as they are not too performance-intensive). For example,
when switching from one view to another view in an OIF application, the view (UIBB) which is moved away from must
check for local consistency.
However, this does not exempt the application from performing a complete check (including performance-critical
checks) before saving. This must be handled in the method IF_FPM_TRANSACTION_CHECK_BEFORE_SAVE .
Performs the actual event processing
For this, the current event can be identified through the attributes MV_EVENT_ID and MO_EVENT_DATA of the event
instance io_event that is passed on. Depending on whether the event is processed successfully or not, the exporting
parameter EV_RETURN must be filled with either IF_FPM_CONSTANTS~GC_EVENT_RESULT-OK or
IF_FPM_CONSTANTS~GC_EVENT_RESULT-FAILED .
A typical implementation of PROCESS_EVENT is shown below:

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 9 of 16

IF io_event->mv_event_is_validating = ABAP_TRUE.
Do local checks and report messages if needed
ENDIF
CASE io_event->mv_event_id.
WHEN XYZ
Handle event and fill EV_RETURN accordingly with a value from IF_FPM_CONSTANTS~GC_EVENT_RESULT
ENDCASE.
If the event processing requires further user interaction (for example, asking for further data in a dialog box), the event
processing can be deferred by returning EV_RETURN = IF_FPM_CONSTANTS~GC_EVENT_RESULT-DEFER.
AFTER_FAILED_EVENT

This method is called by FPM if an event could not be processed successfully. In this case, the UIBB must ensure that its UI
reverts to the state before the user interaction occurred.
For example, let us say that selecting an option in a lead field in a table triggers the display of the details of this field in a new
row in another UIBB. The event might fail if the UIBB containing the details contains unsaved data for the previously-selected
table row. As the detail form still contains the details of the original table row (after the failed event), the lead selection must be
reverted to the original table row too.
If the PROCESS_EVENT method of the current UIBB has been processed successfully, but the event processing failed due to a
problem in another UIBB, the actual event processing must also be reverted. The parameter IV_REVERT indicates this
situation.

PROCESS_BEFORE_OUTPUT

This is the last method to be called on the UIBB. The data to be displayed is read from the model.

1.3.2 Generic User Interface Building Blocks (GUIBBs)

The FPM framework supplies you with generic UI building blocks (GUIBBs) for displaying the content in your applications.
GUIBBs are generic configurations based on feeder classes.
There is a complete separation of the UI and the business logic; the business logic is contained in the feeder class. In the feeder class, the application (at
design time) defines the data to be displayed along with a configuration. The concrete display of the data on the UI is only determined by the GUIBB at
runtime; this is done automatically using the configuration provided and with the data, to be displayed, specified by the feeder class.
You can edit a statically-created GUIBB using the FPM configuration editor, FLUID. However, GUIBBs can also be created dynamically at runtime; the FPM
framework indicates the presence of such GUIBBs at design-time in the Message Area of FLUID.

GUIBB or Freestyle UIBB?

There are a number of reasons why using a GUIBB to display your content is preferable to using a freestyle UIBB:
GUIBBs are SAP UI guideline-conforming templates for displaying content. They make it possible to improve the uniformity of the user-specific views,
and provide an application with a harmonized look and feel.
GUIBBs are fully integrated into the FPM framework. Amongst other things, GUIBBs take care of the UI layout, spacing, and certain product standards
such as accessibility.
GUIBBs provide you with a code-free configuration of the UI.

Which GUIBB to Use?

FPM covers most content display requirements by providing the GUIBBs outlined in the table below:
Purpose

Suitable GUIBB

Display data in a list or table format

List ATS Component

List ATS with Integrated Data Access (IDA)
Hierarchical List (Tree) Component
List Component

Display data in a form format

Form GL2 Component

Form Repeater Component
Form Component

Display data as a search component

Search Component

Display data in other formats

Analytics Component
Chart Component
Launchpad Component
Personal Object Worklist (POWL) Component
Visual Business Component

Organise the layout of other GUIBBs

Composite Component
Tabbed Component

More Information
Feeder Class

1.3.2.1 Feeder Class

A feeder class provides a link between the application and the generic user interface building block (GUIBB). The feeder class contains the business logic
behind an application.
Feeder class implementations are based on a predefined interface definition (supplied by FPM), providing all necessary methods and corresponding signatures

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 10 of 16

to standardize the communication between the application and the GUIBB.

This communication embraces the following:
Application definition (for example, data definition, structure or table definition, and their technical aspects)
Default layout information, and corresponding field dependencies
The (optional) action definition based on meta data
Action/event handling, and data forwarding to the underlying application model
A feeder class is a class that implements one of the following ABAP interfaces:
IF_FPM_GUIBB_FORM (for all Form components)
IF_FPM_GUIBB_FORM_REPEATER (for Form Repeater components)
IF_FPM_GUIBB_LIST (for all List components)
IF_FPM_GUIBB_SEARCH (for Search components)
IF_FPM_GUIBB_TREE (for Hierarchical List components)
IF_FPM_GUIBB_LAUNCHPAD (for Launchpad components)
Each interface above contains the same set of methods; it is the parameter list that is different for each interface.
The following methods must always be implemented by the application (to provide the data at runtime):
GET_DEFINITION
Defines the field catalog of the component (that is, the fields that are available for use in the configuration), and supplies the component at runtime with
data from the application using the GET_DATA method.
GET_DATA

Note
Even if you are not using a particular method in the feeder class interface, implement it as an empty method to avoid a system dump.
Feeder class settings can be accessed in the FPM configuration editor, FLUID; see the General Settings panel of the individual GUIBB component.

1.3.3 Reuse User Interface Building Blocks (RUIBBs)

Definition
A Generic UIBB (GUIBB) is a pure UI pattern that does not support any business functionality; the business functionality is provided in the feeder class by the
application. However, a Reuse UIBB (RUIBB) is, more or less, a complete component offering common business logic and a user interface to go with it.
Floorplan Manager (FPM) provides the marker interface IF_FPM_RUIBB, which all WD components acting as RUIBBs, must implement.
FPM provides the following RUIBB components:
Attachment Component
Notes Component

More Information
Generic User Interface Building Block (GUIBB)

1.3.3.1 Attachment Component

Definition
A component used specifically for the handling of attachments or links in an application.
The required IF_FPM_RUIBB marker interface is implemented by the attachment 'wrapper' component FPM_ATTACHMENT_WRAPPER.
An Attachment Component is an example of a Reuse User Interface Building Block (RUIBB).

Structure
An attachment component is displayed in tabular format at runtime with each row representing a separate attachment or link.
At runtime, you can download new attachments and links, edit and delete existing ones, sort, filter, and group attachments and links.
The exact structure of the attachment component at runtime is determined by the feeder class of the list component within the attachment component.

Integration
You configure this component using the FPM configuration editor, FLUID.
Technically, an attachment component is a list component embedded in an attachment wrapper component. The information displayed at runtime is
determined by the feeder class attached to the list component configuration. If you need to configure the data displayed in an attachment component, you
therefore configure the list component configuration within it.
You can also edit where attachments are stored: open FLUID for the attachment wrapper component to display the Storage Type field.

More Information
List Component (List ATS)

1.3.3.2 Notes Component

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 11 of 16

1.3.3.2 Notes Component

Definition
A component used specifically for the handling of notes in an application.
The required IF_FPM_RUIBB marker interface is implemented by the notes 'wrapper' component FPM_NOTES_WRAPPER.
A Notes Component is an example of a Reuse User Interface Building Block (RUIBB).

Structure
A notes component is displayed in tabular format at runtime with each row representing a separate note.
At runtime, you can create, edit, delete, and sort notes.
The exact structure of the notes component at runtime is determined by the feeder class of the list component within the note component.

Integration
You configure this component using the FPM configuration editor, FLUID.
Technically, a notes component is a list component embedded in a notes wrapper component. The information displayed at runtime is determined by the
feeder class attached to the list component configuration. Therefore, if you need to configure the note component, you configure the list component
configuration within it.
You can also edit where notes are stored: open FLUID for the notes wrapper component to display the Storage Type field.

1.4 FPM Event Loop

An event loop is triggered in an application by an event, such as a mouse-click. When an event occurs, the Event Loop ensures that the event is appropriately
handled by ensuring that all relevant methods are triggered, and in the correct sequence too.
In Web Dynpro ABAP programming, a user interaction is reflected by a Web Dynpro action. If a user interaction should affect not only a local component but
other components in the application too, the Web Dynpro action must be transferred to an FPM event.
This FPM event then passes through an FPM event loop (or phase model) which is integrated into the Web Dynpro phase model. Within the FPM event loop,
all involved components can participate in the processing of the event.
If the FPM event results in another screen assembly (for example, navigation to another step in a GAF application), the FPM handles this itself; there is no
need for the application to take care of this.

1.4.1 Raising Standard FPM Events

In a floorplan-based application, most events are triggered when a user chooses the Next or Previous buttons (in a GAF instance) or when switching from
one page or view to another (in OVP or OIF instances). For these interactions, the FPM automatically initiates the FPM event loop. Furthermore, these
standard events are handled generically by the FPM.
However, there are scenarios where a standard event needs to be triggered from within an application-specific UIBB, for example by-passing the Initial
Screen if all necessary start-up parameters have been provided as URL parameters.
Each FPM event is represented at runtime by an instance of the class CL_FPM_EVENT . This class encapsulates all the information (including the ID and
additional, optional parameters) which is needed to execute the event.

1.4.2 Triggering the FPM Event Loop

Procedure
1. Create an instance of CL_FPM_EVENT with the appropriate attributes.
For all the standard event IDs, there are constants available in the IF_FPM_CONSTANTS interface.
2. Raise the event by calling the method IF_FPM~RAISE_EVENT and passing the instance of CL_FPM_EVENT .
When an event requires no additional parameters, other than the event ID, the FPM offers an additional method RAISE_EVENT_BY_ID. This makes
Step 1 above obsolete. In this case, raise the FPM event as detailed in the sample code below:
data lo_fpm type ref to if_fpm
lo_fpm = cl_fpm_factory=>get_instance( )
lo_fpm->raise_event_by_id( IF_FPM_CONSTANTS=>GC_EVENT-LEAVE_INITIAL_SCREEN )
Since it is unknown whether the event can be executed successfully or not at the point the event is raised, do not enter code after the call to
RAISE_EVENT[_BY_ID] .

1.4.3 Triggering Application-Specific Events

To raise an application-specific event, follow the same rules as described in Triggering the Event Loop section. The only difference is that the FPM, since it
does not know the semantics of the event, does not perform specific actions for this event. However, the processing of the event is identical, in that all
involved components participate in the event loop in the same way as with FPM standard events (see Reacting to Framework Events section).
The following code provides an example of triggering an application-specific event (including event parameters):
data:
lo_fpm type ref to if_fpm,
lo_event type ref to cl_fpm_event.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 12 of 16

create object lo_event

exporting
iv_event_id = 'DELETE_AIRPORT'.
lo_event->MO_EVENT_DATA->set_value(
iv_key = 'AIRPORT_ID'
iv_value = lv_airport_id).
lo_fpm = cl_fpm_factory=>get_instance( ).
lo_fpm->raise_event( io_event = lo_event ).

1.4.4 Asynchronous Callback

With Web Dynpro's notification service, it is possible to start a long-running process from the UI in an asynchronous mode; whilst the process is running in the
background, the UI remains free and the user can continue to work.
The user receives notification as soon as the process is completed. The service is wrapped by FPM so that it can be used without the need for a freestyle
UIBB.
To use this service, the application must do the following:
1. Call IF_FPM~REGISTER_ASYNCHRONOUS_EVENT , and pass the FPM event to the method which shall be triggered after the asynchronous process is
finished. This method returns a Notification ID .
2. When the process is finished, the application must inform the FPM framework by calling the following:
cl_wd_notification_service=>update_event_status(
exporting
event_id = iv_notification_id
"The Notification ID returned by IF_FPM~REGISTER_ASYNCHRONOUS_EVENT
event_status = cl_wd_notification_service=>c_status_done).
FPM then triggers the FPM event provided in the first step automatically.

1.4.5 Interaction with Web Dynpro Phase Model

The FPM event loop is integrated into the Web Dynpro phase model, as the following figure shows:

Figure 1: FPM Event Loop

1.4.6 Key Web Dynpro Methods used in FPM

There are Web Dynpro methods that are used frequently in the FPM framework.
The following Web Dynpro methods are the most important ones in respect of FPM.
Table 1:

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 13 of 16

Table 1:
Method

Description
A standard Web Dynpro method that is called only once in the lifetime of a Web

DOINIT

Dynpro component by the Web Dynpro runtime. This method is used to initialize
your component, for example initialize attributes and create helper classes).
DOBEFOREACTION

A standard Web Dynpro method that is called by the Web Dynpro runtime on all
visible UIBBs when the user triggers a round trip. According to Web Dynpro
programming guidelines, generic validations must be handled in this method; for
example check that all mandatory fields are filled.

Action handler ( ONACTION )

The registered Web Dynpro action handler is called. You then have the following
options:
If the user interaction does not affect other UIBBs, and there is no need for
FPM features such as data-loss dialog boxes, you can handle the action
locally in your UIBB. Use standard Web Dynpro programming; for example
selection of another radio-button leads to different enabled/disabled settings
of other controls on the same view.
For all actions which may affect other UIBBs, raise an FPM event.

1.4.7 Different Categories of Web Dynpro Interfaces

With regard to the behavior of instantiating Web Dynpro components and their participation within the FPM event loop, the Web Dynpro interfaces provided by
the FPM can be divided into the following categories:
Category I
More than one Web Dynpro component implements this Web Dynpro interface.
Those which do, may have more than one instance, and the instances may only participate in a part of the FPM event loop during the applications
lifetime. The following Web Dynpro interfaces belong to this category:
IF_FPM_UI_BUILDING_BLOCK
IF_FPM_TRANSACTION, IF_FPM_WORK_PROTECTION
IF_FPM_RESOURCE_MANAGER
Category II
Only one Web Dynpro component implements this Web Dynpro interface.
The corresponding Web Dynpro component has only one instance which participates at all FPM event loops that happen during the applications lifetime.
The following Web Dynpro interfaces belong to this category:
IF_FPM_APP_CONTROLLER
IF_FPM_SHARED_DATA
IF_FPM_OIF_CONF_EXIT (and IF_FPM_GAF_CONF_EXIT and IF_FPM_OVP_CONF_EXIT )

Note
When using the interfaces IF_FPM_APP_CONTROLLER and IF_FPM_OIF_CONF_EXIT (or IF_FPM_GAF_CONF_EXIT or
IF_FPM_OVP_CONF_EXIT ) together, they must be implemented by the same Web Dynpro component. Furthermore, if the Web Dynpro interface
IF_FPM_SHARED_DATA is also required, it is recommended to implement it in that same Web Dynpro component too.

1.4.8 Triggering a Data-Loss Dialog Box in the FPM Event Loop

Each UIBB can request a data-loss dialog box during the FPM event loop.

Triggering the Dialog Box

To do this, you must return the pre-defined instance of the class CL_FPM_CONFIRMATION_REQUEST as shown in the following code-block:
METHOD needs_confirmation
IF
eo_confirmation_request = cl_fpm_confirmation_request=>go_data_loss
ENDIFENDMETHOD
To display other confirmation dialog boxes, create your own instance of the class CL_FPM_CONFIRMATION_REQUEST and add your own application-specific
text.

Resuming the Event

Once the required user input has been obtained, the frozen FPM event is continued (either receiving the result OK or FAILED).
To do this, call the FPM method RESUME_EVENT_PROCESSING within the action handler methods for the buttons of the dialog box. The sample code below
shows how this might look:
DATA lo_fpm TYPE REF TO if_fpm.
lo_fpm = cl_fpm_factory=>get_instance( ).
lo_fpm->resume_event_processing( if_fpm_constants=>gc_event_result-ok ).
After the event is resumed, the remaining UIBBs are processed (if there is more than one UIBB). The following figure summarizes the behavior described
above:

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 14 of 16

Figure 1: Phase Model for Triggering a Data-Loss Dialog Box and Resumption of Event

1.5 FPM/Web Dynpro ABAP Adjustment Concept

The concrete layout of an FPM application is determined by the application configuration, and the configurations of the embedded components (UIBBs). These
configurations can be adjusted or changed at any time.
Floorplan Manager uses the FPM/Web Dynpro ABAP Adjustment Concept for making such changes. This framework is illustrated in the figure below:

As illustrated above, you can adapt an FPM application to your needs on a number of different levels, and through a number of different people:
Configuration Level (Developer)

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 15 of 16

The fundamental modeling of an FPM application occurs on the this level. Various components used in the application are created, programmed, and
given a basis configuration by developers.
Customizing Level (Administrator)
Applications with their basis configuration can be adapted to enterprise-specific requirements at the customer site on this level. This is done without
modification to the underlying configuration. These kinds of adjustments usually occur on the client-level and for all users.
Personalization Level (User)
Applications can be changed by individual users in various ways to fit their personal needs on this level. This is done without modification to the
underlying configuration..
The individual layers of this concept are explained in more detail in the relevant sections of this documentation.
For more information, search for Web Dynpro ABAP Configuration Framework in the SAP Help Portal.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 16 of 16