Extending Enterprise Search For Talent Management, Not As Hard As You Think
If you’re implementing the Talent Management module for EhP4 and up, then you’ve undoubtedly gotten up close and person with Enterprise Search (ESH). There’s probably also a pretty good chance then that you’ve read the excellent Setting up NetWeaver Embedded Search (TREX) for SAP HCM Talent Management EhP4, 5 and 6 from my good colleague Luke Marson.
However, one thing I had long struggled with when using ESH was what to do when I needed to extend the search. The ‘Advanced Search’ feature of the Talent Search does provide a number of fields for the Talent Management Specialist to search by, but it does have some weak spots.
For instance, the education section will let you let you search for a variety of fields… but the actual school a person went to isn’t one of them. I have yet to find a customer who thinks that field shouldn’t be included. However, adding that field seems pretty complex on the surface, since it’s not one of the fields SAP delivers out of the box to search for.
The intention of this blog is to help show you that adding that field, or any number of available fields, is not really very difficult. And once you get the hang of this, you really are able to enhance the power you’re providing to your TMS users.
First thing we need to do is go to transaction ESH_COCKPIT and click the “Switch to Modeler” button.
Now that we’re here, go ahead and expand the EA-HRGXX option and select the HRTMC_CENTRALPERSON option and click the “Edit” button.
Next, you do have a lot of choices to create whole nodes, but that’s not our plan, so we’ll click the “Next” button up to the “Define Requests” step. Here you see the 4 main requests fields are built into. Default SAP uses the SAP_TALENT request when you use the “Advanced Search” option I mentioned at the start of the blog, so that’s the one we’re going to work on. Once we select that option, we see the lower half of the screen change to list all of the fields included in the request.
This is an interesting time to note that there are a lot more fields in this request than there are available for the TMS to search on. So, why are the fields there but not available on the front end? There is a perfectly good explanation for that; which is…
I have no idea.
Anyway, let’s add school and successors by position to our search. School is an easy one, because it’s already there.
Right here I see the line item entry for school. The alias field is the important field for later, so make a note that EDU_INSTITUTE is your search request alias.
For the other field, successors by position, we need to dig a little harder, but this is hopefully the part where you’ll start to say to yourself “whoa, this is pretty cool”.
Still in the same SAP_TALENT request, click the “Add” button. When you do that you’ll get a new screen that has a full list of details.
You can navigate here through all aspects of the Central Person connector, and then through other connectors that share a relationship with Central Person. So in our example, we start in the Central Person, then we navigate to the HRTMC_REL_S_CP_740.REL_S_CP_740 line. Now that we’ve gotten that far, we can find out a variety of things based up on that. Our focus is on HRTMC_POSITION.POSITION, since we want the position title. You’ll see in the screenshot, when I selected this entry, I got a list of fields in the lower section that I can select. We could use OBJID if we wanted to let TMS users search by position IDs, but we’re going to use STEXT, so users can search by the actual position title. So I highlight STEXT and click the “Select” button.
This takes me back to the list of fields that are in the SAP_TALENT request. If you scroll to the bottom of this list, you’re going to see your position title field you just added. Notice the alias field is STEXT11 or so. That’s just because there are other STEXT fields that have been added to the request already, so SAP just increments to the next one available. In total, we have the EDU_INSTITUTE field and the STEXT11 field. I’ve pictured the line item we added for positions in the below two screenshots.
This would be a good time to click the save button. This is a workbench request, so hopefully you have access to create those, or else this will probably have felt like a pretty fruitless activity so far! Once you’ve saved the changes to a transport, click the “Finish” button and – congrats! – You’re halfway home.
You may be tired after all these changes. Why don’t you take a break, kick back and send your security team an email saying something crazy like you noticed that all your company’s financial data is available to candidates in E-Recruiting, just to see what kind of frenzy you can get them into. Security people love a good hoax!
I’m relaxed now, surely you must be too. Onward to the IMG configuration. Search Requests and Search Field Names is the particular step of configuration to begin with. Once you’re in there, you’ll start to see all of the requests that have been defined thus far. The one we modified, you’ll recall is SAP_TALENT, which is the first line item in the below screenshot. Click that line and double click the “Search Fields” option on the left hand navigation.
Initially, we’re presented with the entire list of fields. You can either copy one of these and change it, or click the “New Entries” button. Either way, you should end up with a value that looks like what I’ve listed below. I’m not trying to satisfy any minimum word counts for this blog, so I’ll just tell you that each field has a pretty good explanation if you hit F1 for them. What I’ve done below will work, but you may wish to tweak yours slightly. The critical think to note here is you can see how I’ve populated the Alias SearchReq field with the alias values I told you to remember from ESH_COCKPIT.remember from ESH_COCKPIT.
So now that you’ve added these fields as official fields to be searched on, SAP needs you to actually include it on the search screen, so users can search for your two new fields. Let’s go do that in the same general IMG section, but this time in step “Define Search Configurations”. Similarly as before, you can either copy an existing entry, or create a new one. Either way, you’ll want to end up with a screen that looks similar to what I’ve defined below in the next two screenshots. Notice Here I use the Alias field as well as the search field name I created in the previous step. You’ll also see I created my own field group for succession data, but you can do whatever you want.
Congratulations! You’re done. You can now go to the Talent Search application where you’ll see the two new search fields you’ve added. Fill in some values and click “Search”. What’s that you say? It didn’t work. As my son would say, “I joked you!”
So, the last step I skipped is that you need to delete and recreate your search connectors. That way, when the connectors get rebuilt, they’ll know to index the two new fields you included. The easiest way to do that is to run program ESH_ADM_INDEX_ALL_SC for EA-HRGXX
Ok, so once that’s finished and you’ve got data indexed, NOW you will be able to successfully test your new fields. Pretty easy, right? It’s cool once you realize how many fields you can add to the search. That way you can satisfy a lot more user requirements than you may have originally thought.
Excellent blog. Thankfully my first experience of implementing Succession Management with SAP TVN didn't require any extensions as I'd heard rumours that it wasn't straightforward. BUT now I've read this, I'd feel a lot more comfortable doing it.
Look forward to trying!
You're spot on. I spent a lot of time at a previous implementation banging my head against a wall trying to figure it all out. One day in fooling around it all came together for me and I was like, "wait, that wasn't so bad". Then I went and told everyone that it was impossibly hard and they'd never be able to figure it out without my help. Just kidding.
"This is an interesting time to note that there are a lot more fields in this request than there are available for the TMS to search on. So, why are the fields there but not available on the front end? There is a perfectly good explanation for that; which is…
I have no idea. "
I know the answer!!! SAP is really nice and likes to allow consultants to have a job.
While I do not use Talent Management right now, I was curious to read this article and found it very clear and concise. Even I feel comfortable extending the enterprise search fields based on the clarity of the information.
It's a shame SAP doesn't take a more holistic view when devising all their standard out of the box search fields. Thank goodness that you are able to bridge the gap !
This is a fantastic blog! I have to echo Michael's sentiments, I think this will become a well referenced blog over time.
I have to put this to practice so I'll let you know how it works for me.
It hurts me that you're calling me a liar. Just kidding.
If you can get results by just entering *, you definitely are proving data is indexed and can be returned, we've gotta just figure out what the difference is. The search is not case sensitive.
Can you take your harvard example and try something for me? If you searched for *v*, do you get any hits? If so, can you add letters until you get any trouble? You're 100% confident you are the TMS for a person who has Harvard listed?
I would say Dale's question is a good time to note one thing I didn't in the blog. Since the field in the Talent Profile is free text, you lose any guarantee of consistency. If someone spells Harvard "Havrad", then you won't find that person in your search for "Harvard".
Live by the sword of flexibility, die by it, I suppose.
Let me know how it goes Dale.
I knew if I sent a note, we'd find the problem. Actually, it was my colleague who found it. Although the Institute field showed up under the Define Request area with an Alias, it did not in Define Nodes. She went to Define Nodes for Template Modeling: 'HRTMC_CENTRALPERSON' and selected Institute as a Resonse Attribute and added teh alias EDU_Institute. I then rebuilt the searcch connectors and indexes and Voila! it works. We can do a wild card search on the field.
I followed your blog and everything was successful, thanks for this. I was wondering though if it is at all possible to add search fields that do not exist in any of the defined nodes.
How do we go about creating our own nodes?
For the sake of completeness (even though this comment is very old)
Talent management esh - extend search model how to v1.2
(Thx Chris for this document, it has saved numerous hours!)
Dear Guillaume Garcia,
Thank you very much for the documentation.. 😀
It had been pointed out this blog would serve in years to come... well, 3 years is actually not bad! 🙂
I had 2 questions for you:
--> Meanwhile, I sorted this out. I edited the template HRTMC_JOB, went to step 2 "Define node", selected the JOB node and clicked the checkbox "Sel.(ected for node)" for the SHORT entry 😉
Many thanks in advance for your help.
Here is the corner of the internet that I don't get back to often!
1) You nailed it.
2) To start I would tell the quality team that I don't care for their tone. After that I'd make the copy because that's probably the best idea. There should be a client copy button laying around somewhere should there not? That's the method I use to create a copy.
You can copy many things but on Step 6, I haven't seen any button to copy the Search request.
I have been to the WD view (ESH_MU_SEARCH_PATTERN view S5) and there is no Copy button...
Yet, in the CL_ESH_OBJ_MODELLING class there is a COPY method that might prove useful!
I'll keep you posted.
I came to the conclusion that this is no easy feature to implement... Everything is stored as GUID and I guess you require a new GUID for every single field, navigation link, ... which is a huge effort for my 1-time copy. 😐
The COPY_OBJECT_TYPE method of class CL_ESH_OM_OTYP_EXT_I does provide some hints though.