Applies to:

SAP NetWeaver 7.40, SAP Business Suite 7 i2013, SAP ECC 6.0 EhP7

Summary

Since Business Suite 7 Innovations 2010, many UIs provided by SAP are built using Floorplan Manager for Web Dynpro ABAP. These 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 (Configuration, Customizing, and Personalization) and discusses their advantages and drawbacks.

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

Company: SAP SE

Continuation of Part 1

Context Based Adaptations

The last option to be discussed is the 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 kind of 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 has to 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. During runtime further adaptation isn’t necessary.

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

For applying 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 schema already exists (DEMOPLAYER) as it is part of the demo applications shipped with FPM in SAP_BASIS 7.31 (see Figure 19).

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.

• Launch the FPM Workbench by using transaction FPM_WB.
• In the section Context-Based Adaptations click on the link Enable FPM Applications for Context-Based Adaptations (see Figure 20).

Figure 20: Launching the CBA Enabler in the FPM Workbench

• 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. At drop down listbox Adaptation Schema choose the value FPM_DEMO_PLAYER. For the fields Adaptation Configuration Name and CBA Application Name enter an appropriate value, in our example Z_FPM_DEMO_PLAYER_CBA. Then continue with the Next button.

Figure 21: CBA Enabler – Step Enter Adaptation Details

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

Figure 22: CBA Enabler – Confirmation Step

Create 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 functionsandin the application header. In the configuration editor open the Adaptations panel using toggle button(see Figure 23). Let’s create an adaptation for football fans by clicking the Add button.

Figure 23: Adding an Adaptation in FLUID

A dialog 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. Also provide an appropriate namespace, and then press OK. A further dialog appears where you can enter the package and transport request, press again OK.

Figure 24: Dialog 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 (button ) your changes.

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 Dynamic Adaptation for Female Players

Normally, dynamic adaptations require feeder classes to fit into the specific CBA event-handling. Therefore, in general, an enhancement of the feeder classes is required (or the feeder class has to be replaced by its own subclass or copy). Our demo feeder class CL_FPM_DEMO_PLAYER, however, already supports CBA and therefore we can 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.

Adaptation – Best Practices

So far you have learned that there are four main ways to adapt an FPM application:

• Customize
• Copy
• Enhance
• Apply a context-based adaptation

From an end-user perspective, all possibilities may lead to the same 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 (see Figure 27).

As a rough rule, you may use 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 layer, e.g. a development consultant should stick to the configuration layer, whereas a system administrator or power-user, being focused on layout changes, should stay on the Customizing level.

Changing button texts, adding form fields, rearranging the UIBBs of a main view are typical examples for fine-tuning that is most effectively done via customizing. Generally, those kinds of changes are done without any programming effort. 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. By definition, this kind of adaptation 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.

Context-Based Adaptations have its strongest use-case where 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.

Note: 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 the creation of new UIBBs always on the configuration level.

Figure 27: Finding the Right Way to your Adaptation