How to Create, Enhance and Adapt Floorplan

Manager Applications for SAP_UI 7.55

Applies to:
SAP S/4HANA 2020 (On Premise), ABAP Platform 2020, SAP Fiori 3.0

Summary
Many business applications provided by SAP S/4HANA 2020 are built using Floorplan Manager for Web
Dynpro ABAP. These user interfaces (UIs) are very flexible, and easy to adapt to the needs of individual
customers. This document presents an overview of the different options that Floorplan Manager provides for
customer adaptations and discusses their advantages and drawbacks. With the introduction of SAP Fiori 3.0,
the new visual theme Quartz led to a visual revision of the Floorplan Manager runtime.

Authors: Simon Hoeg, Julia Bender, Christian Günther

Company: SAP SE

Created: 1. February 2021

1
Table of Contents
Adaptation Concepts in Web Dynpro ABAP................................................................................................... 3
Floorplan Manager for Web Dynpro ABAP .................................................................................................... 3
Component Configurations ........................................................................................................................ 5
Structure of an FPM-Based Application in Detail ........................................................................................ 6
Which Objects Should be Adapted? ........................................................................................................... 8
Options for Adaptations - Overview ............................................................................................................... 9
Copy Application ....................................................................................................................................... 9
Enhancement ............................................................................................................................................ 9
Customizing ............................................................................................................................................ 10
Modification ............................................................................................................................................. 11
Context-Based Adaptations (CBA) ........................................................................................................... 11
SAP Screen Personas ............................................................................................................................. 12
Options for Adaptations – Details ................................................................................................................ 12
Copy Application ..................................................................................................................................... 13
Starting the Application ....................................................................................................................................... 13
Adapting the Floorplan Configuration ................................................................................................................... 14
Adapting the Form .............................................................................................................................................. 15
Customizing ............................................................................................................................................ 15
Adapting the Form .............................................................................................................................................. 16
Enhancement .......................................................................................................................................... 16
Context-Based Adaptations ..................................................................................................................... 17
Defining the Adaptation Schema ......................................................................................................................... 17
Creating a CBA Application ................................................................................................................................. 18
Create a Static Adaptation for Football Fan .......................................................................................................... 19
Create a Dynamic Adaptation for Female Players ................................................................................................ 21
Transport of CBAs .............................................................................................................................................. 22
FPM Mobile Enabler: New Tool to Enable and Support Mobile Use-Cases:........................................................... 22
SAP Screen Personas ............................................................................................................................. 22
Adaptation – Best Practices ........................................................................................................................ 26
Related Content .......................................................................................................................................... 27
Copyright .................................................................................................................................................... 27

2
Adaptation Concepts in Web Dynpro ABAP
Web Dynpro ABAP offers a set of adaptation concepts that are also used by Floorplan Manager (FPM)
applications. The single adaptation concept uses different persistency layers. Figure 1 outlines the basic
idea.

Figure 1: Web Dynpro ABAP Adaptation Techniques

Floorplan Manager for Web Dynpro ABAP

FPM relies considerably on Web Dynpro configurations which, in turn, dictate the typical structure of FPM-
based applications.
The entry point you need for starting an application is the application configuration, which is tied to a single
Web Dynpro application. The necessary information needed to start the application is divided between the
following two entities:
• Web Dynpro ABAP Application: Contains information about the main component (the floorplan
component in FPM applications, described below) and the window of the application
• Web Dynpro ABAP Application Configuration: Contains information about the configuration used
for starting the main component
There are only 3 different main components used in FPM-based applications. Each one corresponds to one
of the supported floorplans:
• OVP (Overview Page Floorplan): component FPM_OVP_COMPONENT
• GAF (Guided Activity Floorplan): component FPM_GAF_COMPONENT
• OIF (Object Instance Floorplan): component FPM_OIF_COMPONENT
These components implement the common behavior which is required by the SAP UI guidelines for all
applications. However, as hundreds of applications share these components, the application-specific settings
obviously cannot be part of the components themselves. Therefore, you can think of the components above
as templates, and all application-specific settings are stored within the configurations that you make of these
components.

3
The configuration of the floorplan component contains information about the structure of the application (e.g.
which roadmap steps shall be displayed in GAF, which pages shall be offered in OVP, etc.). Additionally, it
contains such information as to which components shall be embedded in the content areas, which buttons
are displayed in the toolbar, the name of the application-specific controller, and so on.
The most important information within the floorplan configuration is the list of the embedded components
used for displaying the application data. These are normal Web Dynpro components which implement a
specific interface, IF_FPM_UI_BUILDING BLOCK. To distinguish them from arbitrary Web Dynpro
components, they are called UIBBs (UI Building Blocks). There are two types of UIBBs:
• Freestyle UIBBs: These UIBBs mostly have their own views, which are more or less static and
specific for the application they are used for. Configuration is not relevant or of minor importance for
this type of UIBB.
• Generic UIBBs (GUIBBs): These UIBBs are provided by the FPM framework (e.g. Form UIBB or
List UIBB). These GUIBBs again implement the common behavior defined by the UI Guidelines.
However, as with the floorplan component, everything that is application-specific is stored in the
GUIBB component’s configuration. The configuration contains the layout information for the UI as
well as a link to the feeder class, which is the interface to the backend functionality.
But where is the application-specific code? So far, an FPM-based application is defined by a set of individual
component configurations but, of course, there is specific coding involved in every application.
When deciding how to adapt an FPM-based application, it is crucial to know what is done by coding and
what is defined by configuration. The following is a list of places where coding is relevant:
• Application Controllers: These are used for dynamically changing, at runtime, the settings of the
floorplan configuration. For example, the set of UIBBs within the content area might be configured
statically within the floorplan configuration or set at runtime.
• GUIBB Feeder Classes: These are used to provide the data displayed in the GUIBBs. There is no
option for feeder classes to modify the configured screen layout (except for disabling or hiding fields).
So, in the case of GUIBBs, it is normally quite simple to decide where to adapt.
• Freestyle UIBBs: Freestyle UIBBs must be considered as coding.
To summarize, an FPM-based application can be described as a tree of configurations plus some code, as
Figure 2 shows:

Figure 2: Tree of configurations, controllers and feeder classes

In Figure 2, the darker boxes represent the application and component configurations while the lighter boxes
represent code. There is always the option to dynamically change configurations at runtime; therefore, there

4
is a code box behind each configuration to indicate this. Nevertheless, the configurations have precedence
over the code. The Composite UIBB is included in this figure just to demonstrate how 'deep' an application
hierarchy can be.

Component Configurations
As outlined in the previous section, an FPM-based application is fundamentally defined by a tree of
configurations. A configuration that belongs to a Web Dynpro component is created and edited by
developers using Web Dynpro application CONFIGURE_COMPONENT. Like all workbench objects, the
component configuration is found in all clients and it can be copied, versioned, enhanced and transported.
Furthermore, it consists of an explicit and implicit part:
• The explicit part results from an explicitly-defined, also known as component-defined,
configuration context. All the design templates (floorplans, Generic UIBBs) that are included in the
Floorplan Manager are based on an explicit configuration context. They can be edited by using a
WYSIWYG editor called FLUID (Flexible UI Designer) (see Figure 3 below).
• The implicit part results from a generically created configuration context. UI elements that have
been statically created by Web Dynpro can be edited in the Web Dynpro ABAP configuration editor
via the View dropdown list option Web Dynpro built-in. In most cases, implicit configuration can be
ignored when using FPM.

Figure 3: FLUID (Flexible UI Designer) showing Component Configuration FPM_DEMO_PLAYER_OVP

5
Structure of an FPM-Based Application in Detail
In this section, we will have a detailed look at the structure of an FPM-based application. As an example, we
will use application FPM_DEMO_PLAYER_1 with application configuration FPM_DEMO_PLAYER_1.
When you start the application, the screen looks like that in Figure 4:

Figure 4: Demo Application FPM_DEMO_PLAYER_1

Let’s look at the application’s structure using the Application Hierarchy Browser:
1. Make sure that you have run the demo application with an enabled SET/GET parameter
FPM_CONFIG_EXPERT (see the settings in transaction SU3).
2. Press the button in the header toolbar (see Figure 4).
3. You are directed to the Application Hierarchy Browser which has two modes: Browser Mode and
Deep-Copy Mode. For an overview of the application, we use the Browser Mode.
4. Choose the button ; the screen should look like Figure 5, displaying the application’s structure
in a hierarchical way.

Figure 5: Application Hierarchy Browser

Now let’s try to map what you see in this schematic view of the application with the screen of the application.
The root node corresponds to an application configuration named FPM_DEMO_PLAYER_1(see Figure 5)
which is a configuration for application FPM_DEMO_PLAYER_1. Click the link in the Configuration ID column;
the editor for the application configuration is launched (see Figure 6).

Figure 6: Editor for Application Configuration

6
Application configuration FPM_DEMO_PLAYER_1 is using component FPM_OVP_COMPONENT as the start
component; the one single row1 corresponds to that component. Here, it is specified that
FPM_OVP_COMPONENT will start with component configuration FPM_DEMO_PLAYER_OVP. As component
FPM_OVP_COMPONENT is the component providing the floorplan’s functionality and layout2, we will use the
term 'floorplan component' for it and the term 'floorplan configuration' for the configuration used to start it.
Close this window and go back to the Application Hierarchy Browser. We can see the same information in
the second row (Figure 5).
Below the Overview Page floorplan node there are sub-nodes for each page within the application; the
application consists of two pages (Football Player and Tennis Player). Each page consists of a List UIBB in
the page’s master area and a Form UIBB within the content area.
The UIBBs can be configurable or non-configurable. In this example, we only use configurable UIBBs: a List
and a Form UIBB. The list is used for displaying the names of football or tennis players. If an entry is
selected in the list, the form displays further details of the selected player.
The UIBBs in this demo application are generic UIBBs (GUIBBs), which must be configured. Therefore, in
the rightmost column of the Application Hierarchy Browser you can find the configuration IDs used for
running these UIBBs. For non-configurable UIBBs, this column would be empty.
Figure 7 shows the application at runtime. The colored sections indicate the different component
configurations within the application.

