WebSphere Partner Gateway PIP sample

WebSphere Partner Gateway provides the PIP sample to demonstrate how to set up WebSphere Partner Gateway and WebSphere InterChange Server to exchange messages when you implement WebSphere InterChange Server as a back-end application. Additionally, you can see how WebSphere Partner Gateway behaves when sending and receiving messages from a Community Participant and how it handles attachments.

The PIP sample supports three 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. The third scenario demonstrates how WebSphere Partner Gateway handles a one-action PIP that has an attachment.

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

Topology used by the sample

All of the scenarios use the same topology. As shown in Figure 1, System A has WebSphere InterChange 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.

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 InterChange Server receiving a 3A4 request business object from the port connected to the back-end adapter. 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 these IDs along with the status of the request message.

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. This instance generates a 3A4 PIP for RNIF 2.0 and sends it to the seller's gateway. This 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 process on the WebSphere InterChange Server. The buyer process updates the status of the PIP transaction.

The seller's WebSphere Partner Gateway packages the 3A4 content in back-end integration packaging and sends this message to the seller process running in WebSphere InterChange Server. The seller process saves the IDs contained in the Backend Integration packaging and sends the request to the port connected to the back-end adapter.

The back-end adapter asynchronously sends the PIP 3A4 response message to the seller process. The seller process retrieves the unique IDs (x_aux_process_instance_id and x_aux_system_msg_id) from the database and populates the response message with them. 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 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 statusCode of 100 to the seller process in the WebSphere InterChange Server. The buyer's WebSphere Partner Gateway asynchronously sends the PIP 3A4 response message to the buyer process in WebSphere InterChange Server. The buyer process updates the status of the PIP transaction and sends the response message to the port that connects to the back-end adapter.

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 sends the response to the port that connects to the back-end adapter, it receives a cancellation event from the back-end of the buyer process. The buyer process updates the status of the PIP transaction to 800. 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 in the Documentid column in the database table used to store message metadata
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 process then sends the event notification message to its gateway. The buyer's WebSphere Partner Gateway instance receives the event notification message and generates an 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 process.

Scenario 3: Processing a PIP with attachments

Scenario 3 demonstrates how WebSphere Partner Gateway processes a PIP that has attachments. When a request message arrives from the back-end adapter of the buyer process, it may contain attachments. Each attachment can be a file that WebSphere InterChange Server passes through or an XML representation of a WebSphere InterChange Server business object. This scenario provides an example of each type of attachment. For the file attachment, WebSphere InterChange Server reads the file and base64 encodes it. WebSphere InterChange Server then stores the encoded attachment content as the defaultAttachment as shown in line 5.1.1 in Figure 4:

Figure 4. Specification of an attachment in an InterChange Server business object.
Specification of an attachment in an InterChange Server business object.

For the business object attachment, WebSphere InterChange Server stores it unchanged as attachmentOne in Figure 4.

The buyer process sends the request along with the attachments to the buyer's gateway. The buyer's WebSphere Partner Gateway instance generates the PIP (including attachments) and sends it to the seller's gateway. The seller's WebSphere Partner Gateway instance sends the request and its attachments to the seller's WebSphere InterChange Server. On the seller's WebSphere InterChange Server, the attachment data handler converts the BCG_Persons attachment to a business object.

The seller process retrieves the defaultAttachment, decodes the attachment file, and saves it in the attachment directory. While constructing the message to the back-end adapter, the seller process replaces the attachment content with the path to the file in the attachment directory. The seller process does not make any changes to the BCG_Persons business object. The seller then sends a request message to the port connecting to the back-end adapter. The back-end application uses the file path to retrieve the attachment file when needed.

Copyright IBM Corp. 2003, 2005