TREX - how to setup delta indexing?

[jack_wong]

Hi,

I have got TREX installed and I could search in Succession Planning.

However, when I changed some data (for e.g. assigning a new user id to a PERNR), that new ID couldn't perform a search on employee.

I have scheduled the program ESH_IX_PROCESS_CHANGE_POINTERS, and this program could be completed without error.

But still, I couldn't perform a search until I manually run program ESH_ADM_INDEX_ALL_SC.

FYI, I'm following Luke's guide to setup the TREX:

Regards

[lukemarson]

Hi Jack,

Have you setup authorization indexing? If not then this could be the root of your issue. If you look towards the bottom of the SDN blog it will tell you how to do that.

Good luck!

Luke

[jack_wong]

Hi Luke,

Yes, the RPTMC_CREATE_CHANGEPOINT_AUTH is scheduled to run every 15 mins.

I have an instance of the background job of ESH_IX_PROCESS_CHANGE_POINTERS.

It has been running for almost 2 hours.

The first time, it completed after 5 minutes.

I think the job stuck in:

Indexing object type: HRTMC_AUTHORITY_VIEW

Indexing object type: HRTMC_CENTRALPERSON

Indexing object type: HRTMC_POSITION

Indexing object type: HRTMC_JOB_FAMILY

Indexing object type: HRTMC_JOB_FAMILY

Indexing object type: HRTMC_REL_S_Q_031

Indexing object type: HRTMC_FUNC_AREA

Indexing object type: HRTMC_REL_S_JF_450

Indexing object type: HRTMC_REL_S_JF_450

Any idea?

[lukemarson]

Hi Jack,

Often it gets stuck because of bad data, but this is unlikely if it indexes okay with ESH_ADM_INDEX_ALL_SC. Do you get any errors in ST22? have you tried cancelling and re-creating the scheduled job? Sometimes this has been a solution for me.

Best regards,

Luke

[StephenBurr]

Jack,

Can you check note 1423708 as well and check if your current SP level includes this note?

Important with regards to running RPTMC_CREATE_CHANGEPOINT_AUTH.

HRTMC_AUTHORITY_VIEW indexing can take a long time if there are lots of authorisation changes.

Stephen

[jack_wong]

Hi Stephen,

Thanks for your reply, but I don't think the problem lies on RPTMC_CREATE_CHANGEPOINT_AUTH.

FYI, our system has the OSS note already.

The background job is stucked on ESH_IX_PROCESS_CP_<date&time>

This job will never finish running in SM37.

[lukemarson]

Hi Jack,

Have you tried to cancel the job and recreate all of your indexes? Generally this should fix the problem. Once you've recreated your indexes then you need recreate the scheduling job again.

Best regards,

Luke

[jack_wong]

Hi Luke,

Yup, did that.

The full indexing can be completed without problem.

In SM50, Process Overview, it shows the background job status as On Hold, Reason as SLEEP.

Any idea why it is On Hold state?

Regards

Jack

[lukemarson]

Hi Jack,

I've no idea why it would be on hold - have you asked your basis team? I would cancel the job and create a new job now that your search connector objects have been indexed.

Good luck!

Luke

[Former Member]

The program ESH_IX_PROCESS_CHANGE_POINTERS is little bit different than regular background job.

It looks like a hang, but this program will keep calling SUBMIT of itself. It takes care of its own scheduling based on parameters you provide.

It will finish only after 'Exit processing after [hours]' you gave in selection screen.

Infact its not struck at 'Indexing object type: HRTMC_REL_S_JF_450'

It says that is the last index it worked on.

If it finds change pointers to any other object, it will index them and add a message at the end of job log saying 'Indexing object type: xxxxxx'. Make a change in org and monitor this job to validate this.

You see the job 'on hold', 'SLEEP' because it will wait for a while before it start checking for change pointers again. This duration is based on 'Delay[seconds]' parameter you specified in selection screen.

I thing your problem is that change pointers are not being generated properly which is the task of program RPTMC_CREATE_CHANGEPOINT_AUTH.

Thanks,

Nag

[lukemarson]

Hi Nag,

Thanks for the useful information. I've never seen an indexing job on SLEEP before - usually they are always ACTIVE even if no indexing is taking place. I wonder if this particular behaviour is unique to each SAP system.

Best regards,

Luke

[Former Member]

Yup. If we go to SM37, we will see status 'Active'.

If we go to SM51 and pick the server where this job is running, and double click on process, we see complete details of the job. If its running/reading db/writing to db/on hold/sleep... etc.

AFAIK background jobs will be distributed by scheduler to the app server/process which ever is available.

But this specific program 'ESH_IX_PROCESS_CHANGE_POINTERS' will always keep running at the same app server and process because it never ends based on selection parameters.

I think thats why Jack is assuming that its struck.

Thanks,

Nag