Talent Management - TM - Trex 7.1 - Delta Indexing

[Former Member]

luke.....are you out there??

congrats on your blog being featured right on the SDN homepage... very nice...

http://scn.sap.com/community/erp/hcm/blog/2010/09/20/setting-up-netweaver-embedded-search-trex-for-s...

and congrats to Chris on his first two excellent blogs....

http://scn.sap.com/people/chris.mcnarney/blog/2010/08/26/whats-included-with-the-predefined-performa...

http://scn.sap.com/people/chris.mcnarney/blog/2010/09/09/whats-included-with-the-predefined-performa...

all 3 blogs are very helpful since there is little information available out there on these topics...

so we've been testing the delta indexing program very heavily - ESH_IX_PROCESS_CHANGE_POINTERS

we have found that it does not appear to be able to index new hires (new central_person index does not pick up the new CP).  The only way this data can be indexed is by running a full re-index.  That is problematic for us, b/c we were hoping to only do full re-indexing 1 a week or even 1 a month.  our indexes take 2-3 hrs to complete and trex searching is pretty much inoperable during that time. 

Have you tested new hires with delta indexing?  it seems as a gap in the change_pointers program.  We opened up OSS message to SAP. 

some additional thoughts working with the program, relative to your blog.  I would highly recommend that anyone testing this makes sure the following notes are implemented in your system.  The first one is the most recent and we ourselves did not have that implemented.   

1. 0.350 BC-EIM-ESH 1441190  Error in model assignments to logical system 24.02.2010

  2. 0.230 BC-EIM-ESH 1408655  Alerts in syntax check due to unused indexes 18.11.2009

  3. 0.260 PA-TM 1395703  Positions and termination are missing for indexing 30.10.2009

  4. 0.330 BC-EIM-ESH 1249482  Functional corrections for Enterprise Search 7.01 SP03 26.01.2009

Another area which we found from testing:  SAP by default does not delta index structural authority view.  What this means is that if a new talent specialist is added with 741 relationship there access to see that structure will not be available in TREX search by default delta indexing.  This would also impact existing organizations and positions shifted under existing 741 relationships. 

The information in spro is actually quite helpful, you can find it in:  talent management and talent development > basic settings > search > BAdI: Activate Delta Indexing for Authorization Data

Activtate the BADI, than the program to "create the change pointers" must run periodically in your system.  This is done with RPTMC_CREATE_CHANGEPOINT_AUTH.  Once that program creates the change pointers the next time your scheduled delta program runs (ESH_IX_PROCESS_CHANGE_POINTERS) all of the structural auths will be created and indexed correctly.

If we can just now get new hires to work with ESH_IX_PROCESS_CHANGE_POINTERS we will probably only run the full re-index once a week or once a month. 

Let me know your thoughts,

Michael

Message was edited by: Luke Marson

Message was edited by: Luke Marson

[tframbach]

Hi guys,

just one remark from my side regarding delta extraction. It is important to realize that the underlaying process logic for full extraction and delta extraction (via RPTMC_CREATE_CHANGEPOINT_AUTH) is logical identical. Therefore it might be not meaningful to create the delta changepointers more often as necessary. At the end it will cost almost the same time as the full extraction and will consume some server ressources. So you should schedule RPTMC_CREATE_CHANGEPOINT_AUTH usually once a day but not every few hours.

Regards,

Thomas

[lukemarson]

Hi Thomas,

RPTMC_CREATE_CHANGEPOINT_AUTH is only for delta-indexing of authorizations and not all of the other connectors. So running this hourly should not conflict with the real-time delta-indexing as that is for separate data. Or did I misunderstand your post?

Best regards,

Luke

[tframbach]

Hi Luke,

you are right! RPTMC_CREATE_CHANGEPOINT_AUTH is the only way to realize the delta-indexing for the authorization index. Running this program will not cause technical conflicts of course.

Anyway, it is necessary to plan the regular job for this program carefully as it cost similar server resources as the initial (full)extraction. But in fact you would not schedule a full extraction turn every few hours. While the term "delta" implies usually some kind of small task it is definetly not a little task with respect to the authorization.

Best regards,

Thomas

[lukemarson]

Thanks for clearing that up Thomas!

[Former Member]

so if anyone is interested, from my previous post I mentioned that new hires were not getting picked up by the change pointers program.

after further testing though, we found that when the authorization recon program identifies the new hires and appropriately creates a change pointer.

conclusion: to avoid full re-indexing of trex indexes, perform the following steps:

1. implement / activate the BADI - HRTMC_AUTHORITY_VIEW - talent management -> basic settings -> search

2. Schedule program RPTMC_CREATE_CHANGEPOINT_AUTH - every 30 mins, or 1 or 2 hr. This program will capture whenever anything changes from an authorization data perspective. This would include identifiying new central persons (new hires) or new TMC specialist being setup with 741 relationship. This program "creates change pointers" which than feeds the main delta program - ESH_IX_PROCESS_CHANGE_POINTERS.

3. Use Luke's blog on the instructions for the delta program - ESH_IX_PROCESS_CHANGE_POINTERS - this program you can have run every 5 mins, 10 mins, 15 mins, based on your needs. this processes all delta changes, the first time the program runs after the RPTMC_CREATE_CHANGEPOINT_AUTH program finishes it will also processes the data authorization changes, otherwise every other time the program is running it will catch non-data authorization for all the other indexes (employee name change, new performance rating, new potential, position name change, new profiiciency scale, new career profile data, etc).

hope this helps somebody!

michael

Edited by: Michael L Pappis on Oct 7, 2010 12:05 AM