Understanding PeopleSoft Integration Broker

This chapter provides overview information about PeopleSoft Integration Broker and discusses:

Integration gateway architecture.
Integration engine architecture.
Transaction types.
Incoming and outgoing message flows.
Creating and implementing integrations.

Important! PeopleSoft Integration Broker interacts with a wide variety of third-party products. This PeopleBook is not an authoritative source of information about any third-party product. Most third-party products are delivered with their own documentation, which you should use as the primary source for information about them. This PeopleBook provides guidance that enables you to determine the configuration settings that PeopleSoft Integration Broker requires to work with third-party products. It does not address all configuration permutations. Examples of settings and data relative to a third-party product may not be correct for your particular situation. To properly configure PeopleSoft Integration Broker, you must apply your own expertise and obtain the most accurate and current information about third-party products.

Introduction to PeopleSoft Integration Broker

PeopleSoft Integration Broker is a middleware technology that facilitates synchronous and asynchronous messaging among internal systems and trading partners, while managing message structure, message format, and transport disparities. Because of its modular design, many elements that you develop for an integration using Integration Broker can be reused in other integrations.

PeopleSoft Integration Broker consists of two subsystems: the integration gateway and the integration engine. The integration gateway resides on a PeopleSoft web server, and the integration engine is installed on an application server as part of the PeopleSoft application.

Integration Gateway

The integration gateway is a platform that manages the receipt and delivery of messages passed among systems through PeopleSoft Integration Broker. It supports the leading TCP/IP protocols used in the marketplace today and provides extensible interfaces to develop new connectors for communication with legacy, enterprise resource planning, and internet-based systems.

Additional features include:

Backward compatibility for Extensible Markup Language (XML) links and PeopleSoft Application Messaging.
Listening connectors and target connectors that transport messages between integration participants and the integration engine.

Note. This feature also enables you to build your own connectors to complement those delivered with PeopleSoft Integration Broker.
Basic logging information concerning message receipt, delivery, and errors.
Connection persistence with continuous open feeds to external systems through connectors, with full failover capabilities.
Transport protocol and message format management so that when messages reach the integration engine, they have a PeopleSoft-compatible message format.

Integration Engine

The integration engine runs on the PeopleSoft application server. It’s tied closely to the PeopleSoft application, and it sends or receives messages for the application. Rather than communicating directly with other applications, the integration engine sends and receives messages through one or more separately installed integration gateways.

The integration engine:

Uses a modular architecture, so it can treat gateways as black boxes and communicate with them using standard connectors.
Adapts elements of an existing integration to produce a new integration with only minor adjustments.
Handles messages containing data in a variety of formats, including PeopleSoft rowsets, XML document object model, Simple Object Access Protocol (SOAP), and nonrowset-based data.
Sends and receives messages asynchronously (like email) or synchronously (suspending activity to wait for a response).
Applies message transmission type and routing based on specifications that you define in a PeopleSoft Pure Internet Architecture component.
By applying application engine transform programs, transforms message structure and translates data content according to specifications that you define in PeopleSoft Pure Internet Architecture components and apply with Extensible Stylesheet Language Transformation (XSLT) code or PeopleCode.

These specifications can be reused for other integrations.
Handles security features such as authentication, nonrepudiation, and cookies.

Integration Gateway Architecture

This section discusses:

Architecture components.
Connectors.
Gateway manager.
Gateway services.

Architecture Elements

You use an integration gateway to receive and send messages among integration participant systems.

Listening connectors receive incoming messages and deliver the incoming requests to the gateway manager, which is a dispatcher for messages that flow through an integration gateway. The gateway manager determines which target connector to use to properly deliver the messages to their intended recipients. The target connector then delivers the messages to the intended recipients using the recipients’ preferred protocols.

Integration gateway architecture

Connectors

Listening connectors and target connectors transport messages between integration participants and the integration gateway. These connectors support asynchronous and synchronous message handling. Many connectors are configurable at the integration gateway and system levels.

Listening Connectors

Listening connectors receive incoming data streams and perform services based on the content of the stream. They are invoked externally by other PeopleSoft systems and third-party systems.

Target Connectors

Target connectors initiate communication with other PeopleSoft systems or third-party systems. A target connector might not receive a response from the target system during each operation, but every transmission requires a low-level acknowledgment.

PeopleSoft Integration Broker Connector SDK

The integration gateway provides a fully extensible model for developing new connectors built to the interface specification of the PeopleSoft Integration Broker software development kit (SDK) by PeopleSoft customers, consultants, and application developers.

