O-SES Trouble in Paradise

Well, last month, I wrote a blog about how much I enjoyed my initial installation with Oracle’s Secure Enterprise Search that is now integrated into the Oracle PeopleSoft 9.2 applications. Surprisingly, I received a lot of email saying that I was not alone in my pain, and more surprisingly, folks were having a lot more problems with it then I did. Heck mine worked with only a day of fooling around with it.

Here is a some of the information I put together:

1. Watch the certification levels and the versions delivered by default. For some reason and I just checked this on edelivery the O-SES that is available for download in the Application Media Packs for HR is version 11.1.2.2.0 which is NOT certified on Windows 2008 R2 or Windows 2012, Solaris 11, RHEL 6.x. Version 11.2.2.2.0 is certified on Windows 2008 R2, Solaris 11 and RHEL 6.x. However, at this time there is NO certified version for Windows 2012. —It should be noted that I have installed and configured 11.1.2.2.0 on Windows 2012 and it worked fine for the Portal Registry Search.

2. Integration Broker is HEAVILY used with O-SES.
– Make sure that your IB configuration is setup and working correctly.
– Make sure that you have the nodes setup with password authentication.
– Make sure the Domain Connection Password (8.53) is 8 characters long and is encrypted in the configuration file.
– Even if you don’t do SSL on the webserver, make sure you run the pskeymanager tool to set a non-default password on the keystore (pskey) on the webserver, and then add the password (encrypted with pscipher) to the integrationGateway.properties file for the PSIGW (PeopleSoft Integration Gateway) configuration.
– If you are using a secure gateway url, make sure the root and intermediate certificates for the keychain are in the digital certificates configuration.
– Make sure all the Service Operations associated with Service: ADMINSERVICE, ORACLESEARCHSERVICE, PT_SES, PTFP_FEED, PTSF_SECURITY, PTSF_SES_FEED and PTSF_META_DATA are active and have a valid routing that is active, and make sure the routing makes sense.
– The Service Operation PTSF_SES_SCHEDULED_FEED has two routings on it that I have seen. One is to the WSDL_NODE and the other is to the ATOM node. What I found was that the I had to inactivate the WSDL_NODE and make sure the ATOM routing was active. If you look in the integration broker monitor I had the FEED messages reporting as done, but if you look at the pub contract it was in error. Once I removed them and resubmitted the builds it generate the messages correctly and the contracts executed correctly and therefore started returning valid entries.

3. Make sure that you can do the 4 step test for the round trip. PeopleTools > Search Framework > Utilities > Diagnostics. If the first 2 steps fail there is most likely a problem with O-SES installation and configuration, if step 3 or 4 fail, there is most likely a problem with the Integration Broker setup for O-SES.
Round Trip Test

4. Test the search on the Search Test Page. PeopleTools > Search Framework > Utilities > Search Test Page. There is a button on this page to Clear Security Cache, and I found a couple of times that when I did the clear that searches began to work. I haven’t looked into the specifics of the cache it is clearing, but I just noted that this worked in a couple of cases.
Search Test

5. Make sure the Security Permissions PTPT3100, PTPT3200, PTPT3300 are setup on your administrative user. I also made sure that the PTPT1000 list had permission to the searches that I had deployed under the new tab for permission lists: Search Groups.
Search Permissions

6. Turning on the search dialogue box in the headers. First you need to turn this feature on, which is done on the Portal General Settings page: PeopleTools > Portal > General Settings.
Turn On Global Search

6b. Search groups are not appearing in the search box. Make sure that the search index is added to the home page context. PeopleTools > Search Framework > Administration > View Search Contexts. For example if you want the Portal Registry to be in the search, you need to add PTPORTALREGISTRY to the Home Page Context Type.
Search Context

7. Can Multiple Environments use the same O-SES database? Yes. The best example of this is on a development environment where you might have DEMO, DEV, TEST, QA all running. You can point all of them to use the same O-SES database.

Oracle SES – Permissions & IB Setup

Well, I have just had my first full exposure to the glory they call Oracle Secure Enterprise Search!  All I can say is damn, that was NOT easy.

The documentation is pretty good that I found, and maybe it is easier on a fresh install but I was doing the setup on an existing environment that I had just upgraded.  The upgrade was for Finance from 8.9 to 9.2.  In the 9.2 application VERITY is no long supported, and the PeopleSoft Search Framework only supports Oracle Secure Enterprise Search (O-SES).  The first trick is to download it from edelivery and in my case I installed the software on my batch processing server.  This install will install a full Oracle database with a webservice that by default runs on port 7777.  There is a bunch of setup that needs to be done to get this working, but the documentation I had for the install was very good for this part.

Some of the next parts I thought were a little difficult to follow, and so the first item is, I used my system start user as my main user, and made sure it had the following roles:

Search Administrator, Search Developer, Search Query Administrator, Search Server

I also have a custom permission list that this user has access to and I made sure that the permission was assigned the search group: PTPORTALREGISTRY.  This appears to be a new security element in the permission lists.

The new Search Framework uses a ton of IB service operations to do all of its work, and one element you need to do is set the Portal Content & Portal URI text fields on the Node for all the local nodes, otherwise the search results will return incorrect content reference paths (extra:  don’t forget the “/” at the end of the URI).

Now, I also inactivated all my integration broker routings for the default local node after the upgrade so no IB would unnecessarily be taking place.  This might have been a bad idea, but old habits are hard to break.  Since O-SES uses the IB for its Search Framework, the following Service Operations need to be active with the routing turned on!

Service: PT_SES – Service Operation: PT_SES_CREF_GET, PT_SES_USERSEC_GET, PT_SES_INIT,

Service: PTSF_META_DATA: Service Operation: PTSF_GET_GROUP_CAT_LBLS, PTSF_GET_SRCH_CAT_DET, PSFT_GET_SRCH_GROUPS

Service: PTSF_SECURITY: Service Operation: PTSF_AUTHENTICATEUSER, PTSF_GETSECATTRVALUES, PTSF_GETUSERROLES, PTSF_POSTPROCESS_FILTER, PTSF_VALIDATESRCHUSER, PTSF_VALIDATEUSERROLE,

Service: PTSF_SES_FEED – Service Operation: PTSF_CRAWLER_CFG, PTSF_SES_CRAWLSTATUS, PTSF_SES_GET_CONTROL_FEED, PTSF_SES_PROCESS_ERRS, PTSF_SES_SCHEDULED_FEED

Service: ADMINSERVICE:  Service Operation: CREATE, CREATEALL, DELETE, DELETEALL, EXPORT, EXPORTALL, GETAPIVERSION, GETSTATE, START, UPDATE, UPDATEALL

Service: PTFP_FEED – Service Operation: PTFP_GETPREPUBFEED  (not 100% sure on this one, but I turned it on along the way).


Make sure you add the PTPORTALREGISTRY to the Home Page Context Type, I added mine and made it default.  I also found that I was getting no returns and then after a day of thinking about things I tried again and everything appeared to be working fine.  I believe that the system was bounced web and app during that time, so if all else fails that might work!


Good Luck!