How the Integration Broker Handles Outgoing Requests (Understanding PeopleSoft Integration Broker Part 3)
It is assumed that you’ve already read the Part 1: Understanding Integration Broker – Introduction and Part 2 of the series on Understanding Integration Broker – How the Integration Broker Handles Incoming Requests.
PeopleSoft handles the outgoing messages in the same manner, regardless of the specific outgoing Target Connector being invoked.
1) Application Server generates request and extracts the information about the node that it is to be sent to. The node name is then used to look up the name of the gateway to use, the Target Connector to use on that gateway, as well as any specific connector properties that need to be passed to the connector in order to handle the request. If this information is not found, an error will occur.
The app server modifies the outgoing request with the appropriate connector information, converts it to the MIME standard format, and sends it to the gateway over an HTTP connection.
The request must be sent to the PeopleSoftListeningConnector on the gateway. The app server uses the value of the “Gateway URL” defined for the given gateway. If this URL is not valid or does not point to the PeopleSoftListeningConnector, the app server will be unable to send the request.
2) When the MIME request is received by the PeopleSoftListeningConnector, it is written to the gateway log file. The request is converted from MIME format to a gateway request object. The appropriate TargetConnector is then invoked.
3) The TargetConnector validates the request. Each connector requires certain properties to be set, otherwise the request cannot be sent. For example, the HTTPTargetConnector requires that the “PrimaryURL” be set. If any mandatory connector properties are missing or are invalid, an error will be thrown.
The TargetConnector then converts the request message into whatever format is required by the protocol. The modified request is then written to the gateway log, and the request is sent out.
4) The response received by the TargetConnector is written to the gateway log, and the response is used to build a gateway response object, which is then returned to the PeopleSoftListeningConnector.
5) The response object is then converted to the MIME standard format by the connector.
The MIME’d response is then written to the gateway log file, and is then returned to the app server.
Again, it should be emphasized that interactions with the gateway are always synchronous. If a request is sent to the gateway, a response should be expected.
Step 2 is an HTTP POST request made of the gateway, and the response created here in Step 5 is returned in the response to that HTTP request. The HTTP connection is open for the duration of the processing for that request.
6) A response is built out of the MIME response and is returned to the routine that created the request
