Integration Broker

• 1: Nodes
• 2: Services
• 3: Service Operations
• 4: Application Services
• 5: Messages
• 6: Queues

1 - Nodes

Nodes are the network endpoints of the PeopleSoft Integration Broker. Each external system, partner database, or other PeopleSoft environment that sends or receives messages is represented as a node (PSMSGNODEDEFN). The node carries connection settings (connector type, target URL, authentication mode) and is the unit referenced by every routing rule. psLens shows the node configuration, every routing that involves this node, the service operations granted to its default user, and an inventory of URI text configured against it.

Object Relationships

Nodes represent integration targets and security identities in Integration Broker:

• Endpoints for Routings: Nodes (PSMSGNODEDEFN) are configured as senders or receivers in Routing definitions (PSIBRTNGDEFN).
• Binds User Authorization: Nodes link to default user accounts (OPRID) that dictate execution rights for incoming service operation requests.

How psLens Improves Integration Node Inspection

Reviewing Integration Broker nodes in PIA requires stepping through Connectors, Portal, WS Security, and Routings tabs, while searching Service Operations permissions separately for default node users.

psLens surfaces node properties, password security flags, routing traffic, default user service operation permissions, and URI text in a unified view.

Search Page

URL: /nodes?db={database}

Wildcard % search supported. Each card shows the node type (Local, External, Hub), the node’s active flag, the default user ID, and the descriptive name. Enough at a glance to spot inactive nodes or nodes pointing at unexpected user accounts.

Detail Page

URL: /nodes/{NODENAME}?db={database}

The main pane shows Node Properties: node type, connector ID, default user, authentication option, password-set indicator, contact, and audit metadata. The password-set indicator is the security view: a node with authentication required but no password set is a flag worth investigating (see the Nodes with No Password report). The sidebar has 4 related-data toggles.

Related Data Panels

Routings

Every routing rule (PSIBRTNGDEFN) where this node appears as sender or receiver, with the service operation, direction, and status. Lists the message traffic that flows through this node.

User’s Service Operations

The service operations the node’s default user has been granted permission to invoke. Important for security audits, since a node’s default user can be granted service operations that the human OPRID would never get.

URI Text

The URI text entries configured against the node (PSIBNODEURITEXT). The per-node URL fragments used in REST-style integrations.

Included in Projects

App Designer projects that include the node definition.

2 - Services

A Service is the high-level container in the Integration Broker hierarchy: a logical grouping of related Service Operations (PSSERVICEDEFN). For example, a STUDENT_ENROLLMENT service might contain GET_ENROLLMENT, ADD_ENROLLMENT, and DROP_ENROLLMENT operations. The service itself carries metadata (description, owner, WSDL namespace) and acts as the access point for browsing operations together.

Object Relationships

Services organize Integration Broker message contracts into logical domain groups:

• Groups Service Operations: Services (PSSERVICE) act as parent containers grouping individual Service Operations (PSOPERATION).

How psLens Improves Service Inspection

In PIA, inspecting Integration Broker services requires navigating Integration Setup → Services and clicking through individual operation tabs to view member endpoints.

psLens displays service metadata alongside all contained service operations on a single screen with one-click drilldowns into detailed operation contracts.

Search Page

URL: /services?db={database}

Wildcard % search supported. Each card shows the service name, alias, and description.

Detail Page

URL: /services/{SERVICE}?db={database}

The main pane shows Service Properties (name, alias, namespace, owner, description, audit metadata). The sidebar has one related-data toggle.

Related Data Panels

Service Operations

Every service operation belonging to the service, each link-resolved into its own detail page. The starting point for understanding what messages the service can exchange.

3 - Service Operations

A Service Operation is the actual message-exchange contract — the unit that defines what message type is sent, in which direction (async or sync), through which routings, and handled by which PeopleCode. Each operation belongs to a service and is stored in PSOPERATION with related metadata in PSOPRDESC, PSOPRROUTING, PSOPRHANDLER, and the security tables. psLens consolidates the full operation — versions, routings, handlers, caller nodes, security access from three angles, and live IB transaction history — into one page.

Object Relationships