Figure 7: Overview Page Floorplan (OVP) with List UIBB and Form UIBB

The root of the configuration hierarchy is the application configuration, which has no direct visual
representation in the running application. However, it defines which components and configurations will be
embedded directly into the application. This is the OVP with configuration FPM_DEMO_PLAYER_OVP (grey
overlay in figure 7).
Embedded in the OVP are several UIBBs. The two which are currently visible are marked with the blue
overlay in figure 7.
Close the Application Hierarchy Browser.

1
In the other floorplans (Object Instance Floorplan (OIF) and Guided Activity Floorplan (GAF)) there is a second row; there is a
separate component configuration used for the header area (also known as the Identification Region or IDR)
2
For each supported floorplan, there is exactly one component which must be used as the floorplan component

7
Which Objects Should be Adapted?
As you can see, an FPM-based application is composed of multiple objects: application, application
configurations, component configurations and code (where code may mean feeder classes, application
controllers, and Freestyle UIBBs). It is sometimes not easy to determine which objects must be adapted to
achieve the intended changes. Therefore, the following table - with a small selection of use-cases - is
intended to help you:

Intended Change Where to Make the Change

Change the Page Title (e.g. replace Football Player Adapt the floorplan configuration
with a different title) in an OVP based application (FPM_DEMO_PLAYER_OVP in the example)
Add, remove or replace a UIBB Adapt the floorplan configuration
(FPM_DEMO_PLAYER_OVP in the example)
Add, remove or replace a page in an OVP based Adapt the floorplan configuration
application (FPM_DEMO_PLAYER_OVP in the example)
Change the header in an OIF or GAF based Adapt the header configuration (not applicable in
application this example)
Add or remove a main or sub view in an OIF based Adapt the floorplan configuration (not applicable in
application this example)
Rename a main or sub view (e.g. replace Football Adapt the floorplan configuration (not applicable in
Player with Soccer Player) in an OIF based this example)
application
Change the toolbar (e.g. add or remove a button) Adapt the floorplan configuration
(FPM_DEMO_PLAYER_OVP in the example)
Add or remove a roadmap step in a GAF based Adapt the floorplan configuration (not applicable in
application this example)
Add or change a roadmap sub step in a GAF based Adapt the floorplan configuration (not applicable in
application this example)
Add, remove or rearrange fields in a form Adapt the Form UIBB configuration
(FPM_DEMO_PLAYER_FORM_FOOTBALL_1 in the
example)
Add, remove or rearrange columns in a list Adapt the List UIBB configuration
(FPM_DEMO_PLAYER_LIST_FOOTBALL_1 in the
example)

As you see, there are a lot of use-cases which can be covered by adapting component configurations and
there are very powerful options to do this. Nevertheless, there are some adaptation use-cases where it is not
enough to adapt only the configurations. The following table details some adaptation use-cases where code
must be adapted:

Intended Change Where to Make the Change

Manipulate the data displayed in a form or list The data extraction logic is part of the feeder
classes of the list and form UIBBs. You can make
the changes there.
Dynamically change the floorplan configuration at This is a very common use-case; based on the
runtime application state, the toolbar must be adjusted or a

8
 Intended Change Where to Make the Change
different set of UIBBs must be displayed, etc. This
is possible using APIs.

Options for Adaptations - Overview

This section provides an overview of the following adaptation options which are discussed in more detail in a
later section of this document:

• Copy Application
• Enhancement
• Customizing
• Modification
• Context-Based Adaptations (CBA)
• SAP Screen Personas

Copy Application
The simplest option is to copy an SAP-delivered application. With the help of the Application Hierarchy
Browser for Floorplan Manager it is quite simple to copy the whole configuration tree of an FPM application.
It is also possible to keep some branches of the original tree and copy only the part you need to adapt.
Advantages:
It is easy to understand what is happening, and there is absolutely no interference between your
copied entities and later deliveries of the original application.
Drawbacks:
Corrections and improvements of configurations delivered by SAP which affect the original
application will not reach the copied entities of your application.

Enhancement
The general NetWeaver/AS ABAP Enhancement Framework works with FPM-based applications too, as all
necessary entities can be enhanced (a detailed description of the Enhancement Framework in Web Dynpro
ABAP applications can be found in this here).

Advantages:
It is the only option that allows you to combine both code changes and configuration adaptations.
From SAP NetWeaver 7.31 onwards, the enhancement only contains the changed parts of the
application (so-called delta-handling). Therefore, later changes or corrections will be applied even to
an adapted configuration.
Drawbacks:
It is possible to have more than one enhancement per component configuration, and, additionally,
the single enhancements may originate in different systems. With these possibilities, there is the
danger of losing the overall picture.
For Support Package levels below 12 (NetWeaver 7.40), respectively below 16 (NetWeaver 7.31)
some IDs of newly-created elements such as pages (Overview Page floorplan), main steps, sub
steps (Guided Activity floorplan), main views, sub views (Object Instance floorplan) contain a
cumbersome 32-digit global, unique identifier (GUID). For further details, see SAP Note 1917681.
For Release SAP NetWeaver 7.02: Corrections and improvements made by SAP will not reach the
enhanced component configuration; the enhancement is technically based on a copy of the original
(so-called Delegation Enhancement).

