SWS Assumptions and Limitations

This article discussions some of the assumptions and limitations of the product.

Assumptions

  • You have a working PeopleSoft Integration Broker (IB) setup, including a configured RESTListeningConnector on PSIGW.
  • You want to pull information out of PeopleSoft. SWS is read-only by design.
  • PeopleTools version greater than 8.56.
  • You can create custom Oracle/SQL Server objects in your PeopleSoft database (SWS ships custom records, application packages, and a service operation).

What SWS does not do

These are intentional product boundaries, not bugs. If your use case is on this list, SWS is the wrong tool and another approach is needed.

Read-only, GET-only

SWS exposes PeopleSoft data as HTTP GETs. It does not create, update, or delete PeopleSoft data. There is no PUT, POST-to-write, or DELETE pathway. To push data into PeopleSoft you still need a traditional Integration Broker service operation, a Component Interface, or a delivered web service. Generic insert/update support is discussed on the road map; it does not exist today.

PeopleSoft must be the server

SWS only works when PeopleSoft is the HTTP server answering inbound requests. If you need PeopleSoft to make an outbound call to a third-party REST API, use a standard Integration Broker outbound consumer — SWS plays no role there.

Data is returned in PeopleSoft shape

By default the response uses PeopleSoft field names (EMPLID, ACAD_CAREER, DESCR) and PeopleSoft formats (ISO dates, raw XLAT codes). Two partial mitigations exist today:

  • SQL configurations can alias columns in the Output Fields Grid so the client sees friendly names (see the SQL worked example).
  • PsoftQL can request decoded XLAT and prompt-table descriptions via includeDescriptionsFor and includeAllDescriptions.

Neither covers true data transformation — flattening parent/child trees, computing derived values, or reshaping the response schema for a specific vendor. A future release may add a transformation pipeline; tracked on the road map.

CSV output is SQL-only

CSV (Accept: text/csv) only works for SQL-type SWS configurations. PsoftQL responses are JSON or XML — they are nested by design and CSV has no representation for the parent/child structure. See the Syntax Types comparison on the configuration page.

IN operator in criteriaFields is not honored

The JSON schema lists IN as a supported operator value, but the current server build silently returns zero rows for every input form (comma-separated string, parenthesized list, fieldValues array). Use sqlWhereClause with native SQL IN (...) instead. See the IN operator status note on the Operator Examples page. Closing this gap is on the road map.

Aggregate queries cannot paginate or join

When isAggregate: true is set on a PsoftQL request:

  • Only a single root record is allowed — no child records (parentRecordName) and no joins.
  • Pagination is not supported — pageNumber must be omitted or 1. Setting it to 2 or higher returns responseCode: 400 with the message “Pagination is not supported in aggregate mode.”
  • The flags includeFieldTypes, includeAllFieldLabels, and includeKeyFieldIndicators are ignored.

For the full list of what does and does not work alongside isAggregate: true, see the Aggregate Queries section of the PsoftQL syntax reference.

XML isAggregate mode

Aggregate queries in XML request format do not currently produce the same well-formed aggregate response that JSON requests do. Stick with JSON when using isAggregate: true.

Field-name typos in criteriaFields are silent

The handler does not validate that criteriaFields[].fieldName exists on the target record. A typo causes the criterion to be silently dropped and the request returns the unfiltered result. Always spot-check that the returned rows actually match the criterion you intended. See Silent behaviours on the syntax page.

Authentication options are limited

The only viable REST authentication mechanism today is HTTP Basic Authentication tied to a PeopleSoft OPRID / password stored in PSOPRDEFN. SWS does not currently support API keys, OAuth 2.0 client-credentials grants, mutual TLS, or JWT bearer tokens at the application layer. This is a PeopleSoft IB constraint, not an SWS choice — anything you read in the Integration Broker REST security reference also applies to SWS.

Caching is constrained by the IB cache

SWS exposes the PeopleTools RESTListeningConnector cache via the Minutes to Cache Response configuration field. Read the Caching article before enabling it — the cache key does not include the caller’s OPRID, so caching a response that uses %EMPLOYEEID or %OPERATOR will leak one caller’s data to the next.

Other known boundaries

  • Attachment fields are not auto-handled. Records with EFFDT/EFF_STATUS/EFFSEQ are auto-handled; binary attachment fields (BLOB columns referenced by PV_ATT_* metadata) are not yet auto-rendered.
  • No meta/endpoints discovery endpoint yet. There is no live “list every SWS-configured path” endpoint — the closest substitute today is querying the configuration tables (C_SWS_CONF_TBL and friends) directly.
  • OpenAPI / Swagger generation is on the road map but not yet shipped.

For features under active consideration, see the Road Map.