Gateway Manager

The gateway manager processes every message that flows through an integration gateway and maintains links to the other major integration gateway components, including target connectors, listening connectors, and each of the gateway services.

Listening connectors invoke the gateway manager when they receive a message request. The gateway manager uses the messaging objects IBRequest and IBResponse to determine how to route each message.

The gateway manager uses a number of the gateway services during this stage to perform operations such as message validation. The gateway manager then invokes the appropriate target connector based on the content of the message object and waits for a reply from the target connector. When the reply is received, the gateway manager forwards the reply to the calling listening connector.

If an error occurs, the gateway manager uses the error handling service and works with the service to prepare an error reply for the listening connector.

Gateway Services

This section describes the gateway services that the gateway manager uses.

Error Handling

The integration gateway provides a standard error handling interface that is exposed to each connector. This service provides error handling and error logging for most connectors delivered with PeopleSoft Integration Broker.

Messaging Objects

Two objects comprise the messaging objects service in the integration gateway:

IBRequest
IBResponse

These objects represent the request and response that enter and exit PeopleSoft Integration Broker.

See Understanding Supported Message Structures.

XML Parsing

Most IBRequest objects and IBResponse objects that are processed in the system contain a content section, called IBInfo, that represents the actual business message sent.

Most of the time, these content sections contain XML data. Consequently, often connectors must parse and traverse XML. Many developers find that the standard Java XML objects are cumbersome for manipulating XML, so the integration gateway provides an XML parsing service consisting of objects that provide an intuitive interface for manipulating XML objects. This service is delivered as a set of three classes: XmlDocument, XmlNode and XmlNodeList.

See Enterprise PeopleTools 8.46 PeopleBook: PeopleCode API Reference.

Message Validation

Messages that pass into PeopleSoft Integration Broker must contain certain elements to be processed. Because the integration gateway is the first component that processes messages sent to a PeopleSoft application, it performs basic message validation—such as making sure that the message identifies its requestor and message name—to ensure that the integration engine and the target application can process them.

Connector Management

The connector management service is a composite of several services that manage connectors. The gateway processes each IBRequest to determine the appropriate connector to call in each situation. This is primarily a message routing function that has varying levels of complexity abstracted from the connectors. The connector management service also processes the IBResponse returned by each connector.

Error and Message Logging

Most components in the system use a standard error logging interface.

Each PeopleSoft-delivered connector uses the logging API in the same fashion, ensuring that an administrator can quickly drill down on problems or simply review message logs to see the IBRequest object, the IBResponse object, and even the raw data exchanged with integration participants.

See Managing Error Handling, Logging, Tracing, and Debugging.

Integration Engine Architecture

The integration engine uses a variety of PeopleTools elements to create, implement, manage, and enhance integrations. Its modular architecture separates integration development activities from administrative activities.

The integration engine is a combination of PeopleSoft Application Designer definitions, PeopleSoft Pure Internet Architecture definitions, PeopleCode, and XSLT code, along with the underlying mechanisms that tie all these elements together. The underlying mechanisms include the request handlers that process both inbound and outbound messages according to the specifications in the development and administrative elements.

Transaction Types

PeopleSoft Integration Broker supports four types of messaging transactions. For any transaction type, the application must invoke PeopleCode to generate and send a message, or to receive and process a message.

Transaction Type	Actions
Outbound asynchronous	The application generates and sends a request message. One or more target system receives and processes the request message.
Outbound synchronous	The application generates and sends a request message. The application suspends activity and waits for a response message. A single target system receives and processes the request message, then generates and sends a response message. The application resumes its activity and receives and processes the response message.
Inbound asynchronous	A source system generates and sends a request message. The application receives and processes the request message.
Inbound synchronous	A source system generates and sends a request message. The source system suspends activity and waits for a response message. The application receives and processes the request message, then generates and sends a response message. The source system resumes its activity and receives and processes the response message.

When PeopleSoft Integration Broker sends a message, the receiving system returns a response message back to the sender. With asynchronous transactions, the response is automatically generated by the integration gateway, and it serves only to notify the sending system of the transmission status of the request message. It is processed automatically by the application server, which uses that status information to update the Integration Broker Monitor. With synchronous transactions, however, the response message includes the content that is requested by the sending system, and it must be generated and returned by the receiving system.

Incoming and Outgoing Message Flows

This section discusses how incoming and outgoing messages flow through the architecture components of PeopleSoft Integration Broker.

