We’ve been laser-focused on integrating PeopleSoft into SharePoint for a couple of years and we’ve learned a few things on the way. In fact, before we developed InFlight, we took some serious deep dives into PeopleSoft to SharePoint integration with both WSRP and Web Services and this post shares what we learned about each one.


We’ll start with Web Services for Remote Portlets (WSRP). In a nutshell WSRP provides the ability to drop interactive, existing PeopleSoft components into SharePoint pages as “widgets”.  Out of the box, SharePoint and PeopleSoft have slightly incompatible implementations of the WSRP “standard” — PeopleSoft produces v1.0, SharePoint consumes v1.1 — and even if you should happen to get the two talking, WSRP really struggles with performance. Back in early 2009, the InFlight product started as a WSRP Consumer. However, the limitations of the protocol forced us to develop a higher-performing solution to meet the demands of enterprise-scale customers. Some of our concerns are detailed here.

The Session Replication Limitation

From the PeopleTools Portal Technology PeopleBook:

WSRP and Server Cluster Configuration Considerations

Support for web server clustering with session replication is supported. However, the open source products Enterprise PeopleSoft uses for WSRP functionality, Apache Pluto and WSRP4J, do not support serialization. If you intend to implement web server clustering with session replication and WSRP functionality, you must set up two separate web server environments. The web server environment servicing WSRP functionality cannot have session replication enabled.

What this means is that:

a) if you want to use session replication in your web server cluster (most commonly, to allow failover), you’ll need to serve WSRP from a different cluster.

b) that second cluster can’t support session replication, so you’ll have to address failover some other way, or do away with it altogether.

Draw your own conclusions about the implications in your environment.

More Layers

If you look at the guts of a WSRP transaction, you’ll see that WSRP wraps HTML content in a SOAP wrapper to pass the content back and forth.  Naturally, this is going to be slower than serving the HTML content without the wrapper.  The hit on end-user experience from this overhead will vary by system, but check it out for yourself by setting up a WSRP Consumer/Producer pairing between two PeopleSoft environments.   This will give you a feel for the best case scenario without having to navigate the headaches of WSRP1.0 / WSRP1.1 discrepancies.  Before you make any call on direction, make sure to try this through a load testing tool that simluates your peak user activity.

New Sessions and SSO

While PeopleSoft appears to fully support WSRP, it also pushes JavaScript out through WSRP that tries to trigger new, non-WSRP-based sessions.  So, even if you expose a top-level page (like Personal Information Summary) through WSRP, there’s no guarantee that underlying pages support WSRP.  What users end up with are new browser windows or new tabs, asking for PeopleSoft credentials before delivering the new content.  Yikes.

Worse yet, the WSRP and HTML publishing channels do not share the same authentication mechanism.  To provide users a reasonably smooth experience, you would actually need to implement Single Sign-On twice. Double yikes.

Our Take: WSRP  

Bottom line: while the readers are invited to draw their own conclusions, from our perspective WSRP looks great on paper, but in the case of SharePoint and PeopleSoft, it’s simply not ready to deliver a good user experience. This is especially true in cases where the user base exceeds 500 users, as it will for most PeopleSoft customers. It’s for these reasons that we simply do not consider WSRP a viable PeopleSoft SharePoint integration option. Don’t take our word for it — try it out for yourself by setting up a WSRP Consumer/Producer pairing between two PeopleSoft environments.

Web Services

To start building a PeopleSoft SharePoint integration solution in-house, your organization will likely need to implement a solution using Component Interface-based web services.  This requires that that you re-create the user interface (UI) of each PeopleSoft component that you want to surface into SharePoint using technologies that are native to SharePoint; .NET forms, InfoPath, or Business Connectivity Services (BCS).

In many cases, your organization will need to write data back into PeopleSoft, necessitating that you perform data validation and handle any errors that PeopleSoft may return. Additionally, Component Interface-based Web Services don’t always expose all of the functionality that exists in the PeopleSoft web UI. Security concerns will also need to be addressed.

Version Changes

Building your own PeopleSoft SharePoint integrations with web services could pose significant challenges during subsequent PeopleSoft upgrades. Considering the costs and challenges organization’s already face when upgrading PeopleSoft, this should not be overlooked when evaluating web services as a potential integration technique. Here’s why:

PeopleSoft’s web services are sensitive to changes in PeopleTools and PeopleSoft application versions. A version change means significant regression testing in the best case; additional development, however, is the more likely outcome.

A Tad Bit Stubborn

It is noteworthy that PeopleSoft’s web services are particularly stubborn to work with in .NET applications because of the way in which the data is wrapped.  Exposed elements are never presented as simple data types (like integers and strings).  This makes the development effort significantly more time consuming relative to other web services-based applications.


Another consideration is security. To maintain the same role and permission-based security that PeopleSoft delivers through its UI (particularly if row-level security is involved) will require an organization to effectively recreate the PeopleSoft security stack.  Not for the faint of heart.  Issues like this are the reason why there’s a huge disparity between the effort required to get a simple proof of concept working with web services, and the effort required to make that solution “ready for prime time” in a production environment.   The devil’s in the details. The below video illustrates the fundamental differences between InFlight and web services-based solutions.

Our Take: Web Services

In short, if you pursue a web services approach to PeopleSoft to SharePoint integration, be prepared to deal with a healthy dose of uncertainty, cost overruns or worse; an epic fail should the complexity of security or error reporting prove too costly to overcome. Also, what if you wanted to make PeopleSoft mobile? There’s an easier way.

Have you endeavored to integrate PeopleSoft and SharePoint using either WSRP or web services? If so, please, leave a comment describing your experience. Did it work, did you bail? Let us know.

Likewise, if you are considering either technique for an upcoming PeopleSoft SharePoint integration project and would like to discuss your approach or other considerations, we’d be happy to speak with you. Drop us an email at sales@inflightintegration.com and we’ll get back to you as quickly as possible. As always, follow us on Twitter @inflightcorp

Leave a Reply

Copy link