Assigning Multiple Back-End Systems Support
Multiple Back-End Systems Support
SAP Gateway can support multiple back-end systems. In this case, the same service implementation is deployed in several back-end systems using the same technical name. The service is only published once on the hub, but several back-end systems are assigned to the published service.
Multiple back-end systems support is useful in the following scenarios:
- A company that runs several Business Suite Systems in various regions
- An environment in which one central service shows customer data from several ERP back-end systems in one list instead of having multiple services.
Routing and Multi-Origin Composition
Multiple back-end systems support is useful for routing (getting data from a specific back-end system) and multi-origin composition (getting data from multiple back-end systems).
In the following scenarios, routing is required:
- US employees need to retrieve data about US customers only.
- EMEA employees need to retrieve data about EMEA customers only.
- APJ employees need to retrieve data about APJ customers only.
In the following scenarios, the multi-origin composition is required:
- A CFO needs to retrieve customer data from all regions.
- A manager needs to retrieve data from multiple back-end systems.
In the following scenario, both routing and multi origin composition are required:
- A manager responsible for APJ and EMEA needs to retrieve data from APJ and EMEA customers, but not from American customers.
System Alias
A system alias is a wrapper around the RFC_Destination that points to a back-end system of an SAP Gateway Hub. It contains additional information related to the routing of requests and the location of the service implementation (MPC and DPC classes). The system alias is created in the Gateway Hub system.
The maintenance of system alias entries is done in customizing for SAP Gateway in
Gateway → OData Channel → Configuration → Connection Settings → SAP NetWeaver → SAP Gateway → Manage SAP System Alias (transaction SPRO).
System Alias Properties
In the SAP System Alias field, specify a meaningful logical name, such as ERP_EMEA or SRM. In the description field, an additional description can be maintained. The flags Local GW and Local App must be set based on the deployment scenario that has been chosen or the back-end system.
The RFC Destination field should contain the name of the RFC destination that points to the back-end system. The Software Version field usually contains the value Default. In specific scenarios where services have been generated using the Service Builder, a specific software version must be specified to reflect changes in the generated coding. For example, the generation of services based on SPI objects.
Although maintaining the SystemID and Client fields is not mandatory, it is strongly recommended that you complete those fields, as the system ID and client are used to retrieve the list of system aliases a developer can choose from when registering the service on the hub from within SEGW.
You are not required to maintain the WS provider system field. This information was only applicable to some deprecated integration scenarios.
Deployment Options Recap
As mentioned, the settings for the flags Local GW and For Local App depend on the deployment scenario chosen for the back-end system that the system alias points to. To recap, here are the various available deployment options:
- Central hub deployment — The most used and recommended deployment option for SAP Fiori scenarios with SAP Business Suite back-end systems is central hub deployment, where the service implementation resides on the SAP back-end system.