9
Customizing
Component configurations can be adapted based on two additional layers*:
• Customizing Layer: This is intended for adaptations carried out by the administrator at the
customer's site. Adaptations are valid for all users in the corresponding client and can be
transported. A Customizing can be created and edited both at the design-time (WD application
CUSTOMIZE_COMPONENT) and runtime (URL parameter SAP-CONFIG-MODE = X, plus context
menu entry Settings for Current Configuration).
For any FPM application that has been started in the Administration Mode (URL parameter SAP-
CONFIG-MODE = X), specific buttons appear in the application header that lead you to WD
application CUSTOMIZE_COMPONENT either addressing the floorplan configuration (Function
Customizing Page) or a GUIBB configuration (Function Show Customizable Areas).
The smart thing about customizing is that it only contains the changed parts of the application (so-
called delta-handling). At runtime, the original configuration is merged with the changes in the
customizing layer.

• Personalization Layer. This contains individual settings for each individual user. A personalization
can be made only during the runtime (context menu entry User Settings).
The personalization layer is mentioned only for completeness-sake. It is not relevant for the topic of
this document and is not discussed further in this document.
* For more information: Web Dynpro ABAP Configuration Framework.

Figure 8 compares the different Web Dynpro ABAP adaptation techniques:

Figure 8: Configuration, Customizing, SAP Screen Personas and Personalization

10
Advantages:
Only the changed parts of the configuration are stored. Therefore, later changes or corrections to the
original base configuration will be applied even to an adapted configuration. No additional effort is
required compared to modifying the original object.
Customizing is the straight-in approach for administrators and developers to fine-tune an FPM
application.

Drawbacks:
Customizing is restricted to component configurations; there is no way to customize code.
In contrast to component configurations, it is not possible to create versions or copies as a kind of
'backup'.
Customizing can be created even if there is no underlying component configuration (for example,
after creating UIBBs when working only in the customizing layer). This might lead to semantic data
inconsistencies during the FPM runtime if a corresponding component configuration is created at a
later point. We recommend avoiding this.
If a configuration is deleted, the Customizing delta remains in the database. This could lead to
semantic data inconsistencies during the FPM runtime, as the delta might contain only fragments of
the information needed to render the FPM application. You can remove the Customizing delta by
going to the initial page of the application CUSTOMIZE_COMPONENT.

Modification
Modifying the original object is another option (changing an SAP-delivered component at configuration level).
Modification is mentioned here only for completeness-sake and is not further discussed further in this
document.
Advantages:
Low initial effort and easy to understand.
Drawbacks:
After upgrade of the application or a support package, there is the risk that the modification is
overwritten and must be re-implemented.

Context-Based Adaptations (CBA)

This adaptation concept allows you to have adaptations based on the runtime environment. With CBA, you
have the option to create multiple adaptations of a single application and, at runtime, the adaptation chosen
is based on the current launch (for static CBA) or runtime conditions (for dynamic CBA).
Advantages:
Only the changed parts of the configuration are stored. Therefore, later changes or corrections to the
original base configuration will be applied even to an adapted configuration. No additional effort is
required compared to modifying the original object.
You can have multiple adaptations in parallel, and there is a mechanism to define which adaptation
should be chosen at runtime.
Most suitable for large, global, role-based projects.
Drawbacks:
Dynamic CBA (in which the adaptation is only determined at runtime based on the displayed data)
normally requires some code adaptations. Therefore, it is often necessary to combine CBA with an
enhancement.

11
 Concept work is required before implementation, e.g. defining a meaningful Adaptation Schema.

SAP Screen Personas

SAP Screen Personas allows for styling, scripting and adaptation of web applications. The whole concept is
dedicated to the business process expert: The role who bridges the gap between information technology
(role administrator) and business professionals (role end user). A corresponding authorization concept is
available, in which the business process expert can be equipped with the new objects P_ADMIN, P_EDIT
and/or P_RUNTIME, whereas the administrator holds the existing and well-known objects S_WDR_P13N or
S_DEVELOP (see Figure 8).
All changes made with the Personas Editor are persisted in a new adaptation layer that lies technically in
between the personalization and the customizing layers (see Figure 1). Consequently, settings made in the
personalization layer can be overruled by Personas and/or customizing. Settings done in the Personas layer
can be overruled by customizing. As with customizing, all the changes are valid only in the corresponding
client, i.e. they are client specific.
With SAP Screen Personas, it is possible to assign a set of changes (flavors) to a single end-user or a group
of end-users. This contrasts with customizing, in which adaptations are always valid for all end-users. Given
the fact that application development resources are limited, SAP Screen Personas is especially attractive for
system environments in which end-user personalization must be restrictively handled. Rather, it is the
business process expert who adapts the web applications according to the needs of the end-users.
Unlike Web Dynpro applications, Floorplan Manager based applications make use of personalization
features based on an explicit configuration context, for example the Overview Page floorplan, List UIBB ATS,
Search UIBB, etc. This explicit layer should be considered in addition to the implicitly-built customizing –
personas – personalization stack. Therefore, special logic is needed whenever explicit personalization
interferes with the Personas flavor. For the Overview Page floorplan, this issue is solved by not persisting the
personalized page layout across sessions whenever a flavor is applied.
Advantages:
Easy-to-use editor to fine-tune and style FPM applications
Flavors can be assigned to user groups
Appropriate for systems in which end-user personalization must be restrictively handled

