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.

When doing the upgrade the upgrade template has you modify the  PTIBUPGRADE.DMS script and you are to set it according to your environment but if you are like most people you won’t have a clue what to set in the script. This script I believe occurs if you are upgrade from anything before 8.49, but that is somewhat unclear from what I have read.  I know I have been encountering this dms for years now and everytime I just shake my head.

Here is what it says: “Edit PS_HOME\SCRIPTS\PTIBUPGRADE.DMS and make the necessary modifications as documented in the script. User level node security and transactional security have been added as of PeopleTools 8.48. Service namespace information, a low-level user on the node, and a low-level permission list for service operations, need to be specified. Consult with your Integration Broker specialist for assistance.”

Most likely you are considered the IB specialist so that is why you are now reading this post.

Firstly, the script is a tools base script so you will want to look for it in your PS_HOME\scripts directory.

Default Namespace – This is based on the XML standard “XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references” see http://www.w3.org/TR/1999/REC-xml-names-19990114/. When IB generates WSDL, SOAP messages we refer to the namespace provided in the service , during the upgrade all the service’s that are created are assigned to this namespace.  Interestingly there is no validation done against this namespace value, and it does not even have to be an HTTP URL,  however, it is a best practice to name one.

Finance: http://xmlns.oracle.com/Enterprise/ERP/services

HRMS: http://xmlns.<yourcomanyname>.com/Enterprise/HCM/services

Default UserID – Starting with 8.48 PeopleTools an inbound service operation can be invoked as a particular user , previously it was the user assigned in integrationGateway.properties.

The user assigned should have permissions to all messages and CI’s.

Finance: VP1  (or a customized user id that has similar permissions)

HRMS: PS (or a customized user id that has similar permissions)

Permission list – IB has now introduced user based security to follow the Peoplesoft security model, by assigning services to permission lists, assigning permissions to roles, and assigning roles to users who in turn invoke the service. All services created during the PeopleTools upgrade will be assigned this permission list:

Finance: PTPT1000

HRMS: HCPPALL

When configuring your PeopleSoft environment to use Integration Broker using a secure gateway, sometimes you will get a messaging telling you that the gateway connectors cannot be loaded.  If you use the http:// address it will work but as soon as you use the https:// link it fails to load.

If you check the application server logs, you will most likely find a message:

PSJNI: Java exception thrown: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Untrusted Server Certificate Chain

This is assuming that you have the SSL certificate installed in the keystore correctly and you are able to get to the PIA site using the https address without issue.  The root certificate associated with your SSL certificate is not in the certificates stored within PeopleSoft.  If you navigate to:  PeopleTools > Security > Security Objects > Digital Certificates, you can click on a + link and select a root ca, and then give it a description, refresh the page and then click on the import link, next you need to insert your certificate data for each root certificate.  There are several ways to get the root ca certificate, just note that you may need to insert the intermediate certificates as well.

Commonly when setting up a new system, you will attempt to post a report and it will stay in posting status for a long time and eventually return a Not Posted status.  If you review the details on the message log you will find something similar to:

Error: The XML file returned by the webserver is invalid, xml document object creation failed.

When setting up a report node (Home>PeopleTools>Process Scheduler>Report Node) and you use the SchedulerTransfer as the transfer tool, you must ensure that two things are in place.

1. Make sure that the Default Local Node, has a password assigned to it.  Without a password it will always fail.

2. Make sure the user that started the Process Scheduler has the Role: ProcessSchedulerAdmin assigned to their profile.

This should resolve the problem.