Skip to Content

Create a clear structure of your FPM application

If you want to build applications on top of the FPM framework, you should consider about a clear structure of your application and the data, which will be processed in it. As a first fundamental principle, you should define clear layers in your application:

  • UI-Layer: Visualized by FPM, configured by you.
  • UIBB-Layer: Feeder, Freestyle-UIBBs and some controlling classes developed by you.
  • Application-Layer: Implementing the application behaviour.
  • Backend-Layer: Busines Logic developed by you or provided by somebody else.

When you look at the FPM architecture map , you could see such a structure. In the following image, I show the layers and their elements corresponding to FPM and your application.

Layers in FPM-Applications

As I call the fourth layer “Backend-Layer”, it is only a synonym. You can also call it “Business-Layer” or “Application-Model-Layer”. 

In this blog, I will show you, how to separate a new FPM application into this layers, what are the different tasks of each layer. I will not cover the FPM-Layer and freestyle-UIBBs.


Imagine the following situation: Your customer wants you to build a UI-based application on top of an existing backend system. ( In my examples I will often use the travel-agency demo application of SAP. )

In the first step, you should look at the use cases of your customer and what the UI how the looks like. In most cases, your Customer have an idea about how the UI should looks like.

Than you take your pencil an draw some demo screens on a paper – or if you can better handle it with PowerPoint or something else; on a file -, I will just show simple samples, so that the structure and my approach will be easier to understand.

Here is the example…

A small sample

We have a Identification Region, a Form-Region and a Table in which addionational data will be shown.

Structure your UI-Layout and your FPM-application

Now you got an early vision about your application. Now, try to separate your screen with the help of all known GUIBBs, IDRs and Tabbed-Regions. As I mentioned, try to use GUIBBs as often as you can. The usage of Freestyle UIBB should be strongly avoided. By time, I will handle this topic in a separate blog.

Look at the following picture: Here I have marked all UIBB with a green area. The rest will be done bei FPM. (Naturally, this is a very basic example, and the real life is much more complicated ).


The demo screen separated into FPM-UIBBsAfter this, you have your UI-layer, based on GUIBBs.

Structure your underlying application

OK, after you have identify the several UIBBs, you can define a clear object model, representing the whole UIBB-Layer:

Sample UML Modell

Try to name your classes like the used feeder classes and there concrete job. (And not as I did it here “ListFeeder”, “FormFeeder”, “HeaderIDR” 😉 ).

If you regard to the UML-structure, you will discover some more classes than only the FPM-related objects. That’s right, because I know by our requirements, which data has to be handled and so, I need at least a data-abstraction class, some instance for controlling the application and event handling and at least a subsystem, which encapsulates underlying business and persistence. The think about data-abstraction classes and controlling-instances will be shown in a later blog.

When you structure your application in a similar way, you will meet some (important) architectural principles:

  • Loose Coupling: Every class of your application is so separated, that you can easily enhance and change it.
  • Structural modularity: Due to this splitting of your software, you will get manageable components and not one big “monster”.
  • Separation of concerns: Every part of your application handle only the thing for what it has been built.
  • Open extensibility: You will be open more further requirements and do not have to change the whole application

There are even more architectural principles, which I can enumerate here, but one important should also be named:

  • Fulfillment of standards: Due to the FPM-framework, you will get a standard environment, in which you have to perform your contract with FPM.


In this blog, I do not touch the topic “UI-configuration”. Instead, you have seen, how you can separate and structure your application, to get a stable fundament for your development.

Later, I will show you, what posibilities are behind this approach. Especially, if you think about enhanceability, quality or maintenance.

If you can manage it, you will have the option, to split your team and your tasks in very good packages and gain a lot of speed for implementing new FPM-based UIs.

You must be Logged on to comment or reply to a post.
  • Hi Hendrik,

    Thanks for the nice blog. This is a very interesting topic and I am curious about your solution for making loose coupling classes.
    I think the main problem is data interchange between the objects of the classes.
    We can make for all the classes a semi-singleton class (singleton with a key) for the data interchange, or we can use the wiring models concept. As I mentioned before, I am very curious about your solution.

    Regards, Robin Vleeschhouwer

    • Hi Robin,

      thanks for your comment. I love loose coupling;-) In fact, we realize most of data-transfer with interfaces which are instantiated by “data-classes”. I choose the loose-coupling principle because I like to be open for enhancements and I look for the whole application stack not only the UI-layers.

      The factory-classes are responsible for the creation of those data-classes and as you wrote it, there is a key for identifying and loading them. Dependent of the usage, they are buffered or created every time they are needed.

      The wiring models are not in this scope. The wiring classes allows a very easy data interchange between FPM applications and so, you can integrate such data-classes with wiring classes (especially within EhP3! I love the new editor!). Regarding the whole application stack you can use generic wiring models which transports your specific data.

      I try to post another blog on this topic.