Drawbacks:
Additional installation effort, see this documentation
Error analysis may become difficult for complex applications and flavors having many changes
Limited access to floorplan and GUIBB features

Options for Adaptations – Details

In this section, we will go step-by-step through the different adaptation options. We will also make the
following simple adaptations to our FPM_DEMO_PLAYER_1 application:

• Simplify the application by removing the Tennis Player page

These changes can be made code-free by adapting the floorplan configuration
FPM_DEMO_PLAYER_OVP

• Rearrange the form layout; put all fields below each other and remove the Previous and Next
buttons.

12
 These changes can be made code-free by adapting the Form UIBB configuration
FPM_DEMO_PLAYER_FORM_FOOTBALL_1

After the adaptations, the application should look like Figure 9:

Figure 9: Application at Runtime after the Adaptations

Copy Application
The Application Hierarchy Browser allows us to not only analyze the structure of an FPM-based application
on different persistence levels (Configuration, Customizing, Context Based Adaptation), but to copy the
configuration hierarchy too.

Therefore, let’s start the Application Hierarchy Browser again using the button , and choosing the Deep-
Copy Mode. This will give you two more columns; the Copy checkbox column allows you to determine
whether to copy a configuration or not, and the Target Configuration ID allows you to enter a name for the
copied configuration (see Figure 10). Using function Change Affixes you may automatically apply a defined
prefix or suffix of three characters.

Figure 10: Application Hierarchy Browser in Deep-Copy Mode

Now choose the Start Deep-Copy button; the system starts to create the new configurations. Provide a
Package Name in the transport dialog box. Once the copy has been created, there will be links in the Target
Configuration ID column which you can use to navigate to the editor environment for these configurations.
You may keep this window open for the rest of this section as we will use it later to launch the configuration
editor3.

Starting the Application

First, we will start the copied application. In the Application Hierarchy Browser, click the link that refers to the
application configuration (in our example Z_FPM_DEMO_PLAYER_1) as shown in Figure 11.

3
In case you mistakenly closed this window, you can re-launch it by starting WD application FPM_CFG_HIERARCHY_BROWSER and
enter the name of the copied application configuration on the initial screen (in the example this is Z_FPM_DEMO_PLAYER_1).

13
Figure 11: Application Hierarchy Browser after Deep-Copy

Another window will open, displaying the copied application configuration. In the toolbar, there is a Test
menu option (see Figure 12 ). Click it to launch the application. It looks exactly like the original one in Figure
4. Close the application window.

Figure 12: Editor for Application Configuration Z_FPM_DEMO_PLAYER_1

Adapting the Floorplan Configuration

Now let’s launch FLUID for the floorplan configuration by clicking the corresponding link (in our example
Z_FPM_DEMO_PLAYER_OVP) in the Application Hierarchy Browser (see Figure 11). Here, we want to
remove the Tennis Player page. To do this, we make sure that the Navigation panel is visible. Choose the
Navigation & Repositories toggle button (see Figure 13). In the Navigation panel, select the Tennis
Player page and remove it using the button .

Figure 13: Deleting the Tennis Player Page in FLUID

Save and restart the application. The screen looks less cluttered; the Page Selector dropdown list box is no
longer visible as, with only one page, it’s no longer needed. Close the window.

14
Figure 14: Demo Player Application after deleting the Tennis Player Page

Adapting the Form

To rearrange the form fields, let’s launch FLUID for the form configuration by clicking the corresponding link
(in our example Z_FPM_DEMO_PLAYER_FORM_FOOTBALL_)in the Application Hierarchy Browser (see
Figure 11). Our task here is to delete the buttons, and to put all fields in one column. We can do this using
drag-and-drop in the Preview panel (see Figure 15):

Figure 15: Form UIBB in FLUID – Rearranging the Fields

Select the row with the Previous and Next buttons and click the Delete button . Then move the fields from
the right column by dragging and dropping them below the fields in the left column. Rearrange them so that
Last Name field is located directly below the First Name field.
Save the application; we have completed our task. Refresh the application to see the changes as shown in
Figure 9.

