How to Configure SES with Multiple PeopleSoft Instances

by Apurva T. on May 25, 2014

in General

E-SES: Using SES with Multiple PeopleSoft Instances (Doc ID 1560981.1)

 

Requirements for a shared SES:

  1. All the systems sharing the SES should have a unique database name
  2. All of the systems should be on same tools release (different patch level is fine)
  3. When same user id exists on two systems it should be ok for the user to see the search results from the other system with the same user id and should not be considered as security hole (user-id’s are not name spaced)

Though most of PeopleSoft UI controls what categories user can search , there are some areas example search test page which does not restrict this.

4.When decommissioning an environment it should be done cleanly , i.e. UN-deploy all the definitions from PeopleSoft UI

To make sharing possible we do not delete facets\attributes on SES , If this is a development env where new facets are getting added and deleted on a long run there could be performance degradation (attributes and facets are not name spaced)So should consider clean up SES fully or re-installing SES from scratch.

5.If the integration gateway is shared all the default local node names should be unique and the Service Configuration URL , Call back URL should be suffixed with respective default local node names

6.As of 11.1.2.2 release of SES , SES admin UI supports only one single user who has a super user Developers\QA will need access to this SES admin UI in-order to debug / diagnose issues.

7.For production environments SES can be shared only by environments which have single sign on (Thus ensuring that a user in one system is the same user in all other systems)

Note: Starting with PeopleTools 8.53, the information in the SES Identity Plug-in settings, is no longer used to authorize/authenticate PeopleSoft user. Therefore, you do not need to be concerned, when sharing multiple PeopleSoft instances, about the values in the SES Identity Plug-in settings.    However, you do still need to configure the SES Identity Plug-in since it is required by SES.  But you can use dummy values (eg User id = DUMMY and HTTP endpoint = http://DUMMY).

Security limitations while using same SES instance:
SES enforces security using user id but the user id ‘s PeopleTools Search Framework passed to SES, are not name spaced between databases.

Also Read:  Overview of PeopleSoft

i.e. user id VP1 has access to all the documents for user VP1 on any system shared by SES .

Though this kind of search across application pillars is restricted to end user from the PeopleSoft UI (role based search group in global search, permission list based access to other components .. ) , but it is possible to perform such search using search test page.
Thus for production systems, single sign on is required to be configured between environments which share the SES (ex: FSCM , HCM , ELM ,…).

Recommendation:
For non production environments, as long as the database names are unique, customer can share single SES among them assuming that SES machine is sized appropriately and when perform clean up(undeploy Search Category’s and Search Definitions ) before environments are decommissioned.
For production environments, the databases which intend to share SES needs to keep these items in mind:

1. Single signon needs to be implemented among all of the PeopleSoft systems sharing the Oracle SES instance.

2. On the Oracle SES Global Settings, Identity Management Setup page, the PeopleSoft Identity Plug-in only needs to refer to one of the systems sharing the Oracle SES instance.

For example, while other systems will have different HTTP ports and node names, as long as the following URL points to a system involved in the single signon network, it can be used for all systems as the Call Back Properties URL on the Search Instance Properties page.

http://FASTHOST.bigcompany.com:8080/PSIGW/PeopleSoftServiceListeningConnector/HCM_01

3. While you do not need to synchronize user profiles among multiple PeopleSoft systems, if the same user ID exists on multiple systems, it must be associated with the same, individual user. That is, a user ID must be unique for all of the systems sharing the Oracle SES instance, not just a single PeopleSoft application.

Also Read:  What are Important Files on PeopleSoft Application Server

TIPS ON ADDING ADDITIONAL DB STREAMS TO A SINGLE SES INSTALL

SINGLE SIGNON:
Single signon needs to be implemented among all of the PeopleSoft systems sharing the Oracle SES instance

LOCAL NODES:
The default local nodes from the databases need to be different. Normally, what we do is create the default local node as the name of the database, but you can name it whatever you like. On the TargetLocation and Callback URL, the correct database node needs to on the URL and then the gateway properties file needs to have both nodes defined. When indexing is done from a particular db, PTSF appends the local node name to the index so that SES sees them as separate files, even though they might be named the same.

GATEWAY:
If the customer is sharing single gateway — the default local nodes names have to be unique
If the customer is planning to search across both the systems from single systems — the default local node names need to be unique

DATABASE NAME:
In any case the database names needs to be  unique

CALL BACK URL:
make sure that the call back url’s in each search instance page are valid and the gateway is configured properly to handle the URL and the Service operations are active and security is defined properly.
both urls call back properties and service target location must be the same in the search instance

IDENTITY PLUGIN:
On the Oracle SES Global Settings, Identity Management Setup page, the PeopleSoft Identity Plug-in only needs to refer to one of the systems sharing the Oracle SES instance.

Here is the key though:
Once you have created the search instance for the second DB in the  Search Instance page and SAVED, then you need to Update the deployed definitions from this page (see hyperlink at bottom of the page).  And we cant say it enough… the local nodes for each DB must be unique.

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: