One of the most common problems when dealing with SAP TM UIs is how to determine which is coding that runs behind a certain screen or screen area (here the famous /h from Dynpro is dearly missed).
SAP TM UIs are built using Floorplan Manager (FPM), a WebDynpro (WD) based framework. I am not going to explain here in detail what FPM is, how it works and how can it be adjusted to fit customer needs – there is plenty of information (documentation, cookbooks, guides etc.) posted by FPM development team on their SCN space.
For the purpose of this text it is enough to mention that an FPM-based screen is made up of one or more UI Building Blocks (UIBBs). In SAP TM we use configurable, generic UIBBs, which are as the name says generically programmed WD components, whose behaviour is controlled by (1) a suitable feeder class and (2) a configuration, persisted as WD Component Configuration (WDCC) object.
In SAP TM, we use also a generic feeder engine, called FPM-BOPF Integration (FBI). The generic feeders themselves are controlled by a collection of settings, called FBI Views, saved as well as WDCC objects (this persistence has the advantage that it can be visualised, modified or enhanced using the same techniques as the UIBB configurations).
Let’s see how we can find our way in this jungle of perhaps confusing objects.
Note: The procedure depicted below is valid for NW releases starting with 7.31 (TM 9.0 and later).
First step is to start the screen normally and go to the intended screen area. In my example, I am going to the list of stages in the Freight Order UI. Right click anywhere inside the table, then chosse Technical Help… from the contextual menu:
A dialog appears.
As you can see, if already offers a lot of information:
- the WD application name
- the WD application configuration name – a clikable hyperlink that allows us to jump directly in the corresponding editor
- the application component (relevant for creating support tickets for SAP)
- the starting component – all TM screens use the OVP (Overview Page) floorplan, therefore you’ll always see FPM_OVP_COMPONENT there
- the floorplan configuration – a clikable hyperlink to the corresponding editor (called FLUID)
- if existing, the customer-specific customizing of the floorplan (it can be edited in FLUID as well)
- an indication whether user personalization exists for the floorplan (e.g. rearranged assignment blocks, last visited assignment block). Unlike the other two entries, the hyperlink does not point to an editor, but allows us to navigate to a special WD application, where the personalization of one or more users can be deleted
- on the right side, you see the component name of the “right-cklicked” screen area. In most TM cases, you’ll see there one of the main FPM GUIBBs – the form, the list and the tree, as well as the two composites (composite UIBB and tabbed UIBB) – components that do not have own data, but are used for layouting purposes
- if the component is a GUIBB, then the dialog contains – similar to the floorplan – the name of the UIBB configuration and customizing (as hyperlink to FLUID) and the indication whetehr user-personalization exists.
In this case, the list of stages in a generic UIBB, a list. By clicking on the configuration name, we navigate to the editor.
By clicking on Feeder Parameters we can see both the feeder class name and the parameters that are passed to the feeder:
In this case, we see the generic feeder class from FBI engine, responsible for all List UIBBs, whose behaviour is controlled by a certain FBI View – for the next step I copy its name into clipboard.
To display the settings from the FBI view, create a new editor window:
In the newly appeared window, paste or type the name of FBI View into the field Configuration ID, then click on Continue in Display Mode
The FBI View configuration reveals important settings used to control the behaviour of the feeder:
- the underlying Business Object and Node
- the DDIC structure for the field catalogue
- The conversion class used to convert some data from backend representation (e.g. UUID and Timestamp) into the UI representation (like respectively: readable ID and the combination of date, time and timezone)
- All TM classes inherit from the central class /SCMTMS/CL_UI_CONVERSION and are usually responsible of merely defining the mapping rules (by redefining the method BUILD_MAP_TABLE). The actual conversion is done generically in the superclass.
- The FBI View Exit class, which is used to fine-tune the results of the generic processing of the FBI feeder (you can see it as the FBI counterpart of the BAdI technique).