Customizing
Now let’s do the same adaptations but this time we do it on the Customizing level. Once inside the
customizing environment, the required changes are made in the same way.
Let’s start by launching the application in Customizing mode:
1. Go to transaction SE80 and, using the toolbar button Other object… Shift+F5 , select WD
application configuration FPM_DEMO_PLAYER_1.
2. Start the application by selecting the following menu options in the main toolbar: Web Dynpro
Configuration →Test → Execute in Administration Mode (Shift+F8).
The application looks the same as it as it did previously but with two exceptions: there is a pale
orange warning bar telling you that you are in Customizing mode, and there is a Customize Page
function in the upper right corner of the application (see Figure 16).

15
 3. Navigate to the Customizing editor4 (FLUID) by clicking the Customize Page button.

Figure 16: Demo Player Application launched in Customizing Mode

Note: Alternatively, you can access the Customizing level directly from an application at runtime:

1. Add parameter sap-config-mode=X to the existing URL

2. Open the context menu and select the option Call application in Customizing mode

Adapting the Form

Our last task is the adaptation of the form. From the floorplan Customizing, you can navigate directly to the
form Customizing by firstly selecting the form UIBB in the floorplan schema. Now click the Show
Customizable Areas button (see Figure 17) and you will jump into FLUID on the customizing level.

Figure 17: Navigating to the Form UIBB Editor

As you are using the same configuration editor as for the configuration, you can now execute the same steps
as described in Adapting the Form in the previous section.

Enhancement
The third option is enhancement. Again, we will adapt the same configuration FPM_DEMO_PLAYER_OVP and,
additionally, FPM_DEMO_PLAYER_LIST_FOOTBALL_1.
Before creating enhancements, you should decide whether you want this enhancement switchable or not.
Switchable means that you can activate or deactivate it whenever you like. If you want to have it switchable,
you should create your own package to put the enhancements in.
When you launch the configurations mentioned above in FLUID, make sure that you switch into the display
mode by using the Cancel button. Then follow the menu path Other Functions → Enhance (see Figure 18).

4
The customizing editor is nothing more than the configuration editor started in a different mode. It looks completely the same as in
configuration mode; the only difference is that on pressing 'Save', the changes are stored on customizing level.

16
Figure 18: Creating an Enhancement in FLUID

While creating the enhancements, the system asks you in which package the enhancement should be put.
Enter your switchable package here, if you have created one. Afterwards, you can open the configuration
editor for your enhancement and apply the changes in the same way as previously described.
The implemented enhancement corresponds to a workbench object that can be accessed via transaction
SE80. This development infrastructure contains the following set of functions (very useful for developers):

• Version Management
• Assigned Switch and Switch Position
• Information about the referenced (enhanced) component configuration
• Changing Package Assignment
• Writing Transport Entries
• XML that displays the changed parts (deltas) compared to the referenced object

Context-Based Adaptations
The next option to be discussed is Context-Based Adaptations (CBA). These serve a slightly different use-
case compared to the other options as their application is related to the startup or runtime environment (or
“context”) of the application. Therefore, we will adjust the tasks a little bit in this section:

1. There are tennis and football fans! They are normally not interested in seeing lists of players from
other sports. Therefore, we will remove the tennis player page for football fans and vice versa.
2. We will only rearrange the form fields for female players.

The first task is an example for a static CBA where the application must be adapted based on some startup
parameter. The user of this application is a football fan, a tennis fan or a fan of both, and therefore, the
decision what he or she should see can be taken at startup of the application. Further adaptation isn’t
necessary during runtime.
The second task is an example for a dynamic CBA where different adaptations are to be used based on the
data that is currently displayed. When a female player is chosen from the list of players, the form should look
different than that for a male player. This is a very powerful concept, but it requires some additional code.

Defining the Adaptation Schema

To apply CBA, the application needs to know about the different context characteristics used for adapting. To
fulfill our tasks, we need two characteristics (or adaption dimensions): the fan type (football or tennis fan) and
the gender. Normally, we need to create an appropriate schema for this. This can be done using transaction
SM34 for view cluster FPM_VC_ADAPT_SCHEMA. In this case, the required DEMOPLAYER schema already
exists, as it is part of the demo applications shipped with FPM in SAP_BASIS 7.31 (see Figure 19).

17
Figure 19: DEMOPLAYER Schema in Transaction SM34

Creating a CBA Application

CBA is technically realized by wrapping the original application inside an embedding component which is
responsible for managing the adaptations. This way it’s possible to enable CBAs without modifying the
existing application. However, there is the need for some additional preparation steps, as described below.
1. Launch the FPM Workbench by using transaction FPM_WB.
2. In the section Context-Based Adaptations, click the link Enable FPM Applications for Context-Based
Adaptations (see Figure 20).

Figure 20: Launching the CBA Enabler in the FPM Workbench

3. The CBA Enabler is launched (see Figure 21). In the first step, you enter the Application
Configuration Name to be Adapted, i.e. FPM_DEMO_PLAYER_1. For the dropdown list box
Adaptation Schema, choose the value FPM_DEMO_PLAYER. For the fields Adaptation