Incoming Request Message Flow

This section describes the flow of a typical request message through PeopleSoft Integration Broker.

Incoming request through PeopleSoft Integration Broker

After the incoming request has been received by the integration gateway, the flow through PeopleSoft Integration Broker is the same, regardless of the listening connector used. With this in mind, no specific listening connector will be discussed here. The scenario is simple: a request is sent into the gateway, which then passes it on to the application server. The application server processes the request, and returns a response.

Step 1: External System Sends a Request to PeopleSoft Integration Broker

The first step is that an external system sends a request to PeopleSoft Integration Broker. The external system can be another PeopleSoft system or a third-party system.

Step 2: Request is Received by the Listening Connector

When a request is received by a listening connector, the first thing that the connector does is write the request to the gateway log file. (The gateway’s integration properties file is used to set the logging level, which controls what is actually written to the log. If messages are not being seen in the log file, check to ensure that the log level is set correctly.) The request is written exactly as it is received. This is very useful in that it presents exactly what was sent on the wire, before the connector normalizes the message for use by the application server.

The connector then attempts to populate an internal request message class with the particulars from the received message.

A term often used in conjunction with listening connectors is credentials. Incoming requests are thought to have two logical parts: the credentials and the message body. The credentials can be thought of as the information required by PeopleSoft Integration Broker to process and deliver the payload of the message. The payload is located in the message body. Since the credentials are separate from the body, the integration gateway does not need to parse or otherwise examine the message body for information on how to route the message.

A message without credentials cannot be processed. If the integration gateway receives such a message an error will occur and an error message will be returned to the requestor.

Step 3: Request is Processed by the PeopleSoft Target Connector

In order for a message to be sent from the gateway to the application server, it must pass through the PeopleSoft target connector. This connector has two major responsibilities: it serializes the message to a string, and sends that string via a JOLT connection to the application server.

All communication between the gateway and the application server is done via the use of Multipurpose Internet Mail Extensions (MIME) messages. When the message is received by the connector, it builds a MIME message. Typically the MIME message will only have two sections. In the first, the message credentials are stored in an XML document in a specific format. The second section stores the message body.

At this point the message is in a standard format understood by both the gateway and the application server. All messages must eventually resolve to this format before they can be sent to the application server for processing. This format effectively isolates the application server from the protocols supported by the gateway; for the most part, there is no information present about what listening connector was initially invoked by the external request.

One credential element that may be present is the one for cookies. Obviously if this is set, the application server would be right in assuming that the request came through the HTTP listening connector. Similarly, SOAP requests are passed into the application server in SOAP format. However, as a general rule the application server is isolated from the details of the protocol and the general broker code on the server does not care what listening connector was used for a given request.

Once the MIME message has been built, it is written to the gateway log.

Finally, the connector looks up the JOLT connection properties from the integration properties file and attempts to send the MIME to the application server. If these properties are not set up correctly, the gateway will be unable to send requests. This is a common source of error, so care should be taken when configuring this file.

An important point to keep in mind is that even though the MIME request to the application server may appear in the gateway log file, the actual request may not have made it to the application server, since the log entry is written before the message is sent. If a communication error occurs, the entry will still be present in the log file. However, if this situation occurs an exception will be thrown and an error log entry will also be created.

Step 4: Request is Received by the Application Server

When the MIME request is received by the application server, the message is parsed and is used to build a request object. The MIME structure is not propagated into the server.

Assuming the message parses without error, the application server must pre-process the message before the request can actually be handled.

Pre-processing involves:

Authenticating the message, depending on the authentication scheme configured. If the request fails authentication, an error is returned.
Determining if there is a transaction corresponding to the request in the Node Transaction table. Aside from Ping messages, all incoming messages must resolve to a single, unique entry in this table. If a suitable transaction cannot be found for a request, an error occurs.
Determining the message handler to invoke. Currently, there are three message types supported by the integration broker: Ping, Synchronous, and Asynchronous. The message type determines the handler code to invoke. Synchronous messages are passed to sync-specific code, and asynchronous messages are passed to the publish/subscribe subsystem.

Once messages have been passed to their respective handlers, further processing is dictated by the data and PeopleCode specific to a particular system. Asynchronous requests will be published, and subscription PeopleCode will be executed. Synchronous messages may invoke PeopleCode, or in the case of Hub configurations the request may immediately be routed to another external system.

Step 5: Response is Returned by the Application Server

