Configuring your environment for message exchange

To enable communication between WebSphere Data Interchange and WebSphere Partner Gateway, you perform the following setup and configuration tasks:

Configuring WebSphere MQ communication

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.

Note: Refer to the WebSphere MQ documentation for additional details on defining queue managers.

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.

Note: Your WebSphere Data Interchange queue manager should be configured to trigger the WebSphere Data Interchange Server using the WDI Adapter application.

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.

Table 73. WebSphere MQ objects to create
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.

Figure 30. Message flow between Computer A and Computer B
This figure shows the queues set up for documents coming into and out of WebSphere Data Interchange as well as the queues set up for document coming into and out of WebSphere Partner Gateway.

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.

Configuring WebSphere Data Interchange

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.

MQSeries(R) Queue profile

An MQSeries Queue profile contains information about a WebSphere MQ message queue. Table 74 shows the properties to configure for each profile.

Table 74. Properties in an MQSeries Queue 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:

  1. Create an MQSeries Queue profile for XML_IN_A and EDI_OU_A.

    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.

    Table 75. MQSeries Queue profile for XML_IN_A and EDI_OU_A
    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

    Note: The Queue Profile ID is restricted to a maximum of eight characters. Therefore, the profile ID for the EDI_OUT_A queue must be named EDI_OU_A. All references to the WebSphere MQ queue EDI_OUT_A in WebSphere Data Interchange use EDI_OU_A.
  2. Create an MQSeries Queue profile for EDI_IN_A and XML_OU_A. Table 76 defines the properties of each queue used in EDI-to-XML translation.
    Table 76. MQSeries Queue profile for EDI_IN_A and XML_OU_A
    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 profile

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.

Table 77. Properties in a 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:

  1. Create a new Network profile called HUB_IN.

    This network profile is used in the XML-to-EDI scenario. Table 78 lists the actual parameters specified for HUB_IN.

    Table 78. Network profile 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
  2. Create a second Network profile called HUB_OUT.

    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.

    Table 79. Network profile for 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 profile

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.

Table 80. Properties in a 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:

  1. Create a Mailbox profile for each WebSphere MQ queue used.

    Table 81 lists the actual parameters in each of the Mailbox profiles.

    Table 81. Mailbox profiles for XML_IN_A and EDI_OU_A
    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
  2. Create a second pair of mailboxes.

    Table 82 lists the properties for each.

    Table 82. Mailbox profiles for EDI_IN_A and XML_OU_A
    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 profile

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:

  1. Create a new Service Profile for XML_IN_A. You define the properties under the General tab, as follows:

    Table 83 lists the Common Files properties.

    Table 83. Common Files for XML_IN_A
    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

  2. Enter the following in the Output Files tab:
  3. Create a second Service Profile for EDI_IN_A. You define the properties under the General tab, as follows:

    Table 84 lists the Common Files properties.

    Table 84. Common files for EDI_IN_A
    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

  4. Enter the following details under the Output Files tab:
    Note: XML_OU_A is used rather than XML_OUT_A because of character length restrictions. This restriction was eliminated with CSD10 of the WebSphere Interchange Server.

Import and compile data transformation maps

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.

Setting up the JMS environment

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.

Note: Alternatively, it is possible to use LDAP or WebSphere Application Server as a JNDI provider.

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.

Configuring JMSAdmin

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:

  1. To use a file-based JNDI provider, you would make sure the JMSAdmin.config file contains the lines shown below:
    INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
    PROVIDER_URL=file:/opt/mqm/java/JNDI
  2. If the JNDI directory does not already exist, create the JNDI directory under the following directory:
    /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.

Creating the JMS objects

To create the required JMS objects, you use the JMSAdmin tool. For the sample scenario, you would:

  1. Define a new context:
    DEF CTX(WdiJms)
  2. Change to the new context:
    CHG CTX(WdiJms)
  3. Define a queue connection factory:
    DEF QCF(HUB60_QM_QCF) TRAN(CLIENT) HOST(IP_COMPUTER_B)
    PORT(9999) CHAN(java.channel) QMANAGER(HUB60_QM)
  4. Define the EDI_IN_B queue:
    DEF Q(EDI_IN_B) QMANAGER(HUB60_QM) QUEUE(EDI_IN_B)
  5. Define the EDI_OUT_B queue:
    DEF Q(EDI_OUT_B) QMANAGER(HUB60_QM) QUEUE(EDI_OUT_B)
  6. End the JMSAdmin session
    END

Configuring WebSphere Partner Gateway Enterprise Edition

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:

  1. Creating participants
  2. Setting the B2B capabilities
  3. Creating gateways
  4. Defining interactions
  5. Creating participant connections
  6. Creating targets

Note: For information on how to configure WebSphere Partner Gateway - Express, see Configuring WebSphere Partner Gateway - Express.

Creating participants

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 One

Create 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:

  1. Open the WebSphere Partner Gateway Community Console.
  2. Log in as hubadmin.
  3. Verify that Profiles is already selected from the Account Admin menu.
  4. Click Create and enter the details as listed in Table 85 below.
    Table 85. Participant properties for Partner One
    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.

  5. Click Save.

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.

Important: Make a note of the Administrator's Password for Partner One, as you will need it later. When you log on to the Community Console as Partner One, you will be asked to enter the password and then to change it.
Create a participant for Partner Two

Next, create a community participant to represent Partner Two. To create the participant, you take the following steps:

  1. Click Account Admin on the main menu and Profiles on the horizontal navigation bar.
  2. Click Create.
  3. Enter the values listed inTable 86 below.
    Table 86. Participant properties for Partner Two
    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

  4. Click Save.
Important: Make a note of the Administrator's Password for Partner Two, as you will need it later. When you logged on to the Community Console as Partner Two, you were asked to enter the password and then to change it.