Service Operations form the central communication contracts in Integration Broker:

• Belongs to Services: Operations (PSOPERATION) are grouped under parent Service definitions (PSSERVICE).
• Carries Message Schemas: Operations define request and response payload structures using Message definitions (PSMSGDEFN).
• Routed via Nodes: Operations use Routing definitions (PSIBRTNGDEFN) to direct messages between sender and receiver Nodes (PSMSGNODEDEFN).
• Processed by Handlers: Operations invoke Application Class or App Engine handlers (PSOPRHDLR) upon message arrival or dispatch.
• Secured by Permission Lists: Permission lists (PSAUTHWS) authorize execution of Service Operations.

How psLens Improves Service Operation Inspection

Auditing Integration Broker service operations in PIA requires opening operation definitions, switching between Handlers and Routings tabs, searching permission list Web Services security, cross-referencing role membership, and checking Asynchronous Monitor logs separately.

psLens consolidates operation versions, routings, handlers, three security access views (permission lists, roles, users), caller nodes, project membership, and live transaction history onto a single screen.

Search Page

URL: /serviceoperations?db={database}

Wildcard % search supported. Each card shows the operation type (Async, Sync, One Way), default version, and active flag.

Detail Page

URL: /serviceoperations/{OPERATION}?db={database}

The main pane shows Operation Properties plus four always-visible cards: Versions (every operation version with default flag and message type), Routings (every routing definition with sender/receiver nodes and direction), Handlers (handler PeopleCode and class implementations), and HTTP Request Template (the template body for HTTP-style transactions). The sidebar has 6 related-data toggles, including three security access lenses, project membership, and a live IB transaction history feed.

Related Data Panels

Permission Lists with Access

Permission lists with Full Access or Web Library Access to this operation. The security baseline for which permission lists let a user invoke this operation.

Roles with Access

The roles that contain any of the granting permission lists — saves you from having to walk Permission List → Role mapping manually.

Users with Access

The users whose role membership ultimately grants them access to call this operation, with an optional toggle to include or exclude locked accounts. The end-of-chain answer for who can call this endpoint.

Caller Nodes

Inverts the lens to the integration side: lists nodes whose default user has been granted access to invoke this operation — useful for confirming which external systems can call the endpoint.

Included in Projects

Application Designer projects containing this Service Operation (PSPROJECTITEM.OBJECTTYPE = 80). Shows project name, description, and object owner ID.

IB Transaction History

Recent runtime invocations from PSIBLOGHDR — timestamps, status, transaction ID. The link from “what is configured” to “what is actually happening.” Lets you confirm an operation is being called (or spot that it never is).

4 - Application Services

An Application Service is an Application Services Framework (ASF) definition, stored in PSIBAPPLDEFN. It exposes a REST API backed by application classes, without the hand-built service operations that classic Integration Broker requires. psLens consolidates the service’s operations, URI templates and REST methods, method parameters, result-state-to-HTTP-status mappings, header properties, and security grants onto one page.

Object Relationships

Application Services define REST API boundaries over Application Classes:

• Exposes REST URIs & Operations: Application Services (PSIBAPPLDEFN) define REST operations (PSIBAPPLOPR) and URI templates (PSIBAPPURI) mapped to HTTP methods.
• Backed by Application Classes: Operations execute underlying Application Package handler classes.
• Secured by Permission Lists: Permission lists (PSAUTHAS) authorize access to specific Application Services.

How psLens Improves Application Service Inspection

In PIA, inspecting Application Services Framework (ASF) REST APIs requires switching across operation, URI, parameter, and result-state tabs, then checking Web Services security for each permission list separately.

psLens combines the complete REST API surface—operations, URI templates, HTTP methods, parameters, result state mappings, and security grants—on a single page.

Search Page

URL: /appservices?db={database}

Wildcard % search supported. Search runs against the ASF definitions in PSIBAPPLDEFN. Each result card links to the application service detail page.

Detail Page

URL: /appservices/{APPLNAME}?db={database}

