What is the real business use case of interface IF_FPM_MULTI_INSTANTIABLE  in fpm applicaion?

Hi Experts.

For each feeder class in FPM different feeder parameters are there, where exactly this parameters are defined? or for a custom feeder class if we want to giving parameters how to do that...

Thanks in advance. Kp

Feeder class parameter can be used in many ways to build some more generic feeder class which can be used across multiple UIBB processing in FPM application.

The below post tries to show one use case of the feeder class parameter which can be used to build one list uibb feeder class that can be used in many list uibb configuration.

Let’s create a class which implements interfaces related to list uibb processing.

Go to the GET_PARAMETER_LIST method.

Here we can pass a name and a type . The type may be a data element.

Now create a OVP application in Tx- FPM_WB. Add a list UIBB and create a configuration.

The list UIBB configuration asks for feeder class.

Provide the created feeder class. Click on Edit Parameter.

This data element used in the feeder class IF_FPM_GUIBB~GET_PARAMETER_LIST method as TYPE.

Now the feeder class asks for the parameter value.

Add a parameter name as SPFLI and click on OK.

The feeder class doesn’t provide any field catalogue yet.

In OVP application create one more list UIBB configuration and click on Configure UIBB.

Provide the same feeder class and click on Edit Parameter.

This time provide parameter value as SFLIGHT.

Feeder class doesn’t provide any field catalogue yet. So no columns appear to add in the list UIBB configuration.

Up to this point, we just finished 2 list UIBB configuration where both use the same feeder class and first UIBB configuration sets the parameter value as SPLFI and the second UIBB sets the parameter value as SFLIGHT. Now we have to add the fields in the list uibb and the fields should be provided from the feeder class.

In the feeder class create an attribute.

Go to the feeder class IF_FPM_GUIBB~INITIALIZE method.

The feeder class pass the field type from the method IF_FPM_GUIBB~GET_PARAMETER_LIST to the listUIBB configuration and the list UIBB configuration created a value. The value is then passed to the IF_FPM_GUIBB~INITIALIZE method.

Here we can read the feeder class parameter value set in the list UIBB configuration by the specific list UIBB. Put the below code and put a breakpoint at last.

In the list UIBB configuration, Select the first uibb configuration and click on Configure UIBB.

Now the FPM framework calls the feeder class IF_FPM_GUIBB~INITIALIZE method and passed the parameter value.

Now go back.

Click on the Configure UIBB for the second list UIBB configuration.

It also passed the feeder class parameter value.

Now we have to set the field catalogue in the IF_FPM_GUIBB_LIST~GET_DEFINITION of the feeder class based on the feeder class parameter set on the list uibb configuration.

Now configure the list UIBB configuration.

Add the columns.

Configure the second list UIBB.

Test the application and now we have two list UIBB’s use the same feeder class.

Add below code in the method IF_FPM_GUIBB_LIST~GET_DATA

Test the application.

Hi,

One of the user is getting an error in Production, when she is trying to the open the PO link in her UWL.

Error is with the FPM config : FPM Application /SAPSRM/WDA_L_FPM_OIF started without config.

Kindly suggest as I am not sure how to replicate in QAS or DEV system or how to debug the issue in PRD system.

And We are using SRM in NWBC and NOT Portal.

Please refer attached screen shot

Thanks in Advance

Johnson George

Instance ID is basically makes difference when the same UIBB configuration is used multiple times in a page in  FPM application.It uniquely identifies the UIBB configuration. The below post shows how instance id associated with a UIBB configuration provides more control on the particular UIBB. The post uses an OVP application with two list UIBBs having same configuration and different instance ID for each  and how to control the UIBB behaviour in the feeder class by using the instance ID.

Create a feeder class for the list UIBB.

Create an OVP application and create a list UIBB configuration.

Provide the feeder class.

Add  the columns to the list UIBB configuration. Save and go back.

Now we want to add a new list UIBB component with the same configuration name as ZCC_FLIGHT_LIST_DEMO but the system doesn’t allow it as both list UIBB having the same configuration and allows only if they have a different instance ID. So lets assign an instance id as PART1 to the first uibb configuration.

