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.
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.
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.
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.
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.
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.
Packages are associated with specific protocols. For example, a participant must specify RNIF packaging when sending a RosettaNet document to the hub.
Backend IntegrationAs 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.
ASThe 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.
NoneThe 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.
RNIFThe 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/ASome 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.
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.
The protocols that are provided with the system are:
The Binary protocol can be used with AS, None, and Backend Integration packages. A binary document contains no data about the source or destination of the document.
These EDI protocols can be used with the AS or None packages. As described in N/A, if the EDI transaction or interchange originates from the hub or ends at the hub, you specify N/A for the package. X12 and EDIFACT are EDI standards used for the exchange of data. EDI-Consent refers to content types other than X12 or EDIFACT.
Web service requests can be used only with the None package.
cXML documents can be used only with the None package.
XMLEvent is a special protocol used to provide event notification for documents flowing to and from a back-end application. It can be used only with the Backend Integration package. This protocol is described in the Enterprise Integration Guide.
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.
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.
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.