You may already have heard that it is possible to create web applications with the Floorplan Manager (FPM) for Web Dynpro ABAP without any UI code. You may also have heard that with the NW 7.40 release, the FPM offers a large variety of new modern features such as quickviews, charts, maps, responsive design features, carousels and so on. But if you want to make use of it, you may not know how to start – and how to continue. It is the aim of this blog to show this in a guided tour, supplemented by many screenshots, easy to understand and easy to reproduce.

We will give an example of extraordinary development efficiency: We are going to create an application for product master data maintenance. First we will generate a “raw” UI using a wizard. The wizard already creates an application offering fully functioning capabilities for searching object instances, and to maintain them in a transactional (stateful) UI. Then we start to beautify the generated UI by rearranging UI elements and adding further features. All this does not need deep expert knowledge and you will be impressed what you can achieve by simple configuration. During our beautification, we will allow for some digressions and meet a lot of useful functionality treasures in FPM you probably were not aware of. And in the end you will be convinced that an efficiently developed UI need not imply compromises on usability or visual appeal!

Our journey is split into several sections which are distributed into three parts which are build on each other. In this first part, we generate the raw UI and beautify the search page. In the part II, we fine-tune the filter page and polish up the maintenance page forms. In part III we integrate a Visual Business Map to the maintenance page and connect it to the data flow using wiring.

For a 100% codeless UI we need the business logic to be encapsulated so that it can be consumed via a generic facade: Our only precondition is that our business logic is given as a BOPF object. (BOPF: Business Object Processing Framework.) We will go for a nice SAP demo example, namely a BOPF object based on (a copy of) the well-known EPM data model, and we will choose the EPM Products has main object for our UI. This means in particular that we will create a UI which will has an initial page for searching products as entry point, and an alternative initial page for drilling-down into the set of all EPM products by arbitrary properties. Both from the search and filter results list, we can navigate into the product maintenance page of the UI where we can change product attributes and change the assigned supplier, and it may look like this:


In separate panels we see the assigned supplier’s data and its address located on a map. Whenever the supplier is reassigned, the map is flying out of the old supplier’s address and touching down in the new supplier’s location – a nice wow-effect!

We will use the fairly new FPM-SADL integration for BOPF as it allows to easily and comfortably generate apps with a wizard. You don’ need to know what SADL (“Service Adaptation Description Language”) is – it is sufficient if you think of it as something powerful but internal which provides uniform consumption of different business object frameworks (like BOPF) with the option to conveniently define views and queries on it.

Our system state is based on SAP_BASIS 7.40 SP09, SAP_UI 7.40 SP10, but most features are already available on earlier support package levels. For the BOPF-SADL connection we need SAP_BS_FND 748 – this will be shipped with SAP_BS_FND 747 SP07. Getting interested? Well, then let’s start.

Creating an FPM App via the Wizard for Business Entities

The FPM Workbench will be our starting point. It is an FPM application itself: The WD application configuration ID is FPM_WB, but you can also simply start it from SAPGUI using transaction code FPM_WB. In the browser window, we select “Wizard for Creating FPM apps on Business Entities (CRUD)”.


This starts the SADL-based wizard for creating transactional FPM apps, and the first screen is the same as for any FPM generation wizard. We will create workbench objects which need names, so we first enter a name for the web dynpro application – but without namespace. Instead we use the “Apply Namespace” button in the toolbar and enter the namespace (here we use a local one) in the dialog window so that the wizard can consequently apply it to all generated objects – as we will create a couple of configurations.



We can enter a description if we like and move to the next step which defines the connection to the business logic: As “Business Entity Source” we select “BOPF Business Object” from the drop down list box. That means that SADL connects to BOPF. Now we need to connect to a specific business object node which will be the leading object for our search and maintenance UI. We will go for the EPM product header and thus we type “*epm*prod*” as “Business Entity” and wait for the value suggestion and select “/BOBF/EPM_PRODUCT~ROOT”.


