Just ran into a crazy little problem trying to get Oracle Secure Enterprise Search working at a client site that was using a self-signed internal SSL certificate.

In order to get Firefox to accept the SSL connection I had to add the Trusted CA (The Clients CA Certificate) to the Firefox keystore.  I had tried to load the certificates into the Windows keystore but apparently Firefox has its own.

Next When trying to deploy the search index I was receiving the following error:

Service Exception: ns2:AdminAPIRuntimeFault : EQA-15011: The plug-in manager raised an unexpected error. (262,1018) PT_SEARCH.SESIMPL.MESSAGE.AdminResponse.OnExecute Name:AdminResponse PCPC:1452 Statement:20
Called from:PT_SEARCH.SESIMPL.AdminService.OnExecute Name:doService Statement:848
Called from:PT_SEARCH.SESIMPL.AdminService.OnExecute Name:createAll Statement:794
Called from:PT_SEARCH.SESIMPL.AdminService.OnExecute Name:AddPSFTSources Statement:106
Called from:PTSF_DP_SBO_WRK.PTSF_DEPLOY_BTN.FieldChange Statement:139

I found a case on my oracle support: E-SES 11.2.2.2: Deploy Step Fails when Using SSL-Enabled PeopleSoft Integration Gateway: Error “EQA-15011: The plug-in manager raised an unexpected error” (Doc ID 1600736.1), which basically says that the cacerts keystore for the O-SES does not contain the trusted root identity for the SSL Certificate that is being used on the PeopleSoft System. So export the the Root and Intermediate certificates to a PEM format and import them into the cacerts keystore. There turns out to be many cacerts in the oracle directories, and I updated all of them with the new trusted certificates.

Lastly, I bounced the O-SES installation using the searchctl restart command.

Here is a handy little script to figure out what permissions have been granted to a user in SQL Server. For example the connect id user for PeopleSoft needs to have select access to the PSACCESSPRFL, PSOPRDEFN and PSSTATUS tables.  The default connect id is ‘people’.

select p.name, p.type_desc, pp.permission_name, pp.state_desc, pp.class_desc, object_name(pp.major_id)
from sys.database_principals p left join sys.database_permissions pp on pp.grantee_principal_id = p.principal_id
where p.name = 'people'


Recently I have seen several customers have problems after upgrades/splits/maintenance where after they login the homepage is returning not authorized errors or the homepage styling is completely messed up.

I was a little surprised to find that the root of many of these issues was actually based on security. In several cases the upgrades or the HR / CS separation process caused a removal of a permission list from the PSCLASSDEFN table, however, the reference to that permission list on the PSROLECLASS table which ties Roles to Permission lists does not remove the reference. This causes the security to have invalid (null) pointers which causes a serious problems for items that are associated to that security and effects the rendering of the home page among other things.

I found that in my case that after we ran a sysaudit report that the entries that showed up in the Security #31 section were the permission list references that were causing the problem. Once resolved all the renderings starting to perform as expected.

Smart Thinking Newsletter

The Biggest Problem With ERP (And How To Fix It)

ERP Software can be a terrific asset for your company, but any failure during or after installation can lead to massive inefficiencies and a longer period to positive ROI. The best installation involve substantial planning before installation, and a complete implementation schedule – including training for all users.

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.

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.

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.

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.

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.

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.