Page tree
Skip to end of metadata
Go to start of metadata

FPM SPI Integration (FSI)

How do I ensure that my data in the UI is always refreshed correctly?

It is not recommended to build UI logic which knows about dependencies of the backend calls because this increases the complexity of the UI logic. Furthermore it is normally difficult to reuse such UI logic in the context of e.g. another UI. Therefore such knowledge belongs to the backend layer and when using the SPI this can be implemented as described in the section below.

As a result the UI logic can be kept very simple. The application UI should call the RETRIEVE in every round-trip (typically during the PBO) and the backend call will be blocked automatically in case it is not required. A prerequisite is to always use the Application Model to access the backend.
When using GUIBBs calling the RETRIEVE during every round-trip is already done by the generic feeder class.

What happens if an error in the UI occurs?

Errors in the UI affect the logic of the Application Controller and the Application Model.
More details are described in the respective chapters.

How to get default i.e. 'empty' rows in a table to allow the user the creation of new records?

Two things are required to get some default rows within a list:

  1. The definition of the number and optionally the content of the default rows:
    For the GUIBBs as well as for freestyle UIBBs we offer a simple mechanism to define default rows.
    • The GUIBBs allow defining the number of required default rows via configuration as part of the feeder parameters.
      The content of those rows – if it is not supposed to be blank (then no further implementation is required) – can be set via an application specific feeder implementation of interface /PLMU/IF_FRW_G_DEFAULT_ROW.
    • To add default rows to a freestyle UIBB you should use method SET_DEFAULT_ROWS which you will find at attribute MO_TOOLS of the Application Model.
  2. Implementation of the field control for those rows:
    This implementation is independent from the UIBB type.
    The SP needs to set the field profile for reference type 'INSERT', for example via method GET_PROPERTIES of interface /PLMB/IF_SPI_PROPERTIES_ACCESS when using the PULL mechanism for properties.
    For more info about the field control implementation please have a look at the Collector chapter.

How can I enable/disable/hide the buttons of the main toolbar (CNR) at runtime?

The buttons of the main toolbar, which are defined in the Floorplan configuration, can be hidden or disabled at runtime.
Therefore the FPM offers one interface per Floorplan type.
In addition to that the Application Controller of the FSI offers some automatisms to control standard CNR buttons automatically.
Furthermore it allows associating the CNR buttons with certain operations of the Service Provider (SP), which allows controlling the CNR buttons from within the SP by controlling the according operation.

Why are the messages that I forward to the Collector not linked properly in the UI?

The messages that the Service Provider passes to the Collector are linked to the respective rows or cells in the UI by the Application Model.
So first of all the usage of the Application Model is one prerequisite for this service.
How the links are created by the Application Model is described in the Application Model chapter and the correct format of the messages (especially regarding the usage of the reference data) to make this work is described in the Collector chapter.

How to build an initial screen?

An initial screen has the purpose to select the leading object(s) the application is started with.
Therefore you normally offer some input fields on the initial screen which need to be validated upon leaving this screen:

When the user presses start on the initial screen the leave-initial-screen-event (with the ID CL_FPM_EVENT=>GC_EVENT_LEAVE_INITIAL_SCREEN) is triggered.
This event leads to a view switch to the main area of the Floorplan.
In method PROCESS_EVENT (for GUIBBs PROCESS_GLOBAL_EVENT) you should get the data out of the context and validate it in the backend via the Application Model.
If the data is invalid (e.g. the entered object key does not exist and we are on a display initial screen) you need to cancel the FPM event which will suppress the view switch.

Specialty of the Initial Screen

The Application Model won't automatically call the insert or update when the user enters data on the initial screen since normally the data is supposed to be validated when the user tries to leave the initial screen only.

Mandatory Field Check for freestyle UIBB

To check the mandatory fields of a freestyle UIBB on the initial screen you can use method /PLMU/CL_FRW_SERVICES=>CHECK_MANDATORY_FIELDS.

How to call dialog boxes from your application?

