bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

Introducing B2B Integration

Getting Started with B2B Integration

This section describes how the architecture of WebLogic Integration provides a robust framework supporting B2B integration: messaging, connectivity, business protocols, and integration with business process management and workflow automation. It includes the following topics:

- Configuration Models

- B2B Integration: A Walkthrough

Configuration Models

In order to participate in business transactions with a large set of trading partners who use diverse processes and protocols, an enterprise requires a variety of connectivity options.

To that end, a trading partner using WebLogic Integration can be configured to communicate in a number of different ways. Trading partner applications communicate through their delivery channels either directly, in peer-to-peer mode, or through an intermediary delivery channel, in hub-and-spoke mode, or both. WebLogic Integration can simultaneously support multiple peer-to-peer relationships, and serve as a routing hub, mediating messages among other trading partners that deploy the WebLogic Integration B2B engine. Multiple messaging models can be overlaid on these configurations.

The following sections describe configuration and messaging models for trading partners:

- Peer-to-Peer Configuration

- Hub-and-Spoke Configuration

Peer-to-Peer Configuration

In a peer-to-peer configuration, applications for two trading partners communicate through their respective delivery channels. A trading partner's message sending and receiving characteristics are encapsulated in a delivery channel (see Delivery Channels in Collaboration Agreements).

Multiple trading partner applications can be implemented in the following configurations:

- On a single instance of WebLogic Integration within a company, as shown in the following figure.

Figure 2-1 Peer-to-Peer Configuration: Single Instance WebLogic Integration

- On multiple instances of WebLogic Integration within a company or organization, as shown in the following figure.

  Figure 2-2 Peer-to-Peer Configuration: Multiple Instances WebLogic Integration in a Single Company

- On multiple instances of WebLogic Integration across a firewall and over the Internet, as shown in the following figure.

  Figure 2-3 Peer-to-Peer Configuration: Multiple Instances WebLogic Integration in Multiple Companies

Peer-to-peer configurations support the exchange of business messages using the RosettaNet, cXML, and ebXML business protocols.

See Configuration Tasks in Administering B2B Integration for details about specific configuration tasks.

Collaboration agreements between trading partners capture the information necessary for routing business messages among trading partners. In the case of peer-to-peer communication, the target trading partner for a business message is the other trading partner in the collaboration agreement (or the role of the other trading partner, if there are more than two roles defined for the conversation).

Hub-and-Spoke Configuration

In a hub-and-spoke configuration, a trading partner application communicates via an intermediary (routing proxy) delivery channel to another trading partner's delivery channel (spoke delivery channel). The following figure includes illustrations of possible hub-and-spoke configurations for the delivery channels, the trading partner applications, and the instances of WebLogic Integration that host the trading partner applications.

Caution: Configurations A and B in the following figure show a single trading partner configured with two delivery channels; one hub, one spoke. There is currently a limitation with this configuration. Do not configure the hub and spoke delivery channels on one trading partner. Instead set up two trading partners, each with one delivery channel. Configure a hub delivery channel for one trading partner, and a spoke delivery channel for the other.

See Administering B2B Integration for details about configuring trading partners and delivery channels.

Note: The hub-and-spoke configuration described in this section is based on the XOCP business protocol, which is deprecated as of this release of WebLogic Integration. For information about the features that are replacing XOCP, see the BEA WebLogic Integration Release Notes.

Figure 2-4 Hub-and-Spoke Configuration Models

The hub-and-spoke configuration models in the preceding figure can be summarized as follows:

- Configuration A: Two trading partners are configured on a single instance of WebLogic Integration. Two delivery channels, one hub and one spoke, are configured for one trading partner. A single delivery channel, a spoke, is configured for the second trading partner.

- Configuration B: Two instances of WebLogic Integration are deployed; a single trading partner is configured for each instance. Two delivery channels, one hub and one spoke, are configured for one trading partner. A single delivery channel, a spoke, is configured for the second trading partner.

- Configuration C: Three instances of WebLogic Integration are deployed. A single trading partner is configured for each instance, and a single delivery channel is configured for each trading partner. The hub delivery channel, acts as the intermediary between the two spoke delivery channels.

