Introduction
Intent-based navigation (IBN) is a general cross-application navigation concept used in Fiori Launchpad and natively supported by SAP UI5 Fiori Apps.
Legacy applications based on WebDynpro or Dynpro technologies have their own navigation and resource/target addressing methods that do not map to IBN. To simplify the transition of existing applications from the GUI/WebDynpro world to the simplified experience of Fiori, support of the Fiori-like navigation in Classic UI technology apps is essential. It shall be a way for GUI/WebDynpro applications to use Intent-Based Navigation in the same/similar way as it is used by SAP UI5 apps. It shall be possible to remap the old target used in Visually Harmonized applications to the new lightweight Fiori application, and it shall be done with minimal modification efforts.
It is also necessary to support previous navigation techniques (OBN, Absolute Navigation, Call Transaction, etc.) in Fiori Launchpad, and transparently convert them into IBN, providing such qualifiers as bookmarkability, readability, stability, and deep linking of URLs, ensuring that the target application keeps running in FLP.
Symptoms
- You use one of Classic UIs as WebDynpro, WebGUI, or WebClient UI and open ex-place windows
- Some windows are open ex-place without FLP frame around
- Central Logout does not work for all windows
- Some objects stay locked even if all windows are closed
- In the WebDynpro application, you navigate back and get an error from the browser with the following text "This webpage requires data that you entered earlier to be properly displayed. You can send this data again, but by doing so you will repeat any action this page previously performed" instead of seeing the previous screen.
The solution
The method provided below provides an easy way to automatically translate legacy navigation calls into IBN without or with minimal code changes.
Supported targets
The technique described below supports only the following legacy navigation targets
- WebDynpro
- Dynpro (SAP GUI Transaction)
If a target is something different, for example, a URL, the navigation call will not be translated but will go as before: in-place without changing FLP URL, ex-place - leaving the FLP frame.
Supported Navigations
- Absolute Navigation (WebDynpro). No code modification is necessary.
- Object-Based Navigation (WebDynpro). No code modification is necessary.
- Resolving mode SourceRole is not supported, while in FLP no information about the current role is available. Therefore the OBN resolution logic will not give priority to targets from the current role if .ambiguous matches from different roles are found.
- ABAP Report Launchpad-based navigation == LPD_CUST (WebDynpro). No code modification is necessary.
- Navigation using IF_LSAPI == CL_LSAPI_MANAGER (WebDynpro, Dynpro). No code modification is necessary.
- CALL TRANSACTION. To be replaced by CL_LSAPI_MANAGER=>NAVIGATE_TO_TRANSACTION (Dynpro)
How to enable (ABAP FLP)
To get the solution working you will need to fulfill several requirements:
- Upgrade your backend to SAP_UI 7.54.
- Enabling generic intents for your backend system by creating Target Mappings
- Shell-startGUI
- Shell-startWDA
- Defining additional system alias mapping in sid notation for the backend system on the front-end server system
- Setting the backend system flag that activates translation of navigation.
And now, more details about each step.
Generic intents for Classical UIs
The pre-requisite for enabling the automatic translation of the legacy navigation calls into IBN is the availability (assignment) of generic intents for starting any WebDynpro Application and GUI Transaction for the specific backend.
Assignment of the generic intent to a user would give him the potential ability to
call any GUI Transaction / WebDynpro in the backend, but, of course, standard start authorization would still be executed, and
if the user does not have permission to start the app it would break. So, from the security perspective - everything is ok.
Target Mappings (TM) with generic intents are not pre-delivered with SAP Technical catalogs and shall be explicitly created/assigned on the customer side since TMs refer to explicit systems using system aliases in sid notation, and such names are specific for each system landscape. You can use any business catalog for this - the important thing it shall be assigned to all your users.
The creation of its own target mappings and catalogs is enabled only for S/4 on-premise, but not for S/4 Cloud. So, the way to use generic intents on S/4 Cloud is not yet clear.
HUB scenario: enable the generic start of Classic UI apps for any backend
Any transaction on any connected backend
Any WebDynpro Application on any connected backend
HUB scenario: enable the generic start of Classic UI apps for a specific backend system
Any transaction on system URZ client 120
Any WebDynpro Application on system URZ client 120
Co-deployed scenario: enable the generic start of Classic UI apps
Any transaction on the Front-end system (backend and frontend is co-deployed)
Any WebDynpro Application on the Front-end system (backend and frontend are co-deployed)
How to enable generic intents globally
With modern ABAP FLP versions, it is possible to enable generic intents globally, for all users and all backends without using TargetMappings, catalogs, and roles.
You can enable them in FLP settings using the following flags:
- NAVIGATION_BY_TCODE: globally allows the use of Shell-startGUI generic intent, which can be used to start any GUI transaction from the connected backends. Available from SAP_UI 7.56 for ABAP Frontend server, S/4 Hana Cloud 2105. S/4 Hana OP 2021 FPS0. Deprecated since SAP_UI 7.57 - switch to be on by default. OBSOLETE from 2508
- NAVIGATION_BY_WDA_APPID: globally enables the use of Shell-startWDA generic intent, that can be used to start any WebDnypro application from the connected backends. Available from SAP_UI 7.56 SP01 for ABAP Frontend server, S/4 Hana Cloud 2202. S/4 Hana OP 2021 FPS1. Deprecated since SAP_UI 7.57 - switch to be on by default. OBSOLETE from 2508
Settings can get changed in transaction /UI2/FLP_CUS_CONF => Launchpad configuration
Compatibility Mode for WebDynpro applications
To have the setup working properly for WebDynpro Application it is mandatory to configure the running of the WDA in
Direct, but not
Compatible mode.
Compatible means: surround the WDA with invisible SAP NWBC for HTML frame to ensure that all legacy WDA services are working properly. At the same time, such a Compatible Mode breaks an ability to communicate with FLP, and so the conversion of the legacy to IBN does not work.
You can configure the WebDynpro application to run in Direct mode only in Fiori Application Manager (transaction
MM_APP), the setting is "
WDA Apps Integration Mode". If the mode is not configured explicitly, the default is "System Default" ("Direct" on modern systems and "Compatible" on old ones).
If your apps for some reason can not run in Direct mode, there is an additional flag that can be used to change the default for navigation in WDA and which can be used for triggering the Compatibility mode for targets defined in Fiori Launchpad Designer (FLPD) and for generic intents (Shell-startWDA): the flag
NAVIGATION_WDA_COMPATIBILITYMODE from
FLP Settings.
OBSOLETE from 2508
Definition of the system alias in sid notation for the specific backend
When legacy navigation shall happen locally, on the same backend, the way to express it in IBN is to add a sap-system parameter pointing to the same system. For example sap-system=URZCLNT120. But there is an issue, the IBN call is constructed on the ABAP side, where it is not known how the backend system is named by FLP. The solution here is to pass the name yourself in the alternative form, using a sid notation (system ID + client): sap-system=sid(URZ.120), while this information is available. This requires that the FLP understand the alternative name of the backend system expressed in sid notation. In most cases, when the backend system was added using the task list, the aliasing of the destination using the sid name shall be already available in table /UI2/V_ALIASMAP. Still, if not, it shall be maintained as shown below:
Such a configuration is only necessary with hub or federated deployment if the backend system is different from the front-end server. The alias mapping shall be configured in the front-end server /UI2/V_ALIASMAP.
More information about configuring the system destinations in the ABAP world can be found in
Configuring Remote Systems in SM59.
Configuring using a task list
There is an easier way to connect the backend system to the front-end server using the task list SAP_GATEWAY_ADD_SYSTEM_ALIAS.
Optimizations with the latest SAP_UI releases
If you run modern ABAP FLP against modern backend ( > SAP_UI 7.56) the system can automatically detect the current system alias (FLP sends it to the backend) and therefore does not need an additional definition of system alias in sid notation. So, you can potentially skip this definition. But you still need aliases in sid notation for Enterprise Search, so I recommend defining it.
Backend configuration of Legacy to IBN auto transition
There are two ways to enable the automatic translation of absolute navigation into IBN: global and user-specific. Both ways shall be done on the backend system (not on the front-end system) and work only for this particular system when legacy navigation is triggered by an app located on this system.
- Global for system: Transaction SM30 => /UI2/NWBC_CFGCV => ParameterName = MAP_LEGACY_TO_IBN; ParameterValue = "X".
- For specific user: Transaction SU52 => User parameter => MAP_LEGACY_TO_IBN = "X"
The default for the setting is:
- FLP Version < 1.102 -> FALSE
- FLP Version >= 1.102 -> TRUE
cFLP (SAP Cloud Platform Launchpad)
It shall now be possible to enable
legacy to IBN conversion for cFLP also. The steps and requirements are similar:
Federated content (replicated using content providers)
- Connected frontend servers shall be at least on SAP_UI 7.56, S/4 Hana Cloud 2105, and S/4 Hana OP 2021 FPS0.
- Backends exposed by content providers shall be at least on SAP_UI 7.54.
- To enable generic intents for each of the content providers respective FLP FrontEnd servers shall expose them in CDM export. This can be enabled in transaction /UI2/FLP_CUS_CONF => Launchpad configuration with a parameter EXPOSURE_SUPPORT_LSAPI_TO_IBN_NAV.
- Defining additional system alias mapping in sid notation for the content provider can be done using the function Map Aliases in Site Manager -> Provider Manager:
- Setting the backend system flag that activates the navigation translation shall be done in the same way as described for ABAP FLP.
Local content (apps defined in cFLP manually)
- Backends connected to the cFLP with HTTP destinations shall be at least on SAP_UI 7.54.
- There is no way to define global generic intents (e.g. matching all targets) for all your apps and backends - you will need to define a separate intent (business app) for each possible target. E.g. if you need to start WebDynpro Application ABC with configuration BCD you will need to define a new Business App of Type WebDynpro with semantic object Shell and action startWDA, add the required parameter sap-ui2-wd-app-id = ABC (Name -> sap-ui2-wd-app-id, Filter Value -> ABC), and the required parameter sap-ui2-wd-conf-id=BCD for that backend system.
- Defining additional system alias mapping in sid notation for the local content can be done using the function Alias Mapping in Site Manager -> Settings:
- Setting the backend system flag that activates the navigation translation shall be done in the same way as described for ABAP FLP.
FAQ
How to enable the automatic translation of legacy to IBN on the customer side?
There is no automatic way for now. You need to instruct customers on how to create corresponding TM and assign them to users and how to switch the mode in /UI2/NWBC_CFGCV on each backend. Here is a
central consulting note describing that.