Thursday, January 29, 2015

Advantages of using REST-based Integrations in PeopleSoft

REST-based services support were introduced in PeopleTools 8.52, although you may also build your own REST services using IScripts in previous releases (*). With PeopleTools 8.52, Integration Broker includes support for REST services, enabling PeopleSoft to act as both a consumer and a provider.

What is REST?

There is plenty of documentation in the Web about REST, its characteristics and benefits. I personally find the tutorial published by Dr. Elkstein ( particularly illustrating.

In a nutshell, REST can be seen as a lightweight alternative to other traditional Web Services mechanisms such as RPC or SOAP. A REST integration has considerably less overhead than the two previously mentioned methods, and as a result is more efficient for many types of integrations.

Today, REST is the dominating standard for mobile applications (many of which use REST integrations to interact with the backend) and Rich Internet Applications using AJAX.

PeopleSoft Support

As I mentioned before, PeopleSoft support was included in PeopleTools 8.52. This included the possibility to use the Provide Web Service Wizard for REST services on top of the already supported SOAP services. Also, the Send Master and Handler Tester utilities were updated so they could be used with REST.

PeopleTools 8.53 delivered support for one of the most interesting features of REST GET integrations: caching. Using this feature, PeopleSoft can, as a service provider, indicate that the response should be cached (using the SetRESTCache method of the Message object). In this way, the next time a consumer asks for the service, the response will be retrieved from the cache instead of executing the service again. This is particularly useful when the returned information does not change very often (ie.: list of countries, languages, etc.), and can lead to performance gains over a similar SOAP integration.

PeopleTools 8.54 brought, as in many other areas, significant improvements to the PeopleSoft support. In first place, the security of inbound services (in which PeopleSoft acts as the provider) was enhanced to require that the services are consumed using SSL, basic HTTP authentication, and basic HTTP authentication and SSL, or none of these.

On top of that, Query Access Services (QAS) were also made accessible through REST, so the creation of new provider services can be as easy as creating a new query and exposing it to REST.

Finally, the new Mobile Application Platform (an alternative way to FLUID to mobilise PeopleSoft contents) also uses REST as a cornerstone.


Although REST support is relatively new compared to SOAP web services, it has been supported by PeopleSoft for a while now. Its efficiency and performance (remember GET services caching) makes it an ideal choice for multiple integration scenarios. I'm currently building a mobile platform that interacts with PeopleSoft using REST services. This is keeping me busy and you may have noticed that I'm not posting so regularly in this blog, but hopefully in some time from now I will be able to share with you some learned lessons from a large scale REST implementation.

(*) Although it's possible to build REST services using IScripts, the Integration Broker solution introduced in PeopleTools 8.52 is considerably easier to implement and maintain. So, if you are in PeopleTools 8.52 release or higher, Integration Broker would be the preferred approach. If you are in an earlier release, actually a PeopleTools upgrade would the preferred approach, but I understand there might be other constraints. :)


Anonymous said...


Can peoplesoft consume REST service from 3rd party service

Javier Delgado said...

Sure, but the level of REST support strongly depends on the PeopleTools release. Let me know on which release are you and I can tell you what can and what can't be done.


Anonymous said...


Thanks for the good information. Following the previous response, could you please elaborate on REST support on Peopletools 8.53.19 and maybe add a little comparison with Peopletools 8.54?

Javier Delgado said...


Sorry for the delay. Hectic times!

Anyway, there is not so much difference between PeopleTools 8.53 and 8.54 regarding REST. The big leap was made in 8.53, so in 8.53 is a pretty mature technology.

Using the Cumulative Feature Overview tool (CFO), you can check the specifics, but as I say, I don't think there is nothing significantly improved regarding REST:,P18_X_IMG_HID:PT,PT.gif

Anonymous said...

Hi Javier,
I am at peopletools 8.52.Can I consume third party REST services.Will 8.52 supports JSON.?(Shall I also send SOAP based Request to third party since I am not having knowing on REST)
Please let me know how to proceed.?

Javier Delgado said...


You can use REST services in PeopleTools 8.52, but not JSON as it began to be supported in PeopleTools 8.53. If you absolutely need JSON, you may use Java classes in PeopleCode which may do the trick. Jim Marion's blog contain a good deal of information about is (

You can always use SOAP if it is a possibility from the Third Party point of view. Whatever can be achieved in JSON, can also be done in SOAP. It is true that it is probably less efficient, but unless you're having a big volume of integrations, it shouldn't affect you.

I hope this helps.


Anonymous said...

Thanks Javier for your valuable reply.

Anonymous said...

Hi Javier,
I have a requirement to utilise a third party REST API.In this, from peoplesoft I need to pass data to third party rest webservice and it will process data and return back a string to peoplesoft.
I am new to REST API.Could you please guide me how to approach on this?
How to differentiate consuming webservies&providing webservice in REST?

Thanks in advance.

Javier Delgado said...


I guess the best option would be to have a conference call so I can give you some guidance on this. Please let me know your availability and I'll try to help.


dsfdsf said...

Hi Javier,

We in the process of creating REST Webservice for our Mobile App. We are facing a caching issue during webservices call. We havent used the SetRestCache method explicitly. Will like to know whether the Server side caching is enabled by default for GET methods when using REST web services.

Issue occurs when using the same URI, the output remains same irrespective to the code changes to OnRequest method. We have to make some changes to the URI before the changes reflect.

We would like to disable this type of caching so that we dont have to keeping changing the URI.

Using 8.54 Peopletools.

Javier Delgado said...

That shouldn't be the behaviour. My suggestion would be to report it to My Oracle Support, as REST services should only be cached on explicit calls to SetRestCache.

Many thanks.


Gaurav Rajput said...

Hi Javier,

i have created one REST Based web service and in service operation response content-type is set as application/json and want to enable the application/xml as additional content type in response message in case any user wants the response in that format.

but whenever third party user is sending request with additional accept tag as application/xml in request header, response must go in xml format but same is not working response message is getting generated in json only.

can you please help here..