Hub-and-spoke models support the exchange of business messages using the XOCP business protocol. XOCP business messages can be unicast or multicast among trading partners. Message multicasting is the ability of the XOCP messaging service to broadcast a message from one trading partner to many trading partners, within the constraints of an existing conversation.

Collaboration agreements between trading partners capture the information necessary for routing business messages among trading partners. For business messages to be exchanged between trading partners through an intermediary (hub), collaboration agreements are created between each trading partner and the intermediary. In contrast to the exchange of business messages between trading partners that communicate directly (when the target trading partner for a business message is the other trading partner in the collaboration agreement), trading partners using an intermediary identify the intermediary trading partner (that is, the routing proxy delivery channel) as the target for their business messages. The destination for the message is specified when the message is sent and, in the case of XOCP business messages, can be a single destination (a unicast message) or multiple destinations (a multicast message). Recipient trading partners can be represented in a message by an XPath expression.

See Supporting Business Protocols for a discussion of the XOCP protocol and message multicasting.

Message Mediation Models

In the hub-and-spoke model, WebLogic Integration is installed at both the hub and spoke nodes, as described in the previous section. Messages can be mediated in any of the following ways:

- Routing—Destination trading partners are known to the message initiator. WebLogic Integration, configured as a hub, acts as a routing proxy and passes business messages to the recipients indicated by the sender.

- Interposed workflows—Destination trading partners are not known to the message initiator. There are collaboration agreements between trading partners and the intermediary, but not between the trading partners themselves. The intermediary intercepts the messages with a workflow that can do any type of processing, including complex filtering and routing, integration with back-end systems, message validation, logging, and so on. This model is common in blind auctions, in which the hub is the auction broker.

- Parallel workflows—The message initiator has collaboration agreements with the hub, a trading partner collocated at the hub, and other destination trading partners routed by the hub. A message goes to all trading partners, including the collocated partner at the hub. On the hub, messages are directed to parallel workflows: one workflow passes messages on to their destination trading partners; another mediates messages by performing business processing.

Note: When you define a conversation in the WebLogic Integration B2B Console, you can mark a workflow for a role in the conversation as a proxy workflow. The hub delivery channel uses this proxy flag to differentiate between collaboration agreements that apply to conversations with a role local to the hub, and collaboration agreements that require the hub to be in the role of routing proxy.

- Interceptors—Trading partners know about each other (either a routing model or a parallel workflows model is in place), but the hub uses logic plug-ins to intercept messages and do additional processing. Logic plug-ins are Java classes that can intercept and process business messages at run time. WebLogic Integration provides system logic plug-ins, which you can supplement by writing custom logic plug-ins. The system logic plug-ins include XOCP router, XOCP filter, and RosettaNet logic plug-ins, all of which are directly involved in the processing of message recipients based on XPath expressions in the repository. Custom logic plug-ins can perform a wide range of services that are unrelated to routing or filtering, as well as routing and filtering operations. Multiple logic plug-ins can be installed in chains. A chain of routing logic plug-ins can be invoked when messages are sent, and a chain of filtering plug-ins can be invoked when messages are received.

Trading Partner Zeroweight Clients (Deprecated)

As well as making direct connections between trading partner applications, WebLogic Integration supports zeroweight clients to give small and medium-size trading partners, or trading partners with little or no back-end integration requirements, ways to connect and participate in e-business communities. Such trading partners communicate with WebLogic Integration using either a Web browser or a file-sharing client. Messages for these zeroweight clients are processed by the instance of WebLogic Integration to which they connect. In other words, message processing is hosted on behalf of the trading partner deploying the Web browser or file-sharing client. The following figure represents an example configuration in which two trading partners are created on Company A's instance of WebLogic Integration, one of which hosts the Web browser or file-sharing client used by Company C.

Figure 2-5 Hosted Trading Partner Configuration

For details about configuring and deploying trading partner zeroweight clients, see Trading Partner Zeroweight Client Sample in Running the B2B Integration Samples.

Note: Trading partner zeroweight clients are deprecated as of this release of WebLogic Integration. For information about the features that are replacing zeroweight clients, see the BEA WebLogic Integration Release Notes.

B2B Integration: A Walkthrough

Using a Query Price and Availability conversation as an example, this section describes:

- The approach for setting up the WebLogic Integration components to allow one trading partner to participate in a conversation with another trading partner, which shows how the components work together for B2B collaborations

- The exchange of business messages among trading partners participating in a conversation, which shows how B2B integration works

The Query Price and Availability conversation used in this example is described in Defining Conversations and Roles, from which the following figure, illustrating the conversation, is taken.

Figure 2-6 Workflows in a Query Price and Availability Conversation

For the purposes of this scenario, there are two business partners:

- Company ABC—the buyer

- Company XYZ—the supplier

In this scenario, Company ABC is responsible for preparing the WebLogic Integration environment to participate in this example business collaboration. Before going into production with Company XYZ, Company ABC tests the components of the collaboration in its own WebLogic Integration environment.

The following sections describe how Company ABC sets up two trading partners in its WebLogic Integration environment to participate in this business collaboration. Next, the subsequent exchange of business messages among trading partners is described. Finally, the steps both business partners take to exchange the data required before they can participate in the Query Price and Availability conversation is described:

- Create Conversation Definitions

- Create Workflow Templates

- Create Trading Partners and Delivery Channels

- Create Collaboration Agreements

- Send and Receive Business Messages

- Export and Import Repository Information

- Start Business Collaboration

A detailed discussion of how to use the WebLogic Integration B2B Console or the WebLogic Integration Studio for configuration is beyond the scope of this section. For complete configuration details, see Administering B2B Integration and Online Help for the WebLogic Integration B2B Console.

Create Conversation Definitions

To specify the roles and other details of a conversation, you define a conversation using the B2B Console. The entity you define is known as a conversation definition. A conversation among trading partners is an active instance of a conversation definition.

In this example, an administrator for Company ABC uses the B2B Console to create a conversation definition by performing the following steps:

- Name the conversation definition. (In this example, the conversation definition is Query Price and Availability.)

- Define the roles in the Query Price and Availability conversation: buyer and supplier.

- Reference XOCP as the business protocol to be used in this conversation. (The other choices are cXML1.1, cXML1.2, RosettaNet 1.1, and RosettaNet 2.0.)

- Attach a collaborative workflow template name to each role.

Note: The workflow template names you attach during this step are those of the workflow templates you must define in the WebLogic Integration Studio. For details, see Create Workflow Templates.

The following templates are attached to the roles in this example Query Price and Availability conversation.

Role in Conversation | Collaborative Workflow Template
--- | ---
Buyer | QueryPriceAvailability_Buyer
Supplier | QueryPriceAvailability_Supplier

Create Workflow Templates

Workflows that implement the roles for trading partners in a conversation definition are referred to as collaborative workflows.

To design or edit workflow templates that implement conversation roles in a conversation, you use the WebLogic Integration Studio, specifically, the B2B integration BPM plug-in, which extends the functionality of the Studio to support collaborative workflows. The Studio allows you to assign properties to the workflows. These properties make the workflows usable in the B2B integration environment.

In this example, an administrator from Company ABC uses the WebLogic Integration Studio to create two collaborative workflow templates (one for each role in the conversation): QueryPriceAvailability_Buyer and QueryPriceAvailability_Supplier.

A trading partner may also implement private workflows that work in conjunction with a collaborative workflow and that implement local processes for a trading partner. Such processes are not necessarily dictated by the conversation definition (see Create Conversation Definitions). For example, in the case where a trading partner starts a conversation, that trading partner's private workflow can start the collaborative workflow to initiate the conversation.

The following figure displays example collaborative workflows for the buyer and supplier roles in the Query Price and Availability conversation.

Figure 2-7 Collaborative Workflows for Buyer and Supplier Roles

To prepare collaborative workflows to exchange business messages, you specify conversation properties for the collaborative workflow templates. These conversation properties are specified in the WebLogic Integration Studio using workflow template definitions.

To specify conversation properties for this example, you must complete the following tasks:

