How to Configure SES with Multiple PeopleSoft Instances
E-SES: Using SES with Multiple PeopleSoft Instances (Doc ID 1560981.1)
Requirements for a shared SES:
- All the systems sharing the SES should have a unique database name
- All of the systems should be on same tools release (different patch level is fine)
- 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)
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.
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.
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.
