INTEGRATION BROKER

PeopleSoft Integration Broker to perform asynchronous and synchronous messaging among internal systems and third-party systems.

Because of its modular design, Integration Broker can be reused in other integrations. The two major components of PeopleSoft Integration Broker are the integration gateway and the integration engine. The integration gateway is a platform that manages the receipt and delivery of messages passed among systems through PeopleSoft Integration Broker. The integration engine is an application server process that routes messages to and from PeopleSoft applications as well as tranforms the structure of messages and translates data according to specifications that you define. 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 Architecture 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. 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.

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 thirdparty 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. 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 Outbound asynchronous Actions 1. The application generates and sends a request message. 2. One or more target system receives and processes the request

Transaction Type message. Outbound synchronous

Actions

1. The application generates and sends a request message. 2. The application suspends activity and waits for a response message. 3. A single target system receives and processes the request message, then generates and sends a response message. 4. The application resumes its activity and receives and processes the response message. 1. A source system generates and sends a request message. 2. The application receives and processes the request message. 1. A source system generates and sends a request message. 2. The source system suspends activity and waits for a response message. 3. The application receives and processes the request message, then generates and sends a response message. 4. The source system resumes its activity and receives and processes the response message.

Inbound asynchronous Inbound synchronous

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.

APPLICATION MESSAGE Message definitions are the heart of PeopleSoft Integration Broker. They are templates for the data that the application sends or receives. You create message definitions in PeopleSoft Application Designer. There are two types of messages: Rowset-based messages. For hierarchical data 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. The result is a rowset that doesnt need to match an existing rowset structure in the application. Use the PeopleCode Rowset and Message classes to generate, send, receive, and process these messages. Non-rowset-based messages. 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. Use the PeopleCode XmlDoc and Message classes to generate, send, receive and process these messages. If youre handling Simple Object Access Protocol (SOAP) compliant data, you can also use the SoapDoc class to generate and process these messages. Note : For asynchronous integrations, define a single message. For synchronous integrations, define two messages: one for the request and one for the response.

PeopleCode Associated with Messages: The following People Code events are associated with messages: OnRouteSend OnRouteReceive OnRequest Subscription OnAckReceive OnSend

OnRouteSend and OnRouteReceive: These PeopleCode events are used with routing rules to determine where the messages are routed to and received from. OnRequest: This PeopleCode event is used with synchronous messages, when a message has been received and requires a reply. Subscription: This PeopleCode event is used when the message is subscribed to. Use this for your subscription processing for validating and loading message data.

OnAckReceive: This PeopleCode event is used for asyncronous messages to change the status of the message (such as RETRY, DONE, or ERROR) based on the returned (successful) acknowledgement when it posted to the gateway. Use this when sending to a third party or when receiving a SOAP response, because though the delivery is successful, the content data could be in error. OnSend: This PeopleCode event is used for both synchronous and asynchronous messages to overrride the connector properties before sending the message to the gateway.