The main pane shows the service properties and an always-visible Operations & REST Surface card: each operation’s handler application class, plus a table of its URI templates with the REST methods (GET, POST, PUT, DELETE) mapped to each. The sidebar has four related-data toggles.

Related Data Panels

Parameters

Method parameters for the service’s operations, read from PSIBPARAM and the related base/template parameter tables.

Result States

The mapping from operation result states to HTTP status codes (PSIBAPPLSTATES) — what status a caller receives for each outcome.

Header Properties

Header properties configured for the service (PSIBAPPLHDRPROP).

Security

Permission lists that grant access to the application service, read from PSAUTHAS. The answer to which permission lists let a user call this REST API.

Tables Used

• PSIBAPPLDEFN — application service (ASF) definitions
• PSIBAPPLOPR — operations and handler classes
• PSIBAPPURI — URI templates
• PSIBAPPMETHOD — REST method configuration
• PSIBPARAM, PSIBBASEPARAM, PSIBTEMPLPARAM, PSIBBASETMPLPRM — method parameters
• PSIBAPPLSTATES — result-state to HTTP-status mappings
• PSIBAPPLHDRPROP — header properties
• PSAUTHAS — application service authorization per permission list
• PSSERVICEOPR — service operations within the service

5 - Messages

A Message definition is the payload schema that a Service Operation carries. It defines the structure of the XML or JSON document exchanged between systems. Messages can be rowset-based (mapped to PeopleSoft records), nonrowset-based (free-form XML/JSON), container, or document. psLens reads PSMSGDEFN and the version-specific details from PSMSGSCHEMA, then surfaces the service operations that reference each message and the projects that own them.

Object Relationships

Messages define the data payload structures exchanged by Integration Broker endpoints:

• Payload Schemas for Service Operations: Messages (PSMSGDEFN) act as request and response payload schemas for Service Operations (PSOPERATION).
• Mapped to Records: Rowset-based messages map directly to underlying record definitions (PSRECDEFN).

How psLens Improves Integration Message Inspection

In PIA, inspecting Integration Broker messages requires opening message definitions, switching versions, and manually searching service operation registries to locate payload references.

psLens displays message version schemas, mapped record structures, referencing service operations, and project membership side by side.

Search Page

URL: /msgdefns?db={database}

Wildcard % search supported. Each card shows the message type and version.

Detail Page

URL: /msgdefns/{MESSAGE}?db={database}

The main pane shows Message Properties (alias, owner, description, audit metadata) and a per-version card listing each message version with its type (Nonrowset-Based, Rowset-Based, Container, Document) and the schema details. The sidebar has 2 related-data toggles.

Related Data Panels

Service Operations Using This Message

Service operations that reference this message as a request or response payload.

Projects Containing This Message

App Designer projects containing this message as a project item.

6 - Queues

A Queue is an Integration Broker ordering construct. Async service operations attached to the same queue process serially in the order they arrived, while operations on different queues can run in parallel. Queues are also the unit where IB pauses (“Pause” status) when an administrator stops message processing for maintenance. Each queue is stored in PSQUEUEDEFN with a status (Run, Pause) and a partitioning configuration.

Object Relationships

Queues manage message processing order and concurrency for Integration Broker:

• Orders Service Operations: Queues (PSQUEUEDEFN) group asynchronous Service Operations (PSOPERATION) to enforce sequential or parallel execution flow.

How psLens Improves Integration Queue Inspection

In PIA, queue configuration lives under PeopleTools → Integration Broker → Integration Setup → Queues, and locating dependent service operations requires walking each operation separately.

psLens shows queue run/pause status and all dependent service operations on a single page, helping administrators instantly spot paused queues and stalled integrations.

Search Page

URL: /queues?db={database}

Wildcard % search supported. Each card shows the queue’s run/pause status, the fast way to spot a paused queue causing a stalled integration.

Detail Page

URL: /queues/{QUEUE}?db={database}

The main pane shows Queue Properties (status, partitioning method, archive flag, owner, description) and a Service Operations Using This Queue card. Queues are simple objects — there are no sidebar toggles.

Service Operations Using This Queue

The list of service operations bound to this queue. Together with the IB Monitor, this shows what stops processing when the queue is paused.