1 Introduction
I recently needed to get a large number of Fiori apps up and running as part of an S/4 HANA 1511 on premise implementation. I quickly realised that Fiori Factsheets have a close dependency on Enterprise Search, which itself involved some challenges to set up. In this blog I’ve attempted to share everything that I learnt along the way, to demystify the topic for anyone with the same task in the future.
Also see related blog Fiori Factsheet Configuration on S/4 HANA 1511 FPS01.
2 Scope
This blog is based on implementing S/4 HANA on premise FPS01. Fiori is a fast-moving area and what is written here may not apply to other versions of S/4 HANA.
3 Enterprise Search Configuration
The full step-by-step process for configuring Enterprise Search can be found in the Fiori RDS Guides – document EE0 or MAA covers the prerequisite set-up. A more detailed explanation of Enterprise Search may be found in SAP Help. What follows are some additional tips…
3.1 Background
Originally, fuzzy and text search functionality in SAP Business Suite products was offered as a separate product ‘SAP NetWeaver Enterprise Search’ requiring a separate ‘TREX’ server. Data to be searched on would need to be replicated from Business Suite products to TREX where it could be indexed. Meanwhile more basic search functionality was included in Business Suite under the name ‘Embedded Search’.
From NetWeaver 7.40 (e.g. Suite on HANA edition) the search framework was migrated to HANA and renamed Enterprise Search. The functionality became an integral part of NetWeaver, and no additional license is required as long as the customer uses it for SAP standard applications. For Suite on HANA customers there is no longer any need to replicate data anywhere – search can be performed directly on the primary HANA database.
In S/4 HANA the search UI has been integrated directly into Fiori Launchpad, and has become an integral part of the user experience and the main way to access Factsheets.
3.2 Prerequisites
3.2.1 Web Dispatcher
Assuming a hub deployment of Fiori Front-End Server has been adopted, then being able to use the Fiori Launchpad Search is dependent on SAP Web Dispatcher (or some other reverse proxy) being in place and correctly configured. This Web Dispatcher configuration points the front-end Fiori Launchpad Search function to the correct backend system (and client) and its Enterprise Search. Even if there is only one possible backend system and Web Dispatcher has no other use, it is still required.
With Web Dispatcher in place and configured, it is important to then access the Fiori Launchpad through a URL for Web Dispatcher, rather than directly connecting to the front-end system. Whilst using the Fiori Launchpad the URL should be that for Web Dispatcher – e.g. it should not simply redirect to the URL of the front-end system.
SAP Note:
2227082 - Search fails in 'Fiori Launchpad' but is successful in 'Enterprise Search'
- describes how to verify if the Fiori Launchpad Search is connecting to the correct back-end system.
An exception to this is for an embedded deployment of Fiori Front-End Server. In this case Fiori, Gateway and the backend data are all in one system, and there is no need for a reverse proxy such as Web Dispatcher.
3.2.2 Switch Framework - Activating Embedded Search
This step is covered in both the EE0 and MAA documents, but just as a further reminder: Business Functions BSESH_HANA_SEARCH and BSCBN_HANA_NAV must be switched on in the switch framework (transaction SFW5).
Note that both Business Functions are reversible. It will not be possible to configure and use Enterprise Search without activating these switches. This is discussed further in SAP Note:
2093496 - Cannot create search connector for SAPAPPLH software component in ESH_COCKPIT
3.3 Client Dependent Set-up Tasks
3.3.1 Client 000
The RDS Guides EE0 and MAA describe set-up tasks to be completed in client 000, e.g. running task list SAP_ESH_INITIAL_SETUP_000_CLIENT. However as per SAP Note:
2183730 - ES: Improvements for model update from client 000
this step is no longer necessary from SAP Basis 7.40 SP13 onwards, or if the note is applied for earlier SP levels.
3.4.1 Working Client
The guides then describe tasks to be completed in the 'working client', such as running task list SAP_ESH_INITIAL_SETUP_WRK_CLIENT. Enterprise Search must be set-up and the Search Connectors created in the client where the data resides - this is what is meant by 'working client'. This point especially applies to development systems, where there may be separate clients for configuration and unit testing - in this case the unit test client is the working client, and so these set-up steps must be followed there, not in the configuration client.
Note that this task list involves selecting a software component and search connectors to create - these topics are explored in more detail below.
3.4 Creating Enterprise Search Connectors
3.4.1 Terminology
A Search Model defines how a search should work for a particular business entity. For example what is the primary table that holds instances of the entity; what other tables or objects should be considered, such as text tables or SAPScript texts, and what fields from those tables should be searched on.
A Search Connector is an instance of a Search Model. So all Search Models are delivered through standard components of S/4 HANA, but only once Search Connectors are created for those models can search take place.
3.4.2 Software Component
When creating Search Connectors in ESH_SEARCH, it is first necessary to choose a ‘Software Component’.
For S/4 HANA 1511 FPS1 the correct component is ‘SAPAPPLH’, described as ‘SAP_APPL:Logistics and Accounting SOH’. This is a rather confusing description because this is S/4 HANA, not Suite on HANA (‘SoH’).
UPDATE:
On subsequent projects I found that:
- For S/4 HANA Finance (sFin) the correct component is 'SAPFINH'. The similarly named 'SAP_FIN' was for earlier versions of HANA and for TREX, as explained in SAP Note 2289019.
- For Retail the correct component is 'EARETAILH'.
In both cases these components actually contain the more general SAPAPPLH component, and then add specialist content to it. You can see the structure of these Software Components in the ESH_MODELER app, as shown here for EARETAILH:
Further specialist Software Components may be available for other industries or solutions.
Note that once Search Connectors have been implemented from a higher-level component such as EARETAILH, then it is no longer possible to implement connectors directly from a child component such as SAPAPPLH. Instead, the connectors must be created with reference to the higher level component.
Similarly, if you initially implement connectors from SAPAPPLH, then if you later implement a higher-level connector, then all of your SAPAPPLH connectors will be moved to the higher level component.
Finally, it isn't possible as standard to implement connectors from two components that share the same subcomponent, such as SAPFINH and EARETAILH. However there is a work-around for this, as discussed in SAP Note 2233630.
3.4.3 Choose Connectors to Create
Choose the Connectors to create that you identified from the required Factsheets. There are some dependencies between Search Models, and you may find the cockpit will automatically activate any additional connectors which are prerequisites for those selected. The connectors will be created by a batch job; this typically runs fairly quickly.
3.4.4 Indexing
On creation, most Search Connectors will immediately show as being Active, however some may show a status ‘Prepared’, and an additional step must be followed to schedule their Indexing.
If required at all, this step dates back to the earlier TREX technology, where each Search Connector would require a regular background job to be scheduled to replicate data to TREX. By contrast on HANA, Search Connectors can generally access the underlying HANA tables directly, and so no jobs are necessary. A common exception would be a Search Connector for a business object with a long text (SAPScript text). For these Search Connectors an index job may still be needed for the SAPScript text, whilst other object data can be read directly from HANA. It may be that on some earlier releases index jobs may be needed in other circumstances too.
Initial indexing jobs may be very resource-hungry, requiring for example a lot of memory. For this reason it may be best to Index one Search Connector at a time (or schedule jobs to start at staggered times), rather than trying to start all together. Ideally, do this at a time of low system usage such as overnight, checking that no other system-intensive jobs are expected to run at the same time.
More recently a new generation of Search Connectors are based on CDS views – more about these in 5.6 below.
3.4.5 Status Filter
Be aware that in the Cockpit there’s a dropdown that filters on the Status of the Connectors:
During creation, activation and indexing this filter may change automatically, to the current status of the Connectors selected. It is helpful to be aware of this as otherwise it may seem like your active Connectors have disappeared, when in reality they have just been filtered out.
3.4.6 Search Connector for Connectors
A Connector which should be created, but which may not be mentioned in the Fiori Apps Library, is ESH_CONNECTOR. This is a Search Connector for the Search Connectors themselves. The practical effect of creating this Search Connector is to get the dropdown list of business objects in the Fiori Launchpad Search:
Note that this dropdown list reflects the Search Connectors which are active, not just those for which some objects exist in the system. For this reason, do not create Search Connectors for business objects which are not in functional scope – we only want the user to see relevant business objects in this list.
In previous releases the dropdown did not exist and instead the user was expected to type the object name into the search box. This functionality was also dependent on ESH_CONNECTOR.
There is similarly a Search Connector for Connector Categories, ESH_CATEGORY, which should also be created.
3.5 Testing
Firstly, in ESH_COCKPIT the number of objects found for each Connector is displayed in the table:
Clearly if this shows zero when some data is known to exist then this would be the first indication of an issue.
Beyond this, the search functionality may be tested in the backend by running program ESH_TEST_SEARCH. With this program the search must be restricted, for example to a specific Search Connector. Using the value help on Connector ID will show all the Connectors which are active, a useful test in itself:
The results of a Search include all the attributes returned by that particular Connector, which again may be useful to know:
If no search term is entered then the number of entries from this test program should correspond to the number shown in ESH_COCKPIT, and of course could be verified by checking in the appropriate back-end database tables or transactions.
Note that on Business Suite a backend transaction ESH_SEARCH would launch a web dynpro transaction that could be used to test Enterprise Search independently from the Fiori front-end; however in S/4 HANA the transaction has been deprecated in favour of the built-in Search in Fiori Launchpad. Of course trying the Fiori Launchpad Search is also a valid test; however if there’s an unexpected result, then ESH_TEST_SEARCH is useful to confirm if the issue lies with the back-end Enterprise Search or elsewhere such as the Web Dispatcher or with the front-end Fiori Launchpad.
If issues arise, it may be helpful to run the Consistency Check available in ESH_COCKPIT under ‘Actions’:
Any error messages reported by this check may point to the source of the problem.
3.6 CDS-based Search Models
More recently Search Models are moving away from the Enterprise Search framework altogether, to be defined purely through the use of CDS views. Significantly in this case there is no specific Search Connector to be created in ESH_SEARCH, although ESH_CONNECTOR and ESH_CATEGORY are still required so that the CDS-based search objects are listed in the Search dropdown help. The steps required to use CDS-based Search Models are listed here. Note that this set-up includes granting some HANA authorizations in HANA Studio – that part is described here.
An example is Data Definition C_PROCUREMENTITEMS:
3.7 Authorizations
Two standard back-end roles are available for Enterprise Search:
· SAP_ESH_LOCAL_ADMIN for administrators.
· SAP_ESH_SEARCH for end users.
By copying and adapting SAP_ESH_SEARCH, users may be restricted to specific Search Connectors that are relevant to their business role. This will also affect which Business Objects are listed in the Search box dropdown help.
This front-end role cannot be used to restrict the actual results of a search (e.g. by Org Unit). Instead this is determined by a combination of the Search Model definition and the user’s back-end authorizations. For example Accounting Document Items have a Search Model ACCT_DOC_LINEITEM_H. The Model Definition determines which back-end authorization objects to be checked:
For this to work it may be necessary to Index User Authority:
This step comes from the old TREX-based solution, where details of User Authority in the Business Suite system had to be replicated to TREX and indexed.
4 Conclusion
Enterprise Search is now a key element in the Fiori Launchpad user experience. Hopefully this blog will enable other S/4 HANA customers to draw on the experience I gained on my own project, and therefore get their own Fiori Search functionality up and running more quickly. Do please feel free to add your own thoughts, tips or feedback through the Comments.
- SAP Managed Tags:
6 Comments