18
 Configuration Name and CBA Application Name, enter an appropriate value, in our example
Z_FPM_DEMO_PLAYER_CBA. Click the Next button.

Figure 21: CBA Enabler – Step Enter Adaptation Details

4. In the second step, you can assign a package and a transport request. Click the Save button.
5. The context-based application has now been created. In the confirmation step you may jump into
the runtime by clicking the link Execute Application (see Figure 22).

Figure 22: CBA Enabler – Confirmation Step

Create a Static Adaptation for Football Fan

CBA applications are designed as wrappers around the floorplan configurations. Therefore, without the
context of the wrapper, the adaptation schema to be used is unknown. Nevertheless, when you execute the
CBA application (in our example Z_FPM_DEMO_PLAYER_CBA) you may access the configuration
environment with the known functions in the application header. In the configuration editor, open the
Adaptations panel using the toggle button (see Figure 23). Let’s create an adaptation for football fans by
clicking the Add button.

19
Figure 23: Adding an Adaptation in FLUID

A dialog box appears (see Figure 24) that allows you to define a valid context for this adaptation. Uncheck
the Applies to all values box and enter value F for field Fan Type. Additionally, provide an appropriate
namespace, and then press OK. Another dialog box appears in which you can enter the package and
transport request. Press again OK.

Figure 24: Dialog Box to Provide the Context and the Namespace

The Adaptation panel now lists the two entries (see Figure 25), the Base Configuration and the adaptation for
football fans. Make sure that the latter is selected and remove the Tennis Player page as before. Then save
your changes (button ).

20
Figure 25: Deleting the Tennis Player Page for the Football Fan Adaptation

After starting the application again with the additional URL parameter FAN_TYPE=F, you should see the
application adapted to the needs of the football fans.
Repeat the whole step and create an adaption for tennis fans (make sure the base configuration is selected
when creating the adaptation). Now you have three versions of the same application adapted to each of the
needs of a specific user type.

Create a Dynamic Adaptation for Female Players

Normally, dynamic adaptations require feeder classes to fit into the specific CBA event-handling. Therefore,
an enhancement of the feeder classes is generally required (or the feeder class must be replaced by its own
subclass or copy). Our demo feeder class CL_FPM_DEMO_PLAYER, however, already supports CBA and we
can, therefore, directly navigate to the form configuration and create an adaptation.
Open the Adaptations panel and create a new adaptation. This time uncheck the Applies to all values
checkbox and enter ‘F’ for the Gender dimension (see Figure below).

Figure 26: Adding an Adaptation for the Female Players

Change the form as you did before and save. That’s all there is to do!
Now start the application again (without additional URL parameters) and select a male player. The form
should look like the original application. Then select a female player. You should now see the adapted form.
You can combine this behavior with the static CBA so that the dynamic adaptation will work even when you
start the application for football fans only.

21
Transport of CBAs
The logical transport objects CBAL (Floorplan Manager - Context Based Adaptations - Links/Rules) and
CBAS (Floorplan Manager - Context Based Adaptations – Sets) have been introduced with SAP NetWeaver
7.55 to provide a consistency in transporting all CBA entities belonging together (component configurations,
table entries for links, rules and sets).

Figure 27: Transporting CBAs – Logical Transport Objects CBAL and CBAS

FPM Mobile Enabler: New Tool to Enable and Support Mobile Use-Cases:
SAP_UI component 7.55 (delivered with S/4Hana 2020 and ABAP Platform 2020) provides you with the FPM
Mobile Enabler. Using this new application, existing FPM applications can be optimized to work on mobile
devices such as smartphones and tablets. The FPM Mobile Enabler uses the CBA concept and the CBA
schema FPM_DEVICE. You can start the application using the link FPM Mobile Enabler in the FPM
Workbench (transaction FPM_WB).
Enter the FPM application to be “mobile-enabled” and select – depending on whether smartphone or tablet –
which parts of the application should be changed.
Once you have run the FPM Mobile Enabler, an adaptation configuration will be created for each adapted
FPM configuration. You can fine-tune these afterwards in the configuration editor.

SAP Screen Personas

The last possibility to be discussed here is SAP Screen Personas. The use-case for using SAP Screen
Personas is similar to that described in the Customizing section, that is, it is mainly about fine-tuning of web
applications. You can move and style UI elements, and change labels of fields and buttons. You can also
assign your result (the so-called flavor) to a single user or user groups by using the flavor administration
tools, and you do not need to have S_DEVELOP or S_WDR_P13N authorization.
In addition to the Flavor Editor, there is a Script Editor to build scripts based on Java Script. It allows you to
record actions that, for example, pre-fill input fields or execute button clicks. In our example we focus only on
the styling capabilities of the Flavor Editor.
Let’s try this based on the CBA application Z_FPM_DEMO_PLAYER_CBA for the football players, that is, we
run this CBA application with URL parameter FAN_TYPE=F.
Before we start, make sure that you have assigned appropriate authorizations (see Figure 8 and the Web
Dynpro ABAP Configuration Framework). There is also the corresponding PFCG role:
/personas/editor_role. Check that the global Web Dynpro parameter WD_DISABLE_PERSONAS is not
set (see the settings in WD application WD_GLOBAL_SETTING).