Dialog boxes are normally built and called in 2 different ways

  • Through the NEEDS_CONFIRMATION method, which leads to a simple confirmation popup where the user can typically only press 'OK' or 'Cancel'
  • By raising the FPM event OPEN_DIALOG_BOX, which allows opening more complex popups

Simple Confirmation Popup

To open a confirmation dialog box in your application, you have to implement the method NEEDS_CONFIRMATION of your Application Controller, your freestyle UIBB component or you GUIBB feeder class.

In this method you can create an object of type CL_FPM_CONFIRMATION_REQUEST for a certain event.
Returning this object in the reference EO_CONFIRMATION_REQUEST will automatically call the confirmation popup.
Based on the user selection the according event will be processed or cancelled (i.e. will fail).

Raising the FPM event OPEN_DIALOG_BOX

For this way of calling a dialog box you have to create a dialog box in the configuration of your component.
Then, add a freestyle or generic UIBB to the configuration of the dialog box.
Now you can raise the FPM event FPM_OPEN_DIALOG_BOX with the event parameter DIALOG_BOX_ID which need to contain your dialog box ID to open the popup.

Why does the data loss popup (not) appear?

The data loss popup is raised whenever the user triggers an action that leads to a potential data loss e.g. an FPM event that leads to a CLEAN_UP of the Service Provider or that closes the UI.

The Application Controller triggers such a popup in two ways:

  • by implementing the interface IF_FPM_WORK_PROTECTION
  • by implementing method NEEDS_CONFIRMATION for certain events (such as FPM_CANCEL or FPM_READ_ONLY)

The logic that decides whether or not such a popup is required is the same in both cases:
The UI must be in edit mode and a successful SP call must have happened which was save relevant or there is still some (erroneous) data in the UI that needs to be flushed to the SP.

If a data loss popup is opened although the user did not change any data you need to check the accuracy of the application's metadata with regard to the save relevance and the necessity of the SP calls that were triggered by the application.

If the user did change some data but no data loss popup is opened you need to check the accuracy of the application's metadata with regard to the save relevance and whether a backend call was performed which was bypassing the SPI.

What do I need to consider when displaying the same node in two different UIBBs?

You display the data of the same node in two different UIBBs e.g. in a list GUIBB you display an overview of a set of records and in a form UIBB you display some more details of the selected record of the list.

When now both UIBBs are editable you can change the data of the same record within both UIBBs in one round-trip, which can easily lead to some issues, if the UPDATE is not implemented accordingly:
If the UPDATE logic just writes the complete data record that is supplied into the backend, you might face the problem that the data of the first UPDATE gets completely overwritten by the data of the second UPDATE.

To avoid this issue the UPDATE implementation needs to consider the parameter IT_CHANGED_FIELD and basically execute the changes in the backend on attribute level, rather than on structure level.
A prerequisite is that in the metadata definition of the respective node the field UPDATE_RELEVANT is set accordingly.

How to make use of the Side-Panel?

The FSI offers a simple integration of the Side-Panel which is described in the FSI Services and Tools chapter.


How to activate the mandatory field check?

Mandatory field checks need to be activated once via the configuration of the GUIBBs. Afterwards the checks are executed automatically at runtime.

How to use input fields in the toolbar of the List UIBB?

  1. Add the interface /PLMU/IF_FRW_G_ACTIONS interface to your list feeder class
  2. Implement the method GET_ACTION_DEFINITION of this interface
    • Define a new Action/event for the input field; note: this event is triggered by FPM when pressing enter and the input field has the focus
    • Following components of the definition structure (DDIC type FPMGB_S_ACTIONDEF) have to be filled (minimum setup):




      FPM event ID that is triggered upon <Enter> (Input field must have the focus)


      DDIC type of the input field

    • Additional useful settings (for complete list refer to FPM documentation):




      Label for the input field


      DDIC Search help to be used


      OVS search help


      Fixed allowed values which are used as search help and check table

      Note: if the data element or data structure contains already a DDIC search help it is used automatically!

  3. In the FPM GUIBB configuration choose in change mode 'Configure Toolbar', add the action/event ID created for the input field and choose 'Input Field' as Display Type
  4. As last step you implement the method PROCESS_ACTION_EVENT (again interface /PLMU/IF_FRW_G_ACTIONS) to handle the triggered event when the user presses Enter in the input field. Via the event parameters of the FPM event object you have access to the value of the field.

