bea.com | products | dev2dev | support | askBEA
 Download Docs   Site Map   Glossary 
Search
e-docs > WebLogic Platform > WebLogic Integration > B2B Topics > Introducing B2B Integration > Getting Started with B2B Integration

Introducing B2B Integration

 Previous Next Contents Index View as PDF  

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

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

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:

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:

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:

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

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:

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:

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:

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:

The information to create each trading partner includes:

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:

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:

Returning to our walkthrough example:

Company ABC creates two collaboration agreements as follows:

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:

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:

  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.

 

Back to Top Previous Next