What SWS Installs in PeopleSoft

The SWS (Secure Web Services) framework is the PeopleSoft-side component psLens queries through. This page lists what installing it actually changes in your environment, so the person approving the change can see the full footprint before anything is migrated. The authoritative installation guide lives at sws.books.cedarhillsgroup.com; this page is the summary for a security review.

The Install in One Paragraph

SWS is delivered as a standard App Designer project. You import it into a development environment first, test it there, and migrate it to TEST and PROD through your normal change-management path, the same way you move any other project. There is no installer, no agent, and no software on the database server. Plan for under an hour of PeopleSoft admin time for the first environment.

What the Project Contains

Roughly 100 PeopleSoft objects, all namespaced with the CHG_ prefix (C_ for records):

• 9 records for configuration and logging, including the whitelist tables described below
• 32 fields supporting those records
• 4 pages for administration and testing
• 6 application packages containing the framework’s PeopleCode
• 2 service operations: CHG_SWS_GET and CHG_SWS_PSOFTQL_POST
• 2 roles: CHG_SWS_ADMIN (setup pages) and CHG_SWS_USER (API access)

The full object manifest is in the SWS installation docs. The project ships with sample data for testing; the SWS docs are explicit that sample data is not meant for production systems.

Security Objects and the Service Account

psLens connects as a PeopleSoft operator you create for it (for example PSLENS_API). That account:

• holds the CHG_SWS_USER role, which grants access to the API and nothing else
• authenticates to the service operations with HTTP basic auth over HTTPS
• is an ordinary PeopleSoft account, so your existing controls apply: lock it in PSOPRDEFN and all psLens access stops immediately

No new database users are created. Nothing connects to the database directly; every query runs through the application server like any other Integration Broker request.

The Whitelist

SWS only answers queries against records listed in PS_C_SWS_REC_WL, scoped to the permission list of the calling API user. A query that references anything off-list is rejected before it reaches the database.

psLens needs roughly 130 PeopleTools metadata records whitelisted. The list is published in two places: the Reference page describes each record and which psLens feature uses it, and Whitelist Tables has the SQL inserts you run during installation. You run those inserts yourself, which means you review every record psLens will ever be able to read, and you can narrow the list at any time.

Integration Broker Setup

The two service operations come with routing definitions and handlers and run on your existing Integration Broker gateway. No new gateway, listening connector, or node is required. Because the traffic is ordinary REST service-operation traffic, it is visible in your IB monitoring tools alongside every other integration.

What to Tell Your DBA

• All queries are reads against PeopleTools metadata tables on the whitelist. SWS has no write path for psLens to call.
• Query volume is driven by on-demand page views plus a configurable alert interval (default every 5 minutes). See the load FAQ for the breakdown.
• There is nothing to install or configure at the database layer. The change is entirely PeopleTools objects plus whitelist rows.

Questions

If your security team needs answers in writing before approving the install (object-by-object review, role configuration, whitelist scoping), raise it on the demo call or email chris.malek@cedarhillsgroup.com.