Information needed to set up the hub

You need some information about the types of exchanges in which the Community Manager will participate in order to set up the hub. For example, you need the following information:

When this information is determined, you are ready to begin setting up the hub.

After you define the hub, you can define your participants, using information (such as IP address and DUNS numbers) that is supplied to you by the participants. As noted earlier, you also define the Community Manager as a special type of participant of the hub.

Overview of transports

Documents can be sent from participants to the WebSphere Partner Gateway (the hub) over a variety of transports. A participant can send documents over public networks using HTTP, HTTPS, JMS, FTP, FTPS, FTP Scripting, SMTP, or a file directory. A participant can send documents over a Value Added Network (VAN), a private network, using the FTP Scripting Transport. You can create your own transport, as well.

Note: When the file-directory transport is used between a participant and the hub, the administrator should take care of all the security-related issues.

Similarly, the hub sends documents to back-end applications over a variety of transports. The most commonly used transports between the hub and back-end applications are HTTP, HTTPS, JMS, and file-directory.

Figure 2 shows the various transports that can be used.

Figure 2. Transports supported by WebSphere Partner Gateway
This figure shows the transports (listed in the preceding paragraphs) that can be used between the participant and the hub and between the hub and the Community Manager back-end system

The type of transport used to send and receive documents affects the setup of targets and gateways. A target is an entry point into the hub--the place where documents sent by participants or back-end applications are received at the hub. A gateway is an entry point into the participant's computer or the back-end system--the place where the hub sends documents. To prepare to use the FTP, FTPS, FTP Scripting, JMS, and file-directory transports, you have to do some setup work, as described in Preparing to configure the hub.

Overview of document flow definitions

When you set up the interchange of documents between the participants and the Community Manager, you specify several things about the document:

The packaging of the document, the protocol of the document, and the document flow make up the document flow definition. The document flow definition gives information to the hub about how to process the document. For example, suppose you use the system-supplied document flow definition of:

The hub extracts the AS header information (and uses it to help determine the source and destination of the document). It knows where to find, within the document, certain information, based on its placement in the document. The three parts of the document flow definition have attributes assigned to them. You can modify or add to the system-supplied attributes.

Packaging

The packaging provides information that pertains to the transmission of the document. As mentioned in the previous section, if the packaging is AS, the hub uses information in the AS header to determine the source and destination for the document. If a participant is sending a RosettaNet PIP to the Community Manager, the PIP is packaged as RNIF.

Figure 3 shows you the packaging types that can be set for documents exchanged between the hub and a community participant and between the hub and a back-end application.

Figure 3. Document packaging types
This figure shows that the RNIF, AS, and None packages are used between the participant and the hub and that the Backend Integration and None packages are used between the hub and the Community Manager back-end system

Packages are associated with specific protocols. For example, a participant must specify RNIF packaging when sending a RosettaNet document to the hub.

Backend Integration

As shown in Figure 3, Backend Integration is available only between the hub and the back-end application. When you specify Backend Integration packaging, documents sent by the hub to the back-end system have special header information added. Similarly, when a back-end application sends documents with a packaging of Backend Integration to the hub, it must add header information. The Backend Integration package, and the requirements for the header information, are described in the Enterprise Integration Guide.

AS

The AS package is available only between participants and the hub. The AS package can be used for documents that adhere to the AS1 or AS2 standards. AS1 is a standard used for securely transmitting documents over SMTP, and AS2 is a standard used for securely transmitting documents over HTTP or HTTPS. Documents sent by a participant with a packaging of AS have either AS1 or AS2 header information. Documents sent to a participant that expects AS1 or AS2 headers must be packaged (at the hub) as AS.

None

The None package can be used to send and receive documents between the hub and participants and between the hub and a back-end application. No header information is added (or expected) when a document is packaged as None.

RNIF

The RNIF package is provided on the installation medium. You upload the RNIF package (along with any PIPs you want exchanged), as described in RosettaNet documents. The RNIF package is used to send RosettaNet documents from the participant to the hub or from the hub to the participant.

N/A

Some document flows either end in WebSphere Partner Gateway or originate internally from WebSphere Partner Gateway. For document flows ending in WebSphere Partner Gateway, no packaging is required. Document flows originating internally from WebSphere Partner Gateway do not have source packaging. Therefore, for such flows, the packaging is specified as N/A.

For most one-way transmissions between the participant and the Community Manager (or vice versa), WebSphere Partner Gateway receives a document from a participant and sends it to the Community Manager. In WebSphere Partner Gateway, when creating the participant connection, you specify the packaging in which WebSphere Partner Gateway will receive the document and the packaging WebSphere Partner Gateway will use to send the document. In Figure 4, a document packaged as AS is flowing from a participant to the Community Manager back-end. The document is delivered to the Community Manager gateway with no transport headers. In Figure 4, one action is associated with the exchange of documents.

Figure 4. Typical one-way connection
This figure shows how a document flows from a participant through the hub and to the gateway defined for the Community Manager

Certain protocols, however, involve multiple activities (such as de-enveloping and transformation), some of which occur as intermediate parts of the overall exchange. For example, if a participant sends an EDI interchange to the hub, for eventual delivery to the Community Manager, the interchange is de-enveloped and the individual EDI transactions are processed. The original EDI interchange has a package associated with it when it is sent from the participant. However, because the interchange itself is not delivered to the Community Manager (it is de-enveloped within the hub and no additional processing of the interchange occurs), packaging of the interchange does not apply. When you set up the interaction for the de-enveloping step, therefore, you enter a package on the sending side but you specify N/A for the receiving side.

The process for setting up the document flow definitions required for an EDI exchange is described in Configuring EDI document flows.

Protocols

The protocols that are provided with the system are:

When you upload RNIF packages, you also get the associated protocols (RosettaNet and RNSC). RosettaNet (which is the protocol used between the participant and the hub) is associated with the RNIF package. RNSC (which is the protocol used between the hub and the Community Manager back-end application) is associated with the Backend Integration package.

For EDI transactions or XML or ROD documents that will be transformed, you import a transformation map from the Data Interchange Services client. In the Data Interchange Services client, dictionaries are defined for the protocol associated with this transformation. A dictionary contains information about all of the EDI document definitions, segments, composite data elements, and data elements that make up the EDI Standard. For detailed information about a particular EDI Standard, consult the appropriate EDI Standards manuals. For information about the Data Interchange Services client, refer to the Mapping Guide or to the online help provided with the Data Interchange Services client.

Note: The sender and receiver IDs must be part of the ROD document definition associated with the transformation map. The information necessary to determine the document type and dictionary values must also be present in the document definition. Make sure that the Data Interchange Services client mapping specialist is aware of these requirements when creating the transformation map.

You can create custom protocols to define exactly how you want a document to be structured. For XML documents, you can define an XML format, as described in Custom XML documents.

Document Flow

The document itself can be in a variety of formats. The system-supplied document flows and their associated protocols are:

The following list describes other types of documents and the source of their definition:

You can also create your own document flows, as described in Custom XML documents.

Copyright IBM Corp. 2003, 2005