Add a second list UIBB component and provide the same configuration name and provide instance id as PART2. Save and test the application.

Now the two list UIBBs on the OVP application have the same look and feel though they have a different instance ID. Now we can make a certain change on each list UIBB based on the their instance ID. Let’s take the case in first UIBB we want to hide/invisible the field AIRPFROM & AIRPTO fields/columns and from the second list UIBB want to hide/invisible the field CITYFROM & CITYTO fields/columns

Now create an attribute as shown below in the feeder class.

So when each UIBB is loaded then the associated instance ID provided in the configuration is available in the INITIALIZE method. Now store this instance id in a global parameter.

Now in the GET_DATA method based on the instance ID make the desired fields hide/invisible. Also you can perform any other action as desired.

Now test the application and here  the output is as below. .

Hello Friends,

I have a WD application created for my WD component in FPM_OIF_COMPONENT. It had four parameters previously and I added two more parameters to this application.

I am using mo_app_parameter->get_value for importing the values of these parameters in my WD component. Now I am getting the values for old 4 parameters and not getting the 2 new parameters values in reference variable lo_parameter_app in method HANDLE_URL_PARAMS of FPM window handle_default method.

Now we have devlopemnet server and testing server. When i try to execute the application in development server, all 6 parameters are getting loaded at runtime for lo_parameter_app but for testing server, only 4 parameters are visible in lo_parameter_app. screenshots are added below.

Please help me on this. Thanks in Advance!

Dear experts. I want that the description field of an attribute in the UIBB will be automatically populated soon after selection. I changed at the drop down selection of FPM Event ID for onEnter under action assignment tab into FRW_UPDATE (Aktualisieren). But this didn´t fix the problem.

Thanks a lot for any suggestions

Daniele

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

Floorplan Manager for Web Dynpro ABAP

Most of the adaptation concepts used by Floorplan Manager (FPM) are available for Web Dynpro ABAP applications as well, i.e. Configuration, Customizing and Personalization. Figure 1 outlines these concepts.

Figure 1: Web Dynpro ABAP Adaptation Techniques

However, due to the specific way FPM uses Web Dynpro ABAP, special considerations are needed.

What is specific about FPM is the heavy usage of Web Dynpro configurations. So let’s have a look at the typical structure of an FPM-based application.

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 these two entities:

• Web Dynpro ABAP Application: Contains information about the main component (the floorplan component in FPM applications, described below) and 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.

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.) and which components shall be embedded in the content areas, which buttons are displayed in the toolbar, name of application-specific controller, etc.

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). In order 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.

  And 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.

For the decision on how to adapt an FPM-based application, it is crucial to know what is done by coding and what is defined by configuration. Therefore, a list of places where coding is relevant is necessary:

• 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 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
• 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. Normally, implicit configuration can be ignored when using FPM.

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

A Detailed Look at the Structure of an FPM-Based Application

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 of 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.
3. You are directed to the Application Hierarchy Browser which has two modes: the Browser Mode and the 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, which is a configuration for application FPM_DEMO_PLAYER_1. Click on the link in the Configuration ID column; the editor for the application configuration is launched (see Figure 6).

Figure 6: Editor for Application Configuration

Application configuration FPM_DEMO_PLAYER_1 is using component FPM_OVP_COMPONENT as the start component; the one single row 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 layout, 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 have to 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 (orange overlay).

Embedded in the OVP are several UIBBs. The two which are currently visible are marked with the blue overlay.

Close the Application Hierarchy Browser.

Which Objects have to 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 not easy to determine which objects must be adapted in order to achieve the intended changes. Therefore, the following table with a small selection of use-cases is intended to help you:

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:

Options for Adaptations - Overview

This section provides an overview of the following adaptation options:

• Copy Application
• Enhancement
• Customizing and Personalization
• Modification
• Context-Based Adaptations (CBA)

Copy Application

The simplest option is to copy a 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 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 SAP Help documentation).

       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) mainsteps, substeps (Guided Activity Floorplan), main views, sub views (Object Instance Floorplan) contain a cumbersome 32-digit global unique identifier (GUID). See also SAP Note 1917681.