(We could also use F4.) Now we can move to the next step. It may look a little overwhelming, but don’t worry – we don’t need to do much! The system already proposes names for a couple of configurations which shall be generated. They can be changed but we can also leave them as they are. The first row defines the standard search page comprising two UIBBs, the search UIBB and the associated results list UIBB. In the second row, we mark the “Add Filter Page” option as this will add another page to search for specific products: In contrast to the standard search page, which is ideal if you know more or less what you are searching for, we will get an additional search page which we can reach via toolbar button.


The filter page comprises the new FPM Attribute Filter UIBB with which you can browse and drill-down into the data, and observe the data distribution, and also a results list configuration. Try the dynamic “Preview” button and check the difference! If there are no data for the BOPF EPM product yet you can quickly create data by executing report /BOBF/EPM_DATA_GENERATOR. In the third row we find the form configuration for editing the product in the maintenance UI. The configurations in the fourth row are forms for entering the maintenance UI via a given key or for object creation – they are not important here.

As the preview already demonstrates, we are about to create a fully functioning UI for the EPM product. It could also be any other BOPF object, for example a sales order. In any case, we usually want to see associated nodes in the UI as well, for example, texts connected by text associations, the supplier for a product or the sales order items table for a sales order. That means we need to incorporate associated nodes and this can be done on the next, the fourth step.


Here we see the association net spanned by our main node – as there are loops, it is typically infinite (and hence the tree is initially only expanded to a finite level, but it can be manually expanded). We can add associated nodes using three checkbox columns: Marking “Join to Search Page” means that the attributes of this node will be available for the search (and filter) function as well as their results lists. The other two checkbox columns concern the main page (and potentially further added sub-overview and edit pages) of our maintenance UI: Marking “Create UIBB”  means that a separate UI Building Block will be added to display and change the node attributes. This can be a list (default) or form repeater if the node is associated with multiple cardinality (e.g. the sales order’s items), and it is a form if the node is associated with single cardinality (e.g. the product’s supplier). For single cardinality, we can alternatively join the node attributes to the fields (more precisely: field catalog) of the UIBB of the parent node.

In our example, we join the product texts, name and description, to the search page and main UIBB, and we add the the supplier to the search page and add it as separate UIBB to the object maintenance page. We also join the address to the supplier UIBB. We could also add the supplier contacts as separate UIBB. Then we could choose list or form repeater as collection pattern (try the “Preview” button and observe the difference!) – but let’s keep it simple this time, so we don’t mark the contacts here. We move to the next step “Add Charts to Search Page” – which looks a little boring at the first sight. But the music starts if you press the “Add Chart” button in the toolbar.


We can leave the proposed configuration ID and description as they are, but we need to enter a “Dimension”. We enter “COMPANY_NAME_BO” (or select by value help) and leave the proposed “FPM_SADL_CHART_COUNT” as “Measure”. This way a chart will be shown under the search results list which shows the distribution of products into the supplier names (which is nicer than supplier IDs), and thus we also enter “Products by Supplier” as “Chart Title”. (Use the “Preview” and see what happens! If you like you can add further charts.) The chart dimension defines “the pieces of the cake”, and with the company name we decided that each piece will be a product supplier. The measure defines “the size of the pieces”, and with the technical counter field we decided that we simply count the products by supplier. If we had an appropriate measure with a constant currency this might be interesting as well, but the EPM products have e.g. prices in local currencies and it does not make sense to compare U.S. dollars with Japanese Yen.

Well, now we are almost done. We move to the last step where we are asked to assign a package and a transport request for the generated objects. The default is for local objects: package “$TMP” and no transport request. This fits perfectly to our local namespace starting with “Z” we set in the beginning, but of course you could add a proper package, and then a transport request will be necessary.


We finally press “Save” and: That’s it, and after a second our UI is generated. That was easy – a monkey can do it! 😉 We can directly test it from the confirmation screen:


The link “Execute Application” starts our newly created app, it opens the search page. We can execute the search, select a product link and the product maintenance UI opens.


We are able to change product data, encounter the work protection popup if we cancel after changes, and so on. But we first want to beautify our application. You may have noticed that, in our case, the system administrator has set the SAP_CORBU theme as standard. This can be changed globally, but let me show you how we can locally overrule this setting for our application. We start the configuration editor FLUID for the floorplan configuration with the other link “Edit configuration (FLUID)” of the wizard’s confirmation screen. There we use the first link in the breadcrumb to enter our application configuration.


