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

Introduction

Freestyle UI Building Blocks are application specific Web Dynpro components that implement the Web Dynpro component interface IF_FPM_UI_BUILDING_BLOCK.
The FPM SPI Integration (FSI) offers several services that allow simplifying the application logic within freestyle UIBBs drastically.

Therefore an instance of the Application Model has to be fetched e.g. in the WDDOINIT of the component controller.
The Application Model can then automatically flush the changes that were entered on the UI (i.e. call insert or update of the Service Provider).
It binds the retrieved data automatically to the context, links messages to the respective context element and sets the field and button properties according to the profiles that were set by the SP.

Additionally the FSI offers the possibility to enable the freestyle UIBB for the Wiring in just a few steps, which are explained in the respective chapter.

Context Modeling

The Web Dynpro context of freestyle UIBBs must follow certain rules to allow the Application Model to administer it automatically (i.e. flush, bind data...).

The Application Model only administers nodes that are defined in the Metadata Provider of the Application.
This means that the context node needs to have the same name than the metadata node.

Furthermore when creating a context node hierarchy it needs to follow certain rules:
Web Dynpro context nodes will be administered if the node hierarchy matches the one defined in the MP.
However it is possible to only create a subset (branch) of the node hierarchy in the Web Dynpro context.
When doing so it is important to never skip any intermediate nodes within one branch or to mix up the defined hierarchy.
The branch needs to consist of nodes that are directly adjacent to each other in the MP definition.

For a better understanding of those rules please have a look at the following two examples one of good context modeling and one of bad context modeling.
For those examples the node model defined in the metadata base of the application looks like the following:

Example Node Hierarchy

Good Modeling

The Web Dynpro context may look like the following to allow the Application Model to administer the defined nodes (All nodes that are administered are painted green):Context that can be Administered

Bad Modeling

The following context modeling however won't allow the Application Model to administer all nodes that are part of the node model of the metadata provider (The red nodes won't be administered although they are defined in the metadata provider):Context that cannot be Administered Completely

Field Control

A correctly implemented Service Provider (SP) always provides the field control information along with the provided data.

To allow the Application Model to apply those properties to the respective UI elements, those UI elements need to be bound to the following properties of the respective context element's attribute:

  • enabled
  • read-only
  • required
  • visible

As a result all the input fields that contain data that is provided by the SP will be controlled according to the field properties that were set by the SP.
This also means that every field which is not known by the SP (UI-only field) should not be controlled by the SP but directly on UI-level.

Push-Button Control

Every push-button that is representing an operation of the Service Provider] should be controlled from within the SP.

Unlike to GUIBBs, where the rest is working automatically, there are some more things to do on application side to make it work for freestyle UIBBs:

  1. In the Web Dynpro context of the component controller a node needs to be defined (Do not add this node to the Metadata Provider!).
  2. For each button that needs to be controlled one attribute needs to be added to this Web Dynpro context node.
  3. This context node needs to be mapped to the view where the push-buttons are defined via the standard Web Dynpro context mapping mechanism.
  4. Now the buttons control properties need to be bound to the respective virtual attributes (visibility ...) of the context node (similar to the field control example above).
  5. Finally the mapping between Web Dynpro context node and Service Provider operation properties needs to be defined, which can be done via the method SET_OPERATIONS_MAPPING of the MO_TOOLS object that can be found at the Application Model.
    This method receives a (sorted) table with mapping information. The key fields are:
    • Application Building Block ID (ABBID)
    • Metadata Node Name (SP_NODE_NAME)
    • Operation Type
    • Action Name (optional, only required for Operation Type = Action/Query)

Interaction with the FPM SPI Integration (FSI)

The FPM offers certain Web Dynpro component interfaces that need to be implemented by freestyle UIBBs.
Those interfaces are IF_FPM_UI_BUILDING_BLOCK (which contains methods like NEEDS_CONFIRMATION, PROCESS_EVENT and PROCESS_BEFORE_OUTPUT) and IF_FPM_UIBB_MODEL that is required to use the Wiring for exchanging key information from a parent UIBB to its children.

In addition the FPM SPI Integration (FSI) offers the following optional interfaces which can also be implemented by the Web Dynpro component and which will then be called by the FSI.

Please also have a look at the Application Controller to see additional possibilities to interact with the FSI.

/PLMU/WDI_FRW_DELETE

Method GET_ELEM_INDICES_FOR_IDS

This method gets called during a delete call of the application model if there are records about to be deleted that were not read from or send to the backend (submitted). It receives the node ID of those records and the index of the corresponding context elements which can then be adjusted if necessary.

