Skip to Content

To derive user interfaces directly from business logic relations is a hot, lengthily-discussed topic and an old dream of Software Architects and User Interface Designers over the last decade. Many frameworks were built to reach this goal, but most of them failed due to the complexity of the business logic which needed to be implemented. Until now! With the Floorplan Manager (FPM), this dream became reality: generation and configuration of user interfaces has never been as easy as it is today with FPM.

FPM started from the opposite point. Established as a UI framework based on Web Dynpro ABAP, FPM streamlined the appearances of applications in the classic ERP by providing central components for the assembly of the UI parts. These central components served as the skeleton of the applications and were consequently called ‘floorplans’. What FPM had to offer was spiced up ever more with additional components for common UI patterns such as forms, lists, hierarchies, searches and so on. Business logic was encapsulated in feeder classes and thus the idea was somehow obvious to provide generic feeders to consume business object models. The image below is a screenshot of an FPM application generated purely on OData information retrieved from the World Wide Web (WWW) – without any line of UI coding to be written.


But stop! We should go back three steps …

Where do we come from? What are the stages of UI development? A short subjective historical overview is needed:

As I struggle to decide whether I have just started the second half of my life or have already finished the first half, I came into contact with computers and programming with the legendary TI99 – and I am still missing the GOSUB-statement. Later, with Fortran or the much cooler Pascal, we coded everything into one stream of code. Statements as writeln() and readln() were spread all over the code; UI and business logic were completely mixed up together.

When I started at SAP some time ago, we studied ABAP and wrote reports and GUI screens. The Screen Painter was already a step forward; the first time that I came into contact with a graphical design tool where user interfaces were not coded! But the Screen Painter only provided the UI layout; UI logic and business logic were still mixed inside the coding (LEAVE TO SCREEN 100).

Later, Web Dynpro ABAP came into the game with the MVC (model-view controller) architecture and the separation of components and their configuration. It became possible to define components and allow for code-free configuration on top. Actually, it was the SAP HCM development area who delivered the first pre-configured components. And this is the point where FPM enters the game; and now we can continue with what was said before.


FPM exploited the possibilities of UI components and their configurations to a maximum extent. By means of the UI components, common parts of typical applications were defined and feeder interfaces were introduced as communication interfaces between these UIcomponents and the application logic. Application developers implement the feeder interfaces within the feeder classes in which they define the data structures, the data itself, the actions and the event processing. The entire UI definition is separated from the business logic; the UI is defined entirely in configuration, based on the feeder classes which define what can be configured on the UI (fields defined in data structures convert into form elements or table columns, actions convert into buttons or links). This procedure provides a lot of freedom for UI composition. All good and desirable, but what about a generic approach? What if you knew already about the data definition and their relations? What if you could generically access the data without writing feeder classes? What if you could already propose the structure of the application and a first UI? Unrealistic?  Hmm, let’s see…

Business object models allow the description of objects and their relations in a well-defined way. Some of them – like BOPF – model the business logic directly on the database tables. Others – like BOL – allow the consumption of legacy business logic which has already been encapsulated in APIs. For completeness, one should mention SPI (Service Provider Infrastructure) which provides an external facing on the UI so that it can be used in the Demilitarized Zone and, last but not least, OData, the Open Data protocol which serves as a web standard to expose any data in the WWW for any consumption based on industry standards like REST, XML, HTTP, Atom and JSON.  There are many differences between these object models, but all of them define objects, relations, actions and queries. All of them provide a full and comprehensive encapsulation which serves as a uniform facade for further consumption. So they are generically accessible by a UI framework.

Generic feeders are provided by FPM and by other frameworks to access the data, their relations and their actions. Depending on the relations, the cardinality can be derived and this decides whether a form or a list should be used to display the data (or better still, a form-repeater with a separate details block?). Queries are transformed into a search screen to access the root object. Using the FPM wiring concept, even the dependencies between UIBBs (e.g. adapting content of a details view when changing the selection in a master table) can be pushed to the UI configuration whereas the business logic part of the dependencies (e.g. an association between the nodes) is encapsulated in generic connector classes.

This all works perfectly for BOL (Business Object Layer) and has proven its value in the renovation projects within HCM and FIN development. FPM provides a creation wizard, the ‘Application Creation Tool’ which accesses a certain BOL component and transforms all available nodes into UI Building Blocks (UIBBs) – well, you have a chance to de-select those nodes you do not want to see on your UI and which have no relevance to the application you are going to construct (see image below). These UIBBs are put together into an Overview Page Floorplan (OVP) and are wired according to their relation defined in BOL – and your application can be generated out of the box. You are totally free to adapt this application in FLUID (Flexible UI Designer – the FPM configuration editor). There, you can refine the UI, eliminate unwanted table columns and form elements, add and rearrange fields, columns and buttons or simply change display types if needed, and you can revise the wiring between the UIBBs. So you gain both: an application generated based on the definitions defined in the object modeling layer, and a UI with highly-flexible configurability options. Talk about easy UI creation!


What works for BOL also works for BOPF (Business Object Processing Framework). Since the FPM does not provide generic feeders for BOPF, an intermediate layer has to be used, the so-called BOL-BOPF adapter. This adapter provides a seamless transfer of BOPF model definition to the BOL-based FPM feeders. This allows for a revolutionary end-to-end process. In the Business Object Builder (formerly known as BOPF Enhancement Workbench (see sample image below)) you can define your business logic with all the objects, their relations and their actions. In the next step, you can start the ‘Application Creation Tool’ (mentioned previously) and construct your application with BOL feeders but based on your underlying BOPF scenario.


This approach helps application developers to first invest into the clear analysis of the business process and to separate business logic from the UI entirely. Additionally, with this approach it is possible to start IT projects in complete reverse, compared to how they were started one decade ago. Instead of letting hundreds of UI developers swarm around and build their individual ‘perfect’ islands (which fit together so badly inhomogenously), the first move is with the architects who know and understand the business processes; so they can build and refine the underlying business model. Then, finally, based on this business model, the UI can be created and tailored exactly to the process that customers want to install. These UIs can then be adapted flexibly and enhanced easily by pure UI configuration – but without altering the business model underneath. This will definitely lead to a so-far-unknown and much higher level of business process integrity in modern UIs.


You want more information? See Floorplan
Manager on SCN, e.g. the Administrator’s Guide, the Developer’s Handbook ( ), the Adaptation Guide ( ) and many others. – For BOPF, here is the documentation on the Business Object Builder (BOB).

To report this post you need to login first.


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

  1. Sharath M G

    Hello Dirk Becker,

    Thank you for the article. It has given me a very good insight into the world of FPM.

    As a new entrant to the world of WD ABAP. I am excited about the possibilities of FPM. But, struggle to co-relate the link between using FPM with WD ABAP screens(custom and standard) with standalone WD ABAP developments.

    I will read through other articles. If you have any suitable materials, kindly share them.



  2. Jason Scott

    Dirk, Thankyou for this blog – it is interesting that you can generate fpm apps from BOPF objects; however I can’t see how this is done.

    You state that: “In the next step, you can start the ‘Application Creation Tool’ (mentioned previously) and construct your application with BOL feeders but based on your underlying BOPF scenario.”.

    When I use the ACT tool for BOL it allows you to select *only* BOL components. There is no option to specify any BOPF details.

    I’m looking at an sp6 system so it is the latest release. Are you describing something that is yet to be released? If not – how do you implement this BOL-BOPF adapter.

    I have searched and found some info on FBI (FPM BOPF Integration) but this looks diffferent to what you’re describing and uses different GUIBB feeder classes.

    If SAP wants customers to start using this model-based development technique with fpm a developers guide or tutorial would be good.   😉

    1. Oliver Jaegle

      Dear Jason,

      you are right: FBI (The Floorplan Manager BOPF Integration) is another approach to consume BOPF-models via the FPM.

      FBI is prominently used in the SAP transportation management. It follows the same principle described by Dirk: It provides generic feeders for (most of the) UIBBs directly on top of BOPF.

      In order to consume a BOPF BO via the Business Object Layer (BOL), the BOPF business object needs to “GenIL-enabled’. This can be done in the BOPF configuration UI on the Header of the business object.

      On Save of the BO in BOPF, the corresponding artifacts for BOL/GenIL are getting created. Afterwards, the approach described by Dirk can be followed.

      For BOPF, an SCN space is currently in the process of being formed, as far as I know.

      I hope I could at least clarify a bit of the term questioned.



  3. Abdul Hakim

    Hi Dirk,

    Thanks for sharing this wonderful blog.

    I personally feel SAP is complicating the UI strategy. With the introduction of Netweaver SAP started saying that WDA / FPM is the standard UI and ABAP guys need not worry about HTML or Javascript etc.But right now if i see the trend SAP is again going back to Java school with SAP UI5. I don’t think most of them will give serious thought here in learning Javascript etc because there is so much to learn in WDA/FPM ABAP HANA etc. What is your view on SAP UI strategy ?? Whether WDA / FPM will remain as the key UI technology in SAP or will it just get wiped out by SAP UI5 in the future…


    Abdul Hakim

    1. Dirk Becker Post author

      Hi Abdul,

      regarding the SAP UI Strategy, SAPUI5
      and WDA/FPM build two major pillars which will continue to coexist for many
      years. Both frameworks address very different scenarios. – Using SAPUI5 and
      JavaScript you are much more flexible in creating stateless and client side UI
      which offer a native mobile experience; using FPM/WDA you will continuously
      build your transactional and stateful scenarios.

      Both find its place in the official
      strategy slide deck of TIP Core UI and there is no doubt that FPM/WDA will
      continue to serve customers as a powerful UI framework also in the future.

      Best regards,


      1. Abdul Hakim

        Thanks Dirk for the response.

        I m just curious to understand is there any planned innovation in WDA / FPM to build stateless and client side UI similar to SAPUI5? I was just checking in some of the upcoming SAP Teched sessions and i was very curious to saw Client side rendering in WDA/FPM..Any thoughts??


        Abdul Hakim

        1. Dirk Becker Post author

          Hi Abdul,

          as stated in my previous answer, FPM is the stateful server side framework. however, we allow more and more client side interaction. You might have seen the new List we have introduced with 7.31 which brings a lot of user interaction to the client. We would like to invest into more features like this, but the easiest way to integrate client side controls is the usage of the HTML islands: with these you can bring any control to the frontend, even client side controls or you can reuse (what we will show at TechEd) SAPUI5 controls.

          Best regards,


  4. Martin Ceronio

    Thanks for this perspective.

    The prospect of creating a no-code app that consumes OData as in your first screenshot is of course very tantalizing. Can you do a write-up / tutorial of how you created that particular app?


Leave a Reply