WebSphere Partner Gateway PIP sample

WebSphere Partner Gateway provides the PIP sample to demonstrate how to set up WebSphere Partner Gateway and WebSphere Process Server to exchange messages when you implement WebSphere Process Server as a back-end application. Additionally, you can see how WebSphere Partner Gateway behaves when sending and receiving messages from a community participant.

Note:
For information on how to design and implement your business processes, components, and integration solutions using WebSphere Process Server, refer to the WebSphere Process Server documentation.

Although this PIP sample can be used with a WebSphere Partner Gateway installation that uses either WebSphere Application Server v6.0 or the embedded version of WebSphere Application Server Express, the instructions in this guide assume that the WebSphere Partner Gateway installation is using WebSphere Application Server v6.0.

The PIP sample supports two scenarios. The first scenario demonstrates how WebSphere Partner Gateway handles a two-action PIP. The second scenario is a continuation of the first scenario in which the PIP is cancelled.

For additional information on integrating WebSphere Partner Gateway with WebSphere Process Server, see the Enterprise Integration Guide.

Topology used by the sample

Both of the scenarios use the same topology. As shown in Figure 1, System A has WebSphere Process Server and performs the roles of back-end application and community participant. One process, the buyer process, initiates the PIPs and another process, the seller process, receives the PIPs.

System B has WebSphere Partner Gateway Enterprise Edition performing the role of PIP requester. This system receives the PIP content from the buyer process in System A and sends the PIP message to System C. System C has WebSphere Partner Gateway Enterprise Edition performing the role of PIP responder. This system receives PIP messages from System B and passes the content on to the seller process on System A.

Messages between System A and the other systems are handled by WebSphere platform messaging, running in the instance of WebSphere Application Server that is installed with WebSphere Process Server on System A.

Figure 1. Topology used by the PIP sample.
Topology used by the PIP sample.

Scenario 1: Processing a two-action PIP

Scenario 1 demonstrates how WebSphere Partner Gateway processes a two-action PIP as a sender and receiver. Figure 2 shows the flow of PIP or PIP content messages among the systems in the scenario.

Figure 2. The flow of PIP or PIP content messages among the systems.

The scenario starts with the buyer process in WebSphere Process Server receiving a 3A4 request business object from the JSP file. This JSP file represents EIS for the buyer process. The buyer process creates a 3A4 request message and sets the unique IDs (x_aux_process_instance_id and x_aux_system_msg_id) in the Backend Integration header of the message. The buyer process persists (stores in correlation sets and PIP3A4Buyer database) these IDs.

The buyer process sends the request on JMS to the WebSphere Partner Gateway instance configured as the buyer's gateway, which is the instance on System B. The buyer's gateway sends the RNIF request to the seller's gateway. The seller's gateway is the WebSphere Partner Gateway instance on System C. The seller's WebSphere Partner Gateway receives the RNIF request message, validates it and sends an acknowledgment signal to the buyer's gateway. The buyer's WebSphere Partner Gateway sends an EventNotification message with a statusCode of 100 to the buyer on the WebSphere Process Server. The buyer event dispatcher determines from the database table which buyer process needs to be invoked with this EventNotification message. The event dispatcher then invokes the PIP3A4Buyer process. Using correlation sets, the BPEL engine determines which PIP3A4Buyer process instance is waiting for this EventNotification message. This PIP3A4Buyer process instance receives the message and logs the message in the Systemout.log file.

The seller's WebSphere Partner Gateway packages the 3A4 request content in back-end integration packaging and sends this message to the seller process running in WebSphere Process Server. The seller process saves the IDs (in the correlation set and PIP3A4Seller database) contained in the Backend Integration packaging and logs the message in the Systemout.log file.

The JSP file on the sellers side represents EIS for the seller process. The JSP file (at the seller side) asynchronously sends the PIP 3A4 response message (confirmation) to the seller process. Using correlation sets, the BPEL engine determines which PIP3A4Seller process instance is waiting for this PIP3A4 response message. This PIP3A4Seller process instance receives the PIP3A4 response message. The seller sends the response message to the seller's WebSphere Partner Gateway, which packages the response in RNIF format and sends it to the buyer's gateway. The seller process update the database contents and stops the seller process.

The buyer's WebSphere Partner Gateway validates the response and sends an acknowledgment back to the seller's gateway, which in turn sends an Event Notification message with a status code of 100 to the seller event dispatcher in the WebSphere Process Server. The buyer's WebSphere Partner Gateway asynchronously sends the PIP 3A4 response message to the buyer process in WebSphere Process Server. Using correlation sets, the BPEL engine determines which PIP3A4Buyer process instance is waiting for this PIP3A4 response message. This PIP3A4Buyer process instance receives the PIP3A4 response message. This PIP3A4 process instance then updates the contents of database table, logs a message in the Systemout.log file, and stops the buyer process.

Scenario 2: Processing a 0A1PIP

Scenario 2 is a continuation of Scenario 1. Figure 3 shows the messaging of the first scenario and the messaging used to cancel the PIP, which is Scenario 2.

Figure 3. The flow of PIP or PIP content messages among the systems in scenario 2.

After the buyer process receives the response and successfully logs the message into the Systemout.log file, it stops the buyer process. The buyer event dispatcher receives a cancellation event from the JSP file of the buyer process. From the cancellation event, the buyer event dispatcher determines which process this event should be dispatched. From the database table, the buyer event dispatcher determines if the process instance referenced in the cancellation event is still running. If the PIP3A4Buyer instance is still running, the event dispatcher invokes this process instance with the cancellation event. The JSP page at the buyer process then populates an Event Notification message with the following information:

Table 1. Scenario 2 Event notification field values
Field Value
StatusMessage Text that indicates that the application that sent the 3A4 PIP request has cancelled it
StatusCode "800" to indicate that the Event Notification message is to cancel a PIP
EventMessageID Identifier for this Event Notification message
BusinessObjectID Identifier of the PIP request to be cancelled. This is the value of DocumentId of the original PIP request.
GlobalMessageID Identifier of the PIP request message. This is the value in the Msgid column in the database table used to store message metadata

The buyer event dispatcher then sends the event notification message to its gateway. The buyer's WebSphere Partner Gateway instance receives the event notification message and generates a 0A1 PIP based on the message. The instance sends the 0A1 PIP to the seller's gateway. The seller's WebSphere Partner Gateway instance receives the PIP 0A1 message and sends it to the seller to the seller event dispatcher.

Copyright IBM Corp. 2003, 2005