/PLMU/WDI_FRW_FLUSH

Method AFTER_CANCEL_NAVIGATION

This method is called after the navigation got cancelled, which is the case when an error occurred during the data flush.

Method AFTER_FLUSH

This method is getting called after the data has been flushed.

Method BEFORE_FLUSH

This method will get called before flushing the data changes (performed via UI) of the current round-trip. This allows the UIBB to access the data contained in the change log before any update and/or insert calls are sent 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 UIBB wants to handle this by itself.
Another use case is that the UIBB needs to trigger some additional actions based on the knowledge that certain data was maintained.

Method BEFORE_INSERT

The BEFORE_INSERT is called during the data flush when the Application Model is about to trigger an insert on a node that has a parent node in the node model of the metadata provider but in the Web Dynpro context this node is a direct child of the root context node. The application has now the possibility to trigger an insert by association and to specifying the respective node ID of the parent record via this callback method.

/PLMU/WDI_FRW_TRANSACTION

Method AFTER_CLEANUP

The method will be processed after a SPI CLEAN_UP call which is executed for example after every save or during a refresh by the Application Model.

Method AFTER_SAVE

This method is called after a successful backend save call

Method BEFORE_CLEANUP

This method is called before a SPI CLEAN_UP call.

Deprecated Interfaces

In earlier times most applications were built as a single Web Dynpro component that had the role of the view and the controller (of the MVC pattern) at the same time.
For various reasons (e.g. complexity, reusability, flexibility) this is not recommended anymore.
Instead an application specific controller should be implemented in combination with GUIBBs and/or fine grained freestyle UIBBs, which means one Web Dynpro component per UIBB which normally contain exactly one view.
Due to this change of approaches in implementing the application UI we also do not recommend to still use all of our interfaces anymore:

/PLMU/WDI_FRW_CNR – Node Attribute to CNR Event ID Mapping

Method GET_CNR_EVENTS

Method is Deprecated

The usage of this method is not recommended anymore. Instead the application should use the Application controller service class as described in the Application Controller chapter.

This method can be used to bind the field properties of a certain node attribute to a CNR button so that this button's properties will then be controlled via the Service Provider by setting the field properties of the respective node attribute.

The required mapping is defined by a table of:

  • Metadata Node Name
  • Attribute Name (which is used for field control)
  • Event ID of the CNR button
  • Element ID of the CNR button

/PLMU/WDI_FRW_CONTEXT

Method MAP_MESSAGES

Method is Deprecated

The usage of this method is not recommended anymore. Instead method SET_MESSAGE_MAPPER of the attribute MO_TOOLS of the Application Model should be used.

Messages can be linked to a certain field on the UI. When a message is raised by the backend it can also specify to which record and in more detail to which attribute of which record this message belongs to. The Application Model then automatically links the message to the respective context element attribute which then displays the message in the UI directly linked to this attribute. To adjust this linkage in the UI the MAP_MESSAGES method can be used.

Method MAP_PROPERTIES

Method is Deprecated

The usage of this method is not recommended anymore since it can slow down the application drastically when mass data is involved.

The field properties that the service provider passes to the SPI is automatically bound to the corresponding context elements by the Application Model. To redirect the field properties to another element this method can be used.

Method MODIFY_CONTEXT_CHANGE_LOG

Method is Deprecated

The usage of this method is not recommended anymore. Instead method BEFORE_FLUSH of the Web Dynpro Interface /PLMU/WDI_FRW_FLUSH should be used.

The Application Model calls this method before flushing the data changes (performed via UI) of the current round-trip. This allows the UIBB to access the data contained in the change log before the Application Model 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 UIBB wants to handle this by itself.
Another use case is that the UIBB needs to trigger some additional actions based on the knowledge that certain data was maintained.

/PLMU/WDI_FRW_OIF

Method OVERRIDE_EVENT

Method is Deprecated

The usage of this method is not recommended anymore. Instead an Application specific Controller should be used which offers exactly the same method.

This method gets called for every event before its processing and grants access to the interface IF_FPM_OIF which can be used i.e. to adjust the layout of the Object Instance
Floorplan (OIF)

/PLMU/WDI_FRW_TABBED

Method OVERRIDE_CONFIG_TABBED

Method is Deprecated

The usage of this method is not recommended anymore. Instead the Application specific Controller should be used which offers exactly the same method.

This method gets called for every event before its processing and grants access to the interface IF_FPM_TABBED which can be used i.e. to adjust the layout of the tabbed component.

  • No labels