In the application configuration editor we scroll down to the “Design” section of the “Application Parameter” panel. Here we find the parameter “Stylesheet URI (WDTHEMEROOT)”. Instead of “SAP_CORBU” we enter “SAP_BLUECRYSTAL” and save. Now we refresh our browser window for the application – and it looks indeed a little refreshed!


The same we could achieve temporarily by adding the URL parameter “sap-theme=sap_bluecrystal” to the URL. You can try this also for other applications – e.g. the FPM Workbench.

In the following chapters we will fine-tune our newly created app by editing the FPM configurations. Take a break if you like. Think about what has happened – we have created a running transactional application which could be even more complex if more associated business object nodes had been marked. All this without a line of code! So where is the code? The wizard only creates UI configurations – how is this possible? The answer is: The code is in the feeder classes, in the wiring connector classes and in the transaction handler class assigned in the configurations, but these classes consist of completely generic code and they are reused on any business entity – no matter whether it is sales order item or a business partner address. This is possible since these classes operate between the generic SADL facade and the generic FPM interfaces – thus they can be reused on any BOPF object, even more, on any business object of a BO framework which has a SADL implementation. That’s why we don’t need any application specific code here. But what if we would need any very specific UI behavior? Well, then we might need to derive sub-classes from the generic classes – but this may be a topic of another blog, and we do not need it now.

If you have lost the confirmation screen due to a time-out after a break you can always restart the app or FLUID for the floorplan configuration from SE80 – just open the package in which you created the objects ($TMP in our case).

Beautification Part 1: Page Titles and UIBB Titles

The creation wizard has done its very best: It has added some fields of the business object node attributes to the UIBBs, something like the first N fields of the attribute structure, and it has also written labels and texts into the UI configurations. For instance, we encounter “BOPF EPM Product – Product Header Data (BOPF Demo Version)” quite often in our UI. This does not look like sound titles, does it? Where does it come from? Well, this generic wizard simply grabbed the description texts of the BO nodes and attributes. It cannot recognize whether these texts are good or bad. And here they are….well, a question of taste. Similarly, we might not be interested in some technical looking fields or we might like to rearrange fields on the UI. So we need to work over it if we want to build a UI which can be considered as beautiful. We start with the UI texts.

Let’s start with the texts in the floorplan configuration. We start the configuration editor “FLUID” either by the link offered by the wizard’s confirmation screen, or from the runtime UI via the screw driver icon provided for configuration experts, or from the FPM Workbench (transaction FPM_WB), or old-fashioned from SE80. Here we open the navigation panel (if not open already – this is a matter of personalization), and there we simplify the title texts: We replace “Overview: BOPF EPM Product – Prod…” simply by “Overview: EPM Product” and similarly for the others.


By the way: You will notice that at runtime, the title of the main page is getting concatenated with the product ID of the selected product (since it is a unique alternative key).

Next we change the UIBB titles on the main page: We keep the main page selected in the navigation panel, and then we select the UIBBs in the “Overview Page Schema”. We open the attributes panel if necessary and change the titles. We go for the simple titles like “Product” and “Supplier”.


Now we restart our app. Indeed it looks better, but there is still some work to do.

Excursus: Let me finish this section with a little trick which may ease the following work a little: You can navigate into a UIBB configuration by selecting it in the “Overview Page Schema” and pressing the button “Configure UIBB”. You can navigate back by using the breadcrumb. However, sometimes it is useful to directly navigate into a UIBB configuration from the runtime. To do this, you can promote yourself to an “FPM Configuration Expert” by setting the user parameter “FPM_CONFIG_EXPERT=X”. Then you find nice technical buttons in any FPM UI:


With the first one you can directly navigate to the floorplan configuration. With the second one you get all configurable areas (FPM UIBBs) overlaid, and by pressing in such an area you can directly navigate to the respective UIBB configuration.


Very useful, indeed!

Beautification Part 2: Fine-Tuning the Search Results List with Image Quickviews