• For Release SAP NetWeaver 7.02: Corrections and improvements done by SAP will not reach the enhanced component configuration, since the enhancement is technically based on a copy of the original (so-called Delegation Enhancement).

Customizing and Personalization

Component configurations can be adapted on the basis of two additional layers:

• Customizing Layer: This is 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 applicationCUSTOMIZE_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 leads you to WD application CUSTOMIZE_COMPONENT either addressing the Floorplan configuration or a GUIBB configuration . 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').

Note: This layer is mentioned only for completeness-sake. It is not relevant for the topic of this document and is not discussed further.

Figure 8 compares the different Web Dynpro ABAP adaptation techniques:

Figure 8: Configuration, Customizing and Personalization

       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 best approach to fine-tuning 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. This might lead to semantic data inconsistencies during the FPM runtime if a corresponding component configuration is created at a later point.
• 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.

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 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 has to be re-implemented.

Context-Based Adaptations (CBA)

Context-Based Adaptations is an adaptation concept that 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 or runtime conditions.

       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.
• Concept work is required before implementation, e.g. defining a meaningful Adaptation Schema.

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.

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 Application Hierarchy Browser again via function and choose 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). Via 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 on the transport dialog. Once the deep-copy has been created you will have links in the 'Target Configuration ID' column which will navigate you 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 editor.

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.

Figure 11: Application Hierarchy Browser after Deep-Copy

