TREX full text search

[former_member52021]

hi

We have a SAP E-Recruiting standalone Release 606 system with a running TREX set up to search candidates profile data. We would like to implement an extended full text search for candidates attachment data. Does anyone have experience with a TREX for full text search. How is the performance when the TREX has to index additionally thousands of candidates attachments?

Thanks for the help

Fitli

[Former Member · Accepted solution]

Dear David,

you do not need to develop anything as this is standard functionality in e-erecruiting.

Please make sure that configuration is properly done according the following notes:

650521

1301016

Additionally you have to say which attachments shall be indexed in SPRO

SAP E-Recruiting --> Talent Warehouse --> Candidate Search --> Search Profiles --> Assign Attachment Types to Search Profile Types

The performance of course is something you have to consider during TREX sizing.

See note: 1173518

Best regards

Sebastian

[Former Member · Accepted solution]

It's true, but I think it's standard if you use SES on TREX. You should anyway always use SES because this is a lot better than the standard TREX

[Former Member · Accepted solution]

You are right. SES is the better solution in comparison to the XML-based indexing in e-recruiting.

But even there attachment search is possible if you do the configuration based on the notes.

But actually since EhP4 you must use SES even if notes do not tell you, SAP support says that SES is required since EhP4.

[former_member52021 · Accepted solution]

Sebastian

Thank you for your answer. I forwarded your suggestions to our basic guys. But it still doesn't work. We will now ask SAP to support us with as TREX specialist from their side.

Regards

David

[Former Member · Accepted solution]

Hi,

Have you reindexed after applying the missing steps? Was something missed?

Please check TREXPreprocessor logs when reindexing a test candidate.

Have you adjusted search profile customising to your needs? Otherwise it will not work.

I doubt that TREX specialist can help you. In 99% it is a recruiting setup issue.

Best regards

Sebastian

[Former Member · Accepted solution]

HI Sebastin,

I would like to know what you mean by 'In 99% it is a recruiting setup issue.'

Can you please elaborate.

Regards,

Bharat

[former_member52021]

Hi, finally we couldn't implement the T-REX full text search because we have https communication implemented between TREX and E-Recruiting server.

[Former Member]

Did I understand correctly? It does not work because of https?

Actually it should work. I have attachment indexing running at other customers. They also have an established https communication between trex and SAP.

[former_member52021]

Sebastian

Yes correctly. We have the information from our SAP basic guys that they can't setup an attachment indexing because of the https communication between TREX and SAP. Do you have any suggestions how we can continue? Is it possible to help us?

Regards

David

[Former Member]

Dear David,

please try to index a candidate, which has an attachment and take a look into the error message in TREXPreprocessor log. Let's see this first.

Thanks

Sebastian

[former_member52021]

Sebastian

We set up the whole process for SES search according the SAP note 1301016. Unfortunately we couldn't find any search results from candidates attachments data (structured search). We will now turn off our https communication to check results with http. Can you inform me how to check the TREXPreprocessor logfile? We also see over transaction SKPR07 that the index category for the docarea HR_KW is empty. We've tried over the topic mass actions a reindex but an error message popped up that there is no index category for HR_KW available. Do you knwo were we can create this index category?

Thank you for your help

David

[former_member217429]

Hi David,

the preprocessor trace file should contain information about the document URLs generated by KPRO and the error code in TREX if the indexing of documents failed. As I undertsand you have activated the HTTPs on the ContentServer side , so most likely you see exception 16001 for each document. It means that you need to configure the TREX first as described in the TREX security guide

http://help.sap.com/saphelp_snc70/helpdata/en/48/72305df518055ee10000000a42189b/frameset.htm

http://help.sap.com/saphelp_snc70/helpdata/en/1d/e6d9610acada409d59945617271169/frameset.htm
so that such URLs could be resolved by Preprocessor. As such configuration could have negative impact on the indexing performance  I would like to recommend to switch ContentServer back to HTTP (is HTTPs isn't a business requirement).
Usually you should be able to create an index for HR_KW directly from SKPR07 -> just type the HR_DOC into the document catagory field -> select one of the documents -> index -> the index should be created. If it doesn#t happen , it means that you have some inconsistencies between KPRO and TREX (or between different KPRO tables): in such case I would like to suggest to create a OOS message for this issue .

Best regards,
Mikhail

[former_member52021]

Mikhail

Thank you for your response. We did again a proper setup on our Testsystem and then checked the preprocessor trace. We saw that we got a lot of error messages because of the https communication. We then changed to simple http and it worked. We could find entries from candidates attachements. We will now keep the http switch because we only have to activate https communication between autonom systems.

Regards

David

[Former Member]

Hello Denzel,

we are use SES for full text search on dms document stored in Content server. Several millions of documents

We are using  a full trex in configuration distributed(Master-slave) with central file system storage.

There are some strong contraints in function of you data volume.

You must also avoid the using of '*' as paramater of your search ( in that case all the index is loaded in memory).

Performance of you searching will depends of the size of your index, the number of index servers used and the type of request

regards

Julien