Regardless of how the request is processed, a response message must be returned by the application server to the gateway in the same thread of execution. The connection between the gateway and the application server is essentially synchronous, independent of the type of the message being exchanged. When the gateway sends a request to the application server, it expects and must get a response.

In the case of synchronous messages, the generation of the response is blocked by the processing of the request. A response cannot be generated until the message runs to completion. There may be a noticeable delay in receiving the response, depending if PeopleCode is being run or if the request message is being sent out of the broker to an external system for additional processing.

Asynchronous requests behave differently. Unlike sync requests, there is no blocking. A response is generated for an asynchronous request as soon as the request is written to the publication queue. Because of this, a response generated for an asynchronous request is not a response in the strictest sense of the term. Such responses should really be considered acknowledgments that the pub/sub system has received the message. Receipt of such a response is not a guarantee that any applicable subscription PeopleCode has been successfully run.

Response messages are converted to the MIME standard by the application server, and are returned to the gateway.

Step 6: Response is Received by the PeopleSoft Target Connector

As soon as the MIME response is received by the PeopleSoft target connector, it is written to the gateway log file.

The MIME response is then parsed back into a gateway request object, and is then returned to the listening connector.

Step 7: Response is Received by the Listening Connector

The response object is returned to the listening connector, upon which the response is mapped to a response suitable for the given protocol.

It should be emphasized that, from the viewpoint of the listening connector, the processing of request messages is done synchronously. A request is received by a listening connector which then coverts it to a suitable format, makes a blocking call to the gateway to handle the message, and ultimately gets a response back all in the same thread of execution.

Outgoing Request Message Flow

The following diagram shows an outgoing request through PeopleSoft Integration Broker.

Outgoing request through PeopleSoft Integration Broker

There are several scenarios that might result in a request message being sent out of the broker. Messages can be sent in PeopleCode by using the Publish or SyncRequest methods of the Message class. If the PeopleSoft Integration Broker is operated in a hub configuration, incoming synchronous messages may be set up to be routed out to other systems.

Regardless of how the message is created, the mechanism for sending the message out of the broker is the same, and the flow is the same regardless of the specific outgoing target connector you invoke.

Step 1: Application Server Generates Request

Once an outgoing request message has been generated, the application server must perform some basic processing before it can be sent out.

The application server looks at the request, and extracts the information about the node that it is to be sent to.

The node name is then used to look up the name of the gateway to use, the target connector to use on that gateway, as well as any specific connector properties that need to be passed to the connector in order to handle the request. If this information is not found, an error will occur.

The application server modifies the outgoing request with the appropriate connector information.

The request is then converted to the MIME standard format, and is sent to the gateway over an HTTP connection.

The request must be sent to the PeopleSoft listening connector on the gateway. The application server uses the value of the Gateway URL defined for the given gateway. If this URL is not valid or does not point to the PeopleSoft listening connector, the application server will be unable to send the request.

Step 2: Request is Received by the PeopleSoft Listening Connector

When the MIME request is received by the PeopleSoft listening connector, it is written to the gateway log file.

The request is converted from MIME format to a gateway request object.

The connector then examines the request to determine what target connector the request is to be sent to; that target connector is then invoked.

Step 3: Request is Received by the Target Connector

The target connector validates the request. Each connector requires certain properties to be set, otherwise the request cannot be sent. For example, the HTTP target connector requires that the PrimaryURL be set. If any mandatory connector properties are missing or are invalid, an error will be thrown.

The target connector then converts the request message into whatever format is required by the protocol.

The modified request is then written to the gateway log, and the request is sent out.

Step 4: Response is Received by the Target Connector

The response received by the target connector is written to the gateway log, and the response is used to build a gateway response object, which is then returned to the PeopleSoft listening connector.

Step 5: Response is Received by the PeopleSoft Listening Connector

The response object is then converted to the MIME standard format by the connector.

The MIME response is then written to the gateway log file, and is then returned to the application server.

Interactions with the gateway are always synchronous. If a request is sent to the gateway, a response should be expected.

Step 2 is an HTTP POST request made of the gateway, and the response created here in Step 5 is returned in response to that HTTP request. The HTTP connection is open for the duration of the processing for that request.

The response object is returned to the listening connector, upon which the response is mapped to a response suitable for the given protocol.

Creating and Implementing Integrations

This section discusses:

Messaging elements used in integrations.
Steps for setting up integrations.

Understanding Messaging Elements Used in Integrations

You use the following elements to create and implement integrations.

