Understanding PeopleSoft Integration Broker – Introduction (Part 1)

PeopleSoft Integration Broker can be daunting for those who are new to Integration Broker and hence, this post has been written with the intend of helping those who want to learn PeopleSoft Integration Broker. Skills for understanding PeopleSoft Integration Broker are PeopleTools, PeopleCode and Application Engine are a must. Additional experience in XML, SOAP, HTTP, WSDL, WADL, UDDI and Java would be a plus, but you can learn those later on as well.

Introduction to PeopleSoft Integration Broker

PeopleSoft Integration Broker is a middleware technology that:

• Performs asynchronous and synchronous messaging among internal systems and third-party systems.
• Exposes PeopleSoft business logic as web services to PeopleSoft and third-party systems.
• Consumes and invokes web services from third-party and PeopleSoft systems.

Click here to know more about asynchronous and synchronous messaging

The two major components of PeopleSoft Integration Broker, which help you accomplish this task are the integration gateway and the integration engine, which is otherwise also known as the application engine.

The integration gateway is a collection of Java servlets and classes running on a web server. It is essentially a platform that manages the receipt and delivery of messages passed among systems through PeopleSoft Integration Broker and acts as an interface between the application server and the external system.

The gateway isolates the application server from the various communication protocols that can be used to access it. The gateway also normalizes all incoming requests so that by the time they reach the applications server, they are in a standard format. Similarly, it also converts requests being sent out of the application server from the standard to a format suitable for the outgoing protocol being used.

Although the gateway is comprised of many different classes, two broad types of classes, which are of our interest here are: Listening Connectors and Target Connectors.

Listening Connectors, as the name suggests are used to “listen” for incoming requests from external systems. These connectors provide the point of entry for external systems into the integration broker, and such systems directly access these connectors in order to send requests. Each connector is responsible for normalizing the incoming protocol dependant request before it is sent on to the application server.

Listening Connectors are protocol specific. The following listening connectors are currently available:

• HTTPListeningConnector – handles incoming HTTP requests, including Simple Object Access Protocol (SOAP) requests made over HTTP
• JMSListeningConnector – handles Java Messaging Service (JMS) requests
• PeopleSoftListeningConnector – handles incoming requests from other integration brokers.

Target Connectors complement the Listening Connectors. Target Connectors provide the mechanism for the application server to send requests to external systems. Requests from the application server are sent to the gateway in normalized format. Once the request reaches the gateway it is then passed to the appropriate target connector, which will then convert it to a format appropriate for the outgoing protocol. The message is then sent out to the external system.

Target Connectors are also protocol specific. The following target connectors are currently available:

• HTTPTargetConnector – handles outgoing HTTP and SOAP requests
• FTPTargetConnector – allows the retrieval of files from a File Transfer Protocol (FTP) server
• JMSTargetConnector – handles outgoing Java Messaging Service requests
• SMTPTargetConnector – allows email to be sent to a Simple Mail Transfer Protocol (SMTP) server
• POP3TargetConnector – allows email to be retrieved from a Post Office Protocol (POP3) account.
• PeopleSoftTargetConnector – handles requests being sent to other integration brokers.

Click Here to go to Part 2 of Understanding Integration Broker: How the Integration Broker Handles Incoming Requests