- Identify the QueryPriceAvailability_Buyer collaborative workflow template as the Exchange Initiator. (This specifies that the QueryPriceAvailability_Buyer workflow starts the conversation.)

- Link the QueryPriceAvailability_Buyer template with the buyer role in the Query Price and Availability conversation.

- Link the QueryPriceAvailability_Supplier template with the supplier role in the Query Price and Availability conversation.

- Set run-time properties for workflow templates. Such properties include:

- General properties, such as template effective and expiry dates

- Quality of Service (QoS) properties, such as number of retries, timeouts, and confirmation of delivery options

Note: At run time, the QoS properties assigned to workflows take precedence over QoS properties that you define when you set up delivery channels for trading partners in the B2B Console.

See Creating Workflows for B2B Integration for details about how to use the WebLogic Integration Studio to design collaborative workflow templates.

Create Trading Partners and Delivery Channels

Enterprises that want to participate in a conversation must first configure their environments. This task includes creating a trading partner, and defining trading partner-specific information and one or more delivery channels. A delivery channel describes a trading partner's message sending and receiving characteristics, including the business protocol to be used in the conversation, a transport protocol, and security parameters.

Create Trading Partners for Company ABC

Using the B2B Console, an administrator for Company ABC creates two trading partners:

- Trading Partner A in the buyer role for the conversation

- Supplier-Test in the supplier role for the conversation

Supplier-Test is used for testing the conversation and workflows before bringing the system up for production with a trading partner (in the role of supplier) from Company XYZ.

The information to create each trading partner includes:

- Name: Trading Partner A and Supplier-Test

- Type: Local

- Contact information: Address, email, phone, fax, and so on

- Party ID: A unique name that identifies the trading partner in a collaboration agreement (for example, DUNS A12345678)

- Delivery channels for Trading Partner A

Trading Partner A requires two delivery channels: one spoke and one routing proxy. They are defined as follows:

- Name: Spoke Delivery Channel—contains the following elements:

a. Document Exchange: Defines the business protocol (XOCP) and run-time parameters

b. Transport: Defines the transport protocol (HTTP), end point URI (for example, http://CompanyABC.com/xocp-spoke-transport), and security parameters

- Name: Routing Proxy Delivery Channel—contains the following elements:

a. Document Exchange: Defines the business protocol (XOCP) and run-time parameters

b. Transport: Defines the transport protocol (HTTP), end point URI (for example, http://CompanyABC.com/xocp-hub-transport), and security parameters

- Delivery channel for Supplier-Test

The Supplier-Test trading partner requires one spoke delivery channel. The delivery channel definition contains the following information:

- Document Exchange—defines the business protocol for this trading partner (XOCP) and run-time parameters

- Transport—defines the transport protocol (HTTP), end point URI (for example, http://CompanyABC.com/xocp-spoke-transport), and security parameters

Create Trading Partner for Company XYZ

After Company XYZ installs WebLogic Integration, an administrator uses the B2B Console to create a trading partner: Trading Partner Z in the supplier role.

The information to create Trading Partner Z includes:

- Name: Trading Partner Z

- Type: Local

- Contact information: Address, email, phone, fax, and so on

- Party ID: A unique name that identifies the trading partner in a collaboration agreement (for example, DUNS Z87654321)

- Delivery channel

Trading Partner Z requires one spoke delivery channel. The delivery channel definition contains the following information:

- Document Exchange—defines the business protocol for this trading partner (XOCP) and run-time parameters

- Transport—defines the transport protocol (HTTP), end point URI (for example, http://CompanyXYZ.com/xocp-spoke-transport), and security parameters

The following figure illustrates the configuration of the three trading partners and their delivery channels as defined for this scenario.

Figure 2-8 Configuration of Trading Partners in Example Conversation

Company ABC can use the Supplier-Test trading partner to test the collaboration agreement for the Query Price and Availability conversation before connecting with Company XYZ's trading partner, who will be the supplier in the real-life scenario.

Create Collaboration Agreements

A collaboration agreement binds the trading partners' delivery channels to the conversation definition. It is through this collaboration agreement that trading partners agree on the interactions between them, in particular, the conversation in which they participate and each trading partner's message sending and receiving characteristics.

An administrator uses the B2B Console to create a collaboration agreement, with a specific name and version, in its repository. A collaboration agreement defines a party for each trading partner participating in the agreement, and includes the following information:

- A unique party identifier for each party to the collaboration agreement.

- The delivery channel information for each trading partner, as described in Create Trading Partners and Delivery Channels.

The delivery channels define the business protocol for the collaboration, the run-time parameters for each trading partner, the transport protocol, the end point (URI) for each trading partner's transport, and security parameters.

- The conversation definition, as described in Create Conversation Definitions.

The conversation definition names the business collaboration (in this case, Query Price and Availability), and attaches the roles (for example, buyer and supplier) to collaborative workflow templates.

Returning to our walkthrough example:

Company ABC creates two collaboration agreements as follows:

- QueryPrice-A-A—The parties are the Trading Partner A routing proxy delivery channel and the Trading Partner A spoke delivery channel.

- QueryPrice-A-SpTest—The parties are the Trading Partner A routing proxy delivery channel and the Supplier-Test spoke delivery channel.

Note that each trading partner has a collaboration agreement with the routing-proxy delivery channel. The routing proxy acts as an intermediary; that is, it acts as the proxy supplier in its collaboration agreement with Trading Partner A, and as a proxy buyer in its collaboration agreement with Supplier-Test.

The collaboration agreements bind the delivery channels to the conversation definition, and they reference the collaborative workflow templates that are associated with the roles in the conversation definition. The following figure represents the two collaboration agreements.

Figure 2-9 Components in the Collaboration Agreements

Notice the following in the preceding figure:

- The routing-proxy delivery channel is a party in both collaboration agreements. In the QueryPrice-A-A agreement, the routing-proxy delivery channel is in the role of (proxy) supplier, and in the QueryPrice-A-SpTest agreement, it is in the role of (proxy) buyer.

- The parties in the collaboration agreements are associated with the roles in the conversation definition.

- The conversation definition associates the collaborative workflow template for each role in the conversation with the parties in the collaboration agreement.

Send and Receive Business Messages

After the workflow templates, the conversation definition, the trading partners, the delivery channels, and the collaboration agreements have been created, Company ABC tests its collaboration agreements and conversation using Trading Partner A in the buyer role, and Supplier-Test in the supplier role for the Query Price and Availability conversation.

This section describes how business messages are sent and received during the Query Price and Availability conversation.

Figure 2-10 Sending and Receiving Business Messages

The preceding figure shows the processing of business messages through the trading partner applications and delivery channels. The events are described in the following sequence:

1. The Trading Partner A application begins the conversation by starting an instance of a private workflow which subsequently starts the collaborative workflow defined for the buyer role in the conversation. (This collaborative workflow is named QueryPriceAvailability_Buyer.)

2. The QueryPriceAvailability_Buyer collaborative workflow associates itself with the collaboration agreement QueryPrice-A-A (see Figure 2-9). In the QueryPrice-A-A collaboration agreement, the spoke delivery channel is the buyer and the routing proxy delivery channel is the supplier. Therefore the spoke delivery channel sends the message to the routing proxy delivery channel.

3. The routing proxy delivery channel is responsible for linking collaboration agreements. That is, a message arrives as part of one collaboration agreement and must be routed to another trading partner as part of another collaboration agreement. The collaboration agreements are linked because they use the same routing proxy delivery channel. (In this case they use http://CompanyABC.com/xocp-hub-transport.)

   When the routing proxy delivery channel receives this message, it is acting as the proxy supplier for the QueryPrice-A-A collaboration agreement. It then changes roles and becomes the proxy buyer. The Trading Partner A application uses this common (routing proxy) delivery channel to find the collaboration agreements for the conversations in which it is acting as the buyer. In this case, the message is sent to the Supplier-Test's spoke delivery channel as part of the QueryPrice-A-SpTest collaboration agreement. Note that the routing proxy delivery channel is in the role of proxy buyer in the QueryPrice-A-SpTest collaboration agreement.

4. The Supplier-Test delivery channel uses the collaboration agreement ID in the message to identify the collaborative workflow for the supplier role, QueryPriceAvailability_Supplier. The message starts the QueryPriceAvailability_Supplier workflow.

5. The QueryPriceAvailability_Supplier collaborative workflow extracts the message and sends an event to a private workflow implemented by the Supplier-Test trading partner.

6. The private workflow transforms the request message to a response message and sends an event back to the QueryPriceAvailability_Supplier collaborative workflow.

7. The QueryPriceAvailability_Supplier workflow sends a reply message and terminates. Based on the roles defined in the QueryPrice-A-SpTest collaboration agreement (the Supplier-Test delivery channel is the supplier and the routing proxy delivery channel is the proxy buyer), the reply message is sent to the Trading Partner A routing proxy delivery channel.

8. Trading Party A again changes roles and becomes the proxy supplier. It uses the routing proxy delivery channel to find the collaboration agreements for the conversations in which it is acting as the buyer. In this case, the message is sent back to the Trading Partner A spoke delivery channel as part of the QueryPrice-A-A collaboration agreement.

9. The spoke delivery channel sends the message to the QueryPriceAvailability_Buyer collaborative workflow which, in turn, extracts the message and sends a Done event to the Trading Partner A private workflow. (The collaborative workflows are illustrated in Figure 2-7.)

Export and Import Repository Information

To participate in B2B collaborations, enterprises must be able to share information.

In the B2B example walkthrough described throughout this section, after Company ABC successfully tests its Query Price and Availability conversation (see Send and Receive Business Messages), it can prepare for production (that is, it can set up a Query Price and Availability conversation with Company XYZ).

The B2B Console provides an export facility that allows an enterprise to export data from its repository to an XML file. The XML file can then be imported into another WebLogic Integration repository, again using the B2B Console. You can select the scope of the exported file, that is, you can export all or a subset of the repository data. These export and import facilities are used by companies to share the information they need to set up B2B collaborations.

In our example, Company ABC completes the following tasks to prepare for business transactions with Company XYZ:

1. Import the Trading Partner Z data.

   Company XYZ must have generated the data for Trading Partner Z (as described in Create Trading Partners and Delivery Channels) and exported it to an XML file.

2. Use the B2B Console to change Trading Partner Z's trading partner type from Local to Remote.

3. Create a collaboration agreement between itself and Company XYZ.

   This is similar to the collaboration agreements described in Create Collaboration Agreements, except that the data for Company XYZ's Trading Partner Z is used, instead of the Supplier-Test trading partner and delivery channel data.

4. Export a copy of the newly created collaboration agreement using the B2B Console.

5. Export (publish) the QueryPriceAvailability_Supplier collaborative workflow template (see Create Workflow Templates) and document schemas from the WebLogic Integration Studio.

Company XYZ must subsequently complete the following tasks to prepare for business transactions with Company ABC:

1. Import the collaboration agreement prepared by Company ABC.

2. Use the B2B Console to change the following aspects of the data imported from Company ABC:

   - Trading Partner Z's trading partner type from Local to Remote

   - The Organization defined for Company ABC's role (QueryPriceAvailability_Supplier) in the Query Price and Availability conversation definition

3. Import the QueryPriceAvailability_Supplier collaborative workflow template and document schemas, which were published by Company XYZ from the WebLogic Integration Studio.

4. Creates a private workflow that works in conjunction with the QueryPriceAvailability_Supplier collaborative workflow. This private workflow implements the processes that occur locally to Trading Partner Z in its role as the supplier. These processes are not necessarily dictated by the conversation definition.

Start Business Collaboration

When the steps described in Export and Import Repository Information are complete, each trading partner's repository has the information necessary to implement its role in the conversation definition.

The Trading Partner A application can begin the conversation by starting an instance of a private workflow, which subsequently starts the collaborative workflow defined for the buyer role in the conversation. (This collaborative workflow is named QueryPriceAvailability_Buyer.) Business messages are exchanged between Trading Partner A and Trading Partner Z applications, and the conversation progresses.