bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

Administering B2B

Configuration Requirements

This section presents selected WebLogic Integration B2B integration configurations and provides examples that summarize the configuration requirements for typical participants. It includes the following topics:

- Configuration Overview

- XOCP Applications (Deprecated)

- RosettaNet Applications

- cXML Applications (Deprecated)

- ebXML Applications

- Browser Clients (Deprecated)

- File-Sharing Clients (Deprecated)

The information in this section applies to configurations for collaborative workflows used to manage conversations between trading partners. If you are using the Messaging API or the cXML API to write Java messaging applications, see Programming Messaging Applications for B2B Integration. If you are using logic plug-ins to add functionality to a collaboration, see Programming Logic Plug-Ins for B2B Integration.

Note: The XOCP and cXML protocols, and B2B browser and file-sharing clients, are deprecated as of this release of WebLogic Integration. For information about the features that are replacing XOCP, cXML, and the B2B browser and file-sharing clients, see the BEA WebLogic Integration Release Notes.

Configuration Overview

The following sections describe how to set up some of the basic B2B integration applications supported by WebLogic Integration. These basic configurations illustrate the concepts required for more complex scenarios. In addition to setting the B2B engine properties (for example, B2B engine name, description, and preferences), properties for the following entities must be configured:

- Trading partners
  Basic identifying information, party identifiers, and delivery channel information must be defined for each participant.

- Conversation definitions
  Each conversation definition must include a name, a version, an assigned business protocol, and two or more roles, each associated with a workflow template.

- Collaboration agreements
  A collaboration agreement specifies a conversation definition and the parties to the agreement. For each party, a trading partner party identifier, delivery channel, and role must be defined.

The following figure provides an overview of the entities that must be configured. It shows how information is organized in the WebLogic Integration B2B Console. For a summary of how information is stored in the repository, see Working with the Repository. The detailed information required to set specific properties is provided in the B2B Console online help (see Getting Help).

Figure 1-1 B2B Integration Configuration Overview

As shown in the preceding figure, each delivery channel is associated with a document exchange, which defines its business protocol binding. The parameters defined in the document exchange vary, depending on the selected protocol. The following figure summarizes the business protocols supported by WebLogic Integration.

Figure 1-2 Business Protocol Bindings Defined in the Document Exchange

The following sections describe the configuration requirements for participants in several sample applications. Although configuration is typically performed through the B2B Console, these examples do not demonstrate how configuration is done. Keep in mind that the trading partners, conversation definitions, collaboration agreements, and workflows created on one system can be exported and then imported to another system, as described in Importing and Exporting B2B Integration Components.

A Note About Trading Partner Encoding

Like all XML documents, the messages exchanged between trading partners can potentially be encoded using any valid character set. By default, messages are encoded in UTF-8. To support alternate encodings, the configuration for a trading partner includes the property, encoding, which determines the how the B2B engine encodes messages sent to that trading partner. (See the trading partner general properties shown in Figure 1-1.)

The specification of encoding only has significance in the XOCP protocol. The B2B engine uses UTF-8 to encode all cXML, RosettaNet, and ebXML messages, regardless of how the encoding property is set.

As you will learn in the following section, XOCP Applications (Deprecated), messages in the XOCP protocol are always routed though a trading partner delivery channel that is configured as a hub, as shown in the following figure.

Figure 1-3 Message Delivery

Suppose the following encoding settings applied to the trading partners shown in the preceding figure:

- TP1, encoding is not set (the default of UTF-8 is used)

- TP2, encoding=UTF-16

- TP3, encoding=Shift_JIS

Based on the these settings, encoding of a message from TP1 destined for TP3 would be handled as follows:

1. TP1 sends message to TP2. Based on the encoding set for TP2, the message is encoded in UTF-16.

2. TP2 receives the message. Because the delivery channel on TP2 is a hub delivery channel, message processing only involves the message header. The payload remains unchanged.

3. TP2 sends the message to TP3. The header is encoded in conformity with the encoding setting for TP3. The payload remains unchanged as noted.

The message encoding for this scenario is summarized in the following figure.

Figure 1-4 Message Encoding

In order to achieve the desired results when using the encoding property, it is important to keep in mind how the message will be handled when you configure the trading partners and their associated delivery channels.

If the intention is to have the payload information encoded in Shift_JIS for TP3, then the encoding for TP2 should be set to Shift_JIS.

The following section provides additional information about how trading partner definitions, conversation definitions, and collaboration agreements are configured to route messages using the XOCP protocol. If required, you can configure dummy trading partners and collaboration agreements as needed to ensure trading partners receive messages encoded appropriately.

For a list of valid encoding names and aliases, visit the following URL: http://www.iana.org/assignments/character-sets

XOCP Applications (Deprecated)

The following sections provide background information about the configuration of XOCP delivery channels and examples that show how to configure the B2B engine to use XOCP in peer-to-peer and mediated messaging applications:

- XOCP Hub and Spoke Delivery Channels

- XOCP Peer-to-Peer Messaging

- XOCP Mediated Messaging

XOCP Hub and Spoke Delivery Channels

A delivery channel in the XOCP protocol must be configured as one of the following:

- A hub (routing proxy) delivery channel

- A spoke delivery channel

A hub delivery channel is unique in that it acts as a proxy for either role in a conversation definition. The role assumed by the hub delivery channel depends on the configuration of the collaboration agreements for the conversation definition. For example, if the hub delivery channel for a trading partner is assigned to the role of supplier in one collaboration agreement, and to the role of buyer in another collaboration agreement for the same conversation definition, messages are handled as follows:

- The hub delivery channel receives a message sent to the supplier role. All collaboration agreements for the conversation definition in which this hub delivery channel is assigned the buyer role are identified. The message is forwarded to the trading partner delivery channel assigned to the supplier role in each of these collaboration agreements.

- The hub delivery channel receives a message sent to the buyer role. All collaboration agreements for the conversation definition in which this hub delivery channel is assigned the supplier role are identified. The message is forwarded to the trading partner delivery channel assigned to the buyer role in each of these collaboration agreements.

In other words, if multiple trading partners associated with the same role in a conversation definition enter into a collaboration agreement with a hub delivery channel, that delivery channel can be used to broadcast messages to those trading partners. If it is necessary to limit the broadcast to a subset of trading partners, XPath filter expressions can be used, as described in XPath Expressions in Routing and Filtering.

Although XOCP applications always require a hub-and-spoke configuration for their delivery channels and collaboration agreements, trading partners using the XOCP protocol can participate in either a peer-to-peer or mediated exchange of messages:

- Peer-to-peer message exchange
  Each participating trading partner has a role in the collaboration; messages are exchanged between trading partner peers. To accomplish this, one of the trading partner peers must configure two delivery channels: one as a hub delivery channel; the other, as a spoke delivery channel. Please note that we are simulating the peer-to-peer model here; the XOCP point-to-point protocol is not available in the current version of the product.

- Mediated message exchange
  A trading partner acting as a mediator does not participate directly in any role; instead, it routes messages to the trading partner spokes. The mediator configures a hub delivery channel and each trading partner spoke defines a spoke delivery channel. On the mediator, a collaboration agreement is defined between the trading partner hub delivery channel and each trading partner spoke delivery channel. The collaboration agreement assigns the hub and spoke delivery channels to roles as required for proper routing of messages.

Detailed examples of these two basic XOCP message exchange methods are presented in the following sections. Keep in mind that while these examples themselves show simple scenarios, the principles they illustrate can be used to create more complex hybrid deployments.

XOCP Peer-to-Peer Messaging

Suppose two trading partners, ABC International, a computer manufacturer, and XYZ Systems, a chip supplier, plan to use WebLogic Integration to participate in Query Price and Availability (QPA) transactions. ABC International is the buyer and the initiator of each transaction, and the XOCP protocol is used to exchange messages. Both trading partners have WebLogic Integration installed.

The following sections provide examples of how to:

- Configure the trading partners and their associated delivery channels

- Configure a conversation definition to implement the required roles

- Associate the required trading partner delivery channels with the appropriate roles in the collaboration agreements

It is assumed that the required private and collaborative (public) workflows have been created. The collaborative workflows in this example are named QPA_Public_Supplier and QPA_Public_Buyer. For information about using the Studio (with the extended functionality provided by the B2B integration plug-in) to create collaborative workflows, see Creating Workflows for B2B Integration.

Caution: This example demonstrates a single trading partner configured with two delivery channels: one hub, one spoke. Please note that there is currently a limitation with this configuration. Do not set up one trading partner with two delivery channels. Instead set up two trading partners, each with its own delivery channel. Configure a hub delivery channel for one trading partner, and a spoke delivery channel for the other.

Trading Partners

Trading partner definitions for both ABC International and XYZ Systems must be provided.

Note: For simplicity, SSL or signature certificates are not used in the examples presented in this section. For information about security configuration, see Implementing Security with B2B Integration.

The information that must be defined for the ABC International trading partner in the ABC WebLogic Integration configuration is summarized in the following figure.

Figure 1-5 ABC International Trading Partner Definition in the ABC Configuration

