The main driver around the Fiori Role & Authorization implementation approach is the system infrastructure. In this context, the strategy chosen to deploy the Fiori Front-end server (FES). For SAP Fiori deployment options and recommendations see following blog post Link.
As mentioned, the Role & Authorization implementation strategy follows the FES deployment strategy, - embedded or hub deployment.
Hub scenario
The FES hub deployment strategy requires one physical standalone FES and one or several Backend systems. The roles must be implemented accordantly. This implies that the roles and authorizations must be implemented in the frontend system and backend system(s).
In a hub scenario, the Front-end role contains the OData services of type IWSG where the Backend role contains the corresponding IWSV OData services. From a Fiori conceptional perspective it might be an advantage to assign Fiori catalogs to the role menu instead of assigning OData services or legacy functions directly to the role menu. This is especially valid when using report PRGN_CREATE_FIORI_BACKENDROLE to implement Backend roles. When using the report, the Front-end role must be implemented before implementing the Backend role (NOTE: 2533007). It is further recommended to have an 1:n relationship between Front-end and Backend role(s). The use of the report implies that the role menu of the Backend roles should not be enriched with additional functionality, e.g. manually added transaction codes. Only the “inherited” role menu entries from the Front-end role should be kept in the Backend role(s), since the report does not append the Backend role menu but replaces the role menu. Moreover, OData services should not be assigned directly to the Front-end role menu. Catalogs can be adapted via report PRGN_CREATE_FIORI_BACKENDROLE. By this the backend services and functions are correctly assigned to the Backend role menu (e.g. OData services are assigned as type IWSV). Directly assigned OData services to the Front-end role menu will not be replaced with the corresponding backend service.
Since a typical Gateway system does not contain Organizational Levels like the connected Backend system(s) the generated Backend roles via report PRGN_CREATE_FIORI_BACKENDROLE should be a corresponding parent role from where the child roles can be derived from. In other words, one direct inherited Backend role that again has several derived roles wherein the Organizational Levels can be maintained.
Embedded scenario
When choosing the FES embedded deployment strategy, the FES is deployed on the same system as the Backend. For the implementation of Roles & Authorization it means that the roles must only be implemented and maintained in one system. By this, the implementation and maintenance of roles and authorizations is less cumbersome, compare to the hub scenario. IWSG, IWSV services and legacy functions can be assigned to the same role. Still, also here it is advisable to use the advantage of catalogs instead of assigning OData service and legacy functions directly to the role menu.
As mentioned, the Role & Authorization implementation strategy follows the FES deployment strategy, - embedded or hub deployment.
Hub scenario
The FES hub deployment strategy requires one physical standalone FES and one or several Backend systems. The roles must be implemented accordantly. This implies that the roles and authorizations must be implemented in the frontend system and backend system(s).
In a hub scenario, the Front-end role contains the OData services of type IWSG where the Backend role contains the corresponding IWSV OData services. From a Fiori conceptional perspective it might be an advantage to assign Fiori catalogs to the role menu instead of assigning OData services or legacy functions directly to the role menu. This is especially valid when using report PRGN_CREATE_FIORI_BACKENDROLE to implement Backend roles. When using the report, the Front-end role must be implemented before implementing the Backend role (NOTE: 2533007). It is further recommended to have an 1:n relationship between Front-end and Backend role(s). The use of the report implies that the role menu of the Backend roles should not be enriched with additional functionality, e.g. manually added transaction codes. Only the “inherited” role menu entries from the Front-end role should be kept in the Backend role(s), since the report does not append the Backend role menu but replaces the role menu. Moreover, OData services should not be assigned directly to the Front-end role menu. Catalogs can be adapted via report PRGN_CREATE_FIORI_BACKENDROLE. By this the backend services and functions are correctly assigned to the Backend role menu (e.g. OData services are assigned as type IWSV). Directly assigned OData services to the Front-end role menu will not be replaced with the corresponding backend service.
Since a typical Gateway system does not contain Organizational Levels like the connected Backend system(s) the generated Backend roles via report PRGN_CREATE_FIORI_BACKENDROLE should be a corresponding parent role from where the child roles can be derived from. In other words, one direct inherited Backend role that again has several derived roles wherein the Organizational Levels can be maintained.
Embedded scenario
When choosing the FES embedded deployment strategy, the FES is deployed on the same system as the Backend. For the implementation of Roles & Authorization it means that the roles must only be implemented and maintained in one system. By this, the implementation and maintenance of roles and authorizations is less cumbersome, compare to the hub scenario. IWSG, IWSV services and legacy functions can be assigned to the same role. Still, also here it is advisable to use the advantage of catalogs instead of assigning OData service and legacy functions directly to the role menu.
- SAP Managed Tags:
5 Comments
