EREC: Job Search not showing any new Post

[Former Member]

Hi ,

We are running E-Recruitment 603 Sp2, since late last week any job posted does not appears in the search result. FYI we are not using SES, however we are using TREX. I have checked with our basis team, it seems all jobs in TREX is running. Are missing something here? Anyone can help.

Regards

Ridzuan

[Former Member · Accepted solution]

run RCF_PERIODICAL_SERVICES manual and check SLG1 transaction

[Former Member · Accepted solution]

Hi Andy

The RCF_PERIODICAL_SERVICE is running as well.

[Former Member · Accepted solution]

I didn't ask if it was running. I asked to do it manually AND check transaction SLG1.

Anyway, maybe an earlier job is still running which got stuck in the upgrade.

Go to transaction SM36 and enter RCF_PERIODICAL_SERVICES below in ABAP program. Set the dates back before the upgrade and look for a status different than completed. If you find a job than kill it.

[romanweise · Accepted solution]

Hi,

I'd like to add some background information and add another option.

The program rcf_periodical_services report includes a check which prevents parallel processing of this report. This can not be seen in SM37 as the report will be shown as sucessfully processed but SLG1 should include an antry saying the report was ended due to a parallel running job.

Andy suggested to check SM37 if there is a long running job which might be days or even weeks old. This could happen if you restarted the server and the system did not track the job was canceled. In this case you have to find the job and use the "check status" function. Unfortunately it might happen that this is not working as the job has already been deleted from SM37. In this case an entry remains in a table which still says the rcf_periodical_service job that a parallel job is running.

Therefore I suggest to go to SE38 and run the report in debug mode. The call of funtion module HR_RCF_CHECK_SEARCH_JOB_STATUS will tell you if the report is ended due to a parallel job. If this is the case check SM37. If there is no job you need to go for the table entry.

If the function module does not identify a parallel job there is another option. If the TREX has less than 2 GB of free disc space it stops indexing. This could also be a reason why new publications can not be found while old ones are still working.

Rgds.

Roman

[Former Member · Accepted solution]

Hi Andy & Roman

Thanks for your input, I will check with my basis team.

I just need to ask you another question, our recruiter started posting a new job yesterday both internal & external (as by practice they only post new job in the early part of the month). To my surprise all the job publications did appeared in the search list both internal and external search, except for 1 job posting, this is the job posting which trigger this discussion (NC-50049049).

I am now not sure whether this is a TREX problem or some other problem. I have checked with the recruiter, I don't see anything wrong with the requistion, posting and publication details. If this is a TREX problem all the other posting would not appear on the search result as well.

Andy & Roman, any ideas?

MANDT

PLVAR

OTYPE

OBJID

SUBTY

ISTAT

BEGDA

ENDDA

VARYF

SEQNR

START_DATE

END_DATE

PUBLISHED

WITHDRAW

-

---

	510	01	NC	50049011		1	30.11.2011	31.12.9999		000	30.11.2011	14.12.2011	X
	510	01	NC	50049015		1	30.11.2011	31.12.9999		000	30.11.2011	14.12.2011	X
	510	01	NC	50049021		1	30.11.2011	31.12.9999		000	30.11.2011	14.12.2011	X
	510	01	NC	50049023		1	30.11.2011	31.12.9999		000	30.11.2011	14.12.2011	X
	510	01	NC	50049025		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049029		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049031		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049037		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049039		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049041		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049043		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049045		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X

| |510 |01 |NC |50049049 | |1 |30.11.2011|31.12.9999| |000 |30.11.2011|05.12.2011|X | |

	510	01	NC	50049050		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049058		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049060		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049064		1	30.11.2011	31.12.9999		000	30.11.2011	03.01.2012	X
	510	01	NC	50049066		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049068		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049072		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049076		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049080		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049084		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049088		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X
	510	01	NC	50049092		1	30.11.2011	31.12.9999		000	30.11.2011	08.12.2011	X

-

---

[Former Member · Accepted solution]

I would withdraw the application and recreate all. After that, check SLG1 transaction immediately.

[romanweise · Accepted solution]

Hi,

I had a single case where this was caused by a special, non-printable character which the recruiter accidently copied from MS Word or so into the posting text. The character was not visible in the application UI (appeared as regular SPACE). I only found it when I was debugging the application by the hash (#) displayed in the string of one of the posting texts. The character caused the TREX to skip the indexing of the posting. After removing the special character reindexing worked fine.

Kind Regards

Roman

[Former Member · Accepted solution]

Andy & Roman

It was indeed caused by the 'special' hidden character, as soon as the text was replace with a new one, the search result was ok. Guys thanks a lot, appreciate your input.