|
|
|
|
|
|
B2B Integration
Enterprises interact with customers, suppliers, and trading partners in different ways. Many businesses use electronic data interchange (EDI) for business communication. Using this technology, business systems exchange structured messages using agreed upon message standards over private networks run by EDI service companies. Other businesses engage in collaborative arrangements with a variety of trading partners over the Internet. In these arrangements, trading partners need to link existing back-end applications, databases, and customers together so they can engage in real-time business transactions using a variety of business protocols.
WebLogic Integration provides the next-generation infrastructure that enables this level of inter-enterprise integration. WebLogic Integration provides a B2B integration framework for messaging, connectivity, and business protocols that businesses can use to develop collaborative arrangements with numerous trading partners over the Internet. WebLogic Integration also enables businesses to integrate EDI environments with WebLogic Integration.
The following sections describe the B2B integration functionality provided by WebLogic Integration:
B2B Integration Framework
The B2B integration framework provides the following key features to enable collaboration between trading partners:
The following sections provide details about each of these features.
Conversation Definition and Monitoring
In an e-business environment, collaboration between trading partners occurs through the exchange of business messages that contain XML or nonXML documents in a secure, choreographed arrangement called a conversation. A conversation is, quite simply, a series of business messages exchanged between trading partners.
Figure 4-1 Conversation Between Trading Partners
As Figure 4-1 shows, the composition of business messages and the sequence of an exchange is typically handled by collaborative or public business processes. The composition and sequence of messages can also be handled by Java messaging applications. Conversations can be complex and long-running, or they can be short-lived. Each conversation has a unique name. Each participant in a conversation has a conversation role, such as that of a buyer or a supplier in a supply-chain arrangement. All the details of a conversation, including its name and version, the roles of the participants, and the business protocols it uses, are specified in a conversation definition. Integration specialists create conversation definitions and monitor running conversations using the WebLogic Integration B2B Console. The following figure shows configuration information for a trading partner. Figure 4-2 WebLogic Integration B2B Console
Trading Partner Configuration and Management An e-commerce community is formed when a trading partner joins other trading partners to pursue a common business objective. An e-commerce community can exist in different forms, and for different purposes. It might, for example:
To participate in the conversations of an e-commerce community, integration specialists use the B2B Console to configure trading partners. Specifically, they assign trading partners the names by which they will be known in the conversation, and they specifying the delivery channels to be used for the exchange of business messages.
A delivery channel defines how a trading partner sends and receives messages. It also specifies the business protocol to be used in the conversation (such as XOCP), the transport protocol (such as HTTP), and security parameters. Trading partners can configure their delivery channels to communicate directly with each other in a peer-to-peer configuration, or through an intermediary when deployed in a hub-and-spoke configuration.
Peer-to-Peer Configuration
In a peer-to-peer configuration, trading partners communicate with each other directly through their respective delivery channels, using the RosettaNet or cXML business protocol.
Figure 4-3 Peer-to-Peer Configuration
In this type of configuration, a single trading partner is the controlling entity, and the other trading partners are integrated with it. A peer-to-peer configuration might be used to integrate an enterprise with its suppliers in a supply-chain arrangement. Hub-and-Spoke Configuration In a hub-and-spoke configuration, trading partners communicate with each other through an intermediary, or routing-proxy delivery channel, using the XOCP business protocol. Figure 4-4 Hub-and-Spoke Configuration
In this type of configuration, a single trading partner is the hub that mediates the exchange of messages between the other trading partners enlisted in the conversation. The hub trading partner can perform such tasks as routing and filtering messages, or it can provide customized services to the other trading partners in the conversation. A hub-and-spoke configuration might be used to link buyers and sellers in an electronic marketplace. Business Protocol Support Trading partners can use any of the following business protocols supported by WebLogic Integration:
Collaboration Agreement Definition and Management
Collaboration agreements are a central component of B2B integration because they tie together all the pieces that we have been discussing: conversations and roles, collaborative business processes, and trading partners and delivery channels. Integration specialists use the B2B Console to define collaboration agreements, which map trading partners to the roles specified in conversation definitions. Collaboration agreements reference the delivery channel each trading partner uses, and the business process each role uses to define the sequence in which a role exchanges business messages with other roles in a conversation.
Security Services
The security services provided by the B2B integration framework are built on top of the security services provided by WebLogic Server. They include the following features:
Lightweight Client Support
The B2B integration framework provides support for lightweight clients so that small and medium-size enterprises, or enterprises with few or no back-end integration requirements, can participate in e-business communities simply and inexpensively. Such enterprises can use a Web browser or a file-sharing client to communicate with other trading partners, one of which must have WebLogic Integration deployed. By using lightweight client support, trading partners can enlist other partners in shared business processes without requiring them to commit any in-house technical resources, and they can leverage their integration solutions across a wider audience.
Integration with Business Processes
WebLogic Integration provides a plug-in framework for creating collaborative or public business processes that implement the various roles in a conversation. To create public processes, integration specialists do the following:
Public business processes are typically integrated with private business processes. The design and definition of private processes are specific to a particular organization. Private processes are not visible from outside an organization, and they are usually integrated with back-end business systems. As Figure 4-1 shows, a private process can execute an internal business activity, such as retrieving information from a database, and then it can return the result to a public process, which, in turn, forwards the result to a trading partner.
APIs and Logic Plug-Ins for B2B Application Development
WebLogic Integration provides the following application programming interfaces (APIs) and Java classes that developers can use for the creation of B2B applications:
Samples
WebLogic Integration provides the following samples that integration specialists can use to model B2B integration solutions:
Hello Partner
The Hello Partner sample demonstrates how two or more trading partners can participate in business communication in a hub-and-spoke configuration. Each trading partner includes public and private business processes.
The public processes handle communication between the partners, exchanging messages using the XOCP protocol. The private processes handle the message content processing. The private processes interact with the public ones to deliver messages to trading partners, and with an associated Java application to process message content.
Channel Master
The Channel Master sample shows how a large trading partner uses WebLogic Integration to automate its supply chain.
The interactions between the trading partners occur in the following sequence:
The interactions between the buyer and the selected supplier also demonstrate point-to-point communication.
RosettaNet 2.0 Security
The RosettaNet sample shows how WebLogic Integration can be used to implement RosettaNet 2.0 PIP 3A2 and PIP 0A1 using workflows. This sample shows two trading partners exchanging business messages that conform to the RosettaNet 2.0 PIP 3A2 standard.
The interactions between the trading partners occur in the following sequence:
Lightweight Client
The Lightweight Client sample demonstrates how communication can take place between a requestor and a replier trading partner when they do not have WebLogic Integration installed. Communication is achieved using two types of lightweight clients. The requestor trading partner uses a Web browser client, and the replier uses a file-sharing client.
In the sample, the requestor uses a Web browser to access JSPs served from a remote installation of WebLogic Integration that is configured to handle lightweight clients. The JSPs create mailboxes that the replier then accesses using its file-sharing client.
Messaging API
The Messaging API sample demonstrates two message delivery methods: synchronous messaging and deferred synchronous messaging. When synchronous messaging is used, a trading partner that sends a message waits for a return from the receiving partner before it continues to execute other tasks. When deferred synchronous messaging is used, the sending partner does not wait for a return from the receiving partner, but continues executing other tasks.
The interaction between the trading partners occur in the following sequence:
EDI Integration
Electronic data interchange (EDI) is a means by which businesses communicate with each other electronically in a structured, standardized way. In an EDI environment, businesses place orders or perform financial transactions by exchanging business messages between computer systems. EDI messages are structured according to an agreed upon message standard, and are processed automatically without human intervention. The structured data in EDI messages is exchanged over private networks called value added networks (VANs). VANs are managed and supported by EDI service companies, and function like electronic post offices, routing electronic messages from sender to recipient systems.
EDI integration functionality connects EDI environments with WebLogic Integration, making it possible to integrate XML-based transactions with EDI-based transactions.
Figure 4-5 EDI Integration
To connect EDI and WebLogic Integration, WebLogic Integration provides J2EE CA-compliant service and event adapters that connect to Power.Enterprise!, an EDI-capable system. WebLogic Integration also includes an application view that integration specialists can use to integrate business processes with the EDI system. Using the application view service in a business process, applications can invoke specific functionality in the EDI system using an XML message. Using the application view event, the EDI system can propagate information to WebLogic Integration using an EDI message. The conversion from EDI to XML, and vice versa, is handled by the EDI-to-XML transformation engine bundled with Power.Server!, the EDI server provided by Power.Enterprise! Sample EDI Application WebLogic Integration provides an EDI sample application that demonstrates how WebLogic Integration and Power.Enterprise! can be used to exchange EDI purchase-order information over a VAN. In the sample application, a supplier trading partner uses the EDI integration functionality of WebLogic Integration to connect to a buyer over a VAN. The interactionsbetween the buyer and supplier occur in the following sequence:
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|