Configuring a Hub Deployment (Appendix)

SAP systems can establish trusted relationships with each other. If a calling (sending) SAP system is known to the called (receiving) system as a trusted system and the user who issued the RFC call is defined in both of the systems, no password is supplied. The calling SAP system must be registered with the called SAP system as a trusted system. The called system is the trusting system.

Trusted relationships among various SAP systems have the following advantages:

• Single Sign-On (SSO) is possible beyond system boundaries.

• No passwords are transmitted in the network.

• The timeout mechanism protects against replay attacks.

• User-specific logon data is checked in the trusting system.

The trusted relationship is not mutual, which means that this relationship is applicable in one direction only. To establish a mutually trusted relationship between two partner systems, you must define each of the two trusted systems in the corresponding partner systems.

To communicate with BES, the FES uses an alias for BES and interacts with BES using a trusted RFC connection. In the BES, you must create an RFC destination to the SAP Gateway system on your FES and define the trust relationship between the BES (to be the trusting system) and the FES system (to be the trusted system).

This direction is relevant in a development system, where developers are creating SAP Gateway services in the BES, which should be registered in the FES.

Another use case for this direction are notifications – created in the BES system and sent to the FES system via trusted RFC.

To enable the trusted systems to operate properly, the systems must have the same security level requirements and user administration. Before you can define a trusted system, you must create a destination for this system in the trusting system. To do so, use transaction SMT1, or choose Extras→Trusted systems on the RFC destination overview screen (transaction SM59). In the trusted systems, destinations for trusting systems are automatically created. These destinations are used when you display trusting systems through Extras→Trusting systems (transaction SMT2).

The user using the trusted RFC must have the corresponding authorizations in the trusting system (the S_RFCACL authorization object). In addition, you can configure the system to perform an authorization check on the transaction code from the calling system. To do this, you need to choose the Use transaction code option on the trusted system entry in transaction SMT1. When you choose this option, an authorization check is performed in the called system for the transaction code (the RFC_TCODE field of the S_RFCACL authorization object). You can check the authorizations for the logged-on users in the trusting system in advance by using the AUTHORITY_CHECK_TRUSTED_SYSTEM function module.

Alternatively, run task list SAP_SAP2GATEWAY_TRUSTED_CONFIG to set up a trusted relation.

An SAP system alias is needed as the logical name of a system connection, that is, you specify the location to which the SAP system alias should point. Depending on the SAP Gateway content scenario and your system landscape, you set up the system alias.

In a central hub deployment, the following system aliases (all maintained in the front-end server (FES) system) are of interest:

• LOCAL for the FLP and FLPD
• LOCAL_TGW for workflow apps accessing the FES system
• <BES> for typical apps accessing the BES system
• <BES>_TGW for workflow apps accessing the BES system

As system aliases can be transported, it is not recommended to use the <SID> of a BES system as part of the alias name.

The figure, System Alias Maintenance, shows the content of maintenance view /IWFND/V_DFSYAL exemplary.

For the SAP Fiori system landscape, you need one system alias pointing to the FES with the indicator Local GW selected. If you use workflow in a FES, you need an additional system alias for task processing within the workflows used in this FES (name ending with _TGW).

For each BES client that you want to use, you need at least one system alias with the software version DEFAULT. If you use workflow in a BES, you need an additional system alias for task processing within the workflows used in this BES (name ending with _TGW).

When users want to search for data in the SAP Fiori launchpad, the SAP Fiori search accesses the SAP HANA enterprise search. The protocol used for direct network communication is the SAP proprietary Information Access (InA) protocol, which has some parallels to OData but is specialized for search requests and responses. With SAP S/4HANA 1809, it is also possible to use the SAP Gateway service ESH_SEARCH_SRV instead. So, both InA and OData are suitable ways to access the SAP HANA enterprise search depending on the network landscape.

You can also set SAP Web Dispatcher in front of multiple SAP and non-SAP Web Servers. SAP Web Dispatcher then serves as the entry point for these systems and performs the following tasks:

• SAP Web Dispatcher identifies the system the request was destined for from the URL.

• SAP Web Dispatcher then performs load balancing for this system.

You do not have to set up, configure, and wait for an SAP Web Dispatcher for each system; you use a common SAP Web Dispatcher for all systems. This must then be configured for all connected systems.

For object pages, a connection is established between the ABAP back-end server and SAP Web Dispatcher. You define the routing rules to the required target system to ensure that requests are directed to the correct server.

For the connection between the ABAP back-end server and SAP Web Dispatcher, you need the following routing rules: Dispatch all requests starting with /sap/es to the BES.

SAP Web Dispatcher can be put in front of one or multiple back-end systems. Only one SAP Web Dispatcher has to be configured and maintained. The SAP Web Dispatcher identifies the back-end system the request was destined for from the URL. SAP Web Dispatcher is configured with the wdisp/system_<xx> profile parameter.