PeopleSoft Integration Broker serves as a middleware solution that facilitates communication through both asynchronous and synchronous messaging between internal systems and external third-party applications. It enables the following functionalities:
This integration broker effectively manages variations in data structures, formats, and transport methods between internal systems and third-party partners. Its modular architecture allows for the reuse of various integration components, enhancing efficiency in the development of integration solutions.
PeopleSoft Integration Broker is divided into two primary subsystems:
Important Note: PeopleSoft Integration Broker can connect with various third-party products, but this documentation is not a definitive guide for them. Always refer to the specific documentation for each third-party application. This guide helps you determine the necessary configuration settings for PeopleSoft Integration Broker; however, it does not cover every possible scenario, and examples may not apply to your situation. Effective setup requires your expertise and the most current information about third-party products.
This section discusses the components of the integration gateway, including architecture components, connectors, the gateway manager, and gateway services.
The integration gateway is essential for receiving and sending messages among integration participant systems. It consists of:
Image: Integration Gateway Architecture
This image illustrates the various components that make up the architecture of the integration gateway.
Connectors are crucial for transporting messages between integration participants and the integration gateway. They support both asynchronous and synchronous message handling. Connectors can be configured at both the integration gateway and system levels.
Listening connectors handle incoming data streams and execute specific actions based on the data’s content. These connectors are triggered by external sources, such as other PeopleSoft systems or third-party applications.
Target connectors initiate interactions with other PeopleSoft systems or external applications. While they may not always receive a response from the target system for each operation, a low-level acknowledgment is required for every transmission.
The integration gateway offers a flexible model for creating new connectors that align with the interface specifications of the PeopleSoft Integration Broker SDK, enabling PeopleSoft clients, consultants, and developers to design custom connectors.
The gateway manager processes every message that flows through an integration gateway and maintains links to other major integration gateway components, including target connectors, listening connectors, and each of the gateway services.
Listening connectors invoke the gateway manager upon receiving a request. The gateway manager utilizes the messaging objects IBRequest and IBResponse to decide how to route each incoming request.
During this process, it employs various gateway services to carry out tasks like validating messages. It then invokes the appropriate target connector based on the message content and waits for a reply. Upon receiving the reply, the gateway manager forwards it to the calling listening connector. If an error occurs, the gateway manager uses the error handling service to prepare an error reply for the listening connector.
This section describes the gateway services that the gateway manager uses.
Most IBRequest and IBResponse objects processed in the system contain a content section that represents the actual business content sent, often in XML format. The integration gateway includes an XML parsing service consisting of objects that provide an intuitive interface for manipulating XML objects. This service includes three classes: XmlDocument, XmlNode, and XmlNodeList.
Two objects comprise the messaging objects service in the integration gateway:
These objects represent the request and response that enter and exit PeopleSoft Integration Broker.
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.
WS-Security is an extension to the SOAP envelope header that enables applications to construct secure SOAP message exchanges. It provides a means for associating security tokens with messages.
Most components in the system use a standard error-logging interface. Each PeopleSoft-delivered connector uses the logging API in the same manner, allowing administrators to quickly identify problems or review logs to see the IBRequest object, the IBResponse object, and the raw data exchanged with integration participants.
The integration gateway provides a standard error-handling interface accessible to each connector. This service offers error handling and error logging for most connectors delivered with the PeopleSoft Integration Broker.
Messages entering the PeopleSoft Integration Broker must contain certain elements to be processed. Since the integration gateway is the first component that processes messages sent to a PeopleSoft application, it performs basic validation—such as ensuring that the message identifies its requestor and service operation name—to ensure that the integration engine and target application can process them.
The integration engine plays a critical role in the PeopleSoft Integration Broker, utilizing various PeopleTools elements to effectively create, implement, manage, and enhance integrations. Its modular architecture is designed to separate integration development tasks from administrative functions, promoting efficiency and clarity.
This engine combines several components, including PeopleSoft Application Designer definitions, elements defined in the PeopleSoft Pure Internet Architecture, PeopleCode, and XSLT code. These elements are interconnected through essential underlying mechanisms, which include request handlers responsible for processing both inbound and outbound messages. The design specifications of these messages are derived from the defined development and administrative elements.
The integration engine operates on the PeopleSoft application server, ensuring robust functionality and connectivity.
This diagram illustrates the integration components residing on the integration engine and the various types of processing it performs.
In the PeopleSoft system, a service operation encapsulates the logic required for processing integrations, determining whether the integration occurs synchronously or asynchronously. Each service operation definition consists of several key components:
PeopleSoft Integration Broker facilitates four distinct types of service operations:
Note: In this context, the term transaction refers to the exchange of data between integration partners.
When a service operation is transmitted through PeopleSoft Integration Broker, the receiving system generates a response that is sent back to the original sender. In the case of asynchronous transactions, the integration gateway automatically generates a response solely to inform the sending system about the transmission status of the request. This status is subsequently processed by the application server, which utilizes this information to update the Service Operations Monitor.
Conversely, synchronous transactions involve the receiving system generating and returning a response that includes the requested content. This response must be explicitly created and transmitted back to the sending system.
PeopleSoft Integration Broker supports the following operation types:
Tabulation
This section provides a comprehensive overview of how inbound and outbound service operations flow through the components of the PeopleSoft Integration Broker. For a more in-depth understanding of the PeopleSoft messaging architecture, please refer to the “Understanding Messaging” section in the product documentation.
This segment details the typical flow of an inbound request from an external system into the PeopleSoft Integration Broker.
Image: Flow of an inbound request through the PeopleSoft Integration Broker.
Once the integration gateway receives an incoming request, the subsequent flow through the PeopleSoft Integration Broker remains consistent, irrespective of the listening connector involved. Therefore, specific listening connectors will not be addressed here. The process is straightforward: the request is directed into the gateway, which subsequently forwards it to the application server. The application server then processes the request and generates a response.
An external system, which could be another PeopleSoft system or a third-party application, initiates the process by sending a request to the PeopleSoft Integration Broker.
Upon receipt, the listening connector logs the request in the gateway log file. The gateway’s integration properties file controls the logging level, determining what is recorded. This initial log entry captures the request as received, which is crucial for debugging purposes before normalization occurs for processing by the application server.
The connector then populates an internal request class with details from the incoming request. Requests consist of two logical parts: credentials and the body. Credentials are essential for PeopleSoft Integration Broker to process the message’s payload, while the payload resides in the body. Without valid credentials, the request cannot be processed, resulting in an error message being returned to the requester.
To forward the request from the gateway to the application server, it must first pass through the PeopleSoft target connector. This connector has two primary functions: serializing the request into a string and sending that string via a JOLT connection to the application server.
Communication between the gateway and application server utilizes Multipurpose Internet Mail Extensions (MIME) messages. The target connector constructs a MIME message, typically containing two sections: one for credentials (formatted as an XML document) and another for the request body. This standard format allows the application server to remain isolated from the specific protocols utilized by the gateway.
After constructing the MIME message, it is logged before attempting to send it to the application server. Proper configuration of the JOLT connection properties in the integration properties file is critical; any misconfiguration can lead to failed requests. While the gateway log will display the MIME request, communication errors may occur without an entry indicating failure.
When the MIME request reaches the application server, it is parsed into a request object. The MIME structure does not persist within the server. Assuming successful parsing, the application server then pre-processes the request, which involves:
Authenticating the service operation according to the configured authentication scheme.
Determining the service operation’s direction by examining the external alias in the associated routing definition.
Identifying the runtime handler to invoke, with three supported handler types: Ping, Synchronous, and Asynchronous. The type of service operation dictates the corresponding handler code.
Further processing depends on the specific PeopleCode and data relevant to the system, or in hub configurations, the request may be routed to another external system.
Regardless of the request’s processing outcome, the application server must return a response to the gateway within the same execution thread. This synchronous connection means that the gateway awaits a response after sending a request.
For synchronous processing, the response generation is blocked until the service operation completes. Delays may occur depending on the complexity of the request’s processing or if it requires external system interactions. Conversely, asynchronous requests do not block; a response is generated immediately upon placing the request on the publication queue, serving as an acknowledgment rather than a completion guarantee.
The application server converts responses to the MIME format before returning them to the gateway.
Upon receiving the MIME response, the PeopleSoft target connector logs it, parses it back into a gateway request object, and returns it to the listening connector.
The response object is returned to the listening connector, which then maps it into a suitable format for the corresponding protocol. It’s important to note that the listening connector processes requests synchronously, meaning the entire request-response cycle occurs within the same execution thread.
This section describes the process for outgoing requests through the PeopleSoft Integration Broker to external systems.
Image:
Several scenarios can lead to a request being dispatched from the broker. Requests may be initiated in PeopleCode through the Publish or SyncRequest methods of the Integration Broker class.
No matter how the request is generated, the process for sending it out of the broker remains consistent, and the flow does not change based on the specific outgoing target connector used.
After generating an outgoing request, the application server performs essential processing. It examines the request to determine the target node. If no target connector information is supplied via PeopleCode or routing, the node name is used to identify the gateway, target connector, and any specific connector properties required for processing. If this information is absent, an error is triggered.
The application server modifies the request with the appropriate connector information, converts it to MIME format, and sends it to the gateway over an HTTP connection.
Upon receiving the MIME request, the listening connector logs it and converts it into a gateway request object. The connector then identifies the target connector for further processing.
The target connector validates the request, ensuring all required properties are set. For example, the HTTP target connector mandates that the PrimaryURL is configured. Missing or invalid properties result in an error. After validation, the request is formatted according to the required protocol and logged before being sent out.
The response from the external system is logged by the target connector and used to construct a gateway response object, which is returned to the PeopleSoft listening connector.
The response object is converted back to MIME format and logged before being sent to the application server. Interactions with the gateway are synchronous; upon sending a request, a response is expected.
Step 2 involves making an HTTP POST request to the gateway, while the response generated in Step 5 is returned as a reply to that HTTP request. The HTTP connection remains active for the duration of the request’s processing.
The final response is returned to the listening connector, which maps it into a suitable format for the appropriate protocol.
Connect with us for PeopleSoft End-to-End Implementation, Enhancement, Updates, and Support.
Read More