Another window will open, displaying the copied application configuration. In the toolbar there is a Test button (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 on 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 via function .

Figure 13: Deleting the Tennis Player Page in FLUID

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

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 on 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 achieve this using Drag & 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 left 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.

So 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 exactly the same as it as it did previously but with two exceptions: there is yellow warning bar telling you that you are in Customizing mode, and there is a Customize Page button in the upper right corner of the application (see Figure 16).
3. Navigate to the Customizing editor (FLUID) by clicking this button.

Figure 16: Demo Player Application launched in Customizing Mode

Note: Alternatively, you can access the Customizing level directly from an application at runtime. Add the parameter sap-config-mode=X to the existing URL in the address bar of the browser window at runtime.

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 selecting the form UIBB in the floorplan schema and clicking the Show Customizable Areas toggle button and jump into FLUID on customizing level with function (see Figure 17).

Figure 17: Navigating into 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 for 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 also 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 above mentioned configurations in FLUID, make sure that you switch into the display mode by using the Cancel button. Then follow the menu path Additional Functions→ Enhance (see Figure 18).

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

This document is continued in Part 2.

Dear experts,

i´d like to create a role in PFCG which i can assign to one or more users that makes that

users will have a personalized setted layout of the UI in a change request in MDG.

Any ideas? Thanks

Hi Experts,

I want to adapt a standard SAP standard FPM screen.

Fortunately, it is already adapted already by SAP.

In the same standard adaptation, I want to add my custom 'Schema' addition to the SAP standard one.

Is it possible? please clarify me.

Thanks and Regards,

Raj

The table selection Menu appears in the top left corner of FPM List UIBB in Netweaver 2004 version by default (as shown in the attached screenshot).

In Netweaver 7.4 FPM Configuration the table selection menu is not appearing on the list. Any advise on this would be appreciated.

Hi,

       When lead selection is done on table of  UIBB, then we would like to change definiation of selected row.( Runtime ).

        Can we do in EXIT or BADI relevant for FPM Framework ?

       Thanking you,

Thanking you,

Regards,

  Satya

Hello Folks,

I am working in SAP FPM (WDP/FPM). As suggested by I have declared the field symbol of type standard table. Still dump or run time error.

In my application, CS_DATA is dynamically changing the structure. Every time different structure is loading. cs_data is of type DATA.

My code:

    FIELD-SYMBOLS: <ls_data>       TYPE standard table,

  <ls_data_title> TYPE any,

<LFS_value> type any.

IF NOT cs_data IS INITIAL.

ASSIGN cs_data->* TO <ls_data>.

IF <ls_data> IS ASSIGNED.

ASSIGN COMPONENT 'TITLE' OF STRUCTURE <ls_data> TO <ls_data_title>.

IF <ls_data_title> IS ASSIGNED AND <ls_data_title> IS NOT INITIAL.

ASSIGN COMPONENT 'ZZEHSM_NEW_NR'  OF STRUCTURE <ls_data> TO <LFS_value>.

IF <LFS_value> IS ASSIGNED.

MOVE '2016-06-0001' to <LFS_value>.

ENDIF.

ENDIF.

UNASSIGN: <ls_data_title>, <LFS_value>.

ENDIF.

.

Dump is at statement: ASSIGN cs_data->* TO <ls_data>.

Can you please suggest.

Thanks,

Yerukala Setty

Hi,

how can I change the width of the columns in the List UI? I'm using the interface IF_FPM_GUIBB_LIST.

kind regards,

Pieter

Hi all,

I'm working on MDG which is heavily use FPM for UI.

I would like to enrich the display and add a side panel to display the attachements lists (from standard role SAP_BSSP_ILM_SIDEPANEL)of business partner (supplier) diplayed in MDG.

I work on NW 7.31 and side panel is working for transactions, so configuration look right.

I've been looking into SDN forums but nothing help me on how I can enable the side panel link in the BS_OVP_SP configuration( or copy of configuration) related to the standard application BS_OVP_BP.

I'm wondering if I start on the right level on the application or configuration...

Also, the strange thing is that BS_OVP_BP_CBA configuration of component BS_OVP_BP has a setting enables about side panel and use the configuration id "/BCV/SIDEPANEL_20" so why I can't see it ?

I also read the FPM includes natively the requirements on web dynpro side to add a side panel, so I'm looking for the correct way of activating it.

Does anybody already tried to add a side panel in a standard SAP FPM application ? ca you share with me your experience?

          Pierre

Blogs from members of the FPM team.

You'll find the more recent blogs at the top of the table.

Also:

ALV and FPM on SAP HANA: See and feel the Difference - Thea Hillenbrand

Hi everybody,

I would like to know if there is  a way to detect data changed in a form field without pressing Enter and without clicking a button.

This will be an amount field that needs to be entered and any value entered will already require a message to be displayed. The event for "Enter pressed" will be used for another purpose. Also I want to avoid an unnecessary button in order to speed the user interaction.

thanks,

Guilherme

Hi All,

Copied Create Initiative  functionality in PPM into Z Application . Here we have fields like Initiative Name , Planned Start and Planned Finish .

How to make this fields as mandatory and how to validate the mandatory fields when clicked  on save button ?

  when we clicked on create Initiative Button Below screen will appears

• Here How to make this fields as mandatory ?
• When we clicked on Save button   how to handle  validation of fields ?

Thanks & Regards,

Naveen

Hello together,

i have some questions about:

1. The right way to acces the BCV Sidepanel from an FPM Application

2. The function of the BCV ( here the BCV shall react on the selected line of an ATS List component)

1. Where is the right entry point for creating the SidePanel Access?

I found How to Integrate the BCV Side Panel into a Web Dynpro Application#  and did define the Context key and create a simple  CNR-link to open the side panel at a Initialize of the GUIBB component taht shall pas the tag(s).

But  when i open now the component in configuration mode, it tells me, i'd not have any valid field descriptor, wahts not true. Removing the Code to pass the context key, all erros vanish in configuration.

So, there is something wrong in this aproach.

2nd:  Setting up the bcv and connecting via Tag Name in the ATs-List -Field does "work" somehow, but not in a nice way.

Selecting a line and then using Refresh in the Side-Panel ( as an example the overview has been choossen to show context data) does show the related data for the tagged field(s) of the line. Ok. something seems to be working "ok".

But the refresh shoud be done automatically , when the user selects the line.
(Reason: If the user changes the line and the refresh is not done automatically, he/she has to check if the displayed data in the sidepanel really belong to the selected line and might interprete old data as belonging to the selection   )

(How) ist that possible?

Thanks for suggestions,

Ulrich Becker