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.

Assigning Launch-pads

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

Assigning Object Types and Navigation Targets to Launch-pad Targets

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

Context Menus

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

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' ).

Central Navigation Tasks

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)

Header Data Provisioning

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.

Navigation Parameter Mapping

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)

Navigation Links and Buttons

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:

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.

Context Menus

Freestyle UIBBs

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.

GUIBBs

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

Picking up Navigation Parameters at Runtime

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>).
• 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.