EQG17074: Invalid facet path: ptsf_sbo_name

by Apurva T. on May 10, 2014

in General

After configuring SES, many of the search functionalities started to work fine except for one: Browse Applicants

Browse Applicants used to throw up an error as shown below:

Service Exception: Fault Code = env:Server : Fault String = [Server CodecHandler] Failed to encode fault
-> EQG17074: Invalid facet path: descr_status/010 Active
(262,143) PT_SEARCH.SESIMPL.MESSAGE.QueryResponse.OnExecute  Name:QueryResponse  PCPC:676  Statement:9
Called from:PT_SEARCH.SESIMPL.QueryService.OnExecute  Name:doService  Statement:437
Called from:PT_SEARCH.SESIMPL.QueryService.OnExecute  Name:ExecuteQuery  Statement:47
Called from:PT_SEARCH.SESIMPL.Query.OnExecute  Name:Execute  Statement:39
Called from:HRS_SEARCH.SearchFramework.ApplicantSearch.OnExecute  Name:BeginSearch  Statement:57
Called from:HRS_APPLICANT_SRCH.Activate  Statement:47

EQG17074 Invalid facet path descr_status 010 Active


While configuring a second SES server on Windows server, getting error while using “search in ” ALL option in advanced search or searching in the search bar.

(Diagnostic tests work fine. Able to search using the advanced search dialog when we specify “Search In Menu”)


People Tools 8.52.11, Oracle

EQG17074: Invalid facet path: ptsf_sbo_name

<env:Envelope xmlns:env=”http://schemas.xmlsoap.org/soap/envelope/”><env:Header/><env:Body><env:Fault><faultcode>env:Server</faultcode><faultstring>Server CodecHandler Failed to encode fault
-> EQG17074: Invalid facet path: ptsf_sbo_name
</faultstring><detail><java:string xmlns:java=”java.io”>oracle.search.query.facet.InvalidFacetPathException: EQG17074: Invalid facet path: ptsf_sbo_name


Additional Information- The second SES instance is installed on a different server from the first SES instance. The databases being tested were un-deployed from the first instance and deployed on the second. Un-deploying from the second and redeploying to the first results in search’s working properly again.

Message stream looked into detail and found that there is no difference between messages being sent to the first SES instance and the second SES instance.



When one instance gets UN-deployed and the other gets attached, something is happening during the redeployment process.




Switching SES on the fly is prone to cause issues. Follow the below steps to clean up PeopleSoft side and this should take care of the problem-

1.Un-deploy all deployed definitions
2.From sql command line issue “DELETE FROM PS_PTSF_DEPLOY_OBJ” (Note:Do this only after successfully un-deploying all definitions)
3. Deploy desired indexes and run indexing.

Also Read:  July Newsletter

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: