Getting Started Using WebLogic Collaborate

 

This section describes how the architecture of WebLogic Collaborate provides a robust framework supporting messaging, connectivity, business protocols, and integration with the WebLogic Process Integrator workflow automation tool. It includes the following topics:

• Configuration Models

• Using WebLogic Collaborate: The End-to-End View

 

---

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 Collaborate 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 Collaborate can simultaneously support multiple peer-to-peer relationships, and serve as a routing hub, mediating messages among other trading partners that deploy WebLogic Collaborate as their trading partner server. Multiple messaging models can be overlaid on these configurations.

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

• 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 WebLogic Collaborate delivery channel (see Delivery Channels in Collaboration Agreements).

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

• On a single instance of WebLogic Collaborate within a company

• On multiple instances of WebLogic Collaborate within a company or organization

• On multiple instances of WebLogic Collaborate across a firewall and over the Internet

The following figure illustrates possible peer-to-peer configurations.

Figure 2-1 Peer-to-Peer Configuration Models

 
 

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

For details about specific configuration tasks, see Configuration Tasks in Administering BEA WebLogic Collaborate.

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 Collaborate that host the trading partner applications.

Figure 2-2 Hub-and-Spoke Configuration Models

 

For details about configuring WebLogic Collaborate, see Administering BEA WebLogic Collaborate.

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 who 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.

For a discussion of the XOCP protocol and message multicasting, see Supporting Business Protocols.

Message Mediation Models

In the hub-and-spoke model, WebLogic Collaborate 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 Collaborate, 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 Collaborate Administration 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 Collaborate 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 Lightweight Clients

As well as making direct connections between trading partner applications, the WebLogic Collaborate software supports lightweight 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 Collaborate using either a Web browser or a file-sharing client. Messages for these lightweight clients are processed by the instance of WebLogic Collaborate to which they connect. In other words, message processing is hosted on WebLogic Collaborate 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 Collaborate, one of which hosts the Web browser or file-sharing client used by Company C.

Figure 2-3 Hosted Trading Partner Configuration

 

For details about configuring and deploying trading partner lightweight clients, see Trading Partner Lightweight Client Sample in Using BEA WebLogic Collaborate Samples.

 

---

Using WebLogic Collaborate: The End-to-End View

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

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

• The exchange of business messages among trading partners participating in a conversation, which shows how WebLogic Collaborate 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-4 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 Collaborate 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 Collaborate environment.

The following sections describe how Company ABC sets up two trading partners in its WebLogic Collaborate 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 Collaborate Administration Console or the WebLogic Process Integrator Studio for configuration is beyond the scope of this section. For complete configuration details, see Administering BEA WebLogic Collaborate and BEA WebLogic Collaborate Administration Console Online Help.

Create Conversation Definitions

To specify the roles and other details of a conversation, you define a conversation using the WebLogic Collaborate Administration 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 WebLogic Collaborate Administration 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 Process Integrator 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 WebLogic Collaborate conversation definition are referred to as collaborative workflows.

To design or edit workflow templates that implement conversation roles in a WebLogic Collaborate conversation, you use the WebLogic Process Integrator Studio, specifically, the WebLogic Collaborate plug-in to the Studio, 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 WebLogic Collaborate environment.

In this example, an administrator from Company ABC uses the WebLogic Process Integrator 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-5 Collaborative Workflows for Buyer and Supplier Roles

 
 

To prepare collaborative workflows to exchange business messages in the WebLogic Collaborate environment, you specify conversation properties for the collaborative workflow templates. These conversation properties are specified in the WebLogic Process Integrator 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 properties, such as number of retries, timeouts, and confirmation of delivery options

    Note: At run time, the Quality of Service properties assigned to workflows take precedence over Quality of Service properties that you define when you set up delivery channels for trading partners in the WebLogic Collaborate Administration Console.

For details about how to use the WebLogic Process Integrator Studio to design collaborative workflow templates, see Creating Workflows for BEA WebLogic Collaborate.

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 WebLogic Collaborate Administration Console, an administrator for Company ABC creates two trading partners in the WebLogic Collaborate environment:

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

    - Document Exchange: Defines the business protocol (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

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

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

    - 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 Collaborate, an administrator uses the WebLogic Collaborate Administration Console to create a trading partner in the WebLogic Collaborate environment: 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-6 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 WebLogic Collaborate Administration 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 WebLogic Process Integrator collaboration workflow templates.

Returning to the end-to-end view 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-7 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-8 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-7). 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-5.)
    

Export and Import Repository Information

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

In the end-to-end example 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 WebLogic Collaborate Administration Console provides an export facility that allows an enterprise to export data from its WebLogic Collaborate repository to an XML file. The XML file can then be imported into another repository, again using the WebLogic Collaborate Administration 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 business-to-business 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 WebLogic Collaborate Administration 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 WebLogic Collaborate Administration Console.

5. Export (publish) the QueryPriceAvailability_Supplier collaborative workflow template (see Create Workflow Templates) and document schemas from the WebLogic Process Integrator 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 WebLogic Collaborate Administration 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 WLPI 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 Process Integrator 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.