Note that the trading partner type (listed in the General box) is Local and the configuration includes hub and spoke delivery channels (XOCP-hub-dc and XOCP-spoke-dc), document exchanges (XOCP-hub-de and XOCP-spoke-de), and transports (XOCP-hub-transport and XOCP-spoke-transport). Each transport is associated with a URI that serves as the delivery channel endpoint (http://abc.com/xocp-hub-transport and http://abc.com/xocp-spoke-transport).

Note: As noted in the introduction to this example (see XOCP Peer-to-Peer Messaging), WebLogic Integration currently has a limitation that requires you to configure two trading partners. For example, configure one trading partner named ABC International-Spoke and the other named ABC International. The ABC International definition would include the XOCP-hub-dc, XOCP-hub-de, and XOCP-hub-transport definitions, while the ABC International-Spoke definition would include the XOCP-spoke-dc, XOCP-spoke-de, and XOCP-spoke-transport definitions.

The information that must be defined for the ABC International trading partner in the XYZ WebLogic Integration configuration is summarized in the following figure.

Figure 1-6 ABC International Trading Partner Definition in the XYZ Configuration

In this case the trading partner type (listed in the General box) is Remote and the configuration includes only a hub delivery channel (XOCP-hub-dc), document exchange (XOCP-hub-de), and transport (XOCP-hub-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://abc.com/xocp-hub-transport).

The information that must be defined for the XYZ Systems trading partner in the ABC WebLogic Integration configuration is summarized in the following figure.

Figure 1-7 XYZ Systems Trading Partner Definition in the ABC International Configuration

In this case the trading partner type (listed in the General box) is Remote and the configuration includes only a spoke delivery channel (XOCP-spoke-dc), document exchange (XOCP-spoke-de), and transport (XOCP-spoke-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://xyz.com/xocp-spoke-transport).

The information that must be defined for the XYZ Systems trading partner in the XYZ WebLogic Integration configuration is exactly the same as the information shown in the previous figure, with one exception: the trading partner type (listed in the General box) must be set to Local in the XYZ WebLogic Integration configuration.

Conversation Definitions

The required settings for the Query Price and Availability (QPA) conversation definition in the ABC WebLogic Integration configuration are shown in the following figure.

Figure 1-8 Conversation Definition for QPA

The conversation definition in the XYZ WebLogic Integration configuration is the same, with one exception: the value of the BPM organization (listed as WLPI organization) must be changed to reflect an organization defined at XYZ systems (for example, XYZ_Org).

Collaboration Agreements

The collaboration agreement shown in the following figure is required only in the ABC WebLogic Integration configuration. The agreement makes it possible for the hub delivery channel to act as a proxy for the buyer role, as described in XOCP Hub and Spoke Delivery Channels.

Figure 1-9 Collaboration Agreement ABC-ABC

Note: If you have created two trading partners as described in the note following Figure 1-5, the trading partner name for the buyer role in the previous collaboration agreement is changed to ABC International-Spoke.

The collaboration agreement shown in the following figure is required in both the ABC and XYZ WebLogic Integration configurations.

Figure 1-10 Collaboration Agreement ABC-XYZ

How It Works

The following figure shows how WebLogic Integration supports the exchange of Query Price and Availability (QPA) messages by ABC International and XYZ Systems.

Figure 1-11 QPA Collaboration Overview: XOCP Peer-to-Peer

Note 1
The ABC International hub delivery channel (XOCP-hub-dc) receives the message sent to the supplier role. As described in XOCP Hub and Spoke Delivery Channels, all collaboration agreements in which XOCP-hub-dc is assigned the buyer role are identified. In the case shown here, one collaboration agreement, Query-Price ABC-XYZ, meets the criteria. Based on that agreement, the message is delivered to the XYZ Systems delivery channel assigned to the role of supplier (XYZ Systems XOCP-spoke-dc at http://xyz.com/xocp-spoke-transport).

Note 2
The ABC International hub delivery channel (XOCP-hub-dc) receives the message sent to the buyer role. All collaboration agreements in which XOCP-hub-dc is assigned the role of supplier are identified. In the case shown here, one collaboration agreement, Query-Price ABC-ABC, meets the criteria. Based on that agreement, the message is delivered to the XYZ Systems delivery channel assigned to the role of buyer (ABC International XOCP-spoke-dc at http://abc.com/xocp-spoke-transport).

XOCP Mediated Messaging

In this example, ABC International, a computer manufacturer, plans to contract with IntCo, a company that acts as an intermediary for order management transactions. Two chip suppliers, TUV Corporation and XYZ Systems, are among those contracted with IntCo.

IntCo acts as the intermediary in the Query Price and Availability (QPA) transactions between ABC International and the two chip suppliers. IntCo does not directly participate in any role in the conversation, but acts as a mediator in the transactions between ABC International and the suppliers.

ABC International is the buyer and the initiator of each transaction and the XOCP protocol is used to exchange messages. All participants have WebLogic Integration installed.

The following sections provide examples of how to:

- Configure the trading partners and their associated delivery channels

- Configure a conversation definition to implement the required roles

- Associate the required trading partner delivery channels with the roles defined in the collaboration agreements

It is assumed that the required private and collaborative (public) workflows have been created. The collaborative workflows in this example are named QPA_Public_Supplier and QPA_Public_Buyer. For information about using the Studio (with the extended functionality provided by the B2B integration plug-in) to create collaborative workflows, see Creating Workflows for B2B Integration.

Trading Partners

Trading partners must be configured as follows:

- ABC International and IntCo must be defined in the ABC WebLogic Integration configuration.

- TUV Corporation and IntCo must be defined in the TUV WebLogic Integration configuration.

- XYZ Systems and IntCo must be defined in the XYZ Systems WebLogic Integration configuration.

- ABC International, TUV Corporation, XYZ Systems, and IntCo must be defined in the IntCo WebLogic Integration configuration.

Note: For simplicity, SSL or signature certificates are not used in the examples in this section. For information about security configuration, see Implementing Security with B2B Integration.

The IntCo trading partner definition required in the ABC, TUV, and XYZ WebLogic Integration configurations is summarized in the following figure.

Figure 1-12 IntCo Trading Partner Definition in the ABC, TUV, and XYZ Configurations

Note that the trading partner type (listed in the General box) is Remote and the configuration includes a hub delivery channel (XOCP-hub-dc), document exchange (XOCP-hub-de), and transport (XOCP-hub-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://intco.com/xocp-hub-transport).

The IntCo trading partner definition in the IntCo WebLogic Integration configuration must match the definition shown in the previous figure, with one exception: the trading partner type (listed in the General box) must be set to Local in the IntCo WebLogic Integration configuration.

Each of the other trading partners must provide a trading partner definition for itself as part of its own WebLogic Integration configuration.

The TUV Corporation trading partner definition required in the TUV Corporation configuration is summarized in the following figure.

Figure 1-13 TUV Corporation Trading Partner Definition in the TUV Configuration

Note that the trading partner type is Local and the configuration includes a spoke delivery channel (XOCP-spoke-dc), document exchange (XOCP-spoke-de), and transport (XOCP-spoke-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://tuv.com/xocp-spoke-transport).

The XYZ Systems trading partner definition required in the XYZ configuration is summarized in the following figure.

Figure 1-14 XYZ Systems Trading Partner Definition in the XYZ Configuration

Note that the trading partner type is Local and the configuration includes a spoke delivery channel (XOCP-spoke-dc), document exchange (XOCP-spoke-de), and transport (XOCP-spoke-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://xyz.com/xocp-spoke-transport).

The ABC International trading partner definition required in the ABC configuration is summarized in the following figure.

Figure 1-15 ABC International Trading Partner Definition in the ABC Configuration

Note that the trading partner type is Local and the configuration includes a spoke delivery channel (XOCP-spoke-dc), document exchange (XOCP-spoke-de), and transport (XOCP-spoke-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://abc.com/xocp-spoke-transport).

The requirements for the XYZ, TUV, and ABC trading partner definitions in the IntCo WebLogic Integration configuration are exactly the same as those listed above, with the exception of trading partner type. Trading partner type is set to Remote for XYZ, TUV, and ABC in the IntCo WebLogic Integration configuration.

Conversation Definitions

The information that must be defined for the Query Price and Availability (QPA) conversation in the IntCo WebLogic Integration configuration is summarized in the following figure.

Figure 1-16 Conversation Definition for QPA

The conversation definition in the ABC, TUV, and XYZ WebLogic Integration configurations is the same, with one exception: the value of the BPM organization (listed as WLPI organization) must be changed to reflect an organization defined at each company.

Collaboration Agreements

The collaboration agreement shown in the following figure is required in the IntCo WebLogic Integration configuration. It enables the IntCo hub delivery channel to act as a proxy for the buyer role, as described in XOCP Hub and Spoke Delivery Channels.

Figure 1-17 Collaboration Agreement IntCo-to-Supplier

Note: IntCo has the option of configuring one agreement (as shown in the preceding figure) or two separate agreements (one with each supplier). If separate agreements are configured, each can be exported for use by the appropriate trading partner.

Corresponding agreements are required in the TUV and XYZ configurations. The collaboration agreement for the TUV configuration is shown in the following figure.

Figure 1-18 Collaboration Agreement for TUV-IntCo

The agreement required in the XYZ configuration is shown in the following figure.

Figure 1-19 Collaboration Agreement XYZ-IntCo

The collaboration agreement shown in the following figure is required in the IntCo WebLogic Integration configuration. It enables the IntCo hub delivery channel to act as a proxy for the supplier role, as described in XOCP Hub and Spoke Delivery Channels.

Figure 1-20 Collaboration Agreement IntCo-to-Buyer

The agreement shown in this figure is also required in the ABC configuration.

How It Works

The following figure shows how IntCo mediates the exchange of Query Price and Availability messages between ABC International and the two suppliers, TUV Corporation and XYZ Systems.

Figure 1-21 QPA Collaboration Mediated by IntCo

The message sent to the supplier role by the Send QPA action of the ABC QPA_Public_Buyer workflow is forwarded to the IntCo hub delivery channel as specified by the collaboration agreement in the ABC configuration.

When the IntCo hub delivery channel (XOCP-hub-dc) receives a message sent to the supplier role, collaboration agreements for the Query-Price conversation definition in which XOCP-hub-dc is assigned to the buyer role are identified. In this case, one collaboration agreement, Query-Price IntCo-to-Supplier, meets the criteria. As specified by that agreement, the message is delivered to the TUV Corporation delivery channel (XOCP-spoke-dc at http://tuv.com/xocp-spoke-transport) and the XYZ Systems delivery channel (XOCP-spoke-dc at http://xyz.com/xocp-spoke-transport).

Messages sent to the buyer role by the Send Reply action of the TUV or XYZ QPA_Public_Supplier workflow are sent to the IntCo hub delivery as specified by the collaboration agreements defined in the respective configurations.

When the IntCo hub delivery channel (XOCP-hub-dc) receives a message sent to the buyer role, collaboration agreements for the Query-Price conversation definition in which XOCP-hub-dc is assigned to the supplier role are identified. In this case, one collaboration agreement, Query-Price IntCo-to-Buyer, meets the criteria. As specified by that agreement, the message is delivered to the ABC International delivery channel (XOCP-spoke-dc at http://abc.com/xocp-spoke-transport).

RosettaNet Applications

In this example, the situation is the same as that described in XOCP Peer-to-Peer Messaging, where two trading partners, ABC International, a computer manufacturer, and XYZ Systems, a chip supplier, use WebLogic Integration to participate in Query Price and Availability (QPA) transactions. In this case, the trading partners use the RosettaNet protocol and employ PIP 3A2 to carry out the public processes.

Trading partners participating in Partner Interface Processes (PIPs) need to implement the public process defined by their role in the PIP, and they need to connect their internal systems, as well as their private processes and workflows, to the public process.

It is assumed that the PIP 3A2 template provided in the WebLogic Integration distribution is customized and connected to private processes that interact with internal systems as required. The collaborative workflows in this example are named PIP3A2_Product_Supplier and PIP3A2_Customer.

For general information about using the Studio (with the extended functionality provided by the B2B integration plug-in) to create collaborative workflows, see Creating Workflows for B2B Integration. For information about customizing the PIP templates provided with WebLogic Integration and configuring RosettaNet security, see Implementing RosettaNet for B2B Integration.

The following sections provide examples of how to:

- Configure the trading partners and their associated delivery channels for RosettaNet 2.0

- Configure a conversation definition to implement the required roles

- Associate the required trading partner delivery channels with the roles defined in the collaboration agreements

Note: Before you can use RosettaNet in a WebLogic Integration domain, you must modify the setup of the domain, as described in Setting Up the Environment in Implementing RosettaNet for B2B Integration.

Trading Partners

Trading partner definitions for both ABC International and XYZ Systems must be provided.

Note: For simplicity, SSL or signature certificates are not used in the examples presented in this section. For information about security configuration, see Implementing Security with B2B Integration.

The information that must be defined for the ABC International trading partner in the ABC configuration is summarized in the following figure.

Figure 1-22 ABC International Trading Partner Definition in the ABC Configuration

Note that the trading partner type (listed in the General box) is Local and the configuration includes a single RosettaNet delivery channel (RosettaNet-dc), document exchange (RosettaNet-de), and transport (RosettaNet-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://abc.com/rosettanet-transport).

The ABC trading partner definition in the XYZ WebLogic Integration configuration must match the definition shown in the previous figure, with one exception: the trading partner type must be set to Remote in the XYZ WebLogic Integration configuration.

The information that must be defined for the XYZ Systems trading partner in the XYZ WebLogic Integration configuration is summarized in the following figure.

Figure 1-23 XYZ Systems Trading Partner Definition in the XYZ Configuration

Note that the trading partner type is Local and the configuration includes a single RosettaNet delivery channel (RosettaNet-dc), document exchange (RosettaNet-de), and transport (RosettaNet-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://xyz.com/rosettanet-transport).

The XYZ trading partner definition in the ABC WebLogic Integration configuration must match the definition shown in the previous figure, with one exception: the trading partner type must be set to Remote in the ABC WebLogic Integration configuration.

Conversation Definitions

The required settings for the Query Price and Availability (QPA) conversation definition in the ABC WebLogic Integration configuration are shown in the following figure.

Figure 1-24 Conversation Definition for PIP 3A2

The conversation definition in the XYZ WebLogic Integration configuration is the same, with one exception: the value of the BPM organization (listed as WLPI organization) must be changed to reflect an organization defined at XYZ systems (for example, XYZ_Org).

Collaboration Agreements

The collaboration agreement shown in the following figure is required in both the ABC and XYZ WebLogic Integration configurations.

Figure 1-25 Collaboration Agreement Query-Price-PIP3A2-ABC-XYZ

How It Works

The following figure shows how WebLogic Integration supports the exchange of Query Price and Availability messages by ABC International and XYZ Systems using RosettaNet 2.0.

Figure 1-26 QPA Collaboration Overview: RosettaNet

cXML Applications (Deprecated)

This section provides a summary of the cXML-specific requirements for configuring trading partners, conversation definitions, and collaboration agreements. For information about the architecture used to implement cXML on WebLogic Integration, cXML security, and using the cXML API, see Implementing cXML for B2B Integration.

The documents exchanged in cXML are divided into three basic types: Request, Response, and Message. Within each basic type are a set of subtypes. For example, a Request might be an OrderRequest, PunchOutSetupRequest, SupplierDataRequest, SupplierListRequest, or GetPendingRequest. Each Request-Response pair constitutes a cXML transaction. For example, PunchOutSetupRequest and PunchOutSetupResponse, together, constitute the PunchOutSetup transaction.

The structure of each document adheres to the cXML DTD for a specific document type and version of cXML.

Examples summarizing the basic structure of the three major document types are shown in the following figure.

Figure 1-27 cXML Document Types

When you define the trading partners and conversation definitions for cXML transactions, the values assigned to certain parameters must match specific element and attribute values that appear in the cXML root and Header elements. In addition, conversation definition names must match the cXML transaction, and the roles assigned must be Buyer and Supplier.

The following table summarizes the requirements.

Table 1-1 cXML Requirements

For a . . . | This parameter . . . | Must match . . .
--- | --- | ---
Trading Partner — Supplier | Business ID Type | The value of the To Credential domain attribute. For example if <To><Credential domain="DUNS">, then the business ID type must be set to DUNS.
Business ID | The content of the To Credential Identity element. For example, if <To><Credential domain="DUNS> <Identity>012345123</Identity>, then the business ID must be set to 012345678.
Trading Partner — Buyer | Business ID Type | The value of the From Credential domain attribute. For example if <From><Credential domain="DUNS">, then the business ID type must be set to DUNS.
Business ID | The content of the To Credential Identity element. For example, if <From><Credential domain="DUNS> <Identity>012345123</Identity>, then the business ID must be set to 012345678.
Conversation Definition | Name | The cXML transaction name. The name of the transaction corresponds to the name of the first child of the Request or Response element. For example, if <Request> <OrderRequest> . . .</OrderRequest>, then the conversation definition name must be set to Order.
Version | The value of the cXML version attribute. For example, if <cXML version="1.1.009". . . .>, then the conversation definition version must be set to 1.1.009.
Roles | The roles defined must be Buyer and Supplier.

ebXML Applications

Suppose two trading partners, ABC International, a computer manufacturer, and XYZ Systems, a chip supplier, plan to use WebLogic Integration to participate in Query Price and Availability (QPA) transactions. ABC International is the buyer and the initiator of each transaction, and it uses the ebXML business protocol to exchange messages. WebLogic Integration is installed at ABC International and WebLogic Integration - Business Connect is installed at XYZ Systems.

About Trading Partner Configurations in WebLogic Integration - Business Connect

A trading partner for which WebLogic Integration - Business Connect is deployed stores trading partner configuration data for itself and its trading partners. Other configuration data (such as conversation definitions and collaboration definitions) necessary to support e-business transactions between the WebLogic Integration and the WebLogic Integration - Business Connect trading partners must be entered on the side of the trading partner for which WebLogic Integration is deployed using the B2B Console. The WebLogic Integration environment supports the consumption of trading partner configuration data files created by a WebLogic Integration trading partner by a WebLogic Integration - Business Connect trading partner, and vice versa.

The following sections provide examples of how to:

- Configure the trading partners and their associated delivery channels—See Trading Partners.

- Configure a conversation definition to implement the required roles—See Conversation Definitions.

- Associate the required trading partner delivery channels with the appropriate roles in the collaboration agreements—See Collaboration Agreements.

- Ensure your WebLogic Integration system is correctly configured to support the exchange of ebXML messages between your system and a trading partner using the lightweight client, WebLogic Integration - Business Connect—See Configuration Considerations When You Deploy WebLogic Integration - Business Connect.

Trading Partners

Trading partners for both ABC International and XYZ Systems must be created:

- ABC International creates its trading partner by entering the required data in the WebLogic Integration B2B Console. (For details, see Configuring Trading Partners in Online Help for the WebLogic Integration B2B Console.)

- XYZ Systems creates its trading partner (company profile) by entering the required data in the WebLogic Integration - Business Connect Administrator. For details, see Company Profiles in Using WebLogic Integration - Business Connect, available at the following URL:

>     http://edocs.bea.com/wlibc/docs70/index.html

Note: WebLogic Integration provides an SSL-based secure platform for conducting ebXML collaborations. Security settings are not specified in the examples presented in this section. For information about configuring security, see "Configuring Security" in Administering ebXML in Implementing ebXML for B2B Integration.

Configuration for WebLogic Integration Trading Partner

The data for the ABC International trading partner configuration is summarized in the following figure.

Figure 1-28 ABC International Trading Partner Definition in the ABC International Repository

Note the following specifications shown in the preceding figure:

- The trading partner type (listed in the General box) is Local.

- The configuration includes a single ebXML delivery channel (ebXML-dc), document exchange (ebXML-de), and transport (ebXML-transport).

- The transport is associated with a URI that serves as the delivery channel endpoint: http://abc.com:7001/ebxml-transport.

Note: Each trading partner involved in a business transaction must have a trading partner definition for the other trading partner.

In this case, ABC International stores, in its WebLogic Integration repository, the ABC International trading partner shown in the previous figure. It also sends the trading partner data to XYZ Systems. (For information about exporting trading partner data from the WebLogic Integration repository, see Importing and Exporting B2B Integration Components.)

Configuration for WebLogic Integration - Business Connect Trading Partner

ABC International imports the trading partner data for the XYZ Systems trading partner into the WebLogic Integration repository.

When a trading partner profile created by WebLogic Integration - Business Connect is imported into a WebLogic Integration repository, the elements of the imported trading partner are mapped to equivalent WebLogic Integration-specific elements.

However, several elements required to define trading partners in the WebLogic Integration repository have no equivalent element in a WebLogic Integration - Business Connect trading partner profile. When there are no values to map from the imported data to WebLogic Integration-specific elements, WebLogic Integration assigns default values to those elements.

The data for the XYZ Systems trading partner configuration, after it is imported into the WebLogic Integration repository, is summarized in the following figure.

Figure 1-29 XYZ Systems Trading Partner Definition in the ABC International Repository

Note the following specifications for the trading partner elements in the preceding figure:

- Values for the following elements are defined in the WebLogic Integration - Business Connect trading partner profile, and are assigned to WebLogic Integration-specific elements in the WebLogic Integration repository:

- All elements listed in the General Box, except for the Type element

- All elements listed in the Party IDs box

- The URI Endpoint element (listed in the Transport box)

For more information about how imported trading partner elements are mapped to WebLogic Integration repository elements, see Administering ebXML in Implementing ebXML for B2B Integration.

- WebLogic Integration specifies the trading partner Type element (listed in the General box) as Remote when it imports the WebLogic Integration - Business Connect trading partner.

- The remainder of the elements required to configure a trading partner in the WebLogic Integration repository have no counterparts in the WebLogic Integration - Business Connect trading partner profile. WebLogic Integration specifies the default values shown in the previous figure for these elements when it imports the trading partner data.

Conversation Definitions

The conversation definition for the Query Price and Availability (QPA) conversation is created in the ABC International WebLogic Integration repository. The elements of the QPA conversation definition are shown in the following figure.

Figure 1-30 Conversation Definition for QPA

Collaboration Agreements

The collaboration agreement for the QPA conversation between ABC International and XYZ Systems is created in the ABC International WebLogic Integration repository. The elements of the collaboration agreement are shown in the following figure.

Figure 1-31 Collaboration Agreement Query-Price-ABC-XYZ

Note that there are always two roles associated with an ebXML-based conversation definition. These roles have predefined names: initiator and participant.

Configuration Considerations When You Deploy WebLogic Integration - Business Connect

This section describes configuration information for a scenario in which a trading partner deploying WebLogic Integration engages in business transactions with a trading partner lightweight client, that is, with WebLogic Integration - Business Connect. It includes the following topics:

- Security and Encryption Configuration in WebLogic Integration - Business Connect

- Using SSL Between WebLogic Integration and WebLogic Integration - Business Connect

Security and Encryption Configuration in WebLogic Integration - Business Connect

To make it possible for WebLogic Integration - Business Connect and WebLogic Integration to interoperate, you must turn off security and encryption options when you configure the trading partner that deploys WebLogic Integration - Business Connect.

To turn off security and encryption options for the WebLogic Integration - Business Connect trading partner, complete the following procedure:

1. Start the WebLogic Integration - Business Connect Administrator tool.

2. Click Partner Profiles to view a list of previously created trading partner profiles.

3. Double click the trading partner profile for which you want to change the security settings. Profile tabs are displayed.

4. Select the Security tab and make sure the check boxes for the following fields are not selected:

   - Sign documents

   - Encrypt documents

For information about configuring your WebLogic Integration - Business Connect client, see Using WebLogic Integration - Business Connect or the online help for your WebLogic Integration - Business Connect Administrator tool at the following site:

>     http://edocs.bea.com/wlibc/docs70/index.html

Using SSL Between WebLogic Integration and WebLogic Integration - Business Connect

In the WebLogic Integration environment, each enterprise populates its repository with specifications for the trading partners, conversation definitions, collaboration agreements, and workflows necessary to engage in e-business interactions with its trading partners. WebLogic Integration provides tools to facilitate the exchange of this configuration data among trading partners. These tools can also be used when one of the trading partners deploys WebLogic Integration - Business Connect. (For details, see "Configuring Your Environment for ebXML Messaging" in Getting Started in Implementing ebXML for B2B Integration.)

However, if you want to use SSL in business transactions between trading partners, when one of them is deploying WebLogic Integration - Business Connect, you must exchange the necessary certificates outside the WebLogic Integration environment. For information about using SSL, see "Configuring Security" in Administering ebXML in Implementing ebXML for B2B Integration.

Browser Clients (Deprecated)

In some cases, a trading partner may require little or no integration with backend systems in order to participate in a conversation. In such cases, the trading partner need not have WebLogic Integration installed. A trading partner that has WebLogic Integration can act as a host, allowing these smaller trading partners to subscribe to, and participate in, an authorized set of conversations through either a Web browser or file-sharing client.

When a trading partner has no requirements for integration with backend systems, hosting the components required to allow that partner to participate as a browser client is the appropriate solution. File-sharing clients often have some requirement for backend systems integration, and usually process a higher volume of messages than browser clients.

This section discusses the requirements for supporting browser clients. The following section discusses the requirements for supporting file-sharing clients.

Before conversation messages can be presented to a browser client, processing must occur that transforms the message into a format meaningful to the browser endpoint. This processing must be hosted on behalf of the trading partner.

The following figure summarizes the elements required on the hosting trading partner.

Figure 1-32 Browser Client Host

A Web application that includes the required Java Server Pages (JSPs), servlets, style sheets, static HTML pages, JSP tag library, scripts, and applets, provides the interface to the browser client.

Incoming and outgoing mailboxes, which provide reliable, secure storage for browser client messages, are created via the Web application using tags from the JSP tag library. The JSP tag library is included in the WebLogic Integration distribution. It provides the interface to mailboxes, supports the creation and removal of mailboxes, and allows browser clients to administer stored messages.

CreatemboxTag is used to create mailboxes. The mailboxes must be named as follows:

- For the incoming mailbox use: trading_partner_name_Inbox

- For the outgoing mailbox use: trading_partner_name_Outbox

Workflows provide the interface between the mailboxes and the B2B engine. Although the workflow that interacts with the mailboxes can be the collaborative workflow that implements the trading partner role, for the purposes of this discussion it is assumed to be a private workflow that starts, or is started by, the collaborative workflow.

Appropriately formatted XML messages are exchanged between:

- The Web application and the mailboxes

- The private workflow and the mailboxes

The messages are exchanged as follows:

- Messages from the Web application to the outgoing mailbox
  XML messages from the Web application are sent to the outgoing mailbox for the browser client using the JSP tag library SendMsgTag. If this message is a response to a message that was sent by the private workflow, the workflow instance ID is embedded in the message.

- Messages from the outgoing mailbox to the private workflow
  Upon the arrival of a message in the outgoing mailbox, the mailbox listen method is invoked automatically and posts an XML event to the internal event JMS topic for the mailbox. The private workflow event subscribed to the topic for that mailbox is triggered, and processes or forwards the message as required.

- Messages from the private workflow to the incoming mailbox
  A private workflow business operation posts the XML messages to the incoming mailbox. The workflow instance ID is embedded in the message.

- Message from the incoming mailbox to the Web application
  The browser client can use the JSP tag library ChecknewmsgTag or CheckallmsgTag to retrieve messages from the incoming mailbox.

The WebLogic Integration distribution includes a browser client sample. Core components of the sample Web application and workflows provided can be customized, or reused without change, to implement support for your browser clients. For information about customizing components of the sample Web application, see Trading Partner Zeroweight Client Sample in Running the B2B Integration Samples.

Once you have developed the JSP pages required, and modified the other components as described, the components can be packaged in a Web Application aRchive (WAR) file and deployed as required on WebLogic Server.

The following example summarizes the information that must be defined to support a browser client.

Hosting a Browser Client

In this example, the situation is the same as that described in RosettaNet Applications: two trading partners, ABC International, a computer manufacturer, and XYZ Systems, a chip supplier, participate in Query Price and Availability (QPA) transactions. In this case, ABC International hosts the components required to allow XYZ Systems to participate as a browser client.

The collaborative and private customer workflows, PIP3A2_Customer and PIP3A2_Private_Customer, are the same as the workflows used in the RosettaNet example. The collaborative and private workflows, PIP3A2_Product_Supplier and PIP3A2_Private_Web_Product_Supplier, for the product supplier role are assumed to have been customized to support the XYZ Systems as a browser client.

All workflows are hosted on the ABC International system.

The following elements are configured on the host system, ABC International:

- Trading Partners
  The trading partner definition for ABC International is the same as the definition shown in Figure 1-22.

The trading partner definition for XYZ Systems is the same as the definition shown in Figure 1-23, with the following exceptions:

- The definition resides in the ABC configuration.

- The transport URI endpoint is changed to http://abc.com/rosettanet-client-transport.

- The trading partner name is changed to XYZ_Systems.
  (The space is replaced by an underscore because spaces are not used in mailbox names, and the trading partner name is part of the mailbox name.)

- Conversation Definition
  The conversation definition is the same as the definition shown in Figure 1-24.

- Collaboration Agreements
  The collaboration agreement is the same as the agreement shown in Figure 1-25, except that the trading partner name for XYZ Systems is modified (the space is replaced by an underscore).

The exchange of messages between the PIP3A2_Customer and PIP3A2_Product_Supplier workflows is essentially the same as the exchange shown in Figure 1-26. The only difference is that in this example, the exchange takes place within the same WebLogic Integration instance.

The processing required to support XYZ Systems as a browser client occurs in the Web application and in the PIP3A2_Private_Web_Product_Supplier workflow. This workflow now:

- Transforms the message received from the Send Event task node of PIP3A2_Public_Product_Supplier into an XML message appropriately formatted for delivery to the Web application

- Posts the XML message to XYZ_Systems_Inbox

- Waits for a response to be posted to XYZ_Systems_Outbox

- Transforms the response into a message appropriately formatted for receipt by the Wait for Response event node of the PIP3A2_Public_Product_Supplier

The following figure provides a summary of the actions performed between the time at which a message is received on the Start node and the time at which the Send Reply task of the PIP3A2_Private_Web_Product_Supplier workflow is executed.

Figure 1-33 QPA Collaboration Overview: Browser Client

File-Sharing Clients (Deprecated)

As described in the preceding section, a trading partner that has WebLogic Integration can act as a host for other trading partners that require little or no integration with backend systems.

When a trading partner has minimal requirements for integration with backend systems, hosting the components required to allow that partner to participate as a file-sharing client is usually the appropriate solution. File-sharing clients often process a higher volume of messages than browser clients.

In the preceding section, the requirements for supporting browser clients were discussed. This section discusses the requirements for supporting file-sharing clients.

Before conversation messages can be presented to a file-sharing client, processing must occur that transforms the message into a format meaningful to the file-sharing endpoint. This processing must be hosted on behalf of the trading partner.

The following figure summarizes the elements required on the hosting trading partner.

Figure 1-34 File-Sharing Host

Like the browser client case, workflows provide the interface to incoming and outgoing mailboxes which are created using the JSP tag library CreatemboxTag. In the file-sharing client case, the host system administrator usually creates these mailboxes on behalf of the file-sharing client. The mailboxes must be named as follows:

- For the incoming mailbox use: trading_partner_name_Inbox

- For the outgoing mailbox use: trading_partner_name_Outbox

WebLogic Integration provides the file-sharing daemon. The file-sharing daemon synchronizes files between the incoming and outgoing directories on the local file system with the incoming and outgoing mailboxes, as follows:

- The daemon polls the incoming mailbox at specified intervals. Newly arrived files are copied into the corresponding incoming directory.

- The daemon polls the outgoing directory on the file system at specified intervals. Newly arrived files are copied into the corresponding outgoing mailbox.

An FTP client, supplied by either a customer or a third party, serves as the interface to the incoming and outgoing directories on the file system. The mechanism for transferring the message files from the incoming and outgoing directories to the file system at the file-sharing client location, and the processing required to send or reply to the messages, is implemented by the file-sharing client.

The following example summarizes the information that must be defined to support a file-sharing client.

Hosting a File-Sharing Client

In this example, the situation is the same as that described in Browser Clients (Deprecated): two trading partners, ABC International, a computer manufacturer, and XYZ Systems, a chip supplier, plan to participate in Query Price and Availability (QPA) transactions. In this case, ABC International has agreed to host the components required to allow XYZ Systems to participate as a file-sharing client.

The collaborative and private customer workflows, PIP3A2__Customer and PIP3A2__Private_Customer, are the same as the workflows used in the browser client example. The collaborative and private workflows, PIP3A2_Product_Supplier and PIP3A2_Private_FTP_Product_Supplier, for the product supplier role are assumed to have been customized to support XYZ Systems as a file-sharing client.

All workflows are hosted on the ABC International system.

ABC International must modify the config.xml file for the domain and edit the configuration file for the file-sharing daemon. For the required modifications, see "Configuring a Zeroweight Client" in Trading Partner Zeroweight Client Sample in Running the B2B Integration Samples.

The following elements are configured on the host system, ABC International:

- Trading Partners
  The trading partner definition for ABC International is the same as the definition shown in Figure 1-22.

The trading partner definition for XYZ Systems is the same as the definition shown in Figure 1-23, with the following exceptions:

- The definition resides in the ABC configuration.

- The transport URI endpoint is changed to http://abc.com/rosettanet-client-transport.

- The trading partner name is changed to XYZ_Systems.
  (The space is replaced by an underscore because spaces are not used in mailbox names, and the trading partner name is part of the mailbox name.)

- Conversation Definition
  The conversation definition is the same as the definition shown in Figure 1-24.

- Collaboration Agreements
  The collaboration agreement is the same as the agreement shown in Figure 1-25, except that the trading partner name for XYZ Systems is modified (a space is replaced by an underscore).

The exchange of messages between the PIP3A2__Customer and PIP3A2__Product Supplier workflows is essentially the same as the exchange shown in Figure 1-26. The only difference is that now, this exchange takes place within the same WebLogic Integration instance.

The processing required to support XYZ Systems as a file-sharing client occurs at the file-sharing location and in the PIP3A2_Private_FTP_Product_Supplier workflow. This workflow now:

- Transforms the message received from the Send Event task node of PIP3A2_Public_Product_Supplier into a message appropriately formatted for delivery to the file-sharing client

- Posts the message to XYZ_Systems_Inbox

- Waits for a response to be posted to XYZ_Systems_Outbox

- Transforms the response into a message appropriately formatted for receipt by the Wait for Response event node of the PIP3A2_Public_Product_Supplier