Fundamentals Of PeopleSoft Integration Broker

I have been trying to push myself hard for a long time to publish this article but honestly, I have been way too lazy to do that. Well, now is the time.

A very important highlight of this article is we are going to talk about only absolutely relevant elements so that it becomes easier for you guys to get good understanding on Integration Broker because often times I find people being lost in the PeopleBooks trying to figure out what exactly they should refer to. 

Related Articles:

PeopleSoft to PeopleSoft Integration through Integration Broker

PeopleSoft to Third Party Integration Through Web Services

Lets start with Architecture which shows the elements of Integration:

This architecture clearly depicts the integration between PeopleSoft Finance and PeopleSoft HR system represented by Node A and Node B respectively where the changes made in former would be transmitted to latter through Integration Broker.

Lets assume that the integration is setup for the Bank Account changes done on Finance System which should ultimately be transmitted to HR System to keep both in sync. Now our rest of the discussion would be based on this scenario.

The very first thing we must talk about is the various elements involved in this Integration Setup.

Elements of Integration

Integration Engine

The integration engine as you can see in the architecture above, is something that ties all the elements like Service Operation, Message, Routing etc... together which ultimately creates a mechanism for integrating two systems.

The integration engine runs on the PeopleSoft application server. 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.
• Handles messages containing data in a variety of formats. Formats include the PeopleSoft rowset-based message format, and nonrowset-based message structures including, XML document object model messages, Simple Object Access Protocol (SOAP) messages, and non-XML files.
• 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.

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 application 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:

• Listening connectors and target connectors that transport messages between integration participants and the integration engine.
• 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.

Connectors

Listening Connectors

Listening connectors receive requests from integration participants, send them to the gateway manager, and deliver responses back to the integration participants.

Target Connectors

Target connectors generate requests, send them to integration participants, wait for responses from participants, and deliver the responses back to the gateway manager.

Related Articles:

PeopleSoft to PeopleSoft Integration through Integration Broker

PeopleSoft to Third Party Integration Through Web Services

Message

Message definitions provide the physical description of the data that is being sent, including fields, field types, and field lengths. You create message definitions in the PeopleSoft Internet Architecture. In other words Messages are shapes that describe the contents of a service operation transaction.

In our scenario the message definition would contain the information about the table structure used in the component 'Bank Account' i.e the records used in the component and their hierarchy. This information will be used by Integration Engine to transmit the data when there is a change in employee's bank accounts. 

Message Type	When to Use	Details
Rowset-based messages	All PeopleSoft-to-PeopleSoft integrations	For hierarchical data that is based on PeopleSoft records, you create a message definition by assembling records, organizing them into a hierarchy, and selecting fields from those records to include in the message.
Nonrowset-based messages	Integrations with third-party systems	These messages can have virtually any structure and content. You create a message definition, but you do not insert any records. The message definition serves as a placeholder for the actual message.

Handler

It contains the processing logic for finally writing the data into tables/components of the receiving node. It is combination of Application Package, Class, Method created in the application designer.

In our scenario the handler defined on HR Node would contain the business logic written in PeopleCode to write the Bank Account changes received from Finance Node, to the corresponding tables/components. 

Routing

A routing definition specifies the direction of the integration (inbound or outbound), routing alias names, transformations, and more. 

In our scenario, the routing on HR Node would be Inbound and on Finance Node it would be Outbound.

Service Operations

This element forms for overall processing logic by combing following elements:

• Message
• Handler
• Routing

Node

Nodes represent any organization, application or system that will play a part in integration.

In our scenario there are two nodes:

1. One that represents PeopleSoft FIN System
2. Another that represents PeopleSoft HR System

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.

Each PeopleSoft Integration Broker database involved in an integration must contain a default local node definition for itself, and a remote node definition for each of the other nodes involved.

Local and remote nodes are concepts relative to the database in which the nodes are defined. If you’re signed on to Database A which has Node A defined, then Node A is local. If you’re signed on to Database B, Node A is defined as remote.

In our scenario if we are in the Node A - PeopleSoft FIN System then:

·        Node A (default local)

·        Node B (remote)

The following definitions must exist in the Node B - PeopleSoft HR Systen for it to integrate with Node A:

·        NODE A (remote)

·        NODE B (default local)

In practice, only portals use nodes designated simply as Local. The only local node definition used by PeopleSoft Integration Broker is the one designated Default Local, which represents the database onto which you are signed.

Want to learn PeopleSoft technical module thoroughly? I have several videos with total duration of over 50 hours.

Following is the link to the YouTube videos Technical
Click here to see course contents

Click here to know how it works

However, if you want to save money by purchasing whole module instead of in parts then visit this page to get more details PeopleSoft Functional and technical online training