How to define a proper role concept for an adequate usage of enterprise search in Fiori Launchpad?

The central search slot in the shell of Fiori Launchpad or central Fiori Launchpad allows a search across business entities of connected application systems which are using HANA as database. The prerequisite is that the business entities are connected to SAP HANA enterprise search. Business entities are connected to enterprise search via enterprise search models. A search model embraces all information that is required to execute a successful search.

In SAP S/4 HANA all business entities are connected to enterprise search. The corresponding search models are delivered within the SAP S/4 HANA stack. In SAP S/4 HANA cloud the models are already activated in SAP S/4 HANA on premise the customer needs to activate the search model using the enterprise search cockpit (transaction code: ESH_SEARCH_COCKPIT).

Even though all entities in SAP S/4 HANA are connected to SAP HANA enterprise search, normally an end-user is not searching across all these entities because not all entities are relevant for the end-user. Therefore, in SAP S/4 HANA backends, appropriate backend roles need to be defined and to be assigned to the user to restrict the search to the relevant business entities.

These relevant business entities are listed in the search scope selection box. In the following picture these roles are not properly defined. Therefore, a long list of business entities is shown in the selection box:

Picture 1 – Selection box with too many business entities

The “All” item in the selection box refers to all listed business entities in the selection box and to all apps which are assigned to the frontend role of the end user.

That means if “All” is selected, the search is across all the listed business entities. If no adequate backend role is defined, the search is across a vast number of business entities. In this case the end user will not see all relevant search results because the search scope is not adequate. Also, the search will not run with an adequate performance and put too much unnecessary load on the HANA database. To avoid this, the roles in backend and frontend need to be defined properly.

In this document it is described what needs to be done to take all necessary actions to set up the search appropriately.

Another possibility to define an adequate search scope is the usage of “My Favorites.” In search settings, the user can define the business entities which are really relevant for him:

Picture 2 – Personalization of search: Define relevant business entities in “My Favorites”

The personalization of the search scope is not a replacement for adequate role definition.

Before these role definitions are described, a short overview of relevant search components helps to understand the necessary configurations.

Short overview of relevant components of SAP HANA enterprise search

Picture 3 – Overview of SAP HANA enterprise search components in the application stack

SAP HANA enterprise search is a powerful search solution across multiple business entities that provides free-style and advanced search, navigation, and access to business entities:

The sophisticated scoring algorithms include semantic algorithms for fuzzy search which are optimized for business entity search.

The handling of complex search models utilizes the powerful join capabilities of HANA.

The possibility to use the search in an “embedded mode.” That means data needs not to be replicated to create a search index. SAP HANA enterprise search is defined on top of entity views. S/4 uses SAP HANA enterprise search in an embedded mode.

Model driven approach: Applications only need to define search models to control the search behavior. A search model represents the search behavior of a business entity and is defined as an entity view with annotations. Furthermore, a search model contains all information to visualize the represented entities in a search result list. It utilizes the general SAP CDS annotations for visualizations.

Authorizations are part of the search model and are considered during the search HANA runtime. No separate authorization checks need to be performed.

SAP HANA enterprise search (SAP HANA es)

provides components for the different levels of the software stack enabling a seamless integration

all components are highly optimized for a harmonized for a simple search experience

SAP HANA es Core: generic search engine via built-in procedure with ODATA interface

SAP HANA es embedded Search Services: ODATA service calling the search engine taking into account application specific logic

SAP HANA es Search Models: embrace all information that is required in order to execute a successful search.

SAP HANA es UI: embedded into

SAP (Central) Fiori Launchpad as a central search access point for all applications

Understand the concepts for a proper role definition of enterprise search

Picture 4 – SAP S/4 HANA configuration

It is important to understand that for a proper usage of enterprise search, adequate roles need to be defined at the SAP FLP frontend and S/4 backend server.

In the following the underlying concepts are shortly explained:

In SAP S/4 HANA all business entities are connected to SAP HANA enterprise search. That means for all business entities a corresponding search model exists. In enterprise search a business entity is represented by the corresponding search model for this business entity.

What business entities (= search models) are visible for an end user is defined by adequate backend roles. In these roles corresponding authorization objects are referred which determines which business entities (i.e. Purchase Orders, Suppliers, Sites etc.) an end-user is generally allowed to search for.

Currently there are two classes of search models with respective specific authorization objects:

CDS-based Search Models
The most recent technology, based on search views defined in CDS language. These search models require the user to have corresponding entries in the auth object SDDLVIEW.

Table-based Search Models
The second-most recent technology, also based on views, but not defined via CDS language. These search models require entries in the auth object S_ESH_CONN.

CDS based Search Models:

The authorization object SDDLVIEW has 3 different fields: DDLNAME, DDLSRCNAME and ACTVT.

Field ACTVT represents the different activities like create, change or display. For search only the display activity (=03) is relevant. That means the value of this fields is always “03”.

Field DDLNAME is not used for enterprise search.

Only DDLSRCNAME allows to specify which enterprise search CDS views (= search models) are relevant for the user role. The name of the CDS views can be listed separated by “,”. The name of a CDS view can be found in the CDS view definition as a header annotation:

Picture 5 – SAP S/4 HANA backend configuration – identification of view name for role configuration

Also, another header annotation is crucial for the proper configuration of the backend: the “@Consumption.semanticObject” annotation. The value of the “@Consumption.semanticObject” header annotation specifies the “Semantic Object”. In our example the semantic object “PurchasingInfoRecord”:

Picture 5 – SAP S/4 HANA backend configuration – identification of Semantic Object

The semantic object links the enterprise search view for a business entity to various SAP Fiori Apps for this business entity. In the tile configuration of the SAP Fiori Apps Reference Library the association of apps to semantic objects are listed:

Picture 6 – SAP S/4 HANA frontend configuration – Association of Apps to Semantic Objects

One of the apps, linked via a semantic object to a search model, is a fact sheet. A fact sheet includes all information of a business entity object. Therefore, a fact sheet is also named “object page”.
In the target mapping of apps, a fact sheet can be identified by the action “displayFactSheet”:

Picture 7 – SAP S/4 HANA frontend configuration – Identification of Fact Sheets

In an enterprise search result list, the fact sheet/object page is the primary navigation target for a search result list item (see red box in picture 8):

Picture 8 – SAP S/4 HANA frontend configuration – Fact Sheets as primary navigation targets

Additional Remark:

As mentioned above, the value of the header annotation “@Consumption.semanticObject” links the enterprise search view for a business entity to various SAP Fiori Apps for this busines entity.

But “@Consumption.semanticObject” is used also as an element annotation. During search runtime, the values of the annotated fields …

Picture 10 – SAP S/4 HANA backend configuration – Field annotation for navigation targets

… determines the navigation targets for an enterprise search result list item. One of these navigation targets is marked as a primary navigation target with a parameter value “sap-tag” or “displayFactSheet”.

Fact sheets/object pages plays the crucial role in the role configuration because the underlying OData Service for a fact sheet …

Picture 11 – SAP S/4 HANA configuration – Special Role of the Fact Sheet OData Service

… contains the authorization checks via the authorization object SDDLVIEW:

Picture 12 – SAP S/4 HANA configuration – Authorization Check in Fact Sheet OData Service

Now we have all concepts together to explain how the role definition should be handled.

Proper role definition of enterprise search in 3 steps

FLP Frontend Server: First of all, the customer must determine which catalogs are relevant for a certain frontend PFCG role—adding the relevant catalogs to the PFCG role. A catalog consists of various apps. Apps are assigned to semantic objects (see picture 6). That means the app collection in the PFCG role corresponds to a collection of semantic objects. Now the customer needs to make sure that the defined PFCG role includes a fact sheet app/object page for each semantic object (see picture 7). Details can be found in the standard documentation

S/4 Backend Server: Now the created frontend role in (1) is used as a template to create an adequate backend role.

Only the backend role determines the adequate scope of business entities (see picture 1). For this purpose, the report PRGN_CREATE_FIORI_BACKENDROLES is used (see SAP Note 2533007 ):

Picture 13 – SAP S/4 HANA configuration – Create adequate backend roles based on frontend roles

In the example in picture 13 the frontend role SAP_BR_PURCHASER is used to create a backend role Z_PURCHASER.

If the authorizations of the ODATA fact sheet services included in SAP_BR_PURCHASER are properly maintained, the definition of the backend role would be completed. Nevertheless, it should be checked if the created backend role does not contain any authorization check via SDDLVIEW with an empty value or a “*” value for the field DDLSRCNAME like in the following example (using transaction PFCG/Authorization):

Picture 14 – SAP S/4 HANA configuration – Check created backend role for errors

Any authorization checks with an empty or a “*” value for the field DDLSRCNAME would lead to the situation that the user would search across all entities in a S/4 system (see picture 1).
Therefore either the corresponding check needs to be deleted or an name of a CDS view needs to be entered in DDLSRCNAME. The authorizations need to be generated afterwards.

SAP S/4 HANA Backend Server: The backend role, which was defined in step (2), needs to be assigned to the corresponding users.

Now it needs to be guaranteed that the user has no other role assignment which contains SDDLVIEW based authorization checks with an empty or a “*” value in DDLSRCNAME.
If this is the case either the corresponding role needs to be removed from the user’s profile or it must be adapted correspondingly (see (2)).

Remark:

This paper has described how to define a proper role concept for an adequate usage of enterprise search in Fiori Launchpad. The focus was on CDS based models, the newest generation of enterprise search models. Nevertheless, most search models in use at the customer side are table-based search models. The configuration of roles is completely identical. The only difference is the usage of another authorization object. Instead of using SDDLVIEW the S_ESH_CONN is used. That means in the OData services for factsheets (see picture 12), the S_ESH_CONN is used instead SDDLVIEW. Instead, a name of an enterprise search view in the field DDLSRCNAME of SDDLVIEW, the name of a table-based model in the field TEMP_NAME is referred (e.g., PURCHASE_INFO_REC_H) and the value “COMRUNTIME” for TEMPL_TYPE.

Feedbacks are welcomed!