Integrating to any large system can pose a number of challenges. Over time, we’ve had to integrate to SAP, Siebel, Peoplesoft, and a variety of other systems. One thing we’ve learned is that it’s always possible but also brings with it a number of challenges. Today I wanted to focus on integration to Peoplesoft. Part of this post comes from experience and part from additional research. Depending on the portal vendor chosen, you have a number of choices regarding integration to Peoplesoft. Before diving into integrations specific to a vendor, let’s first address approaches any portal vendor can use. These approaches will work although there exist a number of caveats that we will address in each section.
WSRP
The Web Services Remote Portlet v2.0 standard offers the option of Peoplesoft delivering a producer portlet for almost any view inside of Peoplesoft. You can do this using Peoplesofts Integration Services broker. The Services Broker allows you to identify pagelets and click a checkbox to surface that as a WSRP producer. At that point in time, you only need to go to the portal and configure a WSRP consumer.
When to consider WSRP
WSRP works best when you want to have Peoplesoft deliver a fully formatted set of functionality with a minimum of fuss. When everything is properly configured, all you need to do is create a consumer and point to the producer. You should also consider this when trying to push processing from the portal server(s) to a back end system. Since the consumer receives fully formatted content, the only thing it’s doing is passing security credentials.
If you feel that the delivered Peoplesoft UI does not meet your users’ needs or if you wish to make slight tweaks then you should consider a third party product or use web services / JCA.
Caveats
We should note that WSRP remains a largely untested approach. We have seen it work with a few clients. We have also spoken with other services firms and found that it can work but you will have to work through some kinks. We also never recommend that anyone use a tool supporting only WSRP 1.0. Use of the immature (vs 2.0) spec introduces serious security and single sign on issues.
This approach works for Peoplesoft 8.48 and later. However we have discovered that the specific approach and support for this approach varies depending on version and patch level. We have integrated to Peoplesoft Portal from a variety of portals but have always encountered issues on the Peoplesoft side in getting the right configuration, version, and patch level. Our advice to you would include the allocation of sufficient time with the Peoplesoft team to work through those issues that will arise regardless of portal vendor.
Web Services
Similar to WSRP, Peoplesoft will also allow you to instantiate web services and create WSDL’s for those services. This approach relies on Peoplesoft’s integration broker to take Component within Peoplesoft and allow them to be referenced as web services. Out of the box, Peoplesoft instantiates nothing as a web service. However, the People Tools does provide a decent interface to setup the services you need.
We give a much abbreviated version of how to do this below. We get to the screen below via: Peopletools>Integration Broker>Web Services>Provide Web Services
When to consider Web Services
At this point in time, almost every programmer should be familiar with web services so we won’t delve into SOAP, chatty aps, number of round trips per service call, etc. We have seen that using a direct api can decrease response time by a statistically significant margin so there are times to use and not use web services.That said, web services will work regardless of vendor technology and every major development IDE supports it.
Web services for the most part typically returns data as xml. This implies that when using web services, the portal developer will have complete control over the user interface. This also means that use of web services will incur a greater development cost when compared to WSRP. Given the bloated and difficult UI that ERP vendors typically produce, it’s entirely feasible to choose web services when the UI has to be as easy to use as possible. You just have to define when to use one or the other.
Caveats
As noted with WSRP, this approach works for Peoplesoft 8.48 and later. However we have discovered that the specific approach and support for this approach varies depending on version and patch level. We have integrated to Peoplesoft Portal from a variety of portals but have always encountered issues on the Peoplesoft side in getting the right configuration, version, and patch level. Our advice to you would include the allocation of sufficient time with the Peoplesoft team to work through those issues that will arise regardless of portal vendor.
Cohabitation
Portal integration need not surface Peoplesoft transactions or data within the portal itself. In some cases, it may make sense to take an existing web UI like that in the oob eConnect application or with Peoplesoft Portal and make them cohabitate. Successful cohabitation depends on the following:
- Single Sign On: Define a tool and an approach so that connecting to the HR site doesn’t mean a second sign on. You can do this manually via shared tokens or you can do this with tools like Siteminder or CAS.
- Shared or similar themes: The key to a shared experience is a similar UI. While this is not entirely possible given the different UI standards between the portal and the an HR or financial site in Peoplesoft, you can theme both with a similar logo, brand look/feel, head, footer, and navigation approaches.
- Shared Taxonomy: We are big fans of shared enterprise taxonomy. Don’t treat any site as an island. If you have a defined level one navigation that works for the majority of your users then introduce that exact same navigation in the Peoplesoft portal or oob sites.
Oracle WebCenter Specific
Despite some of the cons to the WebCenter framework, Oracle has one major strength. It has already integrated some tools like UCM and has a roadmap based on the integration via ADF and WebCenter of Peoplesoft, Siebel, OBIEE, Hyperion, and other tools. Over time, Oracle’s integration to its tools should be easier when compared to other portal vendors.
We can see some of that today with the following:
Web Services to ADF
Oracle WebCenter supports the consumption of web services via it’s IDE and use of ADF task flows. ADF represents an extension of the JSF standard and those flows translate to pages in a traditional web application. JSF converts to portlets very easily where page flows become portlet views. In many ways, this can be compared directly to a traditional portlet development model, the labels or terms just differ enough to demand an explanation.
Access to the Java API (JCA)
Peoplesoft provides access to a Java API called the JCA. These can be called from an Java based application. Web Services and the JCA provide the same access to data and transactions within Peoplesoft. However, JCA will most likely perform better than web services.
IBM Specific
As should be expected from a company dealing with many different heterogeneous organizations, IBM supports some options specific to its support of Java and its Web Experience Factory tool. Like all options, there exist pros and cons to the approaches. We list the two options below as approaches to consider but you will still have to make a decision based on your specific circumstances.
Access to the Java API (JCA)
Because IBM’s Portal runs as a Java based application, it can use the Peoplesoft JCA. Peoplesoft provides access to a Java API called the JCA. These can be called from an Java based application. Web Services and the JCA provide the same access to data and transactions within Peoplesoft. However, JCA will most likely perform better than web services.
Web Experience Factory Connector
IBM provides their Web Experience Factory 4G development tool for use in developing widgets, portlets, iOS, and Android OS based applications. One of its strength lies in its ability to connect to a variety of different data sources. This includes an out of the box Peoplesoft Connector that should cut down on development time when creating custom portlets.
Liferay Specific
Liferay runs on a variety of different Java application servers like Tomcat, JBoss, Weblogix, and WebSphere. As such, Liferay JSR 286 portlets can easily access the Java API provided by Peoplesoft.
Access to the Java API
Because IBM’s Portal runs as a Java based application, it can use the Peoplesoft JCA. Peoplesoft provides access to a Java API called the JCA. These can be called from an Java based application. Web Services and the JCA provide the same access to data and transactions within Peoplesoft. However, JCA will most likely perform better than web services.
SharePoint Specific
BTR Group
BTR Group offers a set of tools that solve SSO and interface issues when integrating SharePoint and Peoplesoft. BTR offers out of the box web parts with what it claims are a nicer interface than the out of the box Peoplesoft interface. It’s interface depends on the existing web based Peoplesoft application. You can copy the Peoplesoft content url and put it into the web part to surface that application. You can also choose to use the Peoplesoft look and feel or have the web part use the theme from SharePoint. Aside from that though, the UI relies on the UI from Peoplesoft.
You should consider this approach if concerned about Microsoft’s support for WSRP or if you want a little more flexibility in using SharePoint’s look and feel.
References
This information came from both our personal experience and a variety of sources. We reference those sources here:
- BTR Group Product Information
- Great document outlining integration to Peoplesoft. It’s titled SharePoint Integration but the concepts cut across all technologies as it’s more Peoplesoft specific.
- Web Experience Factory Peoplesoft Connector Information
- IBM Portal configuration for the Peoplesoft JCA
A couple things to consider: PeopleSoft is a WSRP 1.0 producer, not 2.0. Also, PeopleSoft now supports RESTful services.
Pingback: RE: Integration of PeopleSoft - Forums - Liferay.com
We enjoyed your post, thanks for mentioning InFlight as one of the PS to SP integration techniques. You may find it interesting that the InFlight product started as a WSRP 2.0 Consumer, way back in early 2009. The limitations of the protocol forced us to develop a higher-performing solution. While you can buy a WSRP 2.0 Consumer Web Part from NetUnity that can consume v1.0 portlets (like those from PeopleSoft), other drawbacks still exist, which we note in the following post on WSRP and web services http://inflightintegration.com/big-bucks-no-whammy/
Thanks John. WSRP, even though it’s in version two and major vendors like Oracle and IBM are putting portlets out that use that standard, remains very much a niche approach. Of course, sometimes the other options are worse. It all depends on what you are trying to do and the possibilities open to you.
The information you have shared in this blog is remarkable and thanks for sharing such quality information.