We are on Version 3.0 SP1 EhP4 of Nakisa, and TREX Version 7.1 patch level 43.
We have indexed Nakisa with TREX on our Developement and QA systems.
In DEV, When we try to perform HRTMC_SEARCH_OBJECTS, and then use search_id_config SAP_POSITION_NAKISA we receive 111,773 NUMBER_OF_TOTAL_HITS.
In QA, When we try to perform this same search, we receive 0 hits.
The connection of QA and DEV are identical and have been double checked. (Unless you have a suggestion of another link to check out for us).
One of our ideas is that there is something in the authorization of the IDs that are trying to perform the test. Is there a specific role/profile/any other sort of access that is REQUIRED to perform these searches? We also encountered that, in DEV (where the search works with one certain ID) the search would work for one ID, but not for another.
So scenario 1: user xxxxx tests in Dev and recieves 111,000 hits. Same user xxxxx tests in QA and receives 0 hits.
scenario 2: user xxxxx tests in Dev and receives 111,000 hits. Different user yyyyy tests in DEV and receives 0 hits.
Coincidentally I'm having a similar issue at one of my clients for just one new field. It works fine in DEV but in QAS it doesn't.
If you go to tcode TREXADMIN you can search directly in the indexes. I suggest you try this to see if you get expected results. At my client we have the correct data in the indexes but HRTMC_SEARCH_OBJECTS returns no records when perform the same search in the function.
There are no specific authorizations but the data you search for should be accessible by the authorizations that your user has. If you have a lot of authorizations then it might be blocking your access to the data. I would make sure the user has a 741 relationship and that you search for data within this area. I also suggest trying a search wit ha user that has SAP_ALL, so you can see if it is an authorization issue.
I tried to perform a simple search with SAP_ALL.
Went to se37, entered HRTMC_SEARCH_OBJECTS, execute.On the next screen for 'SEARCH_CONFIG_ID' I entered SAP_POSITION_NAKISA' and clicked execute and received 0 results. This is all per OSS Note 1534815.
Inside TREXADMIN, do I go to the search tab to search directly into the indexes? If so, when go to the line IndexID and try to find one to use, it is giving me all of the TREX technical names of the indexes. How do I know which ones are which, and what results to expect? Also, if I randomly select one, I do not know how to determine what I need to put in the fields at the bottom of the screen to try to generate results.
If you could please advise how to search the indexes in TREXADMIN to determine if the connection is there, I would greatly appreciate it! I messed around and randomly selected one called esh:e1d200e1d200hrtmc_job_family~job_family. I have no idea what I am supposed to get from this so in the full text search I did *. I received 20 hits in table form. I really have nothing to compare this to, but I am assuming 20 hits is a good thing. Is it possible to search the index directly to find the results of SAP_POSITION_NAKISA, or are these two separate things? Am I on the right track?
OK I found the index name of our SAP_POSITION_NAKISA it is called esh:e1d200e1d200hrtmc_positon~~sap_position_nakisa. I went to the tab 'index_admin' and clicked display entries for this index. (It actually spits out all info for each index). One thing I can confirm for this is that the # of searchable docs is the SAME # that the user ID that CAN perform this search received, 111,773.
It must be good news to see the same number of searchable docs compared to the # of NUMBER_OF_TOTAL_HITS from HRTMC_SEARCH_OBJECTS .
When you used HRTMC_SEARCH_OBJECTS did you use a search field? If not then this might have effected your outcome.
Yesterday we applied new SuccessionPlanning config in QAS and HRTMC_SEARCH_OBJECTS returned data to the application, even though the function module returned no data in the backend. I'm not sure why because the tests we did in DEV worked perfectly, first time. However, our QAS system is not as stable as DEV or PRD (the joys of cheap outsourcing!).
esh:e1d200e1d200hrtmc_positon~~sap_position_nakisa should be the correct index to check in TREXADMIN. If you can get records in QAS then the problem must be with the HRTMC_SEARCH_OBJECTS function. I recommend you open an OSS message because you can prove the data is in the indexes.
Do the searches in SuccessionPlanning work in QAS?
As of today, we have resolved the issue in Dev and QA.
I will try to layout the fix for future users that run into this situation, as it sounds like it is sort of common.
The main thing to check if you are receiving 0 search results is the account that you are searching with. The users that need to use the TREX search into Nakisa need to be setup as Talent Management Specialists (TMS), which means the position they occupy in the Org Structure has the 741 Relationship between the position and an Org Unit.
If you are receiving 0 results and have you set up everything correctly, this is most likely the issue.
To test this, we removed the user who WAS getting results from this 741 Area of Responsibility, and reindexed. This user tested again and had 0 results. (Which is what we expected). Our next move was to setup all of the people who need to get results into the 741 relationship, and then reindex again. After we reindexed with new authorizations, we were all able to generate results.
There are a few blurbs you can find on this topic when researching that mention 741 relationship and TMS. So I hope I was able put some of the pieces together for those that may run into this in the future.
Thanks for sharing an in-depth response to the solution! This is very helpful to others, although a 741 relationship is a pre-requisite of using Talent Management Specialist functionality.
Please note my first response mentioned checking the 741 relationship.