There is a lot of information to cover about Oracle Secure Enterprise Search and PeopleSoft. As I was writing this I decided it became too much for a single post, so I’ve decided to break it into at least three posts and maybe four:
- Part 1 – SES Installation: Installing the SES product for PeopleSoft
- Part 2 – Integration Configuration: Configuring PeopleSoft and SES to communicate properly
- Part 3 – Administration: How to administer the PeopleSoft/SES functionality
- Probably Part 4 – PeopleSoft/SES troubleshooting: Troubleshooting tips and methods for the SES/PeopleSoft relationship
Oracle Secure Enterprise Search is now the new standard search engine for PeopleSoft with the release of the PeopleSoft 9.2 applications. SES support was introduced in PeopleTools 8.52 with the new PeopleSoft Search Framework. You can use SES with older applications, however you may need to create search indexes yourself because only the newest Feature Packs may include delivered indexes, HCM 9.1 FP 2 for example.
The PeopleSoft Search Framework provides a standardized method for creating and maintaining search indexes for PeopleSoft that should be considered an improvement over what was required previously. Very briefly, the Search Framework Designer is used to create a search definition based on PeopleSoft Query. In the definition you can implement security, data mapping, categories, and related searches for example. The search is then deployed to Oracle SES through the Search Framework Administration pages. You then run an AE which will create your index and publish a feed for Oracle SES and initiate the crawler on the SES side. All the interaction between PeopleSoft and Oracle SES is via Integration Broker.
Verity is no longer supported for the 9.2 applications or later but is still supported in 8.53 for older applications. SES is a separate product that can be used to index and search just about anything. According to documentation no additional licenses are needed to use SES with PeopleSoft, so a limited use licenses is probably wrapped into the standard PeopleTools agreements for 8.52+. SES includes Weblogic, Oracle Database Server, and the SES Application itself. From my understanding Oracle does not support the separation of these components and has stated “SES is packaged as a ‘software appliance’ where Oracle database, mid-tier, and the SES application are all tightly integrated and shipped in a single bundle”.
When planning your deployment of SES into your environment consider the following.
- One SES install can handle/index more than one PeopleSoft application
- SES uses an _DBNAME identifier internally to differentiate PeopleSoft applications/instances
- PeopleSoft users do not have this differentiator when querying but leverage other security features (although test search pages may provide holes)
- SES can only use one PeopleSoft system as a user repository
- Because it can only point to one source system it leverages PeopleSoft’s Single Sign-On functionality to properly function in a shared instance. (I have not yet personally setup SES in a shared capacity)
- SES will install it’s own database server and Weblogic instance
- This is an older version of SES and OS support is lacking newer OS versions, specifcally:
- Windows Server 2008 R2 is specifically not supported.
- OEL and RHEL 6 are both not supported.
- IPV6 is not supported
- I checked the certification matrix on MOS and confirmed it does not support the newer OS’s.
- Minimum Disk space requirements vary by a couple GB but max out at 7.6 GB on x86-64 Linux (1.7GB for initial DB)
- Between 2 – 6 GB of RAM and 4 – 20 GB of disk space would be required for indexing between 100,000 and 1,000,000 documents respectively
Because of the points detailed above, I’ve decided to implement SES as a standalone install, even in Demo and other non production environments. I do not want to comingle the SES Application or it’s Database with my PeopleSoft App or Web servers. I will however setup a single instance for my DEV tier. So my first step was to setup a new VM using my kickstart process. The new VM is my standard minimal install of OEL 5 which is updated to 5.9. I created the VM with 2 GB of ram, 1 CPU, and a 20 GB data drive to install SES on. In a production environment you may want to mount certain paths to different storage. Particularly the database files which end up in $ORACLE_BASE/oradata.
Once you have your target system ready review the documentation for all the prereqs. These looked pretty standard to me. Since a database instance is being installed it has all the normal kernel and additional rpm requirements. My normal kickstart process handles this with a combination of the oracle_validated rpm and a post kickstart script.
Download the SES media from Oracle Software Delivery Cloud and unzip both files to the same location, they unzipped into a directory named ses_11_1_2_2_0_linux64 for me. Login to your system and become the user you want to do the install as, oracle in most cases. I’ve decided to make this install similar to our database installs so have chosen to use the ORACLE_BASE location below. Set ORACLE_BASE prior to running the installer. Once set go to your install media and run the ./runInstaller script.
[oracle@psses ~]$ export ORACLE_BASE=/u01/app/oracle/product/220.127.116.11.0
[oracle@psses ~]$ cd /mnt/media/8.53/ses/ses_11_1_2_2_0_linux64
[oracle@psses ses_11_1_2_2_0_linux64]$ ./runInstaller
Starting Oracle Universal Installer…
Checking Temp space: must be greater than 80 MB. Actual 7389 MB Passed
Checking swap space: must be greater than 150 MB. Actual 5951 MB Passed
Checking monitor: must be configured to display at least 256 colors. Actual 16777216 Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2013-06-22_03-40-33AM. Please wait …[oracle@psses ses_11_1_2_2_0_linux64]$
Note: If you don’t set ORACLE_BASE it defaults to $HOME/oracle/product/18.104.22.168.0/ or /home/oracle/oracle/product/22.214.171.124.0/ in my case, after seeing this default, I chose to use the ORACLE_BASE I used above. Originally I tried ORACLE_BASE as /u01/app/oracle. But after seeing the generated default paths I didn’t like it either.
Note: Search Server Name is limited to 8 characters
As previously mentioned PeopleSoft supports using a single instance of SES for multiple PeopleSoft environments so I’m just going to use the search name sesdev and I will eventually include all my dev apps here. You may or may not be able to create a single SES instance for all your non production environments. I do not think I can because I’ve purposefully broke Single Sign-On between tiers (DEV/QA). I also think there is a benefit to having a seperate DEV/TST/QA SES instance. For more details on shared instances read ID 1560981.1 on MOS and a section in Chapter 8 of the PeopleBook for 8.53. I did not find a lot written on the topic yet to pull from.
Now that I have the installer running we see the default port is 7777. I look at my new system to make sure port 7777 is not already listening and I check /etc/services to see what might be assigned to that port.
[oracle@psses ses_11_1_2_2_0_linux64]$ grep 7777 /etc/services
cbt 7777/tcp # cbt
cbt 7777/udp # cbt
[oracle@psses ses_11_1_2_2_0_linux64]$ netstat -a |grep cbt
Looks clean so I’ll leave the default in place, though I noticed PeopleSoft documentation referenced port 7779. I will leave the software location at $ORACLE_BASE. Home I can’t change and I’ll leave data storage alone as well. I didn’t get far before my first problem, but this one is easy. The password needs to be 8 char with 1 letter and 1 number, and no special chars.
I also want my oraInventory to be the same path as my database server, so I changed it.
After hitting next, we move on to waiting for products to load. During the Prereq checks I got a warning. As mentioned previously, these are all handled by my kickstart process so I just glanced at these. Now lets see what the problem is.
Reviewing the log shows something interesting,
Checking for ip_local_port_range=1024 – 65000; ip_local_port_range=9000 – 65500. Failed <<<<
Check complete. The overall result of this check is: Failed <<<<
Problem: The kernel parameters do not meet the minimum requirements (see above).
Recommendation: Perform operating system specific instructions to update the kernel parameters.
ip_local_port_range refers to the Ephemeral Port Range the system can use, which is a topic in OS administration. Oracle would like to have ports 1024-65000 available to use, I think access to 56,500 ports is enough. I don’t think access to another 7,476 ports is going to make or break this app for. If it’s going to use 56,500 ports it could certainly run through 63,976. Therefore, I decided I was going to ignore this “warning”.
If you rather conform to the recommendation, you can set it in /etc/sysctl.conf by adding the line
net.ipv4.ip_local_port_range = 1024 65000
Or you can
echo “1024 65000” > /proc/sys/net/ipv4/ip_local_port_range
to change it temporarily just to rerun the test. But I just verified it in OUI and moved on.
Finally, SES is installing.
Run orainstRoot.sh as root.
[root@psses ~]# /u01/app/oraInventory/orainstRoot.sh
Changing permissions of /u01/app/oraInventory
Adding read,write permissions for group,Removing read,write,execute permissions for world.
Changing groupname of /u01/app/oraInventory to oinstall.
The execution of the script is complete
At the completion of the install you get a window that displays some URL’s copy them off to keep. They are similar to these:
Search Administration Tool URL:
WebLogic Administration Console URL:
If you are security minded like me and leave the host based firewall on, now would be a good time to open port 7777, so we can connect to SES.
After the installation there is one final thing to take care of. The version of SES we installed lacks the proper mds-owsm datasource, fix it by following these steps (which were clearly documented in the install guide)
[oracle@psses ~]$ export ORACLE_SID=sesdev
[oracle@psses ~]$ sqlplus sys/<password> as sysdba
Note: sqlplus / as sysdba failed to connect
SQL> create user owsmuser identified by <your password>;
SQL> grant connect, resource to owsmuser;
Once the user is created log in to the Weblogic Admin console
Lock and Edit the configuration
Navigate to Services –> JDBC –> Data Sources
Copy the Connection Pool URL for EnterpriseSearchDS, it should look something like
Paste this into the Connection Pool URL for mds-owsm
On the same page in the Properties box change the user=DEV_MDS from DEV_MDS to
Enter the password you used for this user in the fields following Password/Confirm Password fields
Save and Activate your changes.
You can also use the http://<your FQDN>/monitor/check.jsp page to validate the installation along with the normal search page.
The install should now be complete. In part 2 of this series of posts I will go over how to configure HCM 9.2 to integrate with this SES instance.