Indu Learning Platform
Course/Unit 2 · ABAP for MDG
Lesson 2-4

MDG user interfaces: Floorplan Manager and Fiori

How MDG screens are assembled from FPM configurations and feeder classes, how newer Fiori apps differ, and where each kind of UI change belongs.

Watch firstUnderstanding of UIBB | FPM | SAP MDG | Class 10 · TechOpen on YouTube ↗

The UI stack

Classic MDG single-object screens are Web Dynpro ABAP apps built with the Floorplan Manager (FPM), even when opened from a Fiori tile. Newer S/4HANA MDG apps are SAPUI5 on CDS and OData. Both sit on the same MDG model, so your rules fire whichever UI is used.

Fiori launchpad tilerole-based entryFPM application or SAPUI5 appWeb Dynpro / FioriFeeder classes or OData servicedata to the UIMDG model and change requestrules, workflowStaging and active areatables
A label is configuration. Behaviour usually means a feeder class, a BAdI or an OData extension.

How an FPM application is built

A tree of configurations: application, floorplan (for MDG usually an Overview Page), UIBBs (forms, lists), and a feeder class behind each UIBB. Find the names on your system with the technical help on a change request screen rather than memorising them.

Web Dynpro applicationApplicationconfigurationparametersfloorplan referenceOverview Page (OVP)sectionstoolbarUIBBsform UIBBlist UIBBcomponentconfigurationFeeder classGET_DEFINITIONGET_DATAPROCESS_EVENTFLUSH
Configuration describes the screen; the feeder class supplies data and behaviour.
Try it · Match

Match each FPM part to its job.

Pick an item on the left, then its match on the right.

Three levels of change

Prefer customizing or configuration enhancements over copying SAP's configurations, so upgrades still deliver SAP's changes. Before writing a feeder, try component customizing and the field properties per CR type and step. sap-config-mode=X in the URL opens the customizing editor (with authorisation).

LevelWhoScopeTransportedConfigurationDeveloperAll clients, all usersYes (workbench)CustomizingConsultant / adminOne client, all usersYes (customizing)PersonalizationEnd userThat user onlyNo
Most MDG field hiding and relabelling belongs in customizing or a configuration enhancement.

The FPM event loop

Every Enter, dropdown change or button click is a round trip. Its order explains most 'my value disappeared' bugs.

Step through · 1 of 6
User eventEnter, button, dropdownFLUSHUI values to feederPROCESS_EVENTreact to the eventMDG modelderivations, checksGET_DATAdata + field usageRenderscreen updated
The user changes a cost center's company code and presses Enter. FPM raises an event.
FLUSH, PROCESS_EVENT, GET_DATA: learn this order and FPM debugging becomes routine.
Try it · What would you do?

A steward types a currency on the cost center screen, presses Enter, and the value vanishes. What do you do?

Reading a feeder class

You rarely write a feeder from scratch. Inherit from the standard feeder named in the component configuration and redefine one method. This outline makes a field read-only after the request step.

ABAP
" OUTLINE: inherit from the standard feeder named in the component configuration
CLASS zcl_my_cctr_form_feeder DEFINITION PUBLIC
  INHERITING FROM <standard_feeder_class>.
  PUBLIC SECTION.
    METHODS if_fpm_guibb_form~get_data REDEFINITION.
ENDCLASS.

CLASS zcl_my_cctr_form_feeder IMPLEMENTATION.
  METHOD if_fpm_guibb_form~get_data.
    super->if_fpm_guibb_form~get_data( ... same parameters ... ).
    " READ TABLE ct_field_usage ASSIGNING FIELD-SYMBOL(<ls_usage>) WITH KEY name = 'KOSTL'.
    " IF sy-subrc = 0 AND <not the request step>.
    "   <ls_usage>-read_only = abap_true. ev_field_usage_changed = abap_true.
    " ENDIF.
  ENDMETHOD.
ENDCLASS.

Call super first and set the 'changed' flag, or FPM ignores your field usage change.

Try it · Fill the blanks

Complete the key words of a feeder enhancement.

CLASS zcl_my_feeder DEFINITION PUBLIC
   <standard_feeder_class>.
  PUBLIC SECTION.
    METHODS if_fpm_guibb_form~get_data .
ENDCLASS.
...
->if_fpm_guibb_form~get_data( ... ).
<ls_usage>-read_only = .

Fiori apps: a different engine

Newer MDG apps are generated from CDS views, an OData or RAP service and annotations. Extend them with CDS extensions, annotations and Adapt UI. Check the Fiori Apps Reference Library for what exists on your release.

FPM / Web DynproClassic single-object maintenanceComponent configurationsFeeder classes in ABAPCustomizing via config editorSAPUI5 / Fiori elementsNewer MDG apps on S/4HANACDS views + OData / RAPAnnotations shape the layoutAdapt UI and CDS extensionsvs
Same MDG rules underneath; different place to make UI changes.

Where does this UI change belong?

Place each request at the cheapest layer that delivers it, without bypassing a rule.

Business requestWhere it belongsRename 'Search Term 1' to'Short Name'Hide fax number for all usersField read-only in approvalstepField mandatory if country isBRShow open PO count on supplierscreenComponent customizingCR type / step field propertiesBRFplus or validation BAdIFeeder class or OData extensionlabelhideper stepit is a rulenew data
A mandatory-field request is a rule, not a UI setting.

Remember

  • Classic MDG screens are FPM applications: application configuration, OVP floorplan, UIBBs, feeder classes.
  • FPM round trip order: FLUSH, PROCESS_EVENT, then GET_DATA with field usage; prefer customizing over copying or code.
  • Rules belong in BRFplus or BAdIs, not in the UI, so API and AI paths enforce them too.

Check yourself

A field should be read-only for one change request type only. Where should you look first?
In the FPM event loop, which method passes the user's typed values from the screen into the feeder?
Which adaptation level is NOT transported?
The business wants tax number mandatory for Brazilian suppliers. Why not just set it mandatory in the UI configuration?