PeopleSoft Campus Solutions includes a set of web services called Enrollment Web Services (EWS) that enable third-party applications to interact with the Records and Enrollment components.
In this series of articles, we’ll explore how to leverage EWS REST services to perform everyday enrollment tasks such as retrieving study lists, searching courses and classes, managing shopping carts, and processing enrollment transactions.
A Word of Warning
Oracle’s marketing makes these APIs sound like a quick win for integrating external apps with PeopleSoft. They aren’t.
- The web services are largely undocumented. The few docs that exist are incomplete, and it’s hard to determine the required parameters. As a PeopleSoft Expert with decades of experience, I find the official documentation on EWS to be lacking in clarity and depth. The explanations are often too high-level, omitting crucial implementation details that developers need to use these services effectively for basic unit testing.
- There are many aspects of PeopleSoft Campus that were NOT designed from an API-first perspective. EWS is an afterthought, and it shows. Just because these services are “delivered” does not mean they will work out of the box for your use case.
- They aren’t enabled by default, and setup can be frustrating. When you enable these, it is techically a “customization” and when your system gets patches or upgrades you may need to re-apply your changes.
- If your are NOT a PeopleSoft technical person, plan accordingly. You’ll need a PeopleSoft technical expert to debug and research the code and configuration.
- The services are complex and hidden behind poorly documented libraries and application packages. PeopleSoft’s outdated developer tools make it hard to see how the code is structured, what it does, how to debug it, and what parameters it expects.
- I have found through years of headaches that any web services delivered by Oracle are often half-baked and require significant customization and troubleshooting to work in real-world scenarios. EWS is no exception, and I have spent countless hours debugging issues that should have been addressed in the official documentation, or cryptic error messages that turned out to be simple or security configuration issues. Still, the error messages were not helpful at all.
- If I were to create a green field implementation of an external application that integrates with PeopleSoft Campus Solutions today, I would consider building custom REST APIs using PeopleSoft Integration Broker and Application Classes instead of relying on the delivered EWS. This would allow for greater flexibility, better alignment with modern development practices, and improved maintainability over time.
- This also allows you to handle unique situations with the way your school has implemented PeopleSoft. How PeopleSoft was designed and how it is actually being used are often two different things. That is a topic for a book in itself!
- I have personally been down this road where a client wants to build a mobile application that uses delivered web services, only to find out later that the offered services do not meet their needs. This results in wasted time, effort, and budget as we have to backtrack and develop custom solutions anyway.
- Since PeopleSoft was never designed (starting 30 years ago or more) with an API-first approach, the delivered web services often feel bolted on and not well integrated into the overall architecture. This creates challenges for scalability, performance, and long-term support.
SOAP vs REST: We’re Using REST
EWS was initially delivered as SOAP-based web services, with REST versions added in the April 2013 Additional Features pack. Both versions provide equivalent functionality, but this blog series focuses exclusively on the REST-based services.
Why REST? REST services are generally easier to work with from modern web and mobile applications. They use standard HTTP methods, return JSON or XML payloads without the SOAP envelope overhead, and integrate more naturally with contemporary development frameworks. See Understanding SOAP versus REST for more details on the differences between SOAP and REST in PeopleSoft.
The REST service operations follow a naming convention with an _R suffix and _POST method indicator. For example, the SOAP operation SSR_GET_ENROLLMENT becomes SSR_GET_ENROLLMENT_R_POST in REST.
What EWS Offers
EWS exposes core enrollment functionality through these REST services:
| REST Service |
Purpose |
| SSR_ENROLLMENT_R |
Study list retrieval and enrollment transactions |
| SSR_COURSE_R |
Course catalog search and detail |
| SSR_CLASS_R |
Class search and section details |
| SCC_SHOPPING_CART_R |
Shopping cart operations |
Key capabilities include:
- Student study lists - retrieving enrolled classes and deadlines
- Course catalog browsing - searching and viewing course offerings
- Class search - finding available class sections with enrollment options
- Shopping cart management - adding, validating, and checking out courses
- Enrollment transactions - add, drop, swap, and edit enrollments
- Appointment information - retrieving enrollment and validation appointment windows
Security Model
EWS uses WS-Security for authentication, even for REST services. Anonymous access (via the SCC_GUEST user profile) is typically allowed for course and class browsing, while study list and enrollment operations require authenticated user credentials.
Every University implements its security differently. We will explore those topics.
What’s Coming in This Series
In upcoming posts, we’ll cover:
- Setting up Integration Broker for REST-based EWS
- Testing REST services with tools like Postman or SOAP UI
- Working with the StudyList API via REST
- Shopping cart operations
- Processing enrollment transactions
- Handling error responses