Let’s first fine-tune the search results list. In FLUID, we first notice that there are more columns configured than we see in the UI. Why that? The reason is that many columns are configured with “Visibility” set as “Not Visible” – check that by selecting attributes and looking into the attribute panel. Such columns are not displayed by default, but at runtime you can add them via personalization dialog – try it by pressing the personalization button in the results list toolbar!

First we remove all the date-time and user name fields such as “CREA_DATE_TIME”, “CREA_UNAME” etc., and also “LANGUAGE_CODE_PR” and the repeated supplier ID field “BP_ID_BO” by multi-selecting them in the schema and pressing the delete button. Next we drag the fields “NAME_PR” and “DESCRIPTION_PR” to the second and third position, and we set their visibility to “Determined by Feeder Class”. (What does this mean? Why is it not simply called “Visible”? Well, even if we make it in principle visible in the configuration, the feeder class could still set it invisible at runtime – if the BOPF properties tell it to do so.) We recognize them as the attributes of the associated text node, and the suffix “_PR” was proposed by the generation wizard in order to avoid naming conflicts of technical fields like “KEY”, appearing in any BOPF node. We change their “Header” texts to “Product Name” and “Product Description” for obvious reasons.


Now let’s remove the field “PRODUCT_PIC_URL”. We don’t want to open a link for each product, but we also don’t want to have a large image in each table row – we prefer a quickview! Lets select the field “PRODUCT_ID”. In the attributes panel, scroll down to the “Display Type Dependent Properties” section. We enter “PRODUCT_PIC_URL” as image field as we know that it carries the URL of the product image. (You can use the value help.)


This is enough to get an image quickview at runtime! Cool! You may also do the same for the text fields “NAME_PR” and “DESCRIPTION_PR”. But we are not yet done. We now enter the “General Settings” panel in FLUID. There we change the “Search Results Objects Name” to “Products”. This makes the results list header with the records counter more readable. We also mark the “Maximize Button” checkbox (see this blog for more information) and we can mark the “Enable Creation of New Views” checkbox if we would like to be able to personalize different views of the results list.


Excursus: Where is the information stored that we actually consume the product node in this UIBB – and the associated texts and supplier data? Remember that the feeder classes are completely generic, so their is no hard-coded reference to the product node. Just open the “Feeder Class Parameters” using the respective button of the “General Settings”.


Here we can see what the wizard has transferred: The entity source and the business entity (i.e. our BOPF BO node), the associated nodes with suffixes.


Very comfortable. We could even add more associated nodes using the “Insert Child” button. But we don’t need it here.

Now restart the app. Looks much better now, doesn’t it?


The quickviews appear on mouse hovering on the product ID link (or texts).

Beautification Part 3: Fine-Tuning the Search UIBB with Search Groups

Next we want to fine-tune the Search UIBB. We would like to define search groups, therefore we first remove all attributes from the “Search UIBB Schema” but we let the (results) List UIBB survive which is also assigned in the schema. Then we press the “Add Search group” button.


In the attributes panel, we maintain “Product” as “Group Title”. Now we want to add search criteria to this group. We can use it with the “Add Search Criteria” button or drag attributes from the “Repositories” panel into the schema. If your database is capable of fuzzy search (as is a Hana DB) you can add the free text search attribute “FPM_SADL_FREE_TEXT_SEARCH_TERM” by dragging it from the repository and dropping onto the search group.


Similarly, we add the “PRODUCT_ID”. Next we would like to enter the texts of the associated text node. To find the text attributes more easily we use the filter function which separates the different nodes. (This is available since the feeder class uses the special groups in GET_DEFINITION.)


Now we add “NAME_PR” and “DESCRIPTION_PR” and change the text in the attributes panel to “Product Name” and “Product Description”, respectively, as earlier. Wait! We would like to furnish our free text search field with an input prompt. We select it in the schema and enter “Please enter a free text search term” as “Input Prompt” in the attributes panel.


Next we enter another search group with title “Additional Criteria” and add several criteria to it which may be interesting. e.g. “TYPE_CODE”, “CATEGORY”, “CURRENCY_CODE”, “PRICE”, “COMPANY_NAME_BO” (with text “Supplier Name”) etc.