Setting the B2B capabilities

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 One

To define the B2B Capabilities for Partner One, take the following steps:

  1. Click Account Admin on the main menu and Profiles on the horizontal navigation bar.
  2. Click Search to reveal a list of all participants defined in the system.
  3. Click the View details icon next to Partner One, and then click B2B Capabilities.

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:

  1. Click the Role is not active icon underneath Set Source for Package: None to enable it. Repeat this step for Set Target.
  2. Click the Expand icon to drill down.
  3. Click the Role is not active icon for Protocol: EDI-X12 (ALL) for both source and target.
  4. Click the Expand icon.
  5. Click the Role is not active icon for Document Flow: ISA (ALL) for both source and target.
Set the B2B capabilities for Partner Two

To define the B2B capabilities for Partner Two, take the following steps:

  1. Click Account Admin on the main menu and Profiles on the horizontal navigation bar.
  2. Click Search to reveal a list of all participants defined in the system.
  3. Click the View details icon next to Partner Two, and then click B2B Capabilities.

To set the source and target packaging for Partner Two to AS, take the following steps:

  1. Click the Role is not active icon underneath Set Source for Package: AS to enable it. Repeat this step for Set Target.
  2. Click the Expand icon to drill down.
  3. Click the Role is not active icon for Protocol: EDI-X12 (ALL) for both source and target.
  4. Click the Expand icon.
  5. Click the Role is not active icon for Document Flow: ISA (ALL) for both source and target.

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:

  1. Click the Edit icon.
  2. Enter an AS MDN E-mail address.

    This address is used to receive MDNs for AS1.

  3. Enter an AS MDN HTTP URL:
    http://IP_COMPUTER_B:PORT/bcgreceiver/submit
    Note: The URL defined for AS2 uses the same parameters that will be defined for the AS2 Target later in this chapter.

Creating gateways

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 One

Partner 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:

  1. Click Account Admin from the main menu and Profiles from the horizontal navigation bar.
  2. Click Search.
  3. Select Partner One by clicking the View details icon, and then select Gateways.
  4. Click Create to create a new gateway for Partner One.
  5. Enter the values for this new gateway are shown in Table 87.
    Table 87. Properties for Partner One gateway
    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

  6. Click Save.

Make JMStoPartnerOne the default gateway for Partner One, as follows:

  1. Click View Default Gateways.
  2. From the Production list, select JMS2toPartnerOne.
  3. Click Save.
Create a Gateway for Partner Two

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:

  1. Click Account Admin from the main menu and Profiles from the horizontal navigation bar.
  2. Click Search.
  3. Select Partner Two by clicking the View details icon and then select Gateways.
  4. Click Create to create a new gateway for Partner Two.
  5. Enter the values for this gateway as shown in Table 88.
    Table 88. Properties for Partner Two gateway

    Gateway Name

    AS2toPartnerTwo

    Transport

    HTTP/1.1

    Target URI

    http://IP_COMPUTER_C/input/AS2

    User Name

    partnerOne

    Password

    partnerOne

  6. Click Save.
    Note: The User Name and Password as entered above refer to the Inbound Participant Mapping Method for HTTP as defined in WebSphere Partner Gateway - Express.

    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:

  1. Click View Default Gateways.
  2. From the Production list, select AS2toPartnerTwo.
  3. Click Save.

Defining interactions

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:

  1. Click Hub Admin from the main menu and Document Flow Definition from the horizontal navigation bar.
  2. Click Manage Interactions and then Create Interaction.
  3. From the Source column, select:
    1. Package: None
    2. Protocol: EDI-X12 (ALL)
    3. Document Flow: ISA (ALL)
  4. From the Target column, select:
    1. Package: AS
    2. Protocol: EDI-X12 (ALL)
    3. Document Flow: ISA (ALL)
  5. Set the Action as Pass Through.
  6. Click Save.
  7. Click Create Interaction again.
  8. From the Source column, select:
    1. Package: AS
    2. Protocol: EDI-X12 (ALL)
    3. Document Flow: ISA (ALL)
  9. From the Target column select:
    1. Package: None
    2. Protocol: EDI-X12 (ALL)
    3. Document Flow: ISA (ALL)
  10. Set the Action as Pass Through.
  11. Click Save.

Creating participant connections

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:

  1. Click Account Admin from the main menu and Participant Connections from the horizontal navigation bar.
  2. From the Source list, select Partner One.
  3. From the Target list, select Partner Two.
  4. Click Search.
  5. Activate the Participant Connection that is displayed below by clicking on the Activate button. This should display the B2B Capabilities shown in Table 89.
    Table 89. Activate Partner One-to-Partner Two participant connection
    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:

  1. Click Account Admin from the main menu and Participant Connections from the horizontal navigation bar.
  2. From the Source list, select Partner Two.
  3. From the Target list, select Partner One.
  4. Click Search.
  5. Activate the connection with the details shown in Table 90.
    Table 90. Activate Partner Two-to-Partner One participant connection
    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)

Creating targets

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:

  1. Click Hub Admin from the top-level menu.
  2. Click Targets from the second-level menu, and then click Create.
  3. Assign the properties shown in Table 91.
    Table 91. Target properties for receipt over JMS
    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:

  1. Click Hub Admin from the top level menu.
  2. Click Targets from the second level menu, and then click Create.
  3. Assign the properties from Table 92 below:
    Table 92. Target properties for receipt over AS2

    Target Name

    HubAS2Listener

    Transport

    HTTP/S

    Gateway Type

    Production

    URI

    /bcgreceiver/submit

    Note: The URI for receipt of HTTP/S must always begin with /bcgreceiver
  4. Click Save.

Copyright IBM Corp. 2003, 2005