Now launch the Personas Flavor Bar by clicking on the icon at the top of the screen (see Figure 28).

Figure 28: Starting the Personas Flavor Bar

22
Now create a new flavor by clicking on icon and provide an appropriate name and description in the
dialog box that appears (see Figure 29).

Figure 29: Creating a new Flavor for the Football Fans

With button , the new flavor is launched within the SAP Personas editor (see Figure 30). You have
three different tabs (Home, Insert and Tables) in the menu bar equipped with various functions to edit the
flavor. For example, you may assign a background image to the application. For this, you must select the
page header, then press the ESC key to get the parent element (the FPM_OVP_CONTAINER) selected.

Figure 30: Home tab of SAP Screen Personas Editor

By using the Assign Background function, you can upload, select and assign an image (of type bmp, jpg,
png or gif) to the selected container element (see Figure 31).

23
Figure 31: SAP Screen Personas - Assigning an image

As a next step, you may define a transparent background for the Global Toolbar and Details Panel. You can
achieve this with the Fill Color function by changing the value from Default to No Color (see Figure 32).

Figure 32: SAP Screen Personas - Changing the background color

You may hide elements with the Hide function. In Figure 33 we apply this feature to the buttons right-aligned
in the header toolbar. Note, that you can multi-select elements by combining the CTRL-key and left mouse
click.

Figure 33: SAP Screen Personas - Hiding elements

24
Additionally, we will change the color of the text fields in the Details panel. Again, this can be done quickly
with the Font Color function in the Flavor Editor (see Figure 34).

Figure 34: SAP Screen Personas - Changing the font color

You can try additional things like editing the page and panel title, changing the font size or font type of texts,
or adapting the border style and fill-color of buttons, and so on. It depends on the use-case and on your
creativity. You will certainly find the editor easy to handle. The result of the Football Flavor could look like
Figure 35.

Figure 35: SAP Screen Personas - Applying the Flavor at runtime

25
Adaptation – Best Practices
So far you have learned that there are five main ways to adapt an FPM application:
• SAP Screen Personas
• Customizing
• Deep-Copy
• Enhancement
• Context-Based Adaptation

From an end-user perspective, all the above methods may lead to the same or at least a similar result on the
user interface. However, to keep the overall effort to a minimum, it is worth applying the right adaptation
technique to the situation on-site. Figure 36 is a flow chart that will support you in making the right decisions.

Figure 36: Finding the Right Adaptation

As a rough rule, you may use SAP Screen Personas and Customizing for all small adaptations (fine-tuning)
that are valid in the corresponding client, whereas larger development efforts would be better invested in the
configuration layer. There, you may decide between enhancing a delivered application, creating a context-
based adaptation or creating a completely new application.
In addition, we recommend avoiding a mix of different techniques wherever possible. It will help to keep the
overall picture clearer. That also implies that each role should try to complete its work in one persistency

26
layer, e.g. a development consultant should stick to the configuration layer, whereas a business process
expert, being focused on layout changes, should stay on the Personas layer.
Changing button texts, adding form fields, rearranging the UIBBs of a main page are typical examples of
fine-tuning that is most effectively done using SAP Screen Personas or Customizing. Generally, those kinds
of changes are done without any programming effort. If you must address certain user groups without having
developer or administrator authorization, then SAP Screen Personas is certainly the right choice.
In contrast, adaptations that imply changes to ABAP code or creation of new code belong more appropriately
to an enhanced, context-based or newly created application. Examples for this include the creation of a new
OIF variant that should be called at runtime from the OIF initial screen, or the creation of a new feeder class
that is used to configure a new List UIBB.
Enhancements apply to situations where only parts of an application need to be revised. This kind of
adaptation actually corresponds to a modification-free development. The enhancement usually belongs to a
package that is assigned to a switch which can be activated by a business function.
The strongest use-case for context-based adaptations is when there is a dependency between the runtime
context and the corresponding adaptation that is to be involved dynamically during the runtime.
When creating a new application, all the configurations may belong to the customer’s name space. Before
creating all of those on your own, consider the use of the deep-copy function of the FPM Application
Hierarchy Browser.
Be careful with objects that exist only on the Customizing level, such as UIBBs that have been created in the
Administrator mode. At runtime, rendering may become impossible if a configuration of the same ID is
created at a later point in time. Therefore, we recommend that you create new UIBBs on the configuration
level first.

Related Content
SAP Community - Floorplan Manager and Web Dynpro ABAP

Copyright
© 2015 SAP SE or an SAP SE 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 SE Group”) for informational
purposes only, without representation or warranty of any kind, and SAP SE Group shall not be liable for
errors or omissions with respect to the materials. The only warranties for SAP SE 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 SE and other SAP SE 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
[Link]
for additional trademark information and notices.

27