Now we start our application again. Looks cool! Don’t miss to try the responsive layout of a grouped search when you change the browser window width! Also don’t miss to save searches and to personalize your search so that a saved search will be automatically executed when you start the app!


You may also try to paste a bunch of value (e.g. product IDs) from excel or word or notepad in the respective search attribute. Or multi-select values from the value help. There is so much comfortable functionality in the Search UIBB – you just need to know it!

Excursus: Do you know the “Saved Search CHIP” (WD CHIP “FPM_SAVED_SEARCHES_LOCAL_CHIP”)? You can add it to your homepage – or just try the test application configuration “FPM_TEST_SAVED_SEARCHES_LOCAL”. You will see all your saved searches in the system (client), also those which you have just created for your test app, and you can start them from the CHIP.


If you only see the technical WD application name, you know why: You and we were too lazy to set a description in the wizard’s first step… 😉

Excursus: New ABAP on SAP Hana techniques are built in the results list (see also here), i.e. with a Hana DB, the data retrieval is processed in “pages” corresponding to the visible data slice in the list. Here we have only few products, but even if you have pretty large data sets, you will hardly notice an impact on performance with a Hana DB.

We now reached the end of part I and continue our beautification journey here.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Jürgen Lukasczyk

    Cool blog & very interesting FPM features you highlight. I like your focus on simplicity and effect. “More bang per buck” is always welcome on customer side.

    Yet your statement “it’s another generic layer between the generic business layer and the generic FPM feeders” is worrying me a bit: We are currently implementing a SAP solution that also relies heavily on generic frameworks (SPI and others), and our users are complaining about the bad UI response times (e.g. application startup > 4s, server round trip > 2s).

    How are your internal experiences? Are tests only done with the simplest BOs?

    1. Jens Boeckenhauer Post author

      Hi Jürgen,

      thanks a lot for your feedback! The impact of the SADL layer on performance is certainly no what we need to worry about: It is a lean delegation layer optimized also for performance-critical access in many details. (And it is strictly monitored in its various consumption scenarios.) And on the contrary, the query push-down to the data base by-passes the underlying BO framework for optimal performance results (as it is used in the search and filter page constructed in this blog).

      The the best of my knowledge, also the SPI framework is not known for bad performance impact. But of course, the usage of generic BO frameworks comes along with some risks. For instance, putting some flags incorrectly in the BOPF configuration may severely impact the consumption performance.

      According to our experience, the typical performance problems are caused by the following.

      • Huge UIs with an very large number of UIBBs.
      • Deeply nested UIBB structures.
      • The BO node structures do not fit to the UI: BO nodes have large attribute structures (several hundreds of components) whereas the UI only displays a few fields out of it.
      • Missing fixes e.g. Note 2097309.

      There are also some features offered by FPM such as OVP lazy-load which can help to speed-up such large start-up times. In case a performance analysis points to delivered frameworks you may also consider to create an OSS ticket: The start-up and response times you mentioned are hardly acceptable.

      Best regards


      1. Jürgen Lukasczyk

        Hi Jens,

        thanks a lot for the swift reply & tips. From your performance driver list, I think our solution (Material Master) is impacted by

        • Huge UI
        • Deeply nested

        and a BO that has bad performance characteristics (cannot be changed easily).

        Luckily, FPM is very adaptable on customer side 😘 w/o modification, so we’ll reduce UI complexity next. I also found that in OVP, stacking the UIBBs has a very positive performance impact.

        The note we already had, but I can confirm that it enhanced the situation noticeably, along with some others. I also had good experiences with OSS tickets, and SAP support is quite good if you provide detailed problem descriptions.

        I am also happy to report that both the FPM and the MDG-M team have been very supportive in improving the performance in the last months (special thanks to Elke Menninger,Jan Poeschel, Christian Guenther) and that UI performance is important to SAP.

        Best regards


        1. Jens Boeckenhauer Post author

          Hi Jürgen,

          just for your information: We have added another correction instruction to Note 2097309 today. It provides another performance improvement which impacts in case of larger field catalogs without usage of aggregation services. As you already noticed an improvement by the first correction instruction, it is likely that the second correction impacts as well if no aggregation fields are declared.

          Best regards



Leave a Reply