Message channel definitions	A channel isolates different groups of messages from each other. Messages in the same channel are processed sequentially. Each participating node must contain a channel definition by the same name.
Message definitions	This definition holds the message data. Each participating node must contain a message definition by the same name, with the same structure. For synchronous integrations, you must provide a response message definition in addition to the request message definition.
Sending or receiving PeopleCode	PeopleCode used in integration consists of a routing event that routes messages to and from PeopleSoft Integration Broker, messaging PeopleCode that enables you to construct and manipulate data content, and publishing PeopleCode that actually publishes or sends messages.
Integration gateway definitions	This definition is an application’s internal representation of an installed integration gateway. An application requires at least the local gateway, through which it can send and receive messages. Multiple nodes can share the same local gateway, which might be the only gateway that you need for all of the integrations.
Node definitions	Nodes represent any organization, application or system that will play a part in integrations. For example, nodes can represent customers, business units, suppliers, other trading partners, external or third-party software systems, and so on. Node definitions define the locations to or from which messages can be routed. Because an application can send messages to itself, a default local node definition that represents the application is delivered as part of the integration engine. Each PeopleSoft installation must have one, and only one, default local node
Transaction definitions	A transaction assembles integration meta data together to form an integration. A transaction is associated with a specific, request message definition and version, a transmission type (asynchronous or synchronous), and a direction (outbound from or inbound to the default local node). If the transaction is synchronous, it also specifies a response message definition and version.
Relationships and transaction modifiers	A relationship reconciles incompatible transaction parameters to successfully transmit data from the source to the target. Every integration requires at least one transaction that is defined at each participating PeopleSoft Integration Broker node. A source node uses a transaction to send a message, and one or more target nodes use transactions to receive the message. If the transactions at the source and target nodes are defined with different parameters, they’ll be incompatible, and the message won’t be successfully transmitted. You can apply a transaction modifier to the initial transaction to produce a resulting transaction that is compatible with the target node. You define a transaction modifier with respect to a specified pair of nodes, which forms a relationship.
Transformation programs	A transformation or transform program is a type of Application Engine program that you develop and specify as part of a transaction modifier. PeopleSoft Integration Broker supports the use of Extensible Stylesheet Language Transformation (XSLT) code and PeopleCode for developing transform programs. Transform programs can transform, filter and translate data.

Setting Up and Creating Integrations

This section provide a high-level overview of the steps to set up and create integrations.

The Getting Started With Using PeopleSoft Integration Broker chapter in this PeopleBook also provides information for preparing to create integrations and using PeopleSoft Integration Broker.

See Getting Started with PeopleSoft Integration Broker.

Determining the Messaging Architecture

In this step you determine with what systems to integrate and the architecture to use.

For example, your purpose might be to integrate with other PeopleSoft 8.4x systems where a firewall is involved, integration with third-party systems, or integrations with PeopleSoft 8.1x systems.

This PeopleBook features an appendix that provides overview information about messaging architecture scenarios. It discusses the architecture for integrating with:

PeopleSoft Integration Broker systems.
PeopleSoft Integration Broker systems through firewalls.
PeopleSoft Integration Broker systems by using hubs.
Third-party systems.
Third-party systems by using remote gateways.
PeopleSoft 8.1x systems.

See Integration Scenarios.

Installing Web Servers

To install and run PeopleTools, you must install a web server. PeopleTools currently supports BEA WebLogic 8.1 and IBM WebSphere 5.1.

See Your web server documentation

Installing PeopleTools

PeopleSoft Integration Broker is installed as part of the PeopleTools installation process. The PeopleTools installation process also installs the executable file you need to install the PeopleSoft Pure Internet Architecture and the integration gateway.

See PeopleTools 8.46 Install Guide for your database.

Installing Application Databases

After you install PeopleTools, install your application database.

See PeopleTools 8.46 Install Guide for your database.

Installing and Starting the PeopleSoft Pure Internet Architecture and Integration Gateways

The next step is to install and start the PeopleSoft Pure Internet Architecture. The integration gateway is installed as part of the PeopleSoft Pure Internet Architecture installation.

Run the PeopleSoft Pure Internet Architecture setup program and start the application.

The location of the PeopleSoft Pure Internet Architecture setup file is <PS_HOME>\setup\mpinternet\setup.exe.
Verify that the web server is running; it must be running to start the PeopleSoft Pure Internet Architecture.
Start the PeopleSoft Pure Internet Architecture by launching the startPIA.cmd file.

