To enable communication between WebSphere Data Interchange and WebSphere Partner Gateway, you perform the following setup and configuration tasks:
The first step in setting up the environment is to configure WebSphere MQ intercommunication. Intercommunication means sending messages from one queue manager to another. The first step is to define a queue manager (and associated objects) for the WebSphere Data Interchange system and the WebSphere Partner Gateway system. If you will be sending messages in both directions, you set up a source queue manager and a target queue manager on both systems. On the source queue manager, you define a sender channel, a remote queue definition, and a transmission queue. On the target queue manager, you define a receiver channel and a target queue.
This section shows you the values you would use to set up the queue managers and associated objects needed for the sample scenario. In the scenario, WebSphere MQ V5.3 is installed on both Computer A and Computer B. The first step, then, is to create a queue manager on both Computer A and Computer B for use with WebSphere Data Interchange and WebSphere Partner Gateway Enterprise Edition respectively.
To send messages from one queue manager to another using WebSphere MQ, you define the following objects:
In the sample scenario, both Computer A and Computer B act as sender and receiver. Therefore, you would have to define a number of objects on each computer.
Table 73 lists the objects you would create to set Computer A and Computer B as sender and receiver.
WebSphere MQ object | Computer A | Computer B |
---|---|---|
Queue Manager |
WDI32_QM |
HUB_QM |
Sender Channel |
TO.HUB60 |
TO.WDI32 |
Receiver Channel |
TO.WDI32 |
TO.HUB60 |
Remote Queue |
EDI_OUT_A |
EDI_OUT_B |
Transmission Queue |
XMITQ_A |
XMITQ_B |
Local Queue |
EDI_IN_A |
EDI_IN_B |
Local Queue |
XML_IN_A |
XML_IN_B |
Local Queue |
XML_OUT_A |
XML_OUT_B |
Figure 30 shows the message flow between Computer A and Computer B, indicating the role of the WebSphere MQ objects listed in Table 73.
You could use several different methods to define these objects, depending on your WebSphere MQ platform. For example, you could use WebSphere MQ Explorer on Windows to define the objects.
For WebSphere Data Interchange to receive messages from the WebSphere MQ queue and write EDI messages to a queue, you must configure profiles in the WebSphere Data Interchange Client. Using WebSphere Data Interchange Client, you would create the following profiles, which are described in the sections that follow:
In the sample scenario, WebSphere Data Interchange receives XML messages from the WebSphere MQ queue XML_IN_A and writes the result of translation to WebSphere MQ queue EDI_OUT_A. This is called the XML-to-EDI translation. WebSphere Data Interchange also receives EDI from WebSphere Partner Gateway Enterprise Edition on the WebSphere MQ queue EDI_IN_A and writes the result of translation to XML_OUT_A.
An MQSeries Queue profile contains information about a WebSphere MQ message queue. Table 74 shows the properties to configure for each profile.
MQ property | Description |
---|---|
Queue Profile ID |
The unique identifier to name the profile (logical name) |
Full Queue Name |
The actual name of the WebSphere MQ queue |
Queue Manager Name |
The actual name of the WebSphere MQ queue manager |
Description |
Any string to identify the purpose of the profile |
Maximum Length |
The largest possible message for the queue as configured in WebSphere MQ |
Destructive Reads |
If selected, these cause WebSphere Data Interchange to remove the message from the WebSphere MQ queue when reading. |
Syncpoint Control |
When checked, the reading and writing of queue messages is under syncpoint control. If syncpoint control is in effect, modifications to a message queue do not take place until WebSphere Data Interchange issues a syncpoint. |
Because you are working with the WebSphere MQ queues, you require an MQSeries Queue profile in WebSphere Data Interchange for each queue. In all, you would create four MQSeries Queue profiles, one for each WebSphere MQ queue used in the message flow. From the setup area of WebSphere Data Interchange Client, you would:
Table 75 lists the actual parameters specified in each MQSeries Queue profile you created. The queues represented here are used with XML-to-EDI translation.
Queue property | Value for XML_IN_A | Value for EDI_OU_A |
---|---|---|
Queue Profile ID | XML_IN_A | EDI_OU_A |
Full Queue Name | XML_IN_A | EDI_OUT_A |
Queue Manager Name | WDI32_QM | WDI32_QM |
Destructive Reads |
Checked |
Checked |
Syncpoint Control |
Checked |
Checked |
Queue property | Value for EDI_IN_A | Value for XML_OU_A |
---|---|---|
Queue Profile ID | EDI_IN_A | XML_OU_A |
Full Queue Name | EDI_IN_A | XML_OUT_A |
Queue Manager Name | WDI32_QM | WDI32_QM |
Destructive Reads |
Checked |
Checked |
Syncpoint Control |
Checked |
Checked |
Network profiles define for WebSphere Data Interchange the characteristics of the networks you use for communications with trading partners. For this scenario, you would create and configure a Network Profile that communicates with the WebSphere MQ queues created earlier.
Table 77 shows the properties to configure for the Network profile.
Network property | Description |
---|---|
Network ID |
A unique identifier to name the profile |
Communication Routine |
The name of the program that builds network commands and invokes the network program to process the commands |
Network Program |
The program invoked by the communication routine to process requests |
Network Parameters |
Parameters required by the network program |
For this sample scenario, you create and configure a Network profile that communicates with the WebSphere MQ queues created earlier (see MQSeries(R) Queue profile), as follows:
This network profile is used in the XML-to-EDI scenario. Table 78 lists the actual parameters specified for HUB_IN.
Network property | Value for HUB_IN profile |
---|---|
Network ID | HUB_IN |
Communication Routine | VANIMQ |
Network Program | EDIMQSR |
Network Parameters | SENDMQ=EDI_OU_A RECEIVEMQ=XML_IN_A |
This Network profile is used in the translation of EDI received from WebSphere Partner Gateway Enterprise Edition. A second Network profile is required, because WebSphere Partner Gateway Enterprise Edition places messages on the WebSphere MQ queues that include RFH2 headers. Table 79 lists the properties of HUB_OUT.
Network property | Value for HUB_OUT profile |
---|---|
Network ID | HUB_OUT |
Communication Routine | VANIMQ |
Network Program | EDIRFH2 |
Network Parameters | SENDMQ=XML_OU_A RECEIVEMQ=EDI_IN_A |
Mailbox profiles contain the information that WebSphere Data Interchange needs to identify the individuals and groups in your organization that receive documents to be translated. Table 80 shows the properties to configure for each Mailbox profile.
Mailbox property | Description |
---|---|
Mailbox ID |
A unique identifier to name the profile |
Network ID |
The network ID of the network profile created earlier |
You create mailbox profiles for each of the WebSphere MQ queues to identify the individuals and groups in the organization, as follows:
Table 81 lists the actual parameters in each of the Mailbox profiles.
Mailbox property | Value for XML_IN_A | Value for EDI_OU_A |
---|---|---|
Mailbox ID | XML_IN_A | EDI_OU_A |
Network ID | HUB_IN | HUB_IN |
Receive File | XML_IN_A | EDI_OU_A |
Table 82 lists the properties for each.
Mailbox property | Value for EDI_IN_A | Value for XML_OU_A |
---|---|---|
Mailbox ID | EDI_IN_A | XML_OU_A |
Network ID | HUB_OUT | HUB_OUT |
Receive File | EDI_IN_A | XML_OU_A |
Service profiles allow you to enter a utility command and define all the files that will be used during execution of that command.
For the sample scenario, you take the following steps:
PERFORM TRANSFORM WHERE INFILE(XML_IN_A) SYNTAX(X) OUTTYPE(MQ)OUTFILE(EDI_OU_A)
Table 83 lists the Common Files properties.
Common File property | Value |
---|---|
Tracking File |
..\trk\xml_in.trk |
Exception File |
..\xex\xml_in.xex |
Work File |
..\wrk\xml_in.wrk |
Report File |
..\rpt\xml_in.rpt |
Query File |
..\qry\xml_in.qry |
PERFORM TRANSFORM WHERE INFILE(EDI_IN_A) SYNTAX(E) OUTTYPE(MQ) OUTFILE(XML_OU_A)
Table 84 lists the Common Files properties.
Common File property | Value |
---|---|
Tracking File |
..\trk\edi_in.trk |
Exception File |
..\xex\edi_in.xex |
Work File |
..\wrk\edi_in.wrk |
Report File |
..\rpt\edi_in.rpt |
Query File |
..\qry\edi_in.qry |
After you create the profiles, as described in the previous section, you can import any maps you need to transform your data. You then compile the transformation maps and set a rule for each. You use the WebSphere Data Interchange Client to perform these tasks. See the WebSphere Data Interchange documentation for information.
As mentioned earlier in this chapter, WebSphere Partner Gateway Enterprise Edition can use the WebSphere MQ implementation of the Java Message Service (JMS) for integration with WebSphere Data Interchange.
This section outlines the steps involved in creating a JMS environment on Computer B:
WebSphere MQ classes for Java and WebSphere MQ classes for JMS are built in to WebSphere MQ for Windows, version 5.3.
Use the JMSAdmin tool available in WebSphere MQ to create the JMS objects in JNDI. For information on how to create the default configuration file called JMSAdmin.config, see the Hub Configuration Guide.
To create the JMS objects for this tutorial:
INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory PROVIDER_URL=file:/opt/mqm/java/JNDI
/opt/mqm/java/bin
Before invoking the JMSAdmin tool, you would ensure your CLASSPATH contains the following entries:
/opt/mqm/java/lib/jms.jar /opt/mqm/java/lib/com.ibm.mq.jar /opt/mqm/java/lib/com.ibm.mqjms.jar /opt/mqm/java/lib/jta.jar /opt/mqm/java/lib/connector.jar /opt/mqm/java/lib/jndi.jar /opt/mqm/java/lib/providerutil.jar /opt/mqm/java/lib/fscontext.jar
Note: The above entries, which relate to Linux(R), assume you are using file-based JNDI.
To create the required JMS objects, you use the JMSAdmin tool. For the sample scenario, you would:
DEF CTX(WdiJms)
CHG CTX(WdiJms)
DEF QCF(HUB60_QM_QCF) TRAN(CLIENT) HOST(IP_COMPUTER_B) PORT(9999) CHAN(java.channel) QMANAGER(HUB60_QM)
DEF Q(EDI_IN_B) QMANAGER(HUB60_QM) QUEUE(EDI_IN_B)
DEF Q(EDI_OUT_B) QMANAGER(HUB60_QM) QUEUE(EDI_OUT_B)
END
WebSphere Partner Gateway is the communication layer between disparate community participants and internal processes. When setting up WebSphere Partner Gateway to work with EDI documents, you can configure it to:
The Hub Configuration Guide provides complete information on how to configure WebSphere Partner Gateway Enterprise and Advanced Editions. This section provides you with an example of configuring the WebSphere Partner Gateway Enterprise Edition that is described in the sample scenario. It describes the following steps:
A participant profile identifies companies to the system. You create participants for Partner One and Partner Two in the WebSphere Partner Gateway Enterprise Edition Community Console.
Create a participant for Partner OneCreate a participant profile to represent Computer A and Computer B, which are the two systems that Partner One owns.
To create this participant profile, you take the following steps:
Field name | Value |
---|---|
Company Login Name |
partnerOne |
Participant Display Name |
Partner One |
Participant Type |
Community Manager |
Status |
Enabled |
Vendor Type |
Other |
Web Site |
http://IP_COMPUTER_A where IP_COMPUTER_A is the Internet protocol (IP) address of Computer A |
Business ID Type |
Freeform |
Business ID Identifier |
123456789 |
IP Address Gateway Type |
Production |
IP Address |
IP_COMPUTER_A where IP_COMPUTER_A is the Internet protocol (IP) address of Computer A |
Note: To create the Business ID Type and Business ID Identifier, you first click the New button below Business ID. The Business ID must be unique. Similarly, to create details relating to the IP Address, you click the New button below the IP Address header.
WebSphere Partner Gateway Enterprise Edition uses the Business ID Identifier (defined in Table 85) to identify the sender or receiver of a document. When an ANSI X12 EDI transaction is received, the Interchange Sender and Receiver data is read to determine the source and target of the transaction.
Next, create a community participant to represent Partner Two. To create the participant, you take the following steps:
Field name | Value |
---|---|
Company Login Name |
partnerTwo |
Participant Display Name |
Partner Two |
Participant Type |
Community Participant |
Status |
Enabled |
Vendor Type |
Other |
Web Site |
http://IP_COMPUTER_C where IP_COMPUTER_C is the Internet protocol (IP) address of Computer C |
Business ID Type |
Freeform |
Business ID Identifier |
987654321 |
IP Address Gateway Type |
Production |
IP Address |
IP_COMPUTER_C where IP_COMPUTER_C is the Internet protocol (IP) address of Computer C |
You define the B2B capabilities for each participant in WebSphere Partner Gateway Enterprise Edition through the Community Console. After you define the B2B capabilities for participants, you can define a valid Document Flow Definition used to support specific business collaboration types between the participants.
Set the B2B capabilities for Partner OneTo define the B2B Capabilities for Partner One, take the following steps:
B2B Capabilities are set to active by clicking on the Role is not active icon. For the purposes of this sample, you will configure only the B2B Capabilities required to implement the scenario.
To set the source and target packaging for Partner One to None, you would:
To define the B2B capabilities for Partner Two, take the following steps:
To set the source and target packaging for Partner Two to AS, take the following steps:
Next, you update the AS definition for Partner Two, to ensure that Message Disposition Notifications (MDNs) for AS2 sent to Partner Two are returned to the correct address, as follows:
This address is used to receive MDNs for AS1.
http://IP_COMPUTER_B:PORT/bcgreceiver/submit
A gateway in WebSphere Partner Gateway defines a network point that acts as the entrance to another network. The gateway contains the information that tells WebSphere Partner Gateway how to deliver documents to the Enterprise Application Integration (EAI) layer.
Create a Gateway for Partner OnePartner Two sends EDI documents to Partner One using AS2. Partner One's gateway is used to send the EDI documents received via AS2 to a JMS queue and ultimately to WebSphere Data Interchange for translation.
To create a new gateway for Partner One, take the following steps:
Field name | Value |
---|---|
Gateway Name |
JMStoPartnerOne |
Transport |
JMS |
Target URI |
file:///opt/mqm/java/JNDI/WdiJms |
JMS Factory Name |
HUB60_QM_QCF |
JMS Message Class |
TextMessage |
JMS Message Type |
TextMessage |
JMS Queue Name |
EDI_OUT_B |
JMS JNDI Factory Name |
com.sun.jndi.fscontext.RefFSContextFactory |
Make JMStoPartnerOne the default gateway for Partner One, as follows:
Partner One sends EDI documents to WebSphere Partner Gateway Enterprise Edition over a JMS queue. Partner Two's gateway is used to send the received EDI documents to Partner Two via AS2.
To create a new gateway for Partner Two, take the following steps:
Gateway Name |
AS2toPartnerTwo |
Transport |
HTTP/1.1 |
Target URI |
http://IP_COMPUTER_C/input/AS2 |
User Name |
partnerOne |
Password |
partnerOne |
For an example of setting these properties in WebSphere Partner Gateway - Express, see Configuring WebSphere Partner Gateway - Express.
Notice that AS2toPartnerTwo is displayed as Online with a Status of Enabled.
Make AS2toPartnerTwo the default gateway for PartnerTwo, with the following steps:
A document flow definition is a collection of "meta-information" that defines the document processing capabilities of the participant. For the system to process a business document, two or more document flow definitions must be linked to create an interaction.
To create an interaction between Partner One and Partner Two, take the following steps:
Participant connections are the mechanism that enables the system to process and route documents between the Community Manager and its various participants. Connections contain the information necessary for the proper exchange of each document flow.
To create a participant connection between Partner One and Partner Two, take the following steps:
Document flow type | Source | Target |
---|---|---|
Package |
None (N/A) |
AS (N/A) |
Protocol |
EDI-X12 (ALL) |
EDI-X12 (ALL) |
Document Flow |
ISA (ALL) |
ISA (ALL) |
To create a participant connection where Partner Two is the source and Partner One is the target, take the following steps:
Document flow type | Source | Target |
---|---|---|
Package |
AS (N/A) |
None (N/A) |
Protocol |
EDI-X12 (ALL) |
EDI-X12 (ALL) |
Document Flow |
ISA (ALL) |
ISA (ALL) |
The Target List screen provides location information that enables WebSphere Partner Gateway's Document Manager to fetch documents from the appropriate system location based on the transport type of the incoming document. You can create separate target configurations based on transport type. The Document Manager can then poll the document repository locations of multiple Web, FTP, and POP mail servers--including internal directories and JMS queues--for incoming documents.
After the Document Manager retrieves a document from the location based on a pre-defined target, the routing infrastructure can process the document based on channel configuration.
To receive an EDI transaction from WebSphere Data Interchange, create a new JMS target by doing the following:
Target property | Value |
---|---|
Target Name |
WdiJmsListener |
Transport |
JMS |
Gateway Type |
Production |
JMS Provider URL |
file:///opt/mqm/java/JNDI/WdiJms |
JMS Queue Name |
EDI_IN_B |
JMS Factory Name |
HUB60_QM_QCF |
JNDI Factory Name |
com.sun.jndi.fscontext.RefFSContextFactory |
A second target is required for the receipt of EDI from Partner Two via AS2. Take the following steps to create this target: