When integrating external systems or loading batch data into PeopleSoft, developers face a fundamental question: how do you insert or update rows in PeopleSoft’s database tables while still honoring every field default, prompt table validation, PeopleCode event, and record-level audit rule built into the online application?
In a standard PeopleSoft Pure Internet Architecture (PIA) transaction, a user’s browser communicates with the Web Server, which forwards requests to the Application Server. The Application Server loads the Component definition, allocates the component buffer in memory, executes PeopleCode events (SearchInit, RowInit, FieldEdit, FieldChange, SaveEdit, SavePreChange, SavePostChange), validates prompt tables and translate values, and issues SQL against the database.
If an Integration Broker handler or Application Engine program bypasses the Component Processor and writes directly to underlying application tables using SQLExec or standalone Record.Insert() / Record.Update() calls:
USERMAINT or JOB_DATA updates dozens of related tables. Direct SQL leaves orphan or incomplete rows if even one table is missed.A Component Interface (CI) wraps a single PeopleSoft Component inside an object-oriented API. It exposes a black-box interface of keys, properties, collections, and methods so external or internal programs can drive the component buffer without an active browser session.
PSBCDEFN.BCNAME points to a single PNLGRPNAME and MARKET), though a single Component can have multiple Component Interfaces built over it for different integration contexts.At runtime, every Component Interface is instantiated from the current PeopleSoft Session object (%Session) and follows a strict hierarchical object model.
Component Interface keys are automatically derived from the underlying component’s Search Record (and Add Search Record, if different). You cannot manually add or remove key fields inside the CI designer without changing the component’s search record.
| Key Type | How Created | Purpose |
|---|---|---|
GetKeys |
Search Key fields on the component’s Search Record | Used with .Get() to retrieve a single, unique component instance (equivalent to entering full keys on an Update/Display search page and clicking Search). |
FindKeys |
Search Key + Alternate Search Key fields on the Search Record | Used with .Find() to run a partial or wildcard search that returns a collection of matching CI instances (equivalent to clicking the Search button to view a list of results). |
CreateKeys |
Search Key fields on the component’s Add Search Record | Used with .Create() to instantiate a new component buffer (equivalent to the Add a New Value tab online). Only present if the underlying component has the Add action enabled. |
CreateKeys Are Supplied at Runtime: Even though CreateKeys appear as a separate folder in Application Designer, in PeopleCode you populate the exact same top-level key properties on the CI object before calling .Create() as you do before calling .Get(). If a component has Add action disabled in Component Properties, the CreateKeys folder and the .Create() method will not exist on the CI.Properties represent individual fields exposed from the component buffer, plus four standard behavioral flags on the CI root object:
| Behavioral Property | Default | Effect |
|---|---|---|
InteractiveMode |
False |
When False, FieldEdit and FieldChange defer until .Save() is called. When True, setting each property immediately fires FieldEdit and FieldChange (slower, required when downstream fields depend on immediate derived-work-record logic). |
GetHistoryItems |
False |
When False, .Get() operates in Update/Display mode (returning current and future-dated effective rows). When True, .Get() operates in Update/Display All (or Correction) mode and includes historical effective-dated rows in scroll collections. |
EditHistoryItems |
False |
When True (combined with GetHistoryItems = True), operates in Correction mode so existing historical effective-dated rows can be modified. |
StopOnFirstError |
False |
Controls whether validation halts on the first error logged to %Session.PSMessages. |
Whenever a component contains a Level 1, Level 2, or Level 3 scroll area or grid, Application Designer exposes that record in the CI as a Data Collection (indicated by a 3D cube icon).
Rowset in standalone PeopleCode. It supports methods and properties such as .Count, .Item(index), .InsertItem(index), .DeleteItem(index), .CurrentItem, and .ItemByKeys(...)..Item(i) or .InsertItem(i) on a Data Collection returns a Data Item (corresponding to a Row in standalone PeopleCode).Every Component Interface provides up to five Standard Methods (enabled or disabled in Component Interface Properties > Standard Methods):
Get() — Populates the component buffer for an existing key set (True on success, False on failure).Create() — Initializes a new component buffer for the specified CreateKeys (True on success, False on failure).Find() — Returns a collection of CI instances matching partial/wildcard FindKeys.Save() — Runs SaveEdit, SavePreChange, database INSERT/UPDATE/DELETE SQL, and SavePostChange (True on success, False on failure). Note: In Application Engine or Integration Broker handlers, Save() writes to the database within the active unit of work, subject to transaction commit control.Cancel() — Releases the current component buffer state so the CI instance can be reset or discarded.In addition, developers can write Custom Methods directly in the Component Interface’s PeopleCode workspace. For example, PeopleSoft’s delivered USER_PROFILE CI defines custom methods such as SetPassword(), ResetPassword(), and SetUserDescription() that execute specialized PeopleCode against the loaded component buffer.
Because PeopleSoft documentation, Application Designer, and PeopleCode developers use three different vocabularies for the exact same underlying structures, keep this translation table handy when designing or debugging a CI:
| Online PIA / Database Term | Standalone PeopleCode Term | Component Interface Term |
|---|---|---|
| Component | Component Buffer | Component Interface |
| Search Page Keys (Update/Display) | Search Record Key Fields | GetKeys |
| Search Page Keys + Alt Search Keys | Search Record Search + Alt Keys | FindKeys |
| Add a New Value Keys | Add Search Record Key Fields | CreateKeys |
| Level 0 Page Field | Record.Field |
Property |
| Scroll Area / Grid (Level 1–3) | Rowset |
Data Collection |
| Scroll Row / Grid Row | Row |
Data Item |
| Grid Row Field | Row.Record.Field |
Item Property |
| Search / Add / Save Buttons | Component Processor Actions | Standard Methods (Get, Create, Find, Save, Cancel) |
Look up any record, field, page, or component, audit security, and monitor Integration Broker across every database — in seconds.
A web console built for the PeopleSoft community — operational monitoring, security auditing, and metadata browsing in one tool.
On-demand security and operational reports for your PeopleSoft environment — no client install required.
Research any PeopleSoft object and monitor system health from a single browser tab — no App Designer, no SQL.
Chris Malek is a PeopleTools® Technical Consultant with over two decades of experience. He is available for consulting engagements.
Work with ChrisSWS turns SQL into production REST APIs — ready for AI, modern apps, and partner integrations. One install, unlimited potential.
A powerful PeopleSoft bolt-on that makes REST web services easy. You bring the SQL, SWS handles the rest.
Traditional PeopleSoft web services cost $3,600–$13,000 each to develop. SWS deploys production REST APIs in under 5 minutes through configuration alone.
Turn PeopleSoft data into clean REST APIs for AI integrations, modern applications, and vendor data feeds. Configuration-driven — no PeopleCode required.