Contents

PeopleSoft Enrollment Web Services (EWS) Setup

First, let’s talk about the prerequisites for using PeopleSoft Enrollment Web Services (EWS) in your environment. This article outlines the steps to enable and configure EWS REST services in PeopleSoft Campus Solutions.

These web services are not enabled by default, so some configuration is required.

Concepts

The EWS were designed to allow an external application (outside PeopleSoft) to perform enrollment-related tasks on a student’s behalf. This might enable a mobile app, third-party system, or custom web portal to integrate with PeopleSoft for enrollment functionality.

  
flowchart TB
    A[External Application] -->|HTTPS| B[PeopleSoft Integration Broker]
    B --> C[EWS REST Services]
    C --> D[Database Operations]

    U[User] -->A

The external application is a student-facing web application. The user (student) interacts with the external application, which then makes HTTPS calls to the PeopleSoft Integration Broker. The Integration Broker routes these requests to the appropriate EWS REST services, which perform the necessary database operations to retrieve or modify enrollment data.

The external web application will likely have its own database to manage user sessions, preferences, and other non-PeopleSoft data. However, all enrollment-related data (study lists, courses, classes, shopping carts, etc.) will be managed within PeopleSoft via the EWS.

This also assumes your application can talk to the integration broker and that any firewall or network security rules are correctly configured.

Enabling EWS REST Services

By default, the EWS REST services are not enabled. You will need to perform the following steps in PeopleSoft Campus Solutions:

Let’s first enable the security pieces, which we will discuss in more detail in the following article.

We need to do the following on all the web services you

  • Make sure the Service Operation is Active
  • Make sure the Service Operation Handler is active
  • Make sure any-to-local routing is active for the service operation

Let’s look at the key EWS service operations that need to be enabled:

  • SCC_USERREG_AUTHORIZE_POST - We will discuss this in more detail in the following article, but this service operation is used to authenticate users.

This must be repeated for all service operations you plan to use.

Handler Setup

The EWS rest service uses a “Generic handler” that ends up using a configuration table to map the service operation to the underlying PeopleSoft Application Class.

  • Set Up SACR -> System Administration -> Integrations -> Request Handlers
  • Open the Service Operation
  • Make sure the Handler is Active
  • You can see the Application Class that is used to process the request.

Working with the PeopleSoft Team

Understanding the Audience

This guide assumes you are an external developer (not a PeopleSoft developer) who wants to integrate with PeopleSoft EWS using a modern programming language. In most organizations:

  • PeopleSoft Platform Team: Manages system stability, infrastructure, and operations
  • PeopleSoft Developers: Build and maintain PeopleSoft applications
  • External Developers (you): Build applications that consume PeopleSoft APIs

These are typically different teams with different skill sets. As an external developer, you’ll need to coordinate with the PeopleSoft team throughout your development lifecycle.

PeopleSoft Development Model

Before requesting access, understand how PeopleSoft development works:

  1. Code Storage: Unlike traditional applications, PeopleSoft stores all code inside the database in metadata tables. There are almost no code files on the filesystem.

  2. Environment Structure: Every PeopleSoft installation has at least three environments:

    • Development (DEV): Where PeopleSoft developers build and configure services
    • Test (TEST): Where user acceptance testing occurs
    • Production (PROD): The live system with real data

  3. Database Refreshes: When development databases are refreshed from production, both data AND code are copied. This means any code in production overwrites what was in development.

Access and Testing Strategy

Work with your PeopleSoft team to coordinate the following:

1. Development Environment Access

  • Request firewall/network access for your development servers to reach the PeopleSoft DEV environment
  • Ask the PeopleSoft team to enable the specific EWS services you need
  • Configure security settings (covered in the next article)
  • Perform unit testing and initial integration work

2. Test Environment Access

  • Once DEV testing is complete, request access to the TEST environment
  • The PeopleSoft team will migrate their configuration changes from DEV to TEST
  • Conduct user acceptance testing (UAT) with test data
  • Verify all integrations work as expected

3. Production Deployment

  • After successful UAT, coordinate a production deployment window
  • The PeopleSoft team will migrate changes to PROD using their change control process
  • They will enable security and grant your production servers access
  • Perform smoke tests to verify the production integration

Key Coordination Points

Before starting development, discuss these topics with your PeopleSoft team:

  • Change Control Process: How do they manage and approve production changes?
  • Deployment Schedule: When are maintenance windows? How often do they deploy?
  • Environment Refresh Schedule: When do they refresh DEV/TEST with production data?
  • Security Requirements: What authentication methods are required? Do you need specific certificates or credentials?
  • Support Model: Who do you contact for issues in each environment?
  • Testing Data: Can they provide test student IDs and data for your integration testing?

Communication Template

When requesting access, provide the PeopleSoft team with:

  1. Service Operations Needed: List of specific EWS operations (e.g., SSR_GET_ENROLLMENT_R, SSR_POST_CART)
  2. Source Systems: IP addresses or hostnames of servers that need access
  3. Timeline: When you need each environment available
  4. Security Model: Your proposed authentication approach
  5. Testing Plan: High-level overview of what you’ll be testing

This upfront coordination will streamline the process and ensure all teams understand the requirements and timeline.

Author Info
Chris Malek

Chris Malek s a PeopleTools® Technical Consultant with over two decades of experience working on PeopleSoft enterprise software projects. He is available for consulting engagements.

Work with Chris