Fiori app with multiple backend systems
In the following example, I will try to explain how you can connect a Fiori app with multiple backend systems using User Roles with System Aliases in SAP Gateway.
Prerequisites: you have created RFC destinations and System Aliases for backend systems.
As mentioned in the above link, you can assign multiple SAP system aliases to an oData service and also have specific roles assigned to them using transaction /IWFND/MAINT_SERVICE.
In the below screenshot you can see that I have assigned 4 system aliases with different roles assigned to the service of the “Approve Purchase Orders” Fiori app.
- If the system alias do not have a user role assigned, then all users will have access to this system through the Fiori app.
- If the system alias has a user role assigned, then only the users that have this role will have access to this system through the Fiori app.
Let me try to give an example:
– First you create a blank role for each backend system in SAP Gateway (transaction PFCG).
– Then, when you add a system alias to a service, you define also the role for this (transaction /IWFND/MAINT_SERVICE).
– Now the behavior of the app depends on the roles assigned to a user:
User having none of the above roles
App will have access to system ALIAS_SYSTEM_3
User having role Z_ROLE_SYSTEM_1
App will have access to systems
ALIAS_SYSTEM_1 and ALIAS_SYSTEM_3
|User having roles Z_ROLE_SYSTEM_1 and Z_ROLE_SYSTEM_2||
App will have access to systems
ALIAS_SYSTEM_1, ALIAS_SYSTEM_2 and ALIAS_SYSTEM_3
*** ATTENTION ***
SAP Gateway caches the metadata of the service. Because you have one service for the system aliases, you may experience unexpected behavior in case you have extended the oData in one system and not in the others. See the problem here: One quite haunted Gateway cache issue
In system A you extended the Fiori app oData entity through the available BADIs and added some fields.
In system B you use the standard functionality without any modifications.
In Gateway you have the standard Fiori app and you also extended it to a Z_APP to include the additional fields of system A.
– User A accesses the Z_APP with the additional fields in Launchpad through system alias pointing to system A.
– User B accesses the standard app in Launchpad through system alias pointing to system B.
Gateway behavior: Metadata cache is cleared manually or by the system eg. because you raised SP level of the app or the SAPUI5 libraries SP level.
- User A logs on first, Gateway caches the metadata of the service from system A (standard structure + the additional fields). App works fine.
- User B logs on second, Gateway has already cached the metadata and do not get them from system B. App works fine because the standard structure is there.
- User B logs on first, Gateway caches the metadata of the service from system B (only standard structure exists). App works fine.
- User A logs on second, Gateway has already cached the metadata and do not get them from system A. App NOT working because it can’t find the additional fields in the cached metadata.
Caching of metadata based on the system-alias information can be used in the SAP NW Gateway 2.0 SP08 and higher.