How to use dropdown list boxes in the toolbar of List UIBBs?

  1. Add the interface /PLMU/IF_FRW_G_ACTIONS interface to your list feeder class
  2. Implement the method GET_ACTION_DEFINITION of this interface
    • Define a new Action/event for the dropdown list box (DDLB); note: this event is triggered by FPM selecting a value from the DDLB
    • Following components of the definition structure (DDIC type FPMGB_S_ACTIONDEF) have to be filled (minimum setup):




      FPM event ID/action assigned to the DDLB


      DDIC type of the DDLB


      This table contains the valid value for the DDLB

    • A label for the DDLB can be set via the component 'Text' (for complete documentation of all components please refer to the FPM documentation)
  3. In the FPM GUIBB configuration choose in change mode 'Configure Toolbar': add the action/event created for the DDLB and choose 'Drop Down' as Display Type.
  4. As last step you implement the method PROCESS_ACTION_EVENT (again interface /PLMU/IF_FRW_G_ACTIONS) to handle the triggered event when the selects a value from the DDLB. Via the event parameters of the FPM event object you have access to the value of the field.

How to fill dropdown list boxes?

In the GUIBB configuration set the display type of the field to 'Drop Down'.
Add interface /PLMU/IF_FRW_G_FIELD_DEF to your list feeder class and implement method CHANGE_FIELD_DEFINITION.
Fill table FIXED_VALUES of the changing parameter CS_DEFINITION (based on IV_FIELD_NAME).

FSI – Freestyle UIBB

How to fix the dump 'Lead selection not set for context node'?

If you are experiencing a dump with an exception text similar to 'Lead selection not set for context node COMPONENTCONTROLLER.1.MY_NODE' it is very likely that the selection setting of the mentioned context node is incorrect.
For every visible input field, Web Dynpro expects to find a lead selection in the context node the input field value is bound to.
To avoid this dump you need to ensure that there is always at least one context element contained in the context node and that this context node has the selection setting 1..N or 1..1.

Why are messages that my application raises not displayed?

For more information about the message handling you should have a look at the Collector chapter.

One reason for missing messages, which were raised by the application but don't get displayed in the UI is, that the message was linked to a context element whose data is currently not displayed in the UI.

E.g.: The application raises a message for node ID 'A' of node 'INIT' during a SP call. There is currently a context element in the Web Dynpro context node 'INIT' with the node ID 'A'. So the Application Model will link the message to this context element. The problem now is that context node 'INIT' is bound to the input fields of the initial screen but the application is already displaying the main screen when the message is supposed to get displayed. Therefore the message will not be displayed.

So the application needs to ensure that messages are only linked to a certain context element if it is currently visible in the UI.
The application can implement the Web Dynpro interface /PLMU/WDI_FRW_CONTEXT and implement method MAP_MESSAGES to remove the link between the context element and the message.
Therefore you need to set the 'DO_NOT_LINK' indicator of the according message to ABAP_TRUE.

Why does my application dump saying 'could not find attribute '...''?

It is likely that you are passing an invalid field profile to the Collector within your SP.
Please check all profiles that you pass to the Collector and verify if all those attributes are actually part of the node.
The field properties must only be set for attributes that belong to the node!

What is the difference between Web Dynpro context nodes and the nodes defined in the Metadata Provider?

First of all it is important to know that the SPI is UI technology independent. This means it can be consumed by any kind of UI technology that connects to the SPI.
Web Dynpro context nodes are specific for Web Dynpro and are used as the data buffer of a Web Dynpro component. This means Web Dynpro context nodes are a UI technology specific entity.
So to be able to work also without the FPM and Web Dynpro the Metadata Definition is essential for SPI. It is not relying on the definition of Web Dynpro context nodes but only on what is defined in the Metadata Provider. However the 
Application Model of the FPM SPI Integration offers many services around the Web Dynpro context handling which reduce the UI development efforts. Those services also rely on the correct and complete definition of the Metadata.

