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

Introduction

When talking about navigation in this chapter we only refer to cross application (instance) navigation.
So by navigation we do not refer to view switches within one application.

The entire navigation logic of the FPM SPI Integration (FSI) is based on the Launch-pad functionality.

Navigation can be triggered in three different ways:

  • You Can Also/Related Links (navigation menus in the toolbar of the Floorplan)
  • Context menu (right mouse click)
  • Direct link or button click

To make the navigation work, the following steps need to be performed:

  1. Create Launch-pads
  2. Maintain the Navigation Customizing
  3. Implement the Navigation

Create and Maintain Launch-pads

Launch-pads represent the abstraction layer in which the navigation targets are defined.
The Launch-pad maintenance can be reached via transaction LPD_CUST.
It is advisable to create Launch-pads per object type and/or per application.
Launch-pads are partly customizing and thus they have to be created in the customizing client.

For the generic navigation via link or button click the assignment of object types and Application Building Blocks to Launch-pad items must be maintained in customizing table /PLMU/FRW_NAV.
For the context menu definition Launch-pads must be maintained in the customizing table /PLMU/FRW_CTXM.

Customizing

Via view /PLMU/V_FRW_NAV all the navigation actions are maintained that can be triggered with method PROCESS_NAVIGATION.

Maintain Object Type Only for Object Related Navigations

The object type shall only be entered for object related navigation actions – e.g. navigation to the 'Material UI in Display Mode'.
For non-object related navigation actions one must not enter an object type – e.g. navigation to the Object Navigator.

The following customizing is needed to allow the FPM SPI Integration (FSI) to automatically create an application specific context menu for certain fields:

  1. Creation of the Launch-pad
  2. Maintenance of the Parameter Mapping (including the object type)
  3. Assignment of the object type to the Launch-pad via view /PLMU/V_FRW_CTXM
    (It is also possible to have application specific Launch-pad assignments by filling the ABBID field):

    OTYPE

    ABBID

    LPD_ROLE

    LPD_INSTANCE

    SRV_GROUP

    MY_OTYPE

     

    MY_ROLE

    MY_LAUNCHPAD_INSTANCE

    MY_SRV_GRP

Services can be maintained via view /PLMB/V_GOS_SDEF.

For assigning services to context menus, services need to be grouped via view /PLMB/V_GOS_SGDF.

Implementation

To trigger any navigation it is necessary to pick up an action utilities instance (/PLMU/IF_FRW_ACTION_UTIL) from our factory class – ideally during the initialization of the UI, as shown by the example below:

MO_ACTION_UTIL = /PLMU/CL_FRW_FACTORY=>GET_ACTION_UTILITIES( IV_ABBID = 'MY_ABBID' ).

Navigation Constants

The interface for constants of the navigation is /PLMB/IF_FRW_ACTION_C.

Central navigation functionality like 'You Can Also', 'Related Links' or 'Additional Functions' of the Floorplan toolbar (CNR) should be handled by a central unit of the UI e.g. the Application Controller.

Therefore this central unit of the UI also needs to fetch an action utilities instance and when doing so fill import parameter IO_CALLBACK.
The instance that is handed over via parameter is IO_CALLBACK will then be called during the navigation to allow it to handle the following tasks:

  • Header data provisioning (MANDATORY)
  • Influence the Parameter Mapping (OPTIONAL)

To supply the data of the header object, which is needed e.g. during a navigation that refers to the header object or when using the Header-Data-Wire you need to implement one of the following interfaces:

  • /PLMU/IF_FRW_MAP_HEADER (ABAP OO)
  • /PLMU/IWCI_WDI_FRW_MAP_HEADER (Web Dynpro)

Those interfaces contain method SUPPLY_HEADER_DATA which should be implemented as follows:

  1. Retrieves the data of the header object via the Application Model (Store the object ID of the header object e.g. during the FPM_LEAVE_INITIAL_SCREEN event).
  2. Buffer the header data whenever the Application Model returns new data.
  3. Return the buffered header data.

Whenever a central navigation or service is triggered, the map header interface will be called to gather the application parameters.

The Parameter Mapping is needed whenever the application that triggers the navigation and the application that is the target of the navigation are using different names for the same parameter.
So if e.g. an application A wants to pass an attribute called 'MATERIAL' to application B which only knows the attribute 'MATNR' (which has the same meaning) the mapping is needed.

Find more info regarding this topic in the Parameter Mapping chapter.

If you want to manipulate the mapping results after the Parameter Mapping was processed you can implement one of the following interfaces:

  • /PLMU/IF_FRW_MAP_ASSIST (ABAP OO)
  • /PLMU/IWCI_WDI_FRW_MAP_ASSIST (Web Dynpro)

There is also the possibility to manipulate the parameters of the navigation via BAdI /PLMU/EX_FRW_PARAMETERS.

If you want to bypass the Parameter Mapping during the navigation and create an application specific mapping logic you can implement one of the following interfaces:

  • /PLMB/IF_FRW_MAP_FIELD (ABAP OO)
  • /PLMU/IWCI_WDI_FRW_MAP_FIELD (Web Dynpro)

To trigger the navigation you need to call method PROCESS_NAVIGATION of the action utilities interface e.g. in the PROCESS_EVENT method or your Web Dynpro action handler.

The PROCESS_NAVIGATION method has the following import parameter:

Parameter

Optional

Description

IV_NAVIGATION_TARGET

X

Navigation target

IV_OTYPE

X

GOS Object Type

IV_FIELD_NAME

X

Name of the reference field for the navigation

IS_STRUCTURE

X

Data structure that contains the source data for the navigation

IO_CONTEXT_ELEMENT

X

Context element that contains the source data for the navigation

The source data that will be transferred during the navigation needs to be provided either by using the IS_STRUCTURE or the IO_CONTEXT_ELEMENT parameter.
IV_FIELD_NAME needs to contain the name of the reference field of the source data structure and is the starting point of the Parameter Mapping.
If IV_OTYPE is not supplied the GOS object type will be determined via the Parameter Mapping customizing.

To process a certain service for an object or multiple objects, the PROCESS_SERVICE method can be used. The interface of that method is similar to the one of PROCESS_NAVIGATION.

Navigation in dynamic UIs

You can use method GET_OTYPE_RELEVANT_FIELDS of the action utilities interface to get a list of field names which are assigned to an object type in the Parameter Mapping customizing.
This can be used e.g. for dynamic UIs to determine the navigation relevant fields.

To enrich the context menu according to the navigation customizing and to process the navigation you need to do the following:

  1. Implement in each Web Dynpro view in which you might want to offer a context menu the following coding:

    METHOD wddooncontextmenu.
    
        wd_comp_controller->mo_action_util->get_context_menu(
            EXPORTING io_context_menu_event   = context_menu_event
                      io_context_menu_manager = context_menu_manager
            IMPORTING eo_menu                 = menu ).
    
    ENDMETHOD.
  2. Add the action CONTEXT_MENU_ACTION and implement the corresponding action handler:

    METHOD onactioncontext_menu_action.
    
        wd_comp_controller->mo_action_util->process_context_menu_action( wdevent ).
    
    ENDMETHOD.

Of course it is still possible to manually add additional context menu items that are not part of the Launch-pad.
You can just add them to the context menu using the according Web Dynpro interface.

For the GUIBBs the context menu customizing is automatically applied by the generic feeder class.

The navigation parameters can either be picked up via the action utilities interface or when using the Wiring (with a URL connector) via the Wire Model.

When the action utilities interface is implemented by an application, method GET_EXTERNAL_PARAMETERS can be used to pick up the parameters of an inbound navigation.
In the freestyle UIBB environment you can even directly fill a context node (typically of the initial screen) based on the navigation parameters by using method /PLMU/IF_FRW_ACTION_UTIL->FILL_INITIAL_SCREEN_NODE.

Portal Specialties

In the portal environment, a portal system alias is used to identify the relevant backend system.
The Web Dynpro methods that trigger a portal navigation must be supplied with that system alias.

In many scenarios reusable UIBBs are embedded in applications. These reusable UIBBs can run in various backend systems (with different portal system aliases). If a navigation is triggered on these reusable UIBBs, the FPM SPI Integration (FSI) offers a mechanism that ensures that the target application of a navigation will connect against the same backend system as the source application does.

Since every application (that does not already embed reusable UIBBs) might be enhanced e.g. by a customer with a reusable UIBB.
Every application must therefore support the logic to keep the backend system during navigation.

To keep the backend system during navigation, the portal system alias must be set at runtime by the FPM SPI Integration (FSI).
There are two prerequisites to be fulfilled by the application to make that functionality work:

  • All navigation enabled reusable UIBBs must use launch-pads with a dummy portal system alias: SAP_CHANGED_AT_RUNTIME.
    Only if this dummy system alias is used, the system alias will be adjusted at runtime. Every other system aliases will not be changed by the FSI.
  • All portal iViews must send the current portal system alias to the backend system. This can be achieved by entering the following dynamic parameter in the application parameters field of the iView: FRW_SYSALIAS=<System> (or SYSTEM_ALIAS=<System>).IView with Dynamic System Alias Application Parameters
  • Even better than entering the portal system alias into each and every iView is to create an iView template for all the existing application iViews. Having a template iView, there are two different approaches to hold the portal system alias centrally:
    • The first approach is to create an additional iView field for 'individual application parameters'. That way there are two fields to hold parameters. One of them can be set to 'final' in the template so the individual iViews cannot redefine that field. The individual iViews can then use the 2nd field to enter individual parameter. Please contact a portal expert to implement that logic.
    • Another way to have the portal system alias on a central place is to simply enter the system alias in the format mentioned above into the application parameters field. A disadvantage here is that the application parameters field can be redefined (if it is not set to 'final' in the template iView). So the portal system alias might get lost with a redefinition.

IView Template with System Alias Application Parameters and a Reference to the Individual Parameters

  • No labels