The location of the file is <PS_HOME>webserv\peoplesoft\startPIA.cmd.

Note. To stop the PeopleSoft Pure Internet Architecture, launch the stopPIA.cmd file. The location of the file is <PS_HOME>webserv\peoplesoft\stopPIA.cmd.
Verify that the PeopleSoft Pure Internet Architecture is installed correctly by launching it in a web browser.

See PeopleTools 8.46 Install Guide for your database.

Installing, Configuring, and Starting Application Servers

After you install PeopleTools complete the following steps.

Configure an application server domain using the PSAdmin utility and boot the domain.

The location of the PSAdmin utility is <PS_HOME>\appserv\psadmin.exe.

Along with other required parameters, in the Quick-configure Menu be sure to set the Pub/Sub Servers option to Yes.
Boot the application server domain.
Verify that the application server is properly configured by starting PeopleSoft Application Designer.

See Enterprise PeopleTools 8.46 PeopleBook: System and Server Administration.

Activating Pub/Sub Server Domains

You must activate the domain on which the pub/sub server resides before you can use the messaging server.

To activate pub/sub server domains, access the Domain Status page in Integration Broker Monitor. In the Domains section of the page, locate your machine name and select Active from the dropdown list and click the Refresh button.

See Using the Integration Broker Quick Configuration Page.

Defining Integration Gateways and Loading Connectors

To define integration gateways and load connectors, use the Gateway component.

PeopleSoft Integration Broker is delivered with one local gateway, LOCAL, defined. You can use this gateway as the default local gateway, or create a new gateway and designate that one as the default local gateway.

After you access the delivered local gateway or create your own, you must specify its URL and save the changes. The gateway URL is typically the following:

http://<local_host>/PSIGW/PeopleSoftListeningConnector

The integration gateway URL is case sensitive.

Next you must click the Load Gateway Connectors button to load the connectors delivered with PeopleSoft Integration Broker.

See Using the Integration Broker Quick Configuration Page.

Configuring Integration Gateway Properties Files

After you define the default local integration gateway, specify the integration gateway URL and load the delivered connectors, you must configure the integration gateway properties file.

To establish settings for the integration gateway and its delivered connectors, you use the integrationGateway.properties file. To access the properties file, in the Gateways component click the Properties link next to the integration gateway URL field.

At a minimum you must set the BEA Jolt connection string parameters in the DELIVERED CONNECTOR CONFIGURATION Section of the file. In most situations, you set the parameters under “JOLT connect string settings for Application Server(s) with known NODENAMEs.”

See Using the Integration Broker Quick Configuration Page.

Creating Integration Meta Data

The next step is to create the integration meta data. This includes creating the following:

Node definitions.

Use the Node Definitions component to define nodes. You must define one local default node that represents the local system. You must also define nodes that represent the systems with which you integrate. These nodes are often referred to as remote nodes.
Message channels.

Use PeopleSoft Application Designer to define message channels. Verify in the Message Channel properties that the status is set to Active for any message channels you create.
Message definitions.

Use PeopleSoft Application Designer to define messages. Verify in the Message Definition properties that the status is set to Active for any message channels you create.
Add Integration PeopleCode.

To write routing PeopleCode use the routing events available in the message definition in PeopleSoft Application Designer.

PeopleSoft provides three application classes you can use to create and manipulate message content. These classes are the Message class, XMLDoc class, and SOAPDoc class.

To send messages, you also use the Message class

Use Message class functionality on the Subscription event to receive messages.
Transactions.

Use the Node Definitions — Transaction page in the PeopleSoft Pure Internet Architecture to define transactions.
Relationships (Optional.)

Use the Relationships component to define relationships.
Transformation programs. (Optional.)

In PeopleSoft Application Designer, create a new App Engine Program object. Make sure to set the Program Type to Transform Only on the Advanced tab in the Program Properties dialog box.

See Defining Message Channels and Messages, Sending and Receiving Messages, Configuring Nodes and Transactions, Applying Filtering, Transformation and Translation, Administering Relationships.

Granting Security Access to Message Channels

If you create new message channels, you must grant users access to them to view or edit channel information, as well as the messages contained within them. Moreover, granting security access to new message channels is required to see transaction information in the Integration Broker Monitor.

Users can view messages only in channels to which they have read access. All edit actions require write access.

To grant security access to message channels, use the Channel Security Link on the Integration Broker Quick Configuration page.

See Using the Integration Broker Quick Configuration Page.