Introduction to PeopleSoft Integration Broker


PeopleSoft Integration Broker is a middleware technology that:

1)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.

2)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.

3)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.

4)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.

5)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.



There is a series of events which happen when a PeopleSoft Integration Broker receives incoming requests.






1) 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 request is written exactly as it is received. This helps capture the message as it was sent and before normalization occurs.

2) The connector then attempts to populate an internal request message class with the particulars from the received message. Incoming messages have 2 parts – credentials and mesage body. It is interesting to note that a message without credentials cannot be processed . If the gateway receives such a message – an error will occur and an error message will be returned to the requestor. No parsing happens at this step – just the validation.


3) Next the message is served to the PeopleSoftTargetConnector. This connector has two major responsibilities: it serializes the message to a string, and sends that string via a JOLT connection to the app server.

4) PeopleSoftTargetConnector transforms the message in a standard format, which is understood by both the gateway and the application server. All messages must eventually resolve to this format before they can be sent to the app server for processing, else the appserver won’t be able to understand them. This format effectively isolates the app server from the protocols supported by the gateway; there is no information present about what listening connector was initially invoked by the external request.


5)Finally, the connector looks up the JOLT connection properties from the integration properties file and attempts to send the Messages to the application server. If these properties are not set up correctly, the gateway will be unable to send requests.