What SWS Installs in PeopleSoft

The objects, roles, and Integration Broker setup the SWS framework adds to a PeopleSoft environment. Written for the admin, DBA, or security reviewer who has to approve the install.

Categories:

Security

The psLens application connects to your PeopleSoft environments through a scoped, read-only subset of the SWS (Secure Web Services) framework delivered in the CHG_PSLENS Application Designer project. This page lists what installing the project changes in your environment, giving the administrator, DBA, or security reviewer the full footprint before anything is migrated. The step-by-step setup guide is at Installation.

The Install in One Paragraph

The CHG_PSLENS project is delivered as a standard Application Designer project. You import it into a development environment first, build the single whitelist table, test connectivity, 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

The project contains exactly 46 PeopleSoft objects, all namespaced with the CHG_ prefix (and one helper package named PsoftQL). It contains no custom pages, menus, components, or portal definitions, and no standalone fields.

Object Type	Count	Delivered Objects
Record	1	`CHG_PSLENS_WL` (the table whitelist)
Role	1	`CHG_PSLENS_API_USER`
Permission List	1	`CHG_PSLENS_API_USER`
Service	1	`CHG_PSLENS`
Service Operation	2	`CHG_PSLENS_SWSPQL_POST`, `CHG_PSLENS_METADATA_GET`
Service Operation Handler	2	Request handlers for each service operation
Service Operation Version	2	`v1` version definitions
Service Operation Routing	2	Local point-to-point REST routings
Message Definition	3	`CHG_GENERIC`, `CHG_SWS_PARAMS`, `IB_REST_STUB`
Application Package	6	`CHG_ENCODING_TOOLS`, `CHG_HTTP`, `CHG_IB`, `CHG_PSLENS`, `CHG_UTILS`, `PsoftQL`
Application Package PeopleCode	20	Program classes for query parsing, serialization, and whitelist filtering
Schemas	5	Logical, XML, Document, JSON, and HTML schema definitions for `CHG_SWS.PARAMS.V1`
Total	46

Object details:

Record (1): CHG_PSLENS_WL, built as physical SQL table PS_CHG_PSLENS_WL. This is the only table created by the project. It stores the whitelist of PeopleTools records psLens can query.
Role (1) and Permission List (1): CHG_PSLENS_API_USER. Grants web-service authorization for the two service operations. It provides no access to PIA pages, components, queries, or processes.
Service Operations (2):
- CHG_PSLENS_SWSPQL_POST — The primary read-only query endpoint. Accepts structured psoftQL requests (record names, field criteria, WHERE clauses, pagination) and returns data in JSON or XML.
- CHG_PSLENS_METADATA_GET — Returns read-only environment metadata (such as PeopleTools version and IB sync log entries) that cannot be read directly from tables.
Application Packages (6) and PeopleCode (20): Contains serialization logic (CHG_ENCODING_TOOLS), HTTP request handling (CHG_HTTP), Integration Broker response formatting (CHG_IB), query execution and whitelist enforcement (CHG_PSLENS.PsoftQL), and utility helpers (CHG_UTILS).
No Pages or UI Objects: The project adds no pages, components, menus, or portal registry entries. Configuration is managed strictly by populating CHG_PSLENS_WL.
No Sample Data: The project ships only definition metadata. No sample rows, dummy records, or seed business data are imported.

Security Objects and the Service Account

psLens connects as a dedicated PeopleSoft operator you create for it (recommended name: CHG_PSLENS_API_USER). That account:

Holds the CHG_PSLENS_API_USER role, which assigns permission list CHG_PSLENS_API_USER to grant access to the two service operations and nothing else.
Has no access to PIA pages, query tools, process definitions, or database utilities.
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_CHG_PSLENS_WL. 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 in App Designer plus building CHG_PSLENS_WL and inserting 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.