Business-to-Business Integration (B2Bi)

Business-to-business integrations (B2Bi) are becoming common as business processes need to span enterprise boundaries to meet the demand of todays competitive environment, where improving business efficiency is the key to being successful. To support these processes, organizations need to support basic requirements such as workflow management, reliable messaging and routing, and application integration.

B2B integrations are becoming more real-time and are no longer being handled in batch mode. The data exchange protocols being followed, such as HTTP, FTP, and SOAP, are more standardized. B2B integration frameworks provide functionality to businesses to find and interact with trading partners electronically and securely, hence reducing costs. A trading partner is usually an external enterprise collaborating for the purposes of a business process.

B2B Integration Support in WLI

WebLogic Integration provides a standards-based architecture for supporting B2B integration. Business protocols such as RosettaNet and ebXML, which provide the capability to exchange business documents in a secure manner with trading partners, are supported. A framework for managing execution and interaction of trading partner applications is also provided. The XML data repository and a set of configuration tools to manage the metadata and conversation definitions required for B2B integration are provided. Figure 36.12 shows the overall architecture and illustrates how B2Bi fits in with the other WebLogic Integration functional components .

Figure 36.12. WLI B2Bi architecture.

B2Bi Configurations

WebLogic B2Bi functionality supports multiple deployment architectures. The most important architectures are described in the following two sections.

Peer-to-Peer

A WebLogic Integration solution can be configured to communicate directly with others in a peer-to-peer mode. This kind of deployment is desirable in a deployment in which, for example, a direct interaction between trading partners is required.

Figure 36.13 shows a peer-to-peer configuration. Here, customer A is interacting directly with suppliers B, C, and D. Suppliers B and C are running WebLogic Integration, and supplier D is running a third-party integration solution.

Figure 36.13. A peer-to-peer configuration.

Hub-and-Spoke

A hub-and-spoke configuration allows integration between two or more WebLogic Integration deployments via an intermediary. An intermediary (the hub) performs tasks such as routing and filtering messages, or it can provide services to the trading partners in the conversation.

Figure 36.14 illustrates a hub-and-spoke configuration. Here, a business is serving as auctioneer for business-to-business auctions. The business (represented by A) acts as an intermediary to buyers (B and C) and sellers (D and E).

Figure 36.14. A hub-and-spoke configuration.

Business Protocols

A business message is a basic unit of communication among two business partners. It is important for a business message to abide by a protocol that is understood by all business partners involved. A business protocol usually specifies the structure of a business message. It may also specify characteristics of the message in terms of persistence, process of exchanging messages, and reliability. Some of the common business protocols are

• RosettaNet

• ebXML (Electronic Business using Extensible Markup Language)

• XOCP (Extensible Open Collaboration Protocol)

• cXML (Commerce Extensible Markup Language)

Protocols such as RosettaNet and ebXML are supported by WebLogic Integration. For example, WebLogic Integration supports the creation and execution of workflows that model ebXML messages. Therefore, a business that deploys WebLogic Integration can use ebXML to interoperate with another business that deploys WLIs B2Bi component or instead can have a lightweight trading partner solution called Business Connect, which will be discussed later in this chapter. By supporting the standard protocols, WLI facilitates seamless integration between business/trading partners. The out-of-the-box support for these standard protocols can be extended and customized as per the user s need. This is achieved by a framework which is comprised of a set of Java classes which intercept and process business messages at runtime.

Figure 36.15 shows the structure of a sample RosettaNet business message based on the RosettaNet 1.1 protocol specification. A RosettaNet message is made up of three parts : header information containing the version number, the message body, and footer information. The message body is composed of several individual messagesnamely, the preamble header, service header, and service contentwhich are constructed and then encoded as a MIME message.

Figure 36.15. A RosettaNet business message.

Conversation

Businesses exchange information by communicating via business messages. These messages form a part of a conversation. A conversation is a series of business messages exchanged between business partners. In a conversation, the participants play a role. The business messages that can be exchanged in a conversation between participants are determined by these roles. In WLI, each conversation has a unique name and version.

To start, a conversation definition is created; it consists of

• A unique name and version.

• A business protocol (such as ebXML).

• Two or more roles to be used by business partners involved in the conversation.

• Reference to a BPM workflow template for each role. BPM workflow templates are a recommended means of composing and exchanging business messages.

Collaboration Agreement

A very important aspect of B2B is the establishment and management of agreements among business partners. In WLI, this type of agreement is called a Collaboration Agreement . Using these colloboration agreements, trading or business partners agree on interactions in which they participate.

Using Workflows for B2Bi

In B2B, trading partners participate in a conversation in a particular role. A workflow has to be implemented for each such role. These workflows, which encapsulate the processes required for a given trading partners role in a conversation, are known as collaborative workflows . Figure 34.5 (Chapter 34) shows collaborative workflows used in the end-to-end sample shipped with Platform 7.0. Here, based on the collaboration agreement between the E2E_Buyer and E2E_Hub trading partners, the E2E_BuyerQPAPublic workflow sends an XOCP message to the E2E_Hub trading partner. The E2E_Hub trading partner routes the QPA request to two other trading partnersE2E_SupplierOne and E2E_SupplierTwobased on their respective collaboration agreements. Each suppliers private workflow creates its own QPA response, which is eventually routed back to the buyer via the E2E_Hub, which acts as a proxy supplier.

Collaborative workflows are always linked with a particular conversation definition. While youre defining a workflow template in Studio, you can use the B2B Integration tab in the Template Definition dialog box to define various aspects of the conversation definition, including name, version, role, and protocol (see Figure 36.16).

Figure 36.16. Conversation properties in the workflows template definition.

ebXML Workflow Example

Consider an example in which there are two trading partners: Foo and Bar. Foo initiates a request and prepares an ebXML message and sends it to Bar. This process takes place under a defined collaboration agreement. To run this sample, follow these steps:

1. Start the WLI samples server by running

     <  wl_home  >\weblogic700\samples\integration\samples\bin\RunSamples.cmd  

2. Open Studio.

3. Log in as admin/security .

4. Use the Import package tool to import a given workflow under chapter36\example2\FooBarWorkflows.jar in the ORG1 organization. FooBarWorkflows.jar contains both Foo and Bar workflows. Figure 36.17 shows the ask properties of Send EBXML Message of Foo Workflow. Figure 36.18 shows the start properties of the Start node of the Bar Workflow. This specifies that the workflow will trigger on an event caused by an ebXML message.

   Figure 36.17. Foo WorkflowInitiator Rolesends ebXML message.

   

   Figure 36.18. Bar WorkflowParticipant Rolegets triggered on an ebXML message.

   

5. Run BulkLoader to load the conversation definition, collaboration agreement, and other required definitions from chapter36\example2\MyBulkLoaderData.xml .

6. Run the MyQueueSender driver to place an XML message on the configured JMS Queue. This can be achieved by the following steps:

   1. Copy chapter36\example2 to your local drive.

   2. Use cd to change directory to example1 .

   3. While in the example1 directory, run the setWLSenv.cmd script from <wl_home>\weblogic700\server\bin .

   4. Run ant . This will first compile and then run the sample. (Run ant -projecthelp to list all the targets.)

7. In Studio, right-click the Bar template and select Instances.

8. When the workflow instance appears, double-click the instance and check out the contents on the ebXML message received (see Figure 36.19).

   Figure 36.19. The ebXML message received.

   

The B2Bi Plug-in for BPM

The B2Bi plug-in extends the Studio to allow specifying nodes, actions, and events for collaborative workflows to be used among trading partners.

The plug-in also integrates the BPM process engine with the conversation flow.

Administration Using the B2Bi Console

The B2Bi Console is a browser-based component that enables configuration (including creation) and monitoring of various functional aspects of B2Bi functionality. The B2Bi Console, shown in Figure 36.20, allows you to create, configure, and monitor business conversations, trading partners, collaboration agreements, and so on.

Figure 36.20. The B2Bi Console.

Business Connect

Business Connect is a lightweight client that can be deployed by an enterprise (for example, a trading partner), enabling it to be integration ready with a minimal software footprint. Business Connect involves a noninvasive installation with a low cost of management and maintenance. Business Connect also includes an embedded Web server and a database server. It can interoperate with partners existing applications. Document exchange is supported with existing environments, including JMS, MQSeries, Java APIs, FTP, and so on.