Business Integration Connect provides the PIP sample to demonstrate how to set up Business Integration Connect and WebSphere Interchange Server to exchange messages when you implement WebSphere Interchange Server as a back-end application. Additionally, you can see how Business Integration Connect 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 Business Integration Connect 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 Business Integration Connect handles a one action PIP that has an attachment.
For information additional information on integrating WebSphere Interchange Server, see the Integration Overview.
All of the scenarios use the same topology. 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 Business Integration Connect 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 Business Integration Connect 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.
The following diagram shows the topology:
Scenario 1 demonstrates how Business Integration Connect processes a two
action PIP as a sender and receiver. The following diagram shows the
flow of PIP or PIP content messages between the systems in the
scenario.
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 Business Integration Connect 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 Business Integration Connect instance on System C. The seller's Business Integration Connect receives the RNIF request message, validates it and sends an acknowledgment signal to the buyer's gateway. The buyer's Business Integration Connect 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 Business Integration Connect packages the 3A4 content in Backend 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 Business Integration Connect, which packages the response in RNIF format and sends it to the buyer's gateway.
The buyer's Business Integration Connect 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 Business Integration Connect 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 is a continuation of Scenario 1. The following diagram
shows the messaging of the first scenario and the messaging used to cancel the
PIP, which is 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 Business Integration Connect 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 Business Integration Connect instance receives the PIP 0A1 message and sends it to the seller to process.
Scenario 3 demonstrates how Business Integration Connect 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 the following figure:
For the business object attachment, WebSphere Interchange Server stores it unchanged as attachmentOne in the above figure.
The buyer process sends the request along with the attachments to the buyer's gateway. The buyer's Business Integration Connect instance generates the PIP (including attachments) and sends it to the seller's gateway. The seller's Business Integration Connect 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.