Trex search

[Former Member]

Hi

I am trying to resolve an issue we are having with Searching for Candidates in eRecruiting. What we have found is that when we search for candidate whether it be internal or external in our production system we can not find or two candidates that should appear. When we try the same search in our QA system we find them but not others. We have just done a copy back from production a few weeks back so data is nearly the same.

A lot of the searchs came back saying rebooting fixed the issue but we have tried that. The user are in the Backend system so should be found from the frontend searchs.

Any ideas? We are running eRecruit 6 with out any enhancement pakages applied.

Thanks in advance.

[romanweise]

Hello Yadi,

check if the periodical services are running correctly. A problpem regularely appearing is that SM37 does not recognize a running periodical service has aborted when resarting the server. This would be seen as an old very long running job. As long as this job has not been status checked in SM37 the system will exit every new periodical service run.

Furthermore check SLG1 for any additional messages.

I problem which also might result in your system behaviour is a too small server share. If the server share containing the index on the TREX has less that 2 GB free space the index will no longer be updated.

Furthemore you might have the TREX checked for a corrupted index. In some cases the index gets in a state where it still replies on requests but is in a way currupted that it is not updated.

so do the following steps:

- check periodical services -> if not running properly restart / plan wait some time if not working

- check sltg1 -> if no problem appears

- check TREX logs and share spaces -> if ok

- rebuild the index using the IMG node for it -> if this is still not working

- delete the index completely using SKPR07, SMRO and rebuild it

If still not working or you encounter an error message you cannot handle just post another message.

Kind Regards

Roman

[Former Member]

Roman

Thank you for that and I have been working thru the check list. When I checked in SLG1 I found a lot of red lights and when I expanded them they were showing as problem class other and the details are :-

Error while saving a search profile in document storage

The incorrect HR object has the key 01NE50021232

The error occurred in program CL_HRRCF_SPB_CANDIDACY========CM007 line 50

Error while saving a search profile in document storage

The incorrect HR object has the key 01NE50021232

The error occurred in program CL_HRRCF_SP_BUILDER===========CM009 line 30

Serious error; see log

The error occurred in program CL_HRKWF_DOC==================CM01E line 21

There are pages of these all with different number for HR object key ***************

Could these be the problem and if they how to fix them.

Also on your reply you mentioned that look at the TREX log, where would I find these (TREXADMIN)??

Thank you for you help points awarded.

[Former Member]

Hi

The friend managed to solve the problem? I'm having this same error and am not progressing.

Please tell me how to solved.

Thank you.

[Former Member]

Hi,

Please let me know if this has been resolved.

We are also facing the same issue.

Raj

[Former Member]

Same here....seems alot of people have this problem........anybody know how to fix it? We get it over and over again on the same Candidate Id.

[Former Member]

Ok folks, here is the solution:

You have to run RCF_CORRECT_DUP. The issue is that SAP changed the way they were creating directories for objects. So, older entries could have multiple directories.

Run this for the entire range for each of the object types (look at the doco and it tells you which ones) so that it fixes them all at once instead of running into them randomly.

Michelle

[Former Member]

Hi Michelle,

When you tun this program, should the periodic services be turned off?

[Former Member]

Hi,

In My Knowledge Use EHP3 for e-Recruitment 6.0

Regards

Krishna

[Former Member]

Thanks Krishna for your reply but at the moment that is not an option we have and looking into moving that direction but only in maybe Q3 this year. So really need to look for a solution now, knowing that ENP3/ENP4 will have a fix.