Share via

FIM 2010: Practical Alternative to PeopleSoft WebServices MA

  • Article

Introduction

 Lots of projects involve the use of PeopleSoft as the system of record for HR driven provisioning with FIM.  

This article discusses a practical alternative to the PeopleSoft web connector, under certain circumstances.

 

PeopleSoft WebServices Connector MA

The current PeopleSoft management agent relies heavily on what is known as “Component Interfaces”(CIs) and is exposed as web services to external systems such as FIM.  Component Interfaces are essentially function calls into PeopleSoft.  For those of you with an SAP background just think BAPI. The Microsoft documentation, while thorough, is a daunting 90-page document that would make most PeopleSoft Admins’ heads spin.  Couple that with likely possibility that the out of the box Windows Workflows for the MA will not function without a lot of tweaking, then you have a perfect storm to grey your hair.  What then is the answer?  Death by a 90-page document full of PeopleSoft web services that will not work on the first, second or third try?  I think not.

 

The Alternative

Peoplesoft has the ability to expose employee data through a SQL view.  You need to ask the PeopleSoft DBAs to build this view and publish it for you. From there you create either a standard SQL or an Oracle MA to read this data.  See my wiki article for a step by step guide on how to create an Oracle MA.

This approach offers a number of advantages compared to the PeopleSoft WebServices MA.

  1. Show Rapid Value - Most PeopleSoft Admins can quickly get this SQL view up and going compared to setting up all those CIs.  This allows you to quickly demonstrate value and make significant progress while, if you so choose, work on configuring the MS PeopleSoft MA.
  2. Performance - If you work with a large organization, you will get a big boost reading employee objects from SQL instead of calling a web service.  For instance, my current FIM Oracle MA did a full import for 250k employees in just about 6 minutes.  On the other hand, the web service calls would take, um, a while.
  3. Maintenance - Need a new column added?  Have the PeopleSoft DBAs make the addition on their side and you just refresh the schema of the SQL management agent and map it to the appropriate MV attribute.  Want to do this in the PeopleSoft Web Service MA?  Grab a six-pack, some hair dye and have at it, my friend.

There are a few keys fields that you should request from the PeopleSoft DBAs when they create the view.  You want to make sure that the view includes employee objects and the OPRID, which is the equivalent of samAccountName in the AD.  Also get the employeeID, employeeStatus, PositionID and ReportsID as well as HIRE_DT.  You can also request department, job code and title information as well.  There is no manager reference value in PeopleSoft, it is derived from the PositionID and ReportsID.  Let's demonstrate how to calculate the manager in FIM in a future article.

Be sure to stress that you only want employee data that fits the “name rank and serial number” mode.  PeopleSoft has a lot of information that you might want to sync to AD or other target systems so always ask what you can get and what other downstream systems might be able to use it.  Do not include any personal identifying information (PII), if at all possible in this view, like a home phone or Social security number. 

 

The Downside

So what are the negatives to the SQL view approach?

  1. One way street - You cannot update the data directly in the PeopleSoft SQL view.  The PeopleSoft views are built from lots of backend tables so updating data in the view is a no-no.  If you want to update data in PeopleSoft, you are back to calling web services to accomplish this.
  2. No native password sync functionality - If you need to sync a PCNS password change from AD to Peoplesoft then obviously the SQL view won’t support this.  This is where you would have to actually call a PeopleSoft CI to accomplish this.  I am working on a solution for this, so perhaps if it viable I will post more on it.

  

Conclusion

If you have the time and wherewithal to configure the official PeopleSoft web service MA then I say go for it.  Just be sure to publish your findings since there is not a whole lot of information out there on this MA.

A potential compromise is to use the SQL view to make initial progress on your project.  This will allow you to create provisioning services, flow attributes, demonstrate value and buy you time to configure the CIs of the standard PeopleSoft WebServices Management Agent.