Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

Introduction

A Generic UI Building Block (GUIBB) is an application independent Web Dynpro component offered by the Floorplan Manager (FPM) that can be configured to meet the requirements of the application.
The GUIBB itself interacts with an ABAP OO feeder class which needs to implement certain FPM feeder interfaces.

The FPM SPI Integration (FSI) offers generic feeder classes which already implement the FPM feeder interfaces and are directly linked to the Service Provider Infrastructure (SPI).
In the image below you can see the most important entities of a GUIBB in the FSI environment and their relations to each other:

GUIBB Entities

Those generic feeder classes reduce the UI development effort of every application drastically, so that an almost 'code-free' UI can be created by just configuring.
There are generic feeder classes for the following GUIBBs:

GUIBB Type

Feeder Class Name

Description

Form

/PLMU/CL_FRW_G_FEEDER_FORM

Form-based component that is used to display/edit the data of one record

List

/PLMU/CL_FRW_G_FEEDER_LIST

Table-based component that is used to display/edit the data of multiple records

Tree

/PLMU/CL_FRW_G_FEEDER_TREE

Hierarchical-table-based component that is used to display/edit the data of multiple hierarchical records

Search

/PLMU/CL_FRW_G_FEEDER_SEARCH

Component that is used to search for records via QUERY based on the entered select options

Relation of GUIBB and Metadata Node

A GUIBB always belongs to one defined node of your application's metadata model but you can have multiple GUIBBs in one UI using the same node.
It is possible (and recommended) to use the same feeder also for multiple GUIBBs/nodes.

Feeder Parameter

Every feeder class offers a set of parameters which are maintained in the GUIBB configuration.
There are two common mandatory parameters which every feeder offers:

  • Application Building Block ID – FRW_ABBID (mandatory):
    Identifies the Application Building Block (ABB) that will be assigned to the GUIBB.
  • Node Name – FRW_NODE_NAME (mandatory):
    Identifies the node that will be assigned to the GUIBB.

Form Feeder Parameter

In addition to the common feeder parameters there are the following form-specific ones:

  • Retrieve by association – FRW_RETRIEVE_BY_ASSOCIATION:
    By default a direct retrieve is triggered for the form (i.e. retrieve via IDs of the own node).
    Via this flag this default can be changed to a retrieve by association (i.e. retrieve via IDs of the parent node).

List Feeder Parameter

In addition to the common feeder parameters there are the following list-specific ones:

  • Number of default rows – FRW_NUMBER_OF_DEFAULT_ROWS:
    Specifies the number of rows that will be available for the user to enter new records.
  • Display default rows in display mode – FRW_DEFAULT_ROWS_IN_DISPLAY_MODE:
    If you want to show the default rows also in display mode.
  • No retrieve by association – FRW_NOT_RETRIEVE_BY_ASSOCIATION:
    By default a retrieve by association is triggered for the list (i.e. retrieve via an ID of the parent node).
    Via this flag, this default can be changed to a direct retrieve (i.e. retrieve via an ID of the own node).
  • Retrieve mode – FRW_RETRIEVE_MODE:
    By default when calling a direct retrieve all newly retrieved records will be appended and a retrieve by association will replace all old records with the new ones.
    With this feeder parameter you can deviate from the default behavior.

Tree Feeder Parameter

In addition to the common feeder parameters there are the following tree-specific ones:

  • Row key component name – FRW_ROW_KEY_COMPONENT_NAME (mandatory):
    The name of the component of the node data structure that contains the key information of the tree element. The value of this field must be unique!
  • Parent key component name – FRW_PARENT_KEY_COMPONENT_NAME (mandatory):
    The name of the component of the node data structure that contains the parent key information.
    This component must be of the same type than the row key component, since the parent key refers to the row key.
    The content of this field must then match the content of the row key component of the parent tree element to create the hierarchy.
  • Is-leaf component name – FRW_IS_LEAF_COMPONENT_NAME (mandatory):
    The name of the component of the node data structure that indicates that the tree element is a leaf and therefore has no children.
  • Master column text component name – FRW_MASTER_COLUMN_TEXT_COMPONENT_NAME:
    This field shall be filled with the name of the component of the node data structure that contains the text of the master column.
    If this parameter is not set the master column won't contain any text.
  • Icon source component name – FRW_IMAGE_SOUCRE_COMPONENT_NAME:
    This field shall be filled with the name of the component of the node data structure that contains the icon source that is used for the master column.
    If this parameter is not used the master column will be displayed without any icons.
  • No retrieve by association – FRW_NOT_RETRIEVE_BY_ASSOCIATION:
    By default a retrieve by association is triggered for the list (i.e. retrieve via an ID of the parent node).
    Via this flag, this default can be changed to a direct retrieve (i.e. retrieve via an ID of the own node).
  • Retrieve mode – FRW_RETRIEVE_MODE:
    By default when calling a direct retrieve all newly retrieved records will be appended and a retrieve by association will replace all old records with the new ones.
    With this feeder parameter you can deviate from the default behavior.

Search Feeder Parameter

In addition to the common feeder parameters there are the following search-specific ones:

  • Query name – FRW_QUERY_NAME (mandatory):
    Identifies the QUERY that will be used to search the data.

Logic of the Generic Feeder Classes

The generic feeder classes contain a generic logic for all basic functions that are needed by every application e.g. to flush (INSERT/UPDATE) the user input to the Service Provider, to RETRIEVE the data depending on the IDs provided by the Wiring or to trigger an ACTION that was bound to a button.

Field Catalogue

The UI-fields that can be chosen within the GUIBB configuration will be provided by the generic feeder class based on the application's metadata. So by setting the feeder parameters 'ABBID' and 'Node Name' the source of the field catalogue will be set. When additional fields are required that are not known by the backend (e.g. link to action fields), the UI field catalogue can also be enriched by enhancing our generic GUIBB feeder.

In addition to that the generic feeder will automatically apply the field properties of your Service Provider (SP) to the respective UI elements.
So any node attribute that is provided by the SP can be controlled from within the SP without additional coding on UI side.
However if you want to control a certain field in the UI layer directly (e.g. because it is a field which is not known by the backend) you can use method SET_FIELD_PROPERTIES of the feeder context.

Actions

Every feeder class offers a set of actions i.e. FPM events. Each of those actions can be assigned e.g. to a button in the toolbar or in a table row.
The generic feeder class offers per default for the SP operations INSERT, UPDATE and DELETE one FPM event.
Also every ACTION that a node offers will be provided as a feeder action.

For the ACTION and also the DELETE the generic feeder contains already a default logic that will call the backend automatically when the according FPM event is processed. For the toolbar actions an additional event parameter can be set in the configuration that defines which node IDs shall be handed over to the SP when calling the respective operation. The options are none, lead-selection, selection or collection (all data records).

The generic feeder will also automatically apply the operation properties of your Service Provider (SP) to the respective button.
So any button that is linked to a SP operation (e.g. an action) can be controlled from within the SP without additional coding on UI side.

If an action (i.e. button) shall be controlled in the UI layer directly, you can implement the feeder interface /PLMU/IF_FRW_G_AFTER_GET_DATA and modify the action usage table to control e.g. the visibility of a toolbar button. The row actions are controlled via interface /PLMU/IF_FRW_G_ACTION_CNTRL which can be obtained via method GET_ACTION_CONTROLLER at feeder attribute MO_UI_TABLE.

Tree Feeder

The FPM already offers standard FPM events for expanding all (FPM_EXPAND_ALL) and collapsing all (FPM_COLLAPSE_ALL) tree elements.
These actions can be added to the toolbar by setting the checkbox 'Default Button Set is Included' in the 'General Settings' Area.
(If you want to create your own buttons for this functionality you should use the same FPM event IDs as stated above)
The generic part of the feeder will automatically handle those actions for you and expand/collapse the tree accordingly.

In addition there are the following tree specific FPM events that are handled by the tree feeder automatically:

  • FRW_TREE_EXPAND_LEVEL:
    Will expand the selected tree elements to the level defined in the configuration.

Data Retrieval

In general the data retrieval takes place in the GET_DATA method of the feeder. There the Wiring is used to obtain the node IDs for reading the data and with those IDs the RETRIEVE is called. The lock flag is set according to the current mode of the UI or even the UIBB (when using the local edit mode of the FPM).

Search Feeder

Instead of reading the data via the RETRIEVE, the search feeder makes use of the QUERY.
Also the data is not read during every GET_DATA but during the PROCESS_EVENT method whenever the event with the ID IF_FPM_GUIBB_SEARCH=>FPM_EXECUTE_SEARCH is processed.

Tree Feeder

The tree feeder reads the root level via RETRIEVE based on the Wiring but all subordinate levels will be read via a defined ACTION on demand.
This means that the retrieve should never return all/multiple tree levels in one call, but only the data that was requested via the given node IDs.

