Introduction

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.

For example:

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

Supported Shells

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:Index page and navigation menu links, exposing the application to remote systemsOBN targetsQuick launch, collecting links from the navigation menu	Same as for NWBC for Desktop	Remote targets used:When navigating with tiles that point to Web GUI/ Web Dynpro applications defined in ABAP Report Launchpad (LPD_CUST)When passing Data Origin for SAP Fiori applications via sap-system parameter

Use-Cases

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.

Naming Convention

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 to connection types G and H.
• _HTTPS (XYZ_HTTPS) – to define HTTPS connection settings. It can be applied to 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 a 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 an extension.

NOTE

Destination names in SM59, and tools using SM59 aliases, are case-sensitive. The recommended way is to use UPPER case names and to type suffixes in all consumption points. Also, though there are no warnings if you use any special characters or even spaces, it is strongly recommended to use only UPPER case letters, numbers, or underscores for names, while there are a lot of tools around SM59 that may be easily confused by your exotic names and it will lead to errors that very difficult to detect.The technical destination names NONE, LOCAL, SELF, etc. are resolved as the local system, that is, the application is located on the same system as the runtime. Please see F1 help for the name field to see other reserved names.

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:

1. Look up SM59 destinations with the explicit match, that is, with the system alias equal to string sid(SYSID.CLIENT).
2. If this is not found, parse sid string into System ID and Client
3. Search in SM59 for RFC destination associated with given SYSID with the specified client (or without, if not provided)
4. Detect base name of system alias from RFC destination name (use as is, or remove _RFC name extension)
5. 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.

Destination Type	Remarks
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.

Technical Settings (Load Balancing)	Technical Settings (Direct)
Settings for load balancing can be taken from the corresponding SAP Logon system connection. See below for more details.	Target Host can be taken from the SM51 host Instance No. can be taken from the SAP Logon connection definition. See below for more details.

Login & Security

Logon & Security (SNC)

Leave Language empty if you want to use the language from the calling application A generic user is not yet supported, so you cannot hard code a user and password here Ensure that the Client that you have defined in all connection types is the same. If the  Client is not specified, Client of calling Application will be added Set SSL to Active if you want to use Single Sign-On; you need to define SNC settings first.

SNC settings can be taken from the corresponding SAP Logon connection. Partners correspond to SNC name, QoP corresponds to security settings.

HTTP Connection Definition

Technical Settings	Logon & Security
HTTP host and port can be found in transaction SICF of the corresponding systemYou can use Path Prefix to define a fixed prefix path for ALL your web addresses. For example, if you work only with UI5: /sap/bc/ui5_ui5/, but in most cases, it shall be left empty.	Leave Language empty if you want to use the language of the calling applicationGeneric user is not yet supported, so you cannot hard code a user and password hereEnsure that the Client that you have defined in all connection types is the same. If the Client is not specified, the Client of calling application will be addedFor HTTP connection, SSL must be set to Inactive

HTTPS Connection Definition

Technical Settings

Logon & Security

HTTPS host and port can be found in transaction SICF of the corresponding system You can use Path Prefix to define a fixed prefix path for ALL your web addresses. For example, if you work only with UI5: /sap/bc/ui5_ui5/, but in most cases, it shall be left empty.

Leave Language empty if you want to use the language from the calling application Generic user is not yet supported, so you cannot hard code a user and password here Ensure that the Client that you have defined in all connection types is the same. If the Client is not specified, the Client of calling application will be added For HTTPS connection, SSL must be set to Active. Ensure that you have entered HTTPS Port in the Service No. field on the Technical Settings tab.

NOTE

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 the 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

SICF transaction	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.

SAP Logon System Settings (Connection)	SAP Logon System Settings (Network)

NWBC 5.0 System Selector	SM51 Server List

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, the client field shall be left empty). The 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 the 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).

NOTE

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):NWBC_DELETE_MENU_CACHE (when using any of SAP_BASIS delivered NetWeaver Business Client)/UI2/NWBC_DELETE_MENU_CACHE (when using UI Add-on delivered NetWeaver Business Client)/UI2/INVALIDATE_CLIENT_CACHES (when using Fiori Launchpad)/UI2/INVALIDATE_GLOBAL_CACHES (when using Fiori Launchpad)

Configuring “silent” system login

After properly maintaining the system aliases and verifying that navigation between your host and remote systems works, comes the 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 :wink:. But I will try to provide here some information, which may help and lead you in the right direction.

HTTP connection

If the user navigates to a Web-based application, it is enough if there is an 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 is installed – a manual login procedure is required (and browser shall be configured to always show client certificate popup).

RFC connection

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

In the end, there shall be also a trusted relationship between both servers established and that can be done in different ways, as described here (using transactions SSO2 or STRUST).

Mixed Content

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 the remote system integrated addressed by HTTP URL. The message would come if one of your apps refers to a resource from an HTTP destination, or the 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 an 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 starting 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.

Existing documentation

• 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

Requirements

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