There are business scenarios in which the application needs to jump from one system to another, or the application requires information from a remote system.
- an application wants to call a transaction from a remote system
- an application wants to navigate to a Web Dynpro application that is located on a remote system
- an application wants to execute an Object-Based Navigation (OBN) or intent-based navigation (IBN) targeting a remote system
- an application needs to read data from a remote system
- an application wants to generate a URL that would be available outside the corporate network and needs to point to a Web dispatcher
- an application wants to call an OData service from a remote system
In most cases, when there is a need to communicate or navigate to a remote system, the application can use RFC destination names, defined in SM59 as ABAP Connection (Connection type 3). However, in some cases, the information provided in the RFC destination is not enough to resolve a request (for example, the application wants to navigate to a Web Dynpro application using HTTPS), and runtime additionally requires the HTTP destination for the remote system.
The following article covers only ABAP-based use-cases and is targeted at application developers and system administrators working with NetWeaver Business Client (NWBC) and Fiori Launchpad.
The resolution of the remote system configuration and the processing of cross-app (cross-system) navigation is handled by the shell that hosts the application.
The following shells need remote system configurations and must be able to handle cross-system navigation:
|NWBC for Desktop||NWBC for HTML||Fiori Launchpad|
Remote targets used in:
Same as for NWBC for Desktop
Remote targets used:
To refer to remote systems, you can use the SM59 name (RFC Destination Name) or System Alias – the normalized/base form of the SM59 Destination Name(see below).
There are several places and services in which the System Alias can be used, as described in the following list:
- Transaction PFCG. The attribute, Target System, of the navigation menu entry. This indicates that the application shall be called by the remote system that is specified by the System Alias.
- Transaction LPD_CUST. The mandatory parameter, System Alias, in the Change Launchpad Role screen. The application shall call the remote system that is specified by the System Alias. The System Alias can be resolved by the ABAP runtime (NWBC) or by Portal runtime.
- Fiori Launchpad Designer. System alias can be used in a configuration of the Target Mappings in Fiori Launchpad Designer, for such application types as Transaction, URL or WebDynpro, to define application and data origin (SAP Fiori App using LPD_CUST allows a definition of system alias in LPD_CUST, see case above). The system alias can be entered in dedicated field System Alias or as default parameter sap-system in Parameters section (passing of the alias using sap-system parameter has priority over definition in the dedicated field).
- As a dynamic parameter, SYSTEM, when navigating by OBN (PFCG-based) or resolving the Report Launchpad (LPD_CUST) link. Passed as a URL parameter that overwrites customized values defined in LPD_CUST or in PFCG ( …?sap-client=001&sap-language=EN&SYSTEM=ERP1 ).
- As a dynamic parameter, sap-system, passed within intent (intent-based navigation in Fiori Launchpad -> … #SalesOrder-display? sap-system=ERP1). The parameter overwrites the System Alias parameter defined in LPD_CUST.
- As a parameter for System Alias Repository API web service implemented for NWBC 5.0.
SM59 does not allow you to create several destinations with the same name even if the connection types are different. The trick for referencing several destinations by the same name is to have multiple SM59 entries with the same base name and an extension (_RFC, _HTTP, _HTTPS) attached to it to distinguish between the different types of connections.
For example, if the system name is XYZ, the different destination names should be the following:
- SM59 name-resolving sequence for SAP GUI aliases: XYZ_RFC, XYZ
- SM59 name-resolving sequence for HTTP aliases: XYZ_HTTPS, XYZ_HTTP, XYZ
Using this approach, it is possible to reference multiple connections if passing the base name only. Using the example above, it would be XYZ. The following name extensions (suffixes) can be used:
- _HTTP (XYZ_HTTP) – to define HTTP connection settings. It can be applied for connection types G and H.
- _HTTPS (XYZ_HTTPS) – to define HTTPS connection settings. It can be applied for connection types G and H.
- _RFC (XYZ_RFC) – to define RFC / SAP GUI connections. It can be used for connection type 3.
- _BOE (XYZ_BOE) – to define additional HTTP connection when used ABAP Launchpad Crystal Reports links. It can be defined as the connection of types G and H.
For connection types RFC (3) and HTTP (H, G), the name extension can be omitted (base name equal to SM59 destination name) and the runtime will still resolve the connection data properly. This fallback allows you to reuse existing definitions without extra configuration. Be aware, if you have a destination of type H/G with name equal to the base name, it will be picked for all HTTP based connections (_HTTP, _HTTPS, and _BOE). Of course, you can still overwrite fallbacks with an explicitly defined destination with extension.
Destination names in SM59, and in tools using SM59 aliases, are case-sensitive. The recommended way is to use UPPER case names and to type suffixes in all consumption points.
The technical destination names NONE, LOCAL, etc. are resolved as the local system, that is, the application is located on the same system as the runtime.
Referencing by System ID and Client
From UI Add-On SP09 onwards, it is also possible to reference a system not only by logical aliasing but also by system ID and client. The use-case could be the generation of the callback location by the service called remotely: the remote server does not know the name of his system used by the caller, and can only provide its own system ID and client.
If referencing by system ID is required, the following syntax must be used:
sid(SYSTEMID[.CLIENT]) for example : sid(U00.111) or sid(U00)
More information about the notation and usage can be found in respective Gateway Documentation (authors of the idea).
The syntax is case-sensitive. sid definitions may be used in the following cases:
- PFCG -> Target System field
- LPD_CUST -> System Alias field
- SYSTEM -> URL parameter for OBN/LPD_CUST link resolving (… ?SYSTEM=sid(U00.111)…)
- sap-system -> intent parameter in Fiori Launchpad ( …#SalesOrder-display?sap-system=sid(U00.111)…)
The system-resolving logic is as follows:
- Look up SM59 destinations with the explicit match, that is, with the system alias equal to string sid(SYSID.CLIENT).
- If this is not found, parse sid string into System ID and Client
- Search in SM59 for RFC destination associated with given SYSID with the specified client (or without, if not provided)
- Detect base name of system alias from RFC destination name (use as is, or remove _RFC name extension)
- Collect system data using system alias
To enable the SM59 destination to be searchable by SID + client notation, the Load Balancing setting of the corresponding RFC destination must be set to Yes, and the target system settings must be properly maintained.
Because the repository (SM59) can have more than one destination pointing to the same SYSID + client, the first matching value is returned.
Which Connection Types to Maintain?
Different SM59 destination types are used for supporting different application technologies. It is recommended to always maintain all 3 connection types (_RFC, _HTTP, _HTTPS) even if you do not need them currently. This ensures a stable resolution even if your application technology should change in the future.
|RFC (3)||Necessary for supporting navigation using RFC protocol or native application embedding. If you would like to use the native SAP GUI, the _RFC connection must be maintained.|
|HTTP (H)||Necessary for supporting HTTP-based communication, e.g. all Web-browser-based application technologies such as Web Dynpro, SAP UI5, BSP, Portal, etc. If you want to use one of the mentioned app technologies, the _HTTP connection must be defined.|
|HTTPS (H)||Necessary for supporting secure HTTP communication. The requirements are as for HTTP.|
RFC Connection Definition
When maintaining the RFC connection, you can either select Load Balancing or provide direct settings (= Load Balancing OFF + Target Host address). Having Load Balancing switched off in the RFC connection definition ensures that your connection can be used for all versions of NWBC for Desktop and all versions of the NWBC server runtime. If you want to implement load balancing using the RFC connection setting, you need to run NWBC 5.0 together with the server runtime for SAP NetWeaver User Interface Services on User Interface Add-On 1.0 for SAP NetWeaver SPS 09 or SAP NetWeaver 7.4 with software component SAP_UI SPS08.
Referencing by System ID and Client is only supported if RFC Load Balancing is enabled.
HTTP Connection Definition
HTTPS Connection Definition
|If you maintain backend server destinations for Fiori Launchpad DO NOT fill Path Prefix (leave it empty). It will lead to an error when trying to access WebDynpro Applications or WebGUI transactions, while the NWBC URL would be formed using Path Prefix instead of default NWBC handler path. NWBC for HTML used for starting non SAP UI5 applications on backend systems.|
How to Find System Settings
HTTP Hosts and Ports
- In the remote system, call transaction SICF -> F8
- On the application toolbar, press the button Host and Port Information
RFC Load-Balancing Data
Data for configuring the RFC destination can be found in the properties of the corresponding connection defined in SAP Logon (or in NWBC 5.0 System Selector):
- Load-balancing settings can be found on the Connection tab of the SAP Logon connection
- SSO settings can be found on the Network tab.
System Alias not Resolved?
If runtime is unable to determine the system configuration provided by the system alias, it will use the local system (relative path to the application) and will pass the unresolved system alias parameter (SYSTEM or sap-system) for further processing by the application. If a system alias that is dynamically passed (as a URL or Intent hash parameter) is resolved, the URL/Intent parameter is deleted from the parameter list and is not forwarded to the application.
If the application refers to a remote target using System Alias, it normally tries to point to the origin of the target. There are two types of origin:
- Data Origin: Points to the location of data used/consumed by the target application, and indicates the location from where the data shall be loaded. For SAP UI5 applications, this will be a backend system implementing OData services.
- Application Origin: Points to the location of the application sources, and indicates the location from where the application itself shall be loaded. For SAP UI5 applications, it is the front-end server.
The Application Origin may be the same as the Data Origin; examples of this are SAP GUI and Web Dynpro applications. For SAP UI5 applications, the SAP GUI, Web Dynpro, or URL system alias that is passed for resolution with the sap-system parameter is treated as Data Origin in all cases. It should not be used for any other purpose. It is not yet possible to explicitly pass the application origin. Instead, the Fiori Launchpad resolves the Application Origin based on the most likely default:
- SAP UI5 application: FLP origin (front-end server) is assumed to also be the application origin.
- SAP GUI, Web Dynpro, and URL: System Alias(data origin) is assumed to also be the application origin.
System Alias Mapping
In some cases, it makes sense to use indirection in system alias assignments and be able to redirect several system aliases to another one. There are several ways of how such system alias mapping can be done:
- PFCG If you assign system aliases to applications in PFCG, you can use database table SSM_RFC (can be called using dedicated maintenance view transaction SM30_SSM_RFC).SSM_RFC is client independent and you cannot configure any client dependent system alias mappings.
Recursive mappings are not supported.
The SSM_RFC table is available from “stone age”, so it can be used mostly on any SAP_BASIS release.
- ABAP Report Launchpad (LPD_CUST).From SAP_BASIS 730 you can configure system alias mapping in ABAP Report Launchpad. The mapping is Launchpad role/instance and client dependent. There is no way to globally remap system aliases for all Launchpad instances and you can only map system aliases used in selected Launchpad.
- Fiori and NWBC.With UI Add-on V2 there is new functionality available, that allows you to configure system alias mapping for all use cases running within UI2 NWBC (NetWeaver Business Client for UI Add-on) and Fiori Launchpad (PFCG, LPD_CUST, Fiori Launchpad Designer). The mapping can be defined in DB table /UI2/SYSALIASMAP (or using maintenance view /UI2/V_ALIASMAP in transaction SM30). The mapping allows you to define global or client dependent mapping (for global, client field shall be left empty). Client dependent definition has priority over the global definition.
- Fiori and Gateway. SAP Gateway also has a way to define system aliases and therefore maintain an indirection between the logical name used for navigation and real destination name, defined in SM59. The configuration of system aliases in GW can be accessed with a transaction /IWFND/ROUTING. More details can be found in Gateway Documentation: SAP Gateway Foundation => Creating an SAP System Alias.
Important: system aliases to be used in Fiori (FLP) environment shall be defined consistently in Gateway and NWBC way. E.g same aliases in /UI2/V_ALIASMAP view and in the transaction /IWFND/ROUTING, otherwise you can not achieve fluent navigation between SAP UI5 and Classical UI apps (GUI Transactions and WebDynpro).
|Please note, that not all system alias mappings are easily trackable by all frameworks and some settings may be cached and not revoked after changing of mappings. So it is recommended to run invalidation reports, after changes (transaction SE38):
Configuring “silent” system login
After properly maintaining the system aliases and verifying that navigation between your host and remote systems works, comes next question: how to configure the “silent” login of a user during navigation, without the need to enter the login and password.
And here I am not the best expert 😉 . But I will try to provide here some information, which may help and lead you in the right direction.
If the user navigates to a Web-based application, it is enough if there is established Single Sign-on and the user has a client certificate installed. Login to remote system performed by the browser using installed client certificates. If one wants to log in with a user for which no client certificate installed – a manual login procedure is required (and browser shall be configured to always show client certificate popup).
If the user navigates to a native application (SAP GUI for Windows), in addition to configuring Single Sign-on, an extra configuration is necessary.
First, it needs to use a client, supporting the transfer of the login data from the host system to a remote system, for example, NetWeaver Business Client (NWBC). Details about setting up authentication using NWBC can be found here: Authentication and Single Sign-On with NWBC.
Second, you need to set up your systems in such a way, that they allow the transfer of login data from a host system to a remote system.
If this is going about an ABAP-based landscape, details can be found here: Using Logon Tickets with AS ABAP.
Basically, the configuration consists of two parts:
- FOR HOST SYSTEM: Configuring ABAP server to issue login tickets, by setting profile parameter login/create_sso2_ticket = 2 (using transaction RZ10).
- FOR REMOTE SYSTEM: Configuring ABAP server to accept login tickets, by setting profile parameter login/accept_sso2_ticket= 1 (using transaction RZ10).
Sometimes you get a browser message: “This request has been blocked; the content must be served over HTTPS”. The issue here, you have started your main login (FLP, SAP BC) using HTTPS URL but remote system integrated addressed by HTTP URL. The message would come if one of your apps refer to resource from HTTP destination, or shell embeds the remote content using IFrame and connects to the remote system using HTTP.
The only way to get rid of the message, using HTTPS for every URL. E.g for all backend systems connected you need to maintain HTTPS connection also.
The only case, when you can work with mixed content without problems, is using SAP BC (NWBC for Desktop). SAP BC does not use framing for staring WebDynpro or GUI Transaction (when runs in NWBC Connection mode) and does not use framing when running in FLP Connection and starting GUI Transaction natively, in SAP GUI for Windows.
- Configuring remote systems to be used in NetWeaver Business Client (NWBC)
- Configuring of remote systems to be used in ABAP Report Launchpad (LPD_CUST)
Required SAP Notes
- 2318483 – Support of native SAP GUI transactions in Business Client 6.0 with Fiori Launchpad Connection
- 2313296 – Fix for ABAP Launchpad to ITS URL migration
- 2279202 – UI2: HTTP connection for system alias not found
- UI Add-On SP09 (support of sid format and load-balancing in NWBC 5.0)
- To integrate content from other systems by using the property Target System in PFCG, users need display authorization for SM59 in the back end. (NWBC 5.0)