To be able to provide the subordinate hierarchy levels, your Service Provider needs to implement a load-children-action.
Every time a tree element with children that have not been loaded yet is expanded the feeder will call this action.
Since multiple rows can be expanded at the same time and the expansion depth can also be greater than one level, the feeder will firstly evaluate which children are already in the UI and therefore do not need to be loaded from the backend again.
Afterwards all missing children will be loaded by a single action call. So the SP will receive an action call which provides all node IDs of the tree rows that are required to load their children and in addition the required levels of children (expansion depth) that are expected to be returned will be given via the IS_PARAM import parameter.
So it is essential to consider the expansion depth (IS_PARAM) when implementing the SP load-children-action, because otherwise the capabilities of the tree will be very restricted.

Regarding the metadata definition of the load-children-action, for the action name the constant /PLMB/IF_FRW_CONSTANTS=>GC_ACTION_NAME-LOAD_CHILDREN and for the type of the action import parameter IS_PARAM the constant /PLMB/IF_FRW_CONSTANTS=>GC_ACTION_PARAMETER_TYPE-LOAD_CHILDREN_IMPORT shall be used, as shown in the code snipped below:

"Tree Node Definition
ls_node-name       = 'MY_TREE_NODE'.
ls_node-id_struc   = 'MY_TREE_NODE_ID_STRUCTURE'.
ls_node-data_struc = 'MY_TREE_NODE_DATA_STRUCTURE'.
[...]
"Tree Node Action: Load Children
ls_action-name         = /plmb/if_frw_constants=>gc_action_name-load_children.  
ls_action-structure    = /plmb/if_frw_constants=>gc_action_parameter_type-load_children_import.
ls_action-not_save_rel = abap_true.
APPEND ls_action TO ls_node-actions.

Refreshing the Tree Data

The tree feeder refresh logic will make use of the RETRIEVE method to read the data of invalidated elements directly and also of the action method to load children who were invalidated.

There are the following prerequisites to make the refresh logic work correctly:

  • It is mandatory to use a direct retrieve (instead of using a retrieve by association) to load the root level.
  • The tree node needs to be able to provide the data of every tree element via a direct retrieve to allow the feeder to read the data of any record that got invalidated.
  • The SP needs to use the node invalidation in a very fine grained way (node ID level) to increase the performance and avoid a full refresh for every single attribute change of a record that is part of the tree (Massive use of side-effects that invalidate the tree node need to be avoided)

Specialties of the Search UIBB

Using a List UIBB as Result List

When using a List UIBB as a result list the following need to be considered:

  • The Search UIBB will be executing the QUERY and filling the result in its own context.
  • The Wiring needs to be used to pass the whole collection of the Search UIBB context to the List UIBB.
  • It is important to setup the List UIBB's feeder parameters correctly to make the data retrieval work.
    As a result the List UIBB will trigger a new retrieve to the Service Provider every time the search result changes:
    • A direct retrieve needs to be performed (not a retrieve by association)
    • The retrieve mode needs to be set to 'Exact Match', otherwise obsolete entries of an older search run will remain in the result list.

Enhancing the Generic Feeder Classes

The generic feeder classes that we offer can be used directly to run a GUIBB, therefore our recommendation is to use them directly wherever possible.
To deviate from the standard logic of the generic feeder class you can create an own feeder class while using the generic feeder class as a superclass.
Thereby all the logic provided by the generic feeder class is still being executed and can be enhanced at certain points via defined interfaces.
Additionally the protected attributes and methods the generic feeder class provides can be used e.g. to read the context data or the wire of the GUIBB.

The image below gives an impression on how such an enhancement may look like:

Architecture of GUIBB Feeders 

Reuse Feeder Classes

We recommend to use the generic feeder classes of the FSI whenever possible.
If you create application specific feeder classes it is advisable not to create one feeder class for each GUIBB instance but to try to reuse them for multiple GUIBBs wherever it makes sense.

Tutorial Available

A tutorial on how to enhance the generic feeder classes can be found in the tutorials section.

Interfaces for Enhancement

All FPM feeder interface methods that the generic feeder class implements are set to final and therefore can't be redefined by the application specific feeder class.
However there is a set of interfaces that can be implemented by the application specific feeder class to enhance the logic of the generic feeder.
When implemented the interface methods will be called by the generic feeder at certain points in time to allow the application specific feeder to execute its application specific logic.

Here is the complete list of all interfaces that can be implemented optionally by an application specific feeder class:

The methods that are executed within a normal UI round-trip are displayed in the following image:

FPM Event Loop of GUIBBs

/PLMU/IF_FRW_G_ACTIONS – Action Definition and Processing

The generic feeder offers per default actions for the DELETE, INSERT, UPDATE and every ACTION that the node that is assigned to the GUIBB provides.
So every action that you add to your metadata node definition will be also offered by the generic part of the feeder automatically, for assigning it e.g. to a button.
The delete and the actions will also be automatically processed by the generic feeder e.g. when the according button is pressed by the user the SP will get called. For the insert and the update actions no default implementation exists, since the default behavior of the generic feeder is to insert and update data always automatically upon user input.

If in addition to the above described actions further actions which are only processed on UI level are required, the interface /PLMU/IF_FRW_G_ACTIONS needs to be implemented by the application specific feeder.

Guideline on Action Definition and Processing

Actions which only affect the UI and do not need to access the backend should be defined and handled only in the UI layer i.e. should not be added to the Metadata Provider and should not be handled by the Service Provider (e.g. an action which selects the next row in a list should be defined and handled only in the UI, e.g. by the GUIBB feeder).
Furthermore every action which needs to access the backend should be defined in the Metadata Provider and processed by the Service Provider. This increases the reusability (e.g. an action that aggregates certain data or does some calculations should not be implemented in the UI layer).

Interface Method GET_ACTION_DEFINITION

This method allows the definition of actions, (i.e. FPM events) that are then available in the GUIBB configuration and can be assigned e.g. to push buttons or dropdown list boxes.

Method signature:

Parameter

Data Type

Description

CT_ACTION_DEFINITION

FPMGB_T_ACTIONDEF

Table of toolbar actions

CT_ROW_ACTION_DEFINITION

/PLMU/T_FRW_G_ROW_ACTION_DEF

Table of row actions

Additional actions can be defined by inserting into the respective changing parameters, which have among others the following components:

Component

Data Type

Description

ID

FPM_EVENT_ID

Action/Event ID: must be unique within one GUIBB (mandatory)

TEXT

STRING

Description Text (e.g. for push button texts or dropdown list box labels); this text serves as default in the GUIBB configuration and can be modified

TOOLTIP

STRING

Tooltip text

IMAGESRC

STRING

Definition of icons in the format ~Icon/Icon Name

EVENT_PARAM_STRUKNAME

STRUKNAME

Allows supplying of a DDIC structure name whose components can be parameterized in the GUIBB configuration. At runtime the maintained values are contained in the FPM Event data object as CONF_EVENT_PARAMS

DISABLE_WHEN_NO_LEAD_SEL

BOOLE_D

automatically disables the action if no lead selection is set (applies for toolbar actions of List and Tree)

Namespace for Action IDs

An action of the feeder is identified by an ID, which will be used as FPM event ID during the action processing.
Therefore the application should consider using an application specific namespace for all actions to avoid collisions with foreign event IDs.
The application specific action ID must for example never start with 'FPM_' or 'FRW_' since those are used by the FPM/FSI.

Interface Method PROCESS_ACTION_EVENT

This method allows handling of actions/events that are feeder specific (i.e. were defined by the generic part of the feeder based on the node's metadata or by the application specific part of the feeder via method GET_ACTION_DEFINITION).
All other events are not dispatched to this method (e.g. CNR events are dispatched to method PROCESS_GLOBAL_EVENT).

Method signature:

Parameter

Data Type

Description

IO_EVENT

CL_FPM_EVENT

FPM event instance; contains the event ID, event parameters...

IV_INDEX

INT4

Index of Cell based Events

EV_SKIP_DEFAULT

BOOLE_D

Skips the generic feeder's default logic for an action, e.g. the delete (FRW_DELETE) is handled automatically;
such default implementations can be skipped by setting this parameter to ABAP_TRUE to be able to implement an application specific functionality

EV_RESULT

FPM_EVENT_RESULT

FPM result parameter for processed actions, e.g. set to 'FAILED' if the action failed; constants provided at IF_FPM_CONSTANTS=>GC_EVENT_RESULT

ET_MESSAGES

FPMGB_T_MESSAGES

Messages in FPM format

/PLMU/IF_FRW_G_AFTER_CLEANUP – After a Cleanup Call

To process any logic within the application specific feeder after the CLEAN_UP of the Service Provider has been called, the interface /PLMU/IF_FRW_G_AFTER_CLEANUP needs to be implemented by the feeder.

Interface Method AFTER_CLEANUP

In some cases it is required for an application to process some logic after the backend got cleaned up, e.g. if UI specific frontend buffers exist that need to be refreshed. The callback also supplies the reason code of the cleanup (e.g. 'COMMIT'). Constants for the reason code can be found at /PLMU/IF_FRW_CONSTANTS=>GC_REASON_CODE.

Method signature:

Parameter

Data Type

Description

IV_REASON

/PLMB/SPI_CLEAN_UP_REASON

Reason for CLEAN_UP

/PLMU/IF_FRW_G_AFTER_GET_DATA – After Getting the Data from the Backend (Form, List and Tree)

If the application specific feeder needs to execute some logic after the data was fetched from the Service Provider the interface /PLMU/IF_FRW_G_AFTER_GET_DATA needs to be implemented by the feeder.

Interface Method AFTER_GET_DATA

This method will get called at the end of the GET_DATA phase of the feeder, after the data retrieval was performed by the generic part of the feeder.

Method signature:

Parameter

Data Type

Description

IV_FIRST_TIME

BOOLE_D

Is set to ABAP_TRUE if this method is being called for the first time in the lifetime of the feeder

IO_EVENT

CL_FPM_EVENT

FPM Event

IT_SELECTED_FIELDS

FPMGB_T_SELECTED_FIELDS

Selected (Used) Fields

ET_MESSAGE

FPMGB_T_MESSAGES

Messages

EV_FIELD_USAGE_CHANGED

BOOLE_D

Needs to be set to ABAP_TRUE if the field usage table was changed

EV_ACTION_USAGE_CHANGED

BOOLE_D

Needs to be set to ABAP_TRUE if action usage table was changed

CT_FIELD_USAGE

/PLMU/T_FRW_G_FIELD_USAGE

Table of runtime information related to the configured fields of the GUIBB to modify their attributes e.g. label, fixed values

CT_ACTION_USAGE

/PLMU/T_FRW_G_ACTION_USAGE

Table of runtime information related to the configured actions of the GUIBB to modify their attributes e.g. visibility

No Data Invalidation During GET_DATA

If the application calls any backend operation that invalidates a node which belongs to a GUIBB whose data has already been retrieved during this FPM event, a further FPM event is necessary to ensure that the data of this GUIBB is consistent.
To avoid such difficulties, it is strongly recommended to perform all operations that may invalidate any kind of data in the PROCESS_EVENT or FLUSH of the FPM event loop.

/PLMU/IF_FRW_G_AFTER_SAVE – After a Save Call

When any special logic is needed after the save was getting called the interface /PLMU/IF_FRW_G_AFTER_SAVE needs to be implemented by the application specific feeder.

Interface Method AFTER_SAVE

In some cases it is required for an application to have the possibility of processing data after a save call was send to the backend, e.g. the application works with late numbering (the ID of a created object is supplied by the backend only upon the save call) and therefore upon the save a label or header containing the ID might need to be updated.

Method signature:

Parameter

Data Type

Description

IV_REASON

/PLMU/FRW_AFTER_SAVE_REASON

Reason for SAVE

CV_MODE

/PLMB/SPI_MODE

Application Mode

/PLMU/IF_FRW_G_BEFORE_FLUSH – Before the Data is flushed to the Backend (Form, List and Tree)

Whenever the application specific feeder wants to access or modify the UI change log before the data is flushed via INSERT or UPDATE to the Service Provider the interface /PLMU/IF_FRW_G_BEFORE_FLUSH needs to be implemented by the feeder.

Interface Method BEFORE_FLUSH

The generic part of the feeder calls this method before flushing the data changes (performed via UI) of the current round-trip. This allows the application specific feeder to access the data contained in the change log before the generic part of the feeder executes the update and/or insert calls to the backend. By doing so the context change log could be enriched with additional content (thus triggering additional updates/inserts) or lines from the context change log can be removed to suppress automatic updates/inserts, e.g. if the application specific feeder wants to handle this by itself.

Method signature:

Parameter

Data Type

Description

CT_CHANGE_LOG

FPMGB_T_CHANGELOG

Log of data changes done via the UI in this round-trip

Selection Might be Outdated in FLUSH

During the FLUSH the selection that the context contains may be outdated, since the new selection is stored in the context during the process event. Therefore one mustn't rely on the selection during the execution of the FLUSH method!

/PLMU/IF_FRW_G_BEFORE_GET_DATA – Beginning of PBO Phase

If the application specific feeder needs to implement a certain logic at the beginning of the process before output phase (PBO) the interface /PLMU/IF_FRW_G_BEFORE_GET_DATA needs to be implemented by the feeder.

Interface Method BEFORE_GET_DATA

This method will get called at the beginning of the GET_DATA phase of the feeder.
Normally the generic feeder performs a RETRIEVE using the node ID from the Wiring during this phase (an exception is the Search UIBB which reads its data via QUERY in the PROCESS_EVENT). The application specific feeder can also skip the automatic RETRIEVE call and implement an own logic to read the data.

Method signature:

Parameter

Data Type

Description

IO_EVENT

CL_FPM_EVENT

FPM Event

IV_FIRST_TIME

BOOLE_D

Is set to ABAP_TRUE if this method is being called for the first time in the lifetime of the feeder

IV_LOCK

/PLMB/SPI_LOCK_IND

Is set to ABAP_TRUE if the generic part of the feeder locked (or would have locked) the data during a RETRIEVE call (e.g. when the application is in change mode)

EV_SKIP_RETRIEVE

BOOLE_D

When set to ABAP_TRUE the generic part of the feeder won't trigger a RETRIEVE (not relevant for Search UIBB)

No Data Invalidation During GET_DATA

If the application calls any backend operation that invalidates a node which belongs to a GUIBB whose data has already been retrieved during this FPM event, a further FPM event is necessary to ensure that the data of this GUIBB is consistent.
To avoid such difficulties, it is strongly recommended to perform all operations that may invalidate any kind of data in the PROCESS_EVENT or FLUSH of the FPM event loop.

/PLMU/IF_FRW_G_CONFIG_PARAM – Add Feeder Parameters

If application specific feeder parameters are needed which will then be available in the GUIBB configuration the interface /PLMU/IF_FRW_G_CONFIG_PARAM needs to be implemented by the feeder.

Interface Method GET_PARAMETER_DESCRIPTION

Via this method the application specific feeder can add new feeder parameters to the configuration.

Method signature:

Parameter

Data Type

Description

ET_PARAMETER_DESCRIPTION

FPMGB_T_PARAM_DESCR

Table of application specific feeder parameters

Namespace of Parameters

Application specific feeder parameters mustn't use the prefix 'FRW_' as this namespace is used by the FSI.

Interface Method SET_PARAMETER_VALUES

The generic part of the feeder will pass the feeder parameter values that were maintained in the GUIBB configuration to the application specific feeder via this method during the initialization phase of the feeder.

Method signature:

Parameter

Data Type

Description

IT_PARAMETER_VALUE

FPMGB_T_PARAM_VALUE

Table of feeder parameters and their values set via configuration

/PLMU/IF_FRW_G_CONFIRMATION – Create Confirmation Requests (Popups) for FPM Events

If a confirmation for a certain event is required, the interface /PLMU/IF_FRW_G_CONFIRMATION needs to be implemented by the application specific feeder.

Interface Method NEEDS_CONFIRMATION

When the user is supposed to explicitly accept or cancel the processing of a certain event that belongs to the feeder (via confirmation popup) a confirmation request can be created using this method.
The event will then, based on the user's decision be processed or get cancelled.

Method signature:

Parameter

Data Type

Description

IO_EVENT

CL_FPM_EVENT

FPM Event

IV_RAISED_BY_OWN_UI

BOOLE_D

Indicates if the event was raised by the GUIBB itself

EO_CONFIRMATION_REQUEST

CL_FPM_CONFIRMATION_REQUEST

Requests an end-user confirmation (e.g. data loss warning)

/PLMU/IF_FRW_G_CONTEXT_MENU – Dynamic Application Specific Context Menus

When a dynamic application specific context menu e.g. based on the content of the respective row is needed the interface /PLMU/IF_FRW_G_CONTEXT_MENU needs to be implemented by the application specific feeder class.

Interface Method DEFINE_CONTEXT_MENU

Before a context menu on any part of the GUIBB is opened, this method gets called to allow the feeder to define an application specific context menu.

Method signature:

Parameter

Data Type

Description

IV_NAME

NAME_KOMP

Field/Column name (if available)

IV_INDEX

INT4

Row Index (if available)

IO_CONTEXT_MENU

IF_FPM_CTXT_MENU

Context Menu API

Interface Method PROCESS_CONTEXT_MENU_EVENT

When the user clicks on an entry of the context menu that was dynamically defined by the feeder, this method gets called to allow the processing of the triggered event.

Method signature:

Parameter

Data Type

Description

IO_EVENT

CL_FPM_EVENT

FPM Event

IV_NAME

NAME_KOMP

Field/Column name (if available)

IV_INDEX

INT4

Row Index (if available)

EV_SKIP_DEFAULT

BOOLE_D

Skip default logic of the generic feeder for this event?

EV_RESULT

FPM_EVENT_RESULT

Result of this event

ET_MESSAGES

FPMGB_T_MESSAGES

Messages

/PLMU/IF_FRW_G_DEFAULT_ROW – Definition of Default Values for 'Blank' Rows (List only)

When the 'empty' rows of the List UIBB (which are needed for the creation of new data records) should contain certain prefilled fields the interface /PLMU/IF_FRW_G_DEFAULT_ROW needs to be implemented, for example if there is a column which should be filled with consecutive numbering or always contain certain default values.

Interface Method GET_DEFAULT_ROW

Whenever the generic feeder needs to add new 'empty' rows it will call this method.
This method allows the definition of the default content for those rows.

Method signature:

Parameter

Data Type

Description

IV_NEW_ROW_COUNT

INT4

Contains the quantity of 'blank' rows that will be appended to the context

ES_DEFAULT_ROW

ANY

Template that will be used for all new 'blank' rows

ET_DEFAULT_ROW

STANDARD TABLE

Allows to set the prefilled fields of 'blank' rows individually for each row

There are two ways to define the content of new 'empty' rows:

  • By filling the structure ES_DEFAULT_ROW the generic part of the feeder will always use this template row and multiply it if there is more than one 'empty' row required.
  • With table ET_DEFAULT_ROW the application can set the content of each new 'empty' row individually.
    This table then needs to contain the number of rows specified via parameter IV_NEW_ROW_COUNT.

/PLMU/IF_FRW_G_DRAG_AND_DROP – Drag & Drop (Form, List and Tree)

When an application specific drag & drop logic is desired the feeder can implement interface /PLMU/IF_FRW_G_DRAG_AND_DROP.

Interface Method DEFINE_DRAG_AND_DROP

Via this method the initial definition of the drag & drop capabilities of the feeder are done.

Method signature:

Parameter

Data Type

Description

ET_DND_DEFINITION

FPMGB_T_DND_DEFINITION

Drag and Drop Attributes Definition

Interface Method PROCESS_DRAG_AND_DROP_EVENT

This method processes the drag & drop event.

Method signature:

Parameter

Data Type

Description

IT_DRAG_DATA

INDEX TABLE

Drag Data

IV_DROP_POSITION

INT4

Drop Position

IV_DROP_OFFSET

INT4

Drop Offset

IV_TAGS

FPMGB_DND_TAGS

Drag & Drop Tags

IO_EVENT

CL_FPM_EVENT

FPM Event

EV_RESULT

FPM_EVENT_RESULT

FPM Event Result

ET_MESSAGES

FPMGB_T_MESSAGES

Messages

Interface Method REDEFINE_DRAG_AND_DROP

This method allows redefining the drag & drop capabilities at runtime.

Method signature:

Parameter

Data Type

Description

IO_EVENT

CL_FPM_EVENT

FPM Event

EV_DND_DEFINITION_CHANGED

BOOLE_D

Has the Drag & Drop Definition been changed?

CT_DND_DEFINITION

FPMGB_T_DND_DEFINITION

Drag and Drop Attributes Definition

/PLMU/IF_FRW_G_FAILED_EVENT – Reacting on Failed FPM Events

When the application specific feeder wants to react on the failure of an FPM event it can implement the interface /PLMU/IF_FRW_G_FAILED_EVENT.

Interface Method AFTER_FAILED_EVENT

The purpose of this method is to revoke changes that were made during the processing of this event.

Method signature:

Parameter

Data Type

Description

IO_EVENT

CL_FPM_EVENT

FPM Event

IV_RAISED_BY_OWN_UI

BOOLE_D

Was this event raised by the UI that belongs to this feeder?

EV_SKIP_DEFAULT

BOOLE_D

Skip the generic feeder's default logic for the failure of this event?

/PLMU/IF_FRW_G_FIELD_DEF – Changing the Field Catalogue and the Field Definition (Form, List and Tree)

If the application specific feeder wants to change or enhance the field catalogue and definition that is created by the generic part of the feeder based on the application's metadata, the interface /PLMU/IF_FRW_G_FIELD_DEF needs to be implemented by the application specific feeder.

Interface Method CHANGE_FIELD_DEFINITION

This method allows you to manipulate the field catalogue and the definition attributes that come along with each field.

Method signature:

Parameter

Data Type

Description

CO_CATALOGUE

CL_ABAP_STRUCTDESCR

Field Catalogue (Basis for the available fields on the UI)

CT_DEFINITION

/PLMU/T_FRW_G_FIELD_DESCR_APPL

Detailed description of the field catalogue components

The default field catalogue (CO_CATALOGUE) is created based on the node data defined in the Metadata Provider of the application.
If you need additional fields that are not known by your backend but should be displayed in the UI (UI-only-fields) you need to enhance the field catalogue as it is done in the following code snippet:

co_field_catalogue ?= cl_abap_structdescr=>describe_by_name( 'MY_UI_STRUCTURE_DDIC_TYPE' ).

Include SP DDIC Structure in UI DDIC Structure

Your UI DDIC structure should always include the according node data DDIC structure that is defined in the Metadata Provider.

Per default the generic feeder will also automatically fill the field definition table (CT_DEFINITION) that contains additional information to the field catalogue components.
Also when you enhance the field catalogue the field definition will be automatically enhanced by the generic part of the feeder, so you don't need to touch the definition table even if you enhance the field catalog.

In case you want to deviate from the default field definition provided by the generic feeder you can adjust all attributes shown in the following table:

Component

Data Type

Description

Applicable for GUIBB Type

NAME

NAME_KOMP

Name of the field catalogue component

form, list, tree

DDIC_SHLP_NAME

CHAR30

DDIC search help name (e.g. to overwrite the search help assigned to the DDIC structure or data element)

form, list, tree

OVS_NAME

SEOCLSNAME

OVS search help handler class name (when using the feeder class name itself, the feeder has to implement interface /PLMU/IF_FRW_G_OVS as well)

form, list, tree

WD_VALUE_HELP

FPM_COMPONENT_NAME

Name of the freestyle Web Dynpro search help (needs to implement interface IWD_VALUE_HELP)

form, list, tree

FIXED_VALUES

WDR_CONTEXT_ATTR_VALUE_LIST

Definition of a fixed value set for input fields, which can be used e.g. to fill dropdown list boxes or to function as search help for an input field

form, list, tree

LABEL_TEXT

STRING

Text of the field/header label. When no value is entered, the label will be filled by DDIC

form, list, tree

LABEL_TEXT_REF

NAME_KOMP

To set the label for a field dynamically you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the label text at runtime.
The name of this field needs to be given using 'LABEL_TEXT_REF'.

form

TOOLTIP

STRING

Tooltip of the field/column

form, list, tree

TOOLTIP_REF

NAME_KOMP

To set the tooltip for each cell individually you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the tooltip at runtime.
The name of this field needs to be given using 'TOOLTIP_REF'.

form, list, tree

HELP_TEXT

STRING

Help text for the field/column

form, list, tree

HELP_TEXT_REF

NAME_KOMP

To set the help text for each cell individually you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the help text at runtime.
The name of this field needs to be given using 'HELP_TEXT_REF'.

form, list, tree

LINK

STRING

Link

form, list, tree

LINK_REF

NAME_KOMP

To set the link for each cell individually you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the link at runtime.
The name of this field needs to be given using 'LINK_REF'.

form, list, tree

IMAGE_REF

NAME_KOMP

To set the image for each cell individually you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the image at runtime.
The name of this field needs to be given using 'IMAGE_REF'

form, list, tree

WIDTH

STRING

Width of the field/column

form, list, tree

DATE_FORMAT

CHAR1

Date format

form, list, tree

SHORT_TIME

CHAR1

When set to ABAP_TRUE, the short time format will be used for display

form, list, tree

NULL_AS_BLANK

WDY_ATTRFORM_NULL

When set to ABAP_TRUE, zeros will be displayed as blanks

form, list, tree

SIGN_POS

WDY_ATTRFORM_SIGN

Sets the position of the sign for numeric fields

form, list, tree

CONDENSE

WDY_ATTRFORM_CONDENSE

When set to ABAP_TRUE, the value of the field will be condensed

form, list, tree

TECHNICAL_FIELD

BOOLE_D

If the field has a technical character i.e. it should never be visible in the UI, it can be marked as a technical field and thereby be hidden in the configuration

form, list, tree

CQ

CHAR1

Sets the type of CQ_REF field ('C' for currency or 'Q' for quantity)

form, list, tree

CQ_REF

NAME_KOMP

To set the currency or quantity for each cell individually you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the currency or quantity at runtime.
The name of this field needs to be given using 'CQ_REF'. This field is supposed to be used in combination with field 'CQ'.

form, list, tree

PROGRESS_INDICATOR_DISPLAY_REF

NAME_KOMP

To display a text on the progress indicator you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the text at runtime.
The name of this field needs to be given using 'PROGRESS_INDICATOR_DISPLAY_REF'.

form, list, tree

SP_GROUP

CHAR4

Allows to assign a group name to the field

form, list, tree

TAG_NAME

STRING

Tag name of the field

form, list, tree

TEXT

STRING

Text of a column

list, tree

TEXT_REF

NAME_KOMP

To set the text for each cell individually you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the text at runtime.
The name of this field needs to be given using 'TEXT_REF'.

list, tree

CELL_DESIGN_REF

NAME_KOMP

To set the cell design (e.g. color) for each cell individually you need to use a reference field.
This means that you need to have an additional field (of type WDUI_TABLE_CELL_DESIGN) within your field catalogue that will contain the cell design at runtime.
The name of this field needs to be given using 'CELL_DESIGN_REF'.

list, tree

ALLOW_SORT

BOOLE_D

When set to ABAP_TRUE (Default value: ABAP_TRUE), the table can be sorted by the content of this column

list, tree

ALLOW_FILTER

BOOLE_D

When set to ABAP_TRUE (Default value: ABAP_TRUE), the table can be filtered by the content of this column

list

ALLOW_AGGREGATION

BOOLE_D

When set to ABAP_TRUE (Default value: ABAP_TRUE), the table can be aggregated by the content of this column

list

GROUP_SAME_CELLS

BOOLE_D

When set to ABAP_TRUE, same cells will be grouped

list

MIME_TYPE_REF

STRING

To set the mime type for each cell individually you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the mime type at runtime.
The name of this field needs to be given using 'MIME_TYPE_REF'.

form

FILE_NAME_REF

STRING

To set a file name for each cell individually you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the file name at runtime.
The name of this field needs to be given using 'FILE_NAME_REF'.

form

SORT_REF

NAME_KOMP

To define an alternative field that will be considered when sorting this column you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the respective value relevant for sorting at runtime.
The name of this field needs to be given using 'SORT_REF'

list

FILTER_REF

NAME_KOMP

To define an alternative field that will be considered when applying a filter on this column you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the respective value relevant for filtering at runtime.
The name of this field needs to be given using 'FILTER_REF'.

list

GROUPING_REF

NAME_KOMP

To define an alternative field that will be considered when grouping the cells of this column you need to use a reference field.
This means that you need to have an additional field within your field catalogue that will contain the respective value relevant for grouping at runtime.
The name of this field needs to be given using 'GROUPING_REF'.

list

ENUMERATION

WDR_CONTEXT_ATTR_VALUE_LIST

All Fixed Values of an Attribute with Texts

list

ORDER_AS_TEXT

FPMGB_ORDER_AS_TEXT

Sorting: values to be interpreted as standard text

list

ORDER_OF_CRITERION

FPMGB_ORDER_CRITERION

Specifies which values to sort by

list

/PLMU/IF_FRW_G_FIELD_DEF_SEA – Changing/Enhancing the Field Catalogue and the Field Definition of the Search UIBB

If the application specific feeder wants to change or enhance the criteria or result fields of a Search UIBB the interface /PLMU/IF_FRW_G_FIELD_DEF_SEA needs to be implemented by the application specific feeder.

Interface Method CHANGE_FIELD_DEFINITION

This method allows you to manipulate the field catalogue and the definition attributes that come along with each field.
In addition it offers some attributes that are needed in rather special use-cases where for example the labels of some UI elements of the List UIBB need to be adjusted.

Method signature:

Parameter

Data Type

Description

CO_CRITERIA_CATALOGUE

CL_ABAP_STRUCTDESCR

Field catalogue of the search criteria

CO_RESULT_CATALOGUE

CL_ABAP_STRUCTDESCR

Field catalogue of the search result

CT_CRITERIA_DEFINITION

/PLMU/T_FRW_G_SEA_CRIT_DESCR

Search criteria field description

CT_RESULT_DEFINITION

/PLMU/T_FRW_G_SEA_RESULT_DESCR

Search result field description

CS_ENHANCED_DEFINITION

/PLMU/S_FRW_G_SEA_DEF_ENH

Enhanced search definition

The default field catalogues are created based on the query definition in the Metadata Provider of the application.
If you need additional fields that are not known by your backend but should be displayed in the UI (UI-only-fields) you need to enhance the field catalogue as it is done in the following code snippet:

co_criteria_catalogue ?= cl_abap_structdescr=>describe_by_name( 'MY_UI_CRIT_STRUCT_DDIC_TYPE' ).
co_result_catalogue ?= cl_abap_structdescr=>describe_by_name( 'MY_UI_RESULT_STRUCT_DDIC_TYPE' ).

Include SP DDIC Structure in UI DDIC Structure

Your UI DDIC structure should always include the according criteria/result DDIC structure that is defined in the Metadata Provider.

Per default the generic feeder will also automatically fill the field definition tables (CT_CRITERIA_DEFINITION/CT_RESULT_DEFINITION) that contains additional information to the field catalogue components.
Also when you enhance the field catalogue the field definition will be automatically enhanced by the generic part of the feeder, so you don't need to touch the definition table even if you enhance the field catalog.

In case you want to deviate from the default criteria field definition provided by the generic feeder you can adjust all attributes shown in the following table:

Component

Data Type

Description

NAME

NAME_KOMP

Name of the criteria field catalogue component

DDIC_SHLP_NAME

CHAR30

DDIC search help name

OVS_NAME

SEOCLSNAME

OVS search help handler class name (when using the feeder class name itself, the feeder has to implement interface /PLMU/IF_FRW_G_OVS as well)

TEXT

STRING

Text of the search criterion

DATE_FORMAT

CHAR1

Date format

SHORT_TIME

CHAR1

When set to ABAP_TRUE, the short time format will be used for display

NULL_AS_BLANK

WDY_ATTRFORM_NULL

When set to ABAP_TRUE, zeros will be displayed as blanks

SIGN_POS

WDY_ATTRFORM_SIGN

Sets the position of the sign for numeric fields

CONDENSE

WDY_ATTRFORM_CONDENSE

When set to ABAP_TRUE, the value of the field will be condensed

SUPPORTED_OPERATORS

FPMGB_T_SEARCH_OPERATOR

List of supported search operators

EXCLUDE_SIGN_SUPPORTED

BOOLE_D

Indicates that the exclude sign is supported

MULTI_VALUE_STRUCT

CL_ABAP_STRUCTDESCR

Structure that is used for maintenance of multiple values assigned to one search criterion

MULTI_VALUE_LOW_REF

NAME_KOMP

Component in the structure defined in MULTI_VALUE_STRUCT that refers to the LOW field of the select options

MULTI_VALUE_HIGH_REF

NAME_KOMP

Component in the structure defined in MULTI_VALUE_STRUCT that refers to the HIGH field of the select options

MAX_1_VALUE

BOOLE_D

Indicates that only one value is allowed for this search criterion

ENUMERATION

FPMGB_T_NAMEVALUE

Allows to define a list of name-value pairs for the search criterion

IS_OF_TYPE

FPMGB_SEARCH_ATTR_TYPE

Search criterion data type

FREE_TEXT_SEARCH

BOOLE_D

Is a free text search?

WD_VALUE_HELP

FPM_COMPONENT_NAME

Name of the freestyle Web Dynpro search help (needs to implement interface IWD_VALUE_HELP)

DEFAULT_OP

FPMGB_SEARCH_OPERATOR

Default Search Operator

DEACTIVATE_VALUE_HELP

BOOLE_D

Deactivate the value help?

VALUE_SUGGEST

BOOLE_D

Enable the value suggest

MANDATORY

BOOLE_D

Is a mandatory field?

SUPPRESS_PATTERN_SEARCH

WDY_BOOLEAN

Suppress pattern search

The result field definition contains the following fields:

Component

Data Type

Description

NAME

NAME_KOMP

Name of the result field catalogue component

TEXT

STRING

Text of the result column

TAG_NAME

WDY_TAG_NAME

Tag name of the result column

/PLMU/IF_FRW_G_GLOBAL_EVENTS – Processing of Global FPM Events

To allow the application specific feeder to process global FPM events like 'FPM_LEAVE_INITIAL_SCREEN' or 'FPM_EDIT' the interface /PLMU/IF_FRW_G_GLOBAL_EVENTS needs to be implemented by the feeder class.

Interface Method PROCESS_GLOBAL_EVENT

Every event that is not feeder specific (as described in the 'Action Definition and Processing' section) will be processed by this method.

Method signature:

Parameter

Data Type

Description

IO_EVENT

CL_FPM_EVENT

FPM event instance; contains the event ID, event parameters...

IV_RAISED_BY_OWN_UI

BOOLE_D

Was this event raised by the UIBB that belongs to this feeder?

EV_SKIP_STANDARD

BOOLE_D

Skips the generic feeder's default logic for an event to be replaced by an own functionality

EV_RESULT

FPM_EVENT_RESULT

FPM result parameter for processed actions, e.g. set to 'FAILED' if the action failed; constants provided by FPM constant structure IF_FPM_CONSTANTS=>GC_EVENT_RESULT

ET_MESSAGES

FPMGB_T_MESSAGES

Messages in FPM format

/PLMU/IF_FRW_G_LAYOUT_CONFIG – Setting/Checking the Layout Configuration via Coding

If the layout of the configuration should be set or checked, the interface /PLMU/IF_FRW_G_LAYOUT_CONFIG needs to be implemented by the application specific feeder.

Interface Method GET_DEFAULT_CONFIG

This method allows setting the default configuration to ease the creation of new configurations.

Another use-case of this method is to set the layout of the GUIBB dynamically at runtime upon instantiation of the GUIBB.
This is possible when an empty configuration is used, because then the layout will match the default configuration settings done via method GET_DEFAULT_CONFIG.

Method signature:

Parameter

Data Type

Description

IO_LAYOUT_CONFIG

OBJECT

GUIBB configuration interface

Depending on the GUIBB type there will be different configuration interfaces passed via parameter IO_LAYOUT_CONFIG:

  • Form: IF_FPM_GUIBB_FORM_CONFIG or IF_FPM_GUIBB_FORM_CFG_GL2 (depending on the Form UIBB component)
  • List: IF_FPM_GUIBB_LIST_CONFIG
  • Tree: IF_FPM_GUIBB_TREE_CONFIG
  • Search: IF_FPM_GUIBB_SEARCH_CONFIG

Interface Method CHECK_CONFIG

This method offers the possibility to check the configuration for errors and raise messages accordingly.

Method signature:

Parameter

Data Type

Description

IO_LAYOUT_CONFIG

OBJECT

GUIBB configuration interface

ET_MESSAGE

FPMGB_T_MESSAGES

Messages

Again the type of parameter IO_LAYOUT_CONFIG depends on the GUIBB type as described above.

/PLMU/IF_FRW_G_OVS – Use the Object Value Selection (OVS)

The Object Value Selection (OVS) is a reuse Web Dynpro component that functions as an F4 help for UI fields.

To use it the application specific feeder has to implement the following two interfaces:

The interface /PLMU/IF_FRW_G_OVS contains four methods representing the four phases of the OVS, which all offer the following parameters:

Parameter

Data Type

Description

IV_FIELD_NAME

NAME_KOMP

Field name the OVS belongs to

IO_OVS_CALLBACK

/PLMU/IF_FRW_G_OVS_CALLBACK

OVS access interface

In these methods an instance of the interface /PLMU/IF_FRW_G_OVS_CALLBACK is passed, which provides a set of attributes and methods that can be used to configure the OVS screen, to read and write the data of the selection, the result and the data structure for which the input help was requested:

The (read-only) attributes of the interface are:

Attribute

Data Type

Description

PHASE_INDICATOR

INT4

Phase Indicator (suitable constants can be found at the same interface)

CONTEXT_ATTRIBUTE

STRING

Context attribute name for which the input help was requested

COMPONENT_USAGE_NAME

STRING

Component usage name

IS_READ_ONLY

BOOLE_D

Indicates that the F4 field can't be edited

Additionally it offers the following methods:

Method

Description

GET_QUERY_PARAMETERS

Get the selection parameters

GET_ROW_DATA

Get the data structure for which the input help was requested

GET_SELECTION

Get the selected values

SET_CONFIGURATION

Set e.g. the column headings and label texts

SET_INPUT_STRUCTURE

Set the input fields of the selection screen

SET_MESSAGES

Set messages for the OVS component

SET_OUTPUT_TABLE

Set the result list

SET_QUERY_PARAMETERS

Set the selection parameters

SET_ROW_DATA

Set the data structure for which the input help was requested

SET_SELECTION

Set the selected values

Interface Method HANDLE_PHASE_0 – Set Configuration

At this time, the OVS component can be configured.
For example, the window title, the heading, or the column heading of the output table can be defined. In addition, you can set whether one or several rows of the result table should be selected (In the standard configuration of the OVS component, only one row of the results table can be selected). For this purpose parameter IO_OVS_CALLBACK provides the method SET_CONFIGURATION.

Interface Method HANDLE_PHASE_1 – Set Input Structure

If the optional selection view of the OVS component is to be used, the structure of the selection fields to be displayed must be defined in this phase and passed to the OVS component. At the same time, initial values can be passed for the selection fields. Method SET_INPUT_STRUCTURE of parameter IO_OVS_CALLBACK serves that purpose. If the method is not called at all, the display of the selection view is not used and the result view is displayed immediately.

Interface Method HANDLE_PHASE_2 – Fill Value List

It is mandatory in this phase to pass the table with the values available for selection to the OVS component.
This is done via method SET_OUTPUT_TABLE of parameter IO_OVS_CALLBACK.
If values were entered on a selection, these can now be read via method GET_QUERY_PARAMETERS of parameter IO_OVS_CALLBACK.

Interface Method HANDLE_PHASE_3 – Value Return

The result of the search was displayed in the results view of the OVS component and the user has selected one or several rows from the table.
The content of the user's selection can now be obtained via method GET_SELECTION of parameter IO_OVS_CALLBACK.
So finally the result needs to be stored back into the fields that refer to the search help. For that purpose method SET_ROW_DATA of parameter IO_OVS_CALLBACK should be used. The current data of the row can be read via method GET_ROW_DATA of parameter IO_OVS_CALLBACK. This method also offers the event EO_FPM_EVENT  which shall be fired after OVS Closes ( e.g.to trigger a roundtrip if needed )

/PLMU/IF_FRW_G_SEARCH_PERSIST – Own Search Persistence (Search only)

If the search persistence i.e. the storage and administration of the saved searches shall not be handled by the FPM but by the application specific feeder, the interface /PLMU/IF_FRW_G_SEARCH_PERSIST needs to be implemented.

Interface Method GET_OWN_PERSISTENCE_UTIL

To handle the saved searches completely an instance of a class that implements the interface IF_FPM_SEARCH_PERSISTENCE needs to be provided by the feeder via this method.
It therefore only offers the following parameters:

Parameter

Data Type

Description

EO_PERSISTENCE_UTIL

IF_FPM_SEARCH_PERSISTENCE

Provides functionality for saving/loading searches

/PLMU/IF_FRW_G_STATIC_PARAM – Setting Feeder Parameter Values via Coding (removes them from configuration)

When an application specific feeder class wants to set some feeder parameters via coding (e.g. the node name shall be set statically within the feeder) the interface /PLMU/IF_FRW_G_STATIC_PARAM can be implemented by the feeder.

Interface Method DEFINE_STATIC_PARAMETER

This method allows defining certain feeder parameters as static to set their values later on via coding and thereby removing them from the GUIBB configuration.

Method signature:

Parameter

Data Type

Description

IT_PARAMETER

FPMGB_T_PARAM_DESCR

Table of all defined feeder parameters

ET_STATIC_PARAMETER

FPMGB_T_PARAM_DESCR

Definition of static feeder parameters (invisible in GUIBB configuration)

Interface Method GET_PARAMETER_VALUES

This method allows the application specific feeder to provide the values of its static feeder parameters.

Method signature:

Parameter

Data Type

Description

IT_CONFIG_PARAMETER

FPMGB_T_PARAM_VALUE

Values of feeder parameters set via configuration

CT_STATIC_PARAMETER

FPMGB_T_PARAM_VALUE

Values of static feeder parameters

Reusable Feeder Methods

All FPM feeder interface methods that the generic feeder class implements are set to final and therefore can't be redefined by the application specific feeder, as well as they are not to be called by it. However every generic feeder class contains a set of protected methods, which can be used within an application specific feeder class.
Those reusable methods are:

GET_WIRE_MODEL

This method provides an instance of the wire model that belongs to the GUIBB to access the wire that is bound to it.

Method signature:

Parameter

Data Type

Description

RO_WIRE_MODEL

RO_WIRE_MODEL

Wire model interface

GET_UIBB_INSTANCE_KEY

This method provides the UIBB instance key that belongs to the feeder.

Method signature:

Parameter

Data Type

Description

RS_UIBB_INSTANCE_KEY

FPM_S_UIBB_INSTANCE_KEY

UIBB instance key

GET_FPM

This method provides an Instance of the FPM Access Interface.

Method signature:

Parameter

Data Type

Description

RO_FPM

IF_FPM

Provides an instance of the FPM

Reusable Feeder Attributes

Every generic feeder class contains a set of protected attributes, which can be used within an application specific feeder class.
Those attributes are:

Attribute Name

Description

Applicable for

MO_APPLICATION_MODEL

Single point of access the application backend

all

MO_CONTEXT

Read/manipulate e.g. the data, selection or field properties

all

MO_UI_TABLE

Access the UI table control (e.g. to scroll or to set its title)

list, tree

MO_SELECT_OPTIONS

Read/Add select options

search

MO_HIERARCHY

Get info about the tree hierarchy

tree

Feeder Attribute MO_APPLICATION_MODEL

Every generic feeder contains an attribute called MO_APPLICATION_MODEL of type /PLMU/IF_FRW_G_APPL_MODEL which refers to an instance of the Application Model. The Application Model should be the only way for the feeder class to access the backend. It belongs to the same Application Building Block ID (ABBID) than the GUIBB itself (which is defined via feeder parameter).

More details about the capabilities of this object can be found in a separate chapter.

The generic feeder itself also uses this Application Model instance e.g. during the FLUSH to INSERT and UPDATE based on the user input, during the PROCESS_EVENT when handling the DELETE or an ACTION (or even a QUERY in case of the Search GUIBB) or during the GET_DATA, when calling the RETRIEVE to refresh the data in the UI.

Feeder Attribute MO_CONTEXT

Another attribute that every generic feeder contains is MO_CONTEXT of type /PLMU/IF_FRW_G_CONTEXT which contains the data of the UI and can be accessed e.g. for reading or manipulating the UI data, the field properties or the selection.
In addition the context offers method GET_INFO which returns interface /PLMU/IF_FRW_CONTEXT_INFO that allows getting some metadata about the context e.g. the node name or whether multi-selection is allowed.

The data type of the context's data structure matches per default the data type of the node that is associated with the GUIBB.
It is possible to enhance the context's data structure by implementing the interface /PLMU/IF_FRW_G_FIELD_DEF (for form, list or tree) or /PLMU/IF_FRW_G_FIELD_DEF_SEA (for search) in an application specific feeder.

The Application Model of the feeder class automatically administers the context and modifies its content according to the result of any triggered operation which is performed on the node that is assigned to the GUIBB.
This means that per default during the GET_DATA the result of the RETRIEVE is filled into the context automatically and afterwards the whole content of the context will be returned to the FPM and therefore get displayed in the UI.

The context offers the following methods:

ADD_ROW

This method adds a row to the context.
If no index is supplied or when passing /PLMU/IF_FRW_G_CONTEXT=>GC_USE_LEAD_SELECTION via parameter IV_INDEX the index of the lead-selection will be used.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Index of the new row

IS_ROW

ANY

Content of the new row (mandatory)

CLEAR

This method clears the context.

CLEAR_SELECTION

This method clears the whole selection.

GET_ATTRIBUTE

This method provides the value of one field in a certain row.
If no index is supplied or when passing /PLMU/IF_FRW_G_CONTEXT=>GC_USE_LEAD_SELECTION via parameter IV_INDEX the index of the lead-selection will be used.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index

IV_NAME

FIELDNAME

Attribute name

EV_VALUE

ANY

Attribute value

GET_FIELD_PROPERTIES

This method provides the field properties of a certain row.
If no index is supplied or when passing /PLMU/IF_FRW_G_CONTEXT=>GC_USE_LEAD_SELECTION via parameter IV_INDEX the index of the lead-selection will be used.
When only the properties of certain fields are required, the result can be filtered by using parameter IT_FIELDS.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index

IT_FIELDS

/PLMU/T_FRW_G_FIELDNAME

Table of requested fields

ET_PROPERTIES

/PLMB/T_SPI_PROPERTIES

Table of field properties

GET_INFO

This method provides an info-object that provides metadata about the context.

Method signature:

Parameter

Data Type

Description

RO_CONTEXT_INFO

/PLMU/IF_FRW_CONTEXT_INFO

Context info interface

GET_LEAD_SELECTION_INDEX

This method provides the index of the lead selection.

Method signature:

Parameter

Data Type

Description

EV_INDEX

INT4

Index of lead selection

GET_NUMBER_OF_ROWS

This method counts the rows in the context.

Method signature:

Parameter

Data Type

Description

EV_NUMBER_OF_ROWS

INT4

Number of rows in the context

GET_ROW

This method provides the content of one row.
If no index is supplied or when passing /PLMU/IF_FRW_G_CONTEXT=>GC_USE_LEAD_SELECTION via parameter IV_INDEX the index of the lead-selection will be used.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index

ES_ROW

ANY

Content of the row

GET_ROWS

This method provides the content of multiple rows.
If no row indexes are provided, all rows of the context will be returned.

Method signature:

Parameter

Data Type

Description

IT_INDEX

INT4_TABLE

Table of row indexes

ET_ROW

ANY TABLE

Content of the requested rows

GET_SELECTION

This method provides the content of the selected rows.

Method signature:

Parameter

Data Type

Description

ET_SELECTION

ANY TABLE

Content of the selected rows

GET_SELECTION_INDEX

This method provides the index of the selected rows.

Method signature:

Parameter

Data Type

Description

ET_INDEX

INT4_TABLE

Indexes of the selected rows

IS_ALIVE

This method checks if the context is alive i.e. can be used.

Method signature:

Parameter

Data Type

Description

RV_IS_ALIVE

BOOLE_D

Indicates that context is alive

IS_ROW_SELECTED

This method checks if the row with the given index is selected.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index (mandatory)

RV_IS_SELECTED

BOOLE_D

Indicates that the row is selected

MOVE_ROW

This method moves a row from a certain position to another one.
If for one of the index parameters /PLMU/IF_FRW_G_CONTEXT=>GC_USE_LEAD_SELECTION is set, the index of the lead-selection will be used.

Method signature:

Parameter

Data Type

Description

IV_FROM_INDEX

INT4

Source row index (mandatory)

IV_TO_INDEX

INT4

Target row index (mandatory)

REMOVE_ROWS

This method removes the rows with the given indexes from the context.

Method signature:

Parameter

Data Type

Description

IT_INDEX

INT4_TABLE

Row indexes

SET_ATTRIBUTE

This method sets the value of a certain field in a certain row.
If no index is supplied or when passing /PLMU/IF_FRW_G_CONTEXT=>GC_USE_LEAD_SELECTION via parameter IV_INDEX the index of the lead-selection will be used.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index

IV_NAME

FIELDNAME

Attribute name (mandatory)

IV_VALUE

ANY

Attribute value (mandatory)

SET_FIELD_PROPERTIES

This method sets the field properties of a certain row.
The default value for parameter IV_INDEX is /PLMU/IF_FRW_G_CONTEXT=>GC_USE_LEAD_SELECTION which means that the index of the lead selection will be used.
When passing 0 for the index the given properties will be applied to all rows i.e. on column level instead of cell level.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index

IT_PROPERTIES

/PLMB/T_SPI_PROPERTIES

Field properties

SET_LEAD_SELECTION_INDEX

This method sets the lead-selection on the row with the given index.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index

SET_ROW

This method sets the content of a certain row.
If no index is supplied or when passing /PLMU/IF_FRW_G_CONTEXT=>GC_USE_LEAD_SELECTION via parameter IV_INDEX the index of the lead-selection will be used.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index

IS_ROW

ANY

New content of the row

SET_SELECTION_INDEX

This method sets the selection on the rows with the given index.

Method signature:

Parameter

Data Type

Description

IT_INDEX

INT4_TABLE

Row indexes

Context Info

Via this method the context info object can be obtained via method GET_INFO of the context interface.
It offers additional metadata about the context via interface /PLMU/IF_FRW_CONTEXT_INFO:

GET_NODE_NAME

This method provides the node name of the context.

Method signature:

Parameter

Data Type

Description

RV_NODE_NAME

/PLMB/SPI_NODE_NAME

Node name

GET_PATH

This method provides the path of a context – if in a hierarchy, which is not the case for the GUIBBs.

Method signature:

Parameter

Data Type

Description

ET_PATH

/PLMU/T_FRW_CONTEXT_PATH

Context path

GET_RTTI

This method provides runtime type information (RTTI) describing the context data.

Method signature:

Parameter

Data Type

Description

EO_UI_DATA_STRUCTURE

CL_ABAP_STRUCTDESCR

RTTI structure type description of the context

EO_UI_DATA_TABLE

CL_ABAP_TABLEDESCR

RTTI table type description of the context

IS_INITIALIZE_LEAD_SELECTION

This method returns ABAP_TRUE if the lead-selection is set upon context initialization.

Method signature:

Parameter

Data Type

Description

RV_IS_INITIALIZE_SELECTION

BOOLE_D

Indicates that the lead-selection is set upon context initialization

IS_MANDATORY

This method returns ABAP_TRUE if at least one row must be contained in the context at any time.

Method signature:

Parameter

Data Type

Description

RV_IS_MANDATORY

BOOLE_D

Indicates that at least one context row is mandatory

IS_MANDATORY_SELECTION

This method returns ABAP_TRUE if at any time a selection must exist.

Method signature:

Parameter

Data Type

Description

RV_IS_MANDATORY_SELECTION

BOOLE_D

Indicates that the selection is mandatory

IS_MULTIPLE

This method returns ABAP_TRUE if multiple context rows are allowed.

Method signature:

Parameter

Data Type

Description

RV_IS_MULTIPLE

BOOLE_D

Indicates that multiple context rows are allowed

IS_MULTIPLE_SELECTION

This method returns ABAP_TRUE if multiple context rows can be selected.

Method signature:

Parameter

Data Type

Description

RV_IS_MULTIPLE_SELECTION

BOOLE_D

Indicates that multiple rows can be selected

IS_SINGLETON

This method returns ABAP_TRUE if the context is a singleton.
This is only relevant if the context is part of a context hierarchy, which is never the case when using a GUIBB.

Method signature:

Parameter

Data Type

Description

RV_IS_SINGLETON

BOOLE_D

Indicates that the context is a singleton

IS_TOP_NODE

This method returns ABAP_TRUE if the context has no parent context, which is always the case when using a GUIBB.

Method signature:

Parameter

Data Type

Description

RV_IS_TOP_NODE

BOOLE_D

Indicates that the context has no parent context

Feeder Attribute MO_UI_TABLE

The feeder classes of the list and tree UIBB contain an additional attribute called MO_UI_TABLE, which offers methods to access the table UI element e.g. to scroll or to set its title.
There are some common methods which apply for the list and the tree, provided via interface /PLMU/IF_FRW_G_UI_TABLE_CNTRL and some feeder type specific ones provided by the interfaces /PLMU/IF_FRW_G_UI_LIST_CNTRL and /PLMU/IF_FRW_G_UI_TREE_CNTRL:

GET_ACTION_CONTROLLER

This method provides an interface of type /PLMU/IF_FRW_G_ACTIONS to control the row actions.
This interface allows e.g. to enable/disable/hide the row actions via the following methods:

SET_ROW_ACTION_PROPERTIES

This method sets the properties of the row actions.

Method signature:

Parameter

Data Type

Description

IT_PROPERTY

GTY_T_ACTION_PROPERTY

Row action properties (mandatory)

GET_ROW_ACTION_PROPERTIES

This method provides the properties of the requested row actions.

Method signature:

Parameter

Data Type

Description

IT_ACTION_ID

GTY_T_FPM_EVENT_ID

Requested action IDs

IT_INDEX

INT4_TABLE

Row index

ET_PROPERTY

GTY_T_ACTION_PROPERTY

Row action properties

SETUP_ACTION

This method sets control parameters for a specific action.

Method signature:

Parameter

Data Type

Description

IV_FPM_EVENT_ID

FPM_EVENT_ID

Action ID (mandatory)

IV_SUPPORTS_BLANK_ROWS

BOOLE_D

Does the action also support blank rows? If yes, then this action will also be enabled by the generic feeder for blank rows

GET_FIRST_VISIBLE_ROW_INDEX

This method provides the index of the first visible row in the UI table.

Method signature:

Parameter

Data Type

Description

RV_INDEX

INT4

Index of the first visible row

GET_NUMBER_OF_VISIBLE_ROWS

This method provides the amount of visible rows.

Method signature:

Parameter

Data Type

Description

RV_NUMBER_OF_VISIBLE_ROWS

INT4

Number of visible rows

GET_TITLE

This method provides the title text and tooltip of the table.

Method signature:

Parameter

Data Type

Description

EV_TEXT

STRING

Title text

EV_TOOLTIP

STRING

Title tooltip

SET_FIRST_VISIBLE_ROW_INDEX

This method sets the row with the given index to the first visible row in the UI table.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Index of the first visible row (mandatory)

SET_TITLE

This method sets the title of the table.

Method signature:

Parameter

Data Type

Description

IV_TEXT

STRING

Title text

IV_TOOLTIP

STRING

Title tooltip

CONVERT_INDEX_CONTEXT_TO_UI (List only)

This method provides the Context index that refers to the given UI table index.
Those indexes can deviate if frontend sorting and filtering is activated.

Method signature:

Parameter

Data Type

Description

IV_CONTEXT_INDEX

INT4

Context index (mandatory)

EV_UI_TABLE_INDEX

INT4

UI table index

CONVERT_INDEX_UI_TO_CONTEXT (List only)

This method provides the UI table index that belongs to the given Context index.
Those indexes can deviate if frontend sorting and filtering is activated.

Method signature:

Parameter

Data Type

Description

IV_UI_TABLE_INDEX

INT4

UI table index (mandatory)

EV_CONTEXT_INDEX

INT4

Context index

GET_UI_TO_CONTEXT_INDEX_MAP (List only)

This method provides a mapping of UI table to Context index.
Those indexes can deviate if frontend sorting and filtering is activated.
Also provides the information which rows are hidden.

Method signature:

Parameter

Data Type

Description

ET_INDEX_MAP

/PLMU/T_FRW_G_UI_CONTEXT_MAP

Mapping of UI table index to Context index

The mapping table has the following structure:

Component

Data Type

Description

UI_INDEX

INT4

UI table index

CONTEXT_INDEX

INT4

Context index

IS_HIDDEN

BOOLE_D

Indicates that the row is hidden

SET_INSERT_POSITION (List only)

This method sets the UI table index that will be used for newly added rows.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

UI table index (mandatory)

IV_INSERT_BEFORE

BOOLE_D

Indicates that the row will be inserted before the given index

SET_TREE_ATTRIBUTES (Tree only)

This method sets tree specific attributes e.g. the text of the master column.

Method signature:

Parameter

Data Type

Description

IS_TREE_ATTRIBUTES

FPMGB_S_TREE_ATTRIBUTES

Tree Attributes (mainly referring to the master column)

GET_TREE_ATTRIBUTES (Tree only)

This method provides tree specific attributes e.g. the text of the master column.

Method signature:

Parameter

Data Type

Description

ES_TREE_ATTRIBUTES

FPMGB_S_TREE_ATTRIBUTES

Tree Attributes (mainly referring to the master column)

Feeder Attribute MO_SELECT_OPTIONS

The search UIBB offers attribute MO_SELECT_OPTIONS which refers to interface /PLMU/IF_FRW_G_SELECT_OPTIONS and allows accessing the current values of the search criteria (i.e. select options) which will be used for the QUERY.

Like the Context, this object contains UI data which is handed over to the FPM during the GET_DATA method of the feeder. Its content will be kept in synch with the search criteria that are displayed on the UI.

It provides the following methods:

GET_SEARCH_CRITERIA

This method provides the current values of the search criteria.

Method signature:

Parameter

Data Type

Description

ET_SEARCH_CRITERIA

/PLMB/T_SPI_SELECTION_PARAM

Search criteria for QUERY

GET_MAX_NUMBER_OF_RESULTS

This method provides the maximum number of results that the QUERY should provide.
If set to '0', all results are supposed to be delivered.

Method signature:

Parameter

Data Type

Description

RV_MAX_NUMBER_OF_RESULTS

INT4

Maximum number of results

ADD_SEARCH_CRITERIA

This method adds new search criteria.

Method signature:

Parameter

Data Type

Description

IT_SEARCH_CRITERIA

/PLMB/T_SPI_SELECTION_PARAM

Search criteria for QUERY (mandatory)

Feeder Attribute MO_HIERARCHY

The tree UIBB offers attribute MO_HIERARCHY which refers to interface /PLMU/IF_FRW_G_HIERARCHY_CNTRL and allows expanding and collapsing the tree and get information about its hierarchy.
It provides the following methods:

ARE_CHILDREN_LOADED

This method provides the information if the children of a certain row were already loaded from the backend.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index (mandatory)

RV_CHILDREN_LOADED

BOOLE_D

Returns ABAP_TRUE if the children of the row are loaded

COLLAPSE

This method collapses a set of rows.

Method signature:

Parameter

Data Type

Description

IT_INDEX

INT4_TABLE

Table of row indexes (mandatory)

COLLAPSE_ALL

This method collapses all rows.

EXPAND

This method expands a set of rows the given amount of levels

Method signature:

Parameter

Data Type

Description

IV_LEVEL

INT4

Requested level of expansion (mandatory)

IV_COLLAPSE_BELOW

BOOLE_D

Collapse already expanded elements below the requested level of expansion? (Default value: ABAP_TRUE)

IT_INDEX

INT4_TABLE

Table of row indexes (mandatory)

EXPAND_ALL

This method expands all rows up to the maximum possible level.

GET_INDEX_OF_CHILDREN

This method provides the indexes of the children of a certain row.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index (mandatory)

ET_INDEX

INT4_TABLE

Table of indexes of the children

IS_EXPANDED

This method provides the information if a certain row is expanded.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index (mandatory)

RV_IS_EXPANDED

BOOLE_D

Returns ABAP_TRUE if the row is expanded

IS_LEAF

This method provides the information if a certain row is a leaf, i.e. has no children.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index (mandatory)

RV_IS_LEAF

BOOLE_D

Returns ABAP_TRUE if the row is a leaf

IS_ROOT

This method provides the information if a certain row is a root, i.e. has no parent row.

Method signature:

Parameter

Data Type

Description

IV_INDEX

INT4

Row index (mandatory)

RV_IS_ROOT

BOOLE_D

Returns ABAP_TRUE if the row is a root

  • No labels

5 Comments

  1. Hi

    I feel the  interface methods/PLMU/IF_FRW_G_AFTER_GET_DATA~AFTER_GET_DATA should have same parameters like IF_FPM_GUIBB_FORM/LIST get_data . If CT_DATA was available then it would have been easy to manipulate the data .

    Regards

    Arshad

     

    1. Former Member

      Hi Arshad,

      to manipulate the data of the GUIBB you can use attribute MO_CONTEXT.
      By following such an approach the generic feeder is able to offer additional services like writing the change log or filling certain internal fields out of the box which helps to reduce the effort on application side.

      Best regards,
      Maximilian

  2. Hi Maximillan,

    I have one doubt. Can I use the FPM SPI generic UIBB in an FBI OVP application??

    IF Yes, how to do the wiring? IF FBI application is in different namespace and FPM GUIBB is in different namespace, Which connector class I should use.

    IF not. Then is that mean if you have a guibb in fpm spi we can not reuse it?

    Regards,

    Malathesha Sodad

    1. Former Member

      Hello Malathesha,

      there is a dedicated page for the wiring topic:
      https://wiki.scn.sap.com/wiki/display/SPI/Wiring

      You need to use the right connector class.
      There are already a couple of standard ones provided by FSI but you can also use your own ones.

      Best regards,
      Maximilian

  3. Former Member

    Hi Maximilian,

    Thanks for comprehensive guide.

    In our application we are using Tree UIBB for tree like list, and we are using Retrieve by association in our whole application as we will migrate this to FIORI later on.

    We are using Retrieve by association as it will be very efficient way to communicate between Fiori and Backend.

    But sadly it's mentioned that to fetch root node for TREE UIBB, we need to use Direct Retrieve only. 

    Now this will break our whole application architecture.

    I was thinking is there a workaround for this or if it is not implemented now then will it be taken in future?

    Regards,

    Upendra