Which logic belongs into the Web Dynpro methods/actions and which into the Service Provider/backend?

Ideally you should put only the UI relevant logic into the Web Dynpro component. This means all interactions with UI controls like setting a selection or filling certain fields should be implemented in the Web Dynpro component.
All logic which is somehow application/business logic that is independent from the UI (technology) belongs into the backend.
Some more guidelines around this topic you can read in the Guidelines and Best Practices chapter.

Service Provider Infrastructure (SPI)

How to pass data changes from the backend to the consumer (e.g. UI)?

All methods that can be used to create or change records (INSERT, UPDATE, ACTION) allow giving back the result directly via export parameter ET_NODE_DATA.
This parameter however should contain only the records that were directly addressed by the called operation.
Therefore no foreign records, which might be affected implicitly, should be handed over to the consumer via this export parameter directly.

For such implicit changes there are two mechanisms that can be used to inform the consumer about the data changes.
With this info the consumer can again invoke a RETRIEVE to get the refreshed data:

  • Side-effects and dependencies of nodes, which are defined in the application's metadata.
    The advantage of the side-effects and dependencies is that they are easy to maintain and to identify when having a look at the metadata.
    Their disadvantage is that they don't consider runtime data and are rather rough since they always affect one or multiple nodes and no single records, which may lead to superfluous read accesses.
  • Invalidation info of nodes or records which are passed by the Service Provider to the Collector.
    The advantage of the node invalidation is that it allows the application to inform its consumer about changes depending on the runtime data and that it allows passing this info not only on node level but even on data record level.
    Its disadvantage is that the logic of a very fine grained and optimized invalidation logic might be more complex, which leads to more effort and potentially less easy to identify data dependencies.

Consuming the Same Node Multiple Times

When the same node is consumed multiple times and one of the consumers triggers an UPDATE for example, all other consumers are automatically informed about this change via a node invalidation entry that the SPI writes automatically.
Example: In a UI there is a master list and a detail form which both refer to the same node, if now in the form a field gets changed by the user there is no further side-effect or node invalidation implementation within the SP needed to ensure that the changed record also gets refreshed within the list

How to handle side-effects across applications?

The handling of side-effects across applications is similar than the handling within one application. A prerequisite is that both applications are using SPI (and may it be only to communicate those side-effects).
For more details on how to handle side-effects in general read the section above.
When you want to add side-effects or node invalidation to an existing application without changing the original coding you may use the SPI BAdIs to do so modification free.

How to enable late numbering?

What is late numbering and how is it triggered from the backend? Those questions are answered in the Collector chapter.

General FAQ

What are the relevant package interfaces when using SPI or FSI?

  • BS_PLM_UI_FRAMEWORK_BASIS when using only SPI

How to use a DO from a higher software layer?

Example: VC (SAP_APPL) uses Thumbnail DO (PLMWUI)

  1. Create a BAdI in the software layer where you want to use the DO.
    Example: Enhancement Spot VC2HL_UI_DECO – BAdI EX_VC2HL_UI_DECO_THUMBNAIL
    The BAdI needs (at least):
    • one method to create a Web Dynpro component usage during runtime
    • one method to call the interface controller method of the used Web Dynpro component
  2. Create a corresponding BAdI Implementation in the software layer of the DO (in a switchable package – assigned to a switch – assigned to a business function)
    Example: BAdI Implementation /PLMU/IM_EX_VC2HL_DECO_THUMB
    • package /PLMU/VCHL_SFWS_ENH_01
    • switch /PLMU/VCHL_SFWS_ENH_01
    • business function /PLMU/WEB_UI_2
  3. Provide a view container for the used DO.
  4. Call the BAdI Implementation within the Web Dynpro component where you want to use the DO
    • during WDDOINT to create to component usage
      Example: Web Dynpro Component WDC_VC2HL_CT View V_POPUP_DETAIL Method WDDOINIT
    • within each round-trip where you want to call the used component
      Example: Web Dynpro Component WDC_VC2HL_CT View V_POPUP_DETAIL Method DISPLAY_THUMBNAIL
  • No labels