PeopleSoft Integration Broker

As I have indicated earlier in my previous post, I am currently part of the 70+ person team that is in the implementation phase of the PeopleSoft Campus Solutions 9.0 for the Student Information System.  In charge of Security, in a nutshell I am in charge of who has access to what.  We started with the usual DEV, TST, QA & PROD environments.  Now, I am also in charge of Security for the Enterprise Portal instances as well.

In this article, I just want to share some experiences with the PeopleSoft Integration Broker that hopefully would be beneficial for everyone else.  After 3 year of working with PeopleSoft, I could not help being a conservative.  PeopleSoft through now Oracle University provides some foundations through their classes.  I took PeopleSoft Security fundamentals in their campus in Atlanta.  And recently had the Integration Tools rel. 8.48 training as well.

The classes were great way to be familiar with the “basic” concepts.  Unfortunately, they are not enough to prepare one for the real world experiences.  Building Permission List, and Roles, and User Profiles, are what constitutes the bulk of PeopleSoft Security work.  And for starters, they are straightforward and to the point.   In my case, the complexity shows its true color when Admission team came up with Security Matrix that details more than 2500 pages for 20+ permission lists & 10+ roles.  That was only in Wave 1.

In Wave 2 of the implementation phase, Student Records decided to be more granular and came up with 1500+ pages for 40+ permission lists and 30+ roles.  And soon, Financial Aid and Student Finance would come into play in the next Wave.

If that is not enough to provide me a daily dose of headaches, then almost out of the blue, we had the requirements to support the Enterprise Portal as well primarily for the Self Service users: Applicants, Students, and Faculty/Advisor.

WIthin this context, the Self Service Applicants data would come in through the WHOIS database on the daily basis.  Those profiles would then be created through Mass Change, and finally be “copied” or “synched” over from the Campus Solutions PS instance to the Enterprise Portal.

The User Profiles “synch” operations is accomplished through the USER_PROFILE & DELETE_USER_PROFILE Web Services (Service Operations) that would have to go through the PS Integration Broker.  Those two Service Operations are Asynchronous One Way.  The PS Campus Solutions instance is setup as the “source” or “publishing” node, whereas the PS Enterprise Portal is setup as the “subscribing” node.

Here are some of Security & General key points from our experiences while trying to support those 2 Service Operations in place.  First, by default both Service Operations allows PTPT1000, the delivered PS Permission List that is part of the PeopleSoft User Role, “Full Access”.  The DBAs always log in with PS Super User, hence PeopleSoft User role and PTPT1000 permission list, and they had no problem experimenting with both operations.  We had our custom “UV PeopleSoft User” Role that are not associated with the PTPT1000 permission list.  So when I logged in and created a User Profile, it did not “synch” up to the Enterprise Portal because I did not have the appropriate security.   Thus, if you have a custom permission list for your enterprise, you need to give “Full Access” to that permission list to those Service Operations Security.

Secondly, and not least important, in order for anyone to have access to the USER_PROFILE Service operations, his/her User Profile would also have to be present in both Campus Solutions (CS) and Enterprise Portal (EP) instances.  This may seem minor point but unfortunately not emphasized enough by PS in the documentations and/or in training classes.  Again, the DBAs always logs in as PS, thus they would have no problem because PS “Super User” always exists BY DEFAULT in both CS & EP instances.  We spent hours until we realize this seemingly minor points.

Advertisement