|
|
|
|
|
|
Configuration Requirements
This section presents selected WebLogic Integration B2B integration configurations and provides examples that summarize the configuration requirements for typical participants. It includes the following topics:
The information in this section applies to configurations for collaborative workflows used to manage conversations between trading partners. If you are using the Messaging API or the cXML API to write Java messaging applications, see Programming Messaging Applications for B2B Integration. If you are using logic plug-ins to add functionality to a collaboration, see Programming Logic Plug-Ins for B2B Integration.
Configuration Overview
The following sections describe how to set up some of the basic B2B integration applications supported by WebLogic Integration. These basic configurations illustrate the concepts required for more complex scenarios. In addition to setting the B2B engine properties (for example, B2B engine name, description, and preferences), properties for the following entities must be configured:
The following figure provides an overview of the entities that must be configured. It shows how information is organized in the WebLogic Integration B2B Console. For a summary of how information is stored in the repository, see Working with the Repository. The detailed information required to set specific properties is provided in the B2B Console online help (see Getting Help).
Figure 1-1 B2B Integration Configuration Overview
As shown in the preceding figure, each delivery channel is associated with a document exchange, which defines its business protocol binding. The parameters defined in the document exchange vary, depending on the selected protocol. The following figure summarizes the four protocols supported by WebLogic Integration. Figure 1-2 Business Protocol Bindings Defined in the Document Exchange
The following sections describe the configuration requirements for participants in several sample applications. Although configuration is typically performed through the B2B Console, these examples do not demonstrate how configuration is done. Keep in mind that the trading partners, conversation definitions, collaboration agreements, and workflows created on one system can be exported and then imported to another system, as described in Importing and Exporting B2B Integration Components. A Note About Trading Partner Encoding Like all XML documents, the messages exchanged between trading partners can potentially be encoded using any valid character set. By default, messages are encoded in UTF-8. To support alternate encodings, the configuration for a trading partner includes the property, encoding, which determines the how the B2B engine encodes messages sent to that trading partner. (See the trading partner general properties shown in Figure1-1.) The specification of encoding only has significance in the XOCP protocol. The B2B engine uses UTF-8 to encode all cXML and RosettaNet messages, regardless of how the encoding property is set. As you will learn in the following section, XOCP Applications, messages in the XOCP protocol are always routed though a trading partner delivery channel that is configured as a hub, as shown in the following figure. Figure 1-3 Message Delivery
Based on the these settings, encoding of a message from TP1 destined for TP3 would be handled as follows:
The message encoding for this scenario is summarized in the following figure.
Figure 1-4 Message Encoding
In order to achieve the desired results when using the encoding property, it is important to keep in mind how the message will be handled when you configure the trading partners and their associated delivery channels. If the intention is to have the payload information encoded in Shift_JIS for TP3, then the encoding for TP2 should be set to Shift_JIS. The following section provides additional information about how trading partner definitions, conversation definitions, and collaboration agreements are configured to route messages using the XOCP protocol. If required, you can configure dummy trading partners and collaboration agreements as needed to ensure trading partners receive messages encoded appropriately. For a list of valid encoding names and aliases, visit the following URL: http://www.iana.org/assignments/character-sets
XOCP Applications
The following sections provide background information about the configuration of XOCP delivery channels and examples that show how to configure the B2B engine to use XOCP in peer-to-peer and mediated messaging applications:
XOCP Hub and Spoke Delivery Channels
A delivery channel in the XOCP protocol must be configured as one of the following:
A hub delivery channel is unique in that it acts as a proxy for either role in a conversation definition. The role assumed by the hub delivery channel depends on the configuration of the collaboration agreements for the conversation definition. For example, if the hub delivery channel for a trading partner is assigned to the role of supplier in one collaboration agreement, and to the role of buyer in another collaboration agreement for the same conversation definition, messages are handled as follows:
In other words, if multiple trading partners associated with the same role in a conversation definition enter into a collaboration agreement with a hub delivery channel, that delivery channel can be used to broadcast messages to those trading partners. If it is necessary to limit the broadcast to a subset of trading partners, XPath filter expressions can be used, as described in XPath Expressions in Routing and Filtering.
Although XOCP applications always require a hub-and-spoke configuration for their delivery channels and collaboration agreements, trading partners using the XOCP protocol can participate in either a peer-to-peer or mediated exchange of messages:
Detailed examples of these two basic XOCP message exchange methods are presented in the following sections. Keep in mind that while these examples themselves show simple scenarios, the principles they illustrate can be used to create more complex hybrid deployments.
XOCP Peer-to-Peer Messaging
Suppose two trading partners, ABC International, a computer manufacturer, and XYZ Systems, a chip supplier, plan to use WebLogic Integration to participate in Query Price and Availability (QPA) transactions. ABC International is the buyer and the initiator of each transaction, and the XOCP protocol is used to exchange messages. Both trading partners have WebLogic Integration installed.
The following sections provide examples of how to:
It is assumed that the required private and collaborative (public) workflows have been created. The collaborative workflows in this example are named QPA_Public_Supplier and QPA_Public_Buyer. For information about using the Studio (with the extended functionality provided by the B2B integration plug-in) to create collaborative workflows, see Creating Workflows for B2B Integration.
Caution: This example demonstrates a single trading partner configured with two delivery channels: one hub, one spoke. Please note that there is currently a limitation with this configuration. Do not set up one trading partner with two delivery channels. Instead set up two trading partners, each with its own delivery channel. Configure a hub delivery channel for one trading partner, and a spoke delivery channel for the other.
Trading Partners
Trading partner definitions for both ABC International and XYZ Systems must be provided.
Note: For simplicity, SSL or signature certificates are not used in the examples presented in this section. For information about security configuration, see Implementing Security with B2B Integration.
The information that must be defined for the ABC International trading partner in the ABC WebLogic Integration configuration is summarized in the following figure.
Figure 1-5 ABC International Trading Partner Definition in the ABC Configuration
Note that the trading partner type (listed in the General box) is Local and the configuration includes hub and spoke delivery channels (XOCP-hub-dc and XOCP-spoke-dc), document exchanges (XOCP-hub-de and XOCP-spoke-de), and transports (XOCP-hub-transport and XOCP-spoke-transport). Each transport is associated with a URI that serves as the delivery channel endpoint (http://abc.com/xocp-hub-transport and http://abc.com/xocp-spoke-transport). Note: As noted in the introduction to this example (see XOCP Peer-to-Peer Messaging), WebLogic Integration currently has a limitation that requires you to configure two trading partners. For example, configure one trading partner named ABC International-Spoke and the other named ABC International. The ABC International definition would include the XOCP-hub-dc, XOCP-hub-de, and XOCP-hub-transport definitions, while the ABC International-Spoke definition would include the XOCP-spoke-dc, XOCP-spoke-de, and XOCP-spoke-transport definitions. The information that must be defined for the ABC International trading partner in the XYZ WebLogic Integration configuration is summarized in the following figure. Figure 1-6 ABC International Trading Partner Definition in the XYZ Configuration
In this case the trading partner type (listed in the General box) is Remote and the configuration includes only a hub delivery channel (XOCP-hub-dc), document exchange (XOCP-hub-de), and transport (XOCP-hub-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://abc.com/xocp-hub-transport). The information that must be defined for the XYZ Systems trading partner in the ABC WebLogic Integration configuration is summarized in the following figure. Figure 1-7 XYZ Systems Trading Partner Definition in the ABC International Configuration
In this case the trading partner type (listed in the General box) is Remote and the configuration includes only a spoke delivery channel (XOCP-spoke-dc), document exchange (XOCP-spoke-de), and transport (XOCP-spoke-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://xyz.com/xocp-spoke-transport). The information that must be defined for the XYZ Systems trading partner in the XYZ WebLogic Integration configuration is exactly the same as the information shown in the previous figure, with one exception: the trading partner type (listed in the General box) must be set to Local in the XYZ WebLogic Integration configuration. Conversation Definitions The required settings for the Query Price and Availability (QPA) conversation definition in the ABC WebLogic Integration configuration are shown in the following figure. Figure 1-8 Conversation Definition for QPA
The conversation definition in the XYZ WebLogic Integration configuration is the same, with one exception: the value of the BPM organization (listed as WLPI organization) must be changed to reflect an organization defined at XYZ systems (for example, XYZ_Org). Collaboration Agreements The collaboration agreement shown in the following figure is required only in the ABC WebLogic Integration configuration. The agreement makes it possible for the hub delivery channel to act as a proxy for the buyer role, as described in XOCP Hub and Spoke Delivery Channels. Figure 1-9 Collaboration Agreement ABC-ABC
Note: If you have created two trading partners as described in the note following Figure1-5, the trading partner name for the buyer role in the previous collaboration agreement is changed to ABC International-Spoke. The collaboration agreement shown in the following figure is required in both the ABC and XYZ WebLogic Integration configurations. Figure 1-10 Collaboration Agreement ABC-XYZ
How It Works The following figure shows how WebLogic Integration supports the exchange of Query Price and Availability (QPA) messages by ABC International and XYZ Systems. Figure 1-11 QPA Collaboration Overview: XOCP Peer-to-Peer
Note 1 Note 2 XOCP Mediated Messaging In this example, ABC International, a computer manufacturer, plans to contract with IntCo, a company that acts as an intermediary for order management transactions. Two chip suppliers, TUV Corporation and XYZ Systems, are among those contracted with IntCo. IntCo acts as the intermediary in the Query Price and Availability (QPA) transactions between ABC International and the two chip suppliers. IntCo does not directly participate in any role in the conversation, but acts as a mediator in the transactions between ABC International and the suppliers. ABC International is the buyer and the initiator of each transaction and the XOCP protocol is used to exchange messages. All participants have WebLogic Integration installed. The following sections provide examples of how to:
The ABC International hub delivery channel (XOCP-hub-dc) receives the message sent to the supplier role. As described in XOCP Hub and Spoke Delivery Channels, all collaboration agreements in which XOCP-hub-dc is assigned the buyer role are identified. In the case shown here, one collaboration agreement, Query-Price ABC-XYZ, meets the criteria. Based on that agreement, the message is delivered to the XYZ Systems delivery channel assigned to the role of supplier (XYZ Systems XOCP-spoke-dc at http://xyz.com/xocp-spoke-transport).
The ABC International hub delivery channel (XOCP-hub-dc) receives the message sent to the buyer role. All collaboration agreements in which XOCP-hub-dc is assigned the role of supplier are identified. In the case shown here, one collaboration agreement, Query-Price ABC-ABC, meets the criteria. Based on that agreement, the message is delivered to the XYZ Systems delivery channel assigned to the role of buyer (ABC International XOCP-spoke-dc at http://abc.com/xocp-spoke-transport).
It is assumed that the required private and collaborative (public) workflows have been created. The collaborative workflows in this example are named QPA_Public_Supplier and QPA_Public_Buyer. For information about using the Studio (with the extended functionality provided by the B2B integration plug-in) to create collaborative workflows, see Creating Workflows for B2B Integration.
Trading Partners
Trading partners must be configured as follows:
Note: For simplicity, SSL or signature certificates are not used in the examples in this section. For information about security configuration, see Implementing Security with B2B Integration.
The IntCo trading partner definition required in the ABC, TUV, and XYZ WebLogic Integration configurations is summarized in the following figure.
Figure 1-12 IntCo Trading Partner Definition in the ABC, TUV, and XYZ Configurations
Note that the trading partner type (listed in the General box) is Remote and the configuration includes a hub delivery channel (XOCP-hub-dc), document exchange (XOCP-hub-de), and transport (XOCP-hub-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://intco.com/xocp-hub-transport). The IntCo trading partner definition in the IntCo WebLogic Integration configuration must match the definition shown in the previous figure, with one exception: the trading partner type (listed in the General box) must be set to Local in the IntCo WebLogic Integration configuration. Each of the other trading partners must provide a trading partner definition for itself as part of its own WebLogic Integration configuration. The TUV Corporation trading partner definition required in the TUV Corporation configuration is summarized in the following figure. Figure 1-13 TUV Corporation Trading Partner Definition in the TUV Configuration
Note that the trading partner type is Local and the configuration includes a spoke delivery channel (XOCP-spoke-dc), document exchange (XOCP-spoke-de), and transport (XOCP-spoke-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://tuv.com/xocp-spoke-transport). The XYZ Systems trading partner definition required in the XYZ configuration is summarized in the following figure. Figure 1-14 XYZ Systems Trading Partner Definition in the XYZ Configuration
Note that the trading partner type is Local and the configuration includes a spoke delivery channel (XOCP-spoke-dc), document exchange (XOCP-spoke-de), and transport (XOCP-spoke-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://xyz.com/xocp-spoke-transport). The ABC International trading partner definition required in the ABC configuration is summarized in the following figure. Figure 1-15 ABC International Trading Partner Definition in the ABC Configuration
Note that the trading partner type is Local and the configuration includes a spoke delivery channel (XOCP-spoke-dc), document exchange (XOCP-spoke-de), and transport (XOCP-spoke-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://abc.com/xocp-spoke-transport). The requirements for the XYZ, TUV, and ABC trading partner definitions in the IntCo WebLogic Integration configuration are exactly the same as those listed above, with the exception of trading partner type. Trading partner type is set to Remote for XYZ, TUV, and ABC in the IntCo WebLogic Integration configuration. Conversation Definitions The information that must be defined for the Query Price and Availability (QPA) conversation in the IntCo WebLogic Integration configuration is summarized in the following figure. Figure 1-16 Conversation Definition for QPA
The conversation definition in the ABC, TUV, and XYZ WebLogic Integration configurations is the same, with one exception: the value of the BPM organization (listed as WLPI organization) must be changed to reflect an organization defined at each company. Collaboration Agreements The collaboration agreement shown in the following figure is required in the IntCo WebLogic Integration configuration. It enables the IntCo hub delivery channel to act as a proxy for the buyer role, as described in XOCP Hub and Spoke Delivery Channels. Figure 1-17 Collaboration Agreement IntCo-to-Supplier
Note: IntCo has the option of configuring one agreement (as shown in the preceding figure) or two separate agreements (one with each supplier). If separate agreements are configured, each can be exported for use by the appropriate trading partner. Corresponding agreements are required in the TUV and XYZ configurations. The collaboration agreement for the TUV configuration is shown in the following figure. Figure 1-18 Collaboration Agreement for TUV-IntCo
The agreement required in the XYZ configuration is shown in the following figure. Figure 1-19 Collaboration Agreement XYZ-IntCo
The collaboration agreement shown in the following figure is required in the IntCo WebLogic Integration configuration. It enables the IntCo hub delivery channel to act as a proxy for the supplier role, as described in XOCP Hub and Spoke Delivery Channels. Figure 1-20 Collaboration Agreement IntCo-to-Buyer
The agreement shown in this figure is also required in the ABC configuration. How It Works The following figure shows how IntCo mediates the exchange of Query Price and Availability messages between ABC International and the two suppliers, TUV Corporation and XYZ Systems. Figure 1-21 QPA Collaboration Mediated by IntCo
The message sent to the supplier role by the Send QPA action of the ABC QPA_Public_Buyer workflow is forwarded to the IntCo hub delivery channel as specified by the collaboration agreement in the ABC configuration. When the IntCo hub delivery channel (XOCP-hub-dc) receives a message sent to the supplier role, collaboration agreements for the Query-Price conversation definition in which XOCP-hub-dc is assigned to the buyer role are identified. In this case, one collaboration agreement, Query-Price IntCo-to-Supplier, meets the criteria. As specified by that agreement, the message is delivered to the TUV Corporation delivery channel (XOCP-spoke-dc at http://tuv.com/xocp-spoke-transport) and the XYZ Systems delivery channel (XOCP-spoke-dc at http://xyz.com/xocp-spoke-transport). Messages sent to the buyer role by the Send Reply action of the TUV or XYZ QPA_Public_Supplier workflow are sent to the IntCo hub delivery as specified by the collaboration agreements defined in the respective configurations. When the IntCo hub delivery channel (XOCP-hub-dc) receives a message sent to the buyer role, collaboration agreements for the Query-Price conversation definition in which XOCP-hub-dc is assigned to the supplier role are identified. In this case, one collaboration agreement, Query-Price IntCo-to-Buyer, meets the criteria. As specified by that agreement, the message is delivered to the ABC International delivery channel (XOCP-spoke-dc at http://abc.com/xocp-spoke-transport). 
RosettaNet Applications
In this example, the situation is the same as that described in XOCP Peer-to-Peer Messaging, where two trading partners, ABC International, a computer manufacturer, and XYZ Systems, a chip supplier, use WebLogic Integration to participate in Query Price and Availability (QPA) transactions. In this case, the trading partners use the RosettaNet protocol and employ PIP 3A2 to carry out the public processes.
Trading partners participating in Partner Interface Processes (PIPs) need to implement the public process defined by their role in the PIP, and they need to connect their internal systems, as well as their private processes and workflows, to the public process.
It is assumed that the PIP 3A2 template provided in the WebLogic Integration distribution is customized and connected to private processes that interact with internal systems as required. The collaborative workflows in this example are named PIP3A2_Product_Supplier and PIP3A2_Customer.
For general information about using the Studio (with the extended functionality provided by the B2B integration plug-in) to create collaborative workflows, see Creating Workflows for B2B Integration. For information about customizing the PIP templates provided with WebLogic Integration and configuring RosettaNet security, see Implementing RosettaNet for B2B Integration.
The following sections provide examples of how to:
Note: Before you can use RosettaNet in a WebLogic Integration domain, you must modify the setup of the domain, as described in Setting Up the Environment in Implementing RosettaNet for B2B Integration.
Trading Partners
Trading partner definitions for both ABC International and XYZ Systems must be provided.
Note: For simplicity, SSL or signature certificates are not used in the examples presented in this section. For information about security configuration, see Implementing Security with B2B Integration.
The information that must be defined for the ABC International trading partner in the ABC configuration is summarized in the following figure.
Figure 1-22 ABC International Trading Partner Definition in the ABC Configuration
Note that the trading partner type (listed in the General box) is Local and the configuration includes a single RosettaNet delivery channel (RosettaNet-dc), document exchange (RosettaNet-de), and transport (RosettaNet-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://abc.com/rosettanet-transport). The ABC trading partner definition in the XYZ WebLogic Integration configuration must match the definition shown in the previous figure, with one exception: the trading partner type must be set to Remote in the XYZ WebLogic Integration configuration. The information that must be defined for the XYZ Systems trading partner in the XYZ WebLogic Integration configuration is summarized in the following figure. Figure 1-23 XYZ Systems Trading Partner Definition in the XYZ Configuration
Note that the trading partner type is Local and the configuration includes a single RosettaNet delivery channel (RosettaNet-dc), document exchange (RosettaNet-de), and transport (RosettaNet-transport). The transport is associated with a URI that serves as the delivery channel endpoint (http://xyz.com/rosettanet-transport). The XYZ trading partner definition in the ABC WebLogic Integration configuration must match the definition shown in the previous figure, with one exception: the trading partner type must be set to Remote in the ABC WebLogic Integration configuration. Conversation Definitions The required settings for the Query Price and Availability (QPA) conversation definition in the ABC WebLogic Integration configuration are shown in the following figure. Figure 1-24 Conversation Definition for PIP 3A2
The conversation definition in the XYZ WebLogic Integration configuration is the same, with one exception: the value of the BPM organization (listed as WLPI organization) must be changed to reflect an organization defined at XYZ systems (for example, XYZ_Org). Collaboration Agreements The collaboration agreement shown in the following figure is required in both the ABC and XYZ WebLogic Integration configurations. Figure 1-25 Collaboration Agreement Query-Price-PIP3A2-ABC-XYZ
How It Works The following figure shows how WebLogic Integration supports the exchange of Query Price and Availability messages by ABC International and XYZ Systems using RosettaNet 2.0. Figure 1-26 QPA Collaboration Overview: RosettaNet
cXML Applications
This section provides a summary of the cXML-specific requirements for configuring trading partners, conversation definitions, and collaboration agreements. For information about the architecture used to implement cXML on WebLogic Integration, cXML security, and using the cXML API, see Implementing cXML for B2B Integration.
The documents exchanged in cXML are divided into three basic types: Request, Response, and Message. Within each basic type are a set of subtypes. For example, a Request might be an OrderRequest, PunchOutSetupRequest, SupplierDataRequest, SupplierListRequest, or GetPendingRequest. Each Request-Response pair constitutes a cXML transaction. For example, PunchOutSetupRequest and PunchOutSetupResponse, together, constitute the PunchOutSetup transaction.
The structure of each document adheres to the cXML DTD for a specific document type and version of cXML.
Examples summarizing the basic structure of the three major document types are shown in the following figure.
Figure 1-27 cXML Document Types
When you define the trading partners and conversation definitions for cXML transactions, the values assigned to certain parameters must match specific element and attribute values that appear in the cXML root and Header elements. In addition, conversation definition names must match the cXML transaction, and the roles assigned must be Buyer and Supplier. The following table summarizes the requirements.
Browser Clients
In some cases, a trading partner may require little or no integration with backend systems in order to participate in a conversation. In such cases, the trading partner need not have WebLogic Integration installed. A trading partner that has WebLogic Integration can act as a host, allowing these smaller trading partners to subscribe to, and participate in, an authorized set of conversations through either a Web browser or file-sharing client.
When a trading partner has no requirements for integration with backend systems, hosting the components required to allow that partner to participate as a browser client is the appropriate solution. File-sharing clients often have some requirement for backend systems integration, and usually process a higher volume of messages than browser clients.
This section discusses the requirements for supporting browser clients. The following section discusses the requirements for supporting file-sharing clients.
Before conversation messages can be presented to a browser client, processing must occur that transforms the message into a format meaningful to the browser endpoint. This processing must be hosted on behalf of the trading partner.
The following figure summarizes the elements required on the hosting trading partner.
Figure 1-28 Browser Client Host
A Web application, which includes the required Java Server Pages (JSPs), servlets, style sheets, static HTML pages, JSP tag library, scripts, and applets, provides the interface to the browser client. Incoming and outgoing mailboxes, which provide reliable, secure storage for browser client messages, are created via the Web application using tags from the JSP tag library. The JSP tag library is included in the WebLogic Integration distribution. It provides the interface to mailboxes, supports the creation and removal of mailboxes, and allows Browser clients to administer stored messages. CreatemboxTag is used to create mailboxes. The mailboxes must be named as follows:
Workflows provide the interface between the mailboxes and the B2B engine. Although the workflow that interacts with the mailboxes can be the collaborative workflow that implements the trading partner role, for the purposes of this discussion it is assumed to be a private workflow that starts, or is started by, the collaborative workflow.
Appropriately formatted XML messages are exchanged between:
The messages are exchanged as follows:
The WebLogic Integration distribution includes a browser client sample. Core components of the sample Web application and workflows provided can be customized, or reused without change, to implement support for your browser clients. For information about customizing components of the sample Web application, see Trading Partner Lightweight Client Sample in Running the B2B Integration Samples.
Once you have developed the JSP pages required, and modified the other components as described, the components can be packaged in a Web Application aRchive (WAR) file and deployed as required on WebLogic Server.
The following example summarizes the information that must be defined to support a browser client.
Hosting a Browser Client
In this example, the situation is the same as that described in RosettaNet Applications: two trading partners, ABC International, a computer manufacturer, and XYZ Systems, a chip supplier, participate in Query Price and Availability (QPA) transactions. In this case, ABC International hosts the components required to allow XYZ Systems to participate as a browser client.
The collaborative and private customer workflows, PIP3A2_Customer and PIP3A2_Private_Customer, are the same as the workflows used in the RosettaNet example. The collaborative and private workflows, PIP3A2_Product_Supplier and PIP3A2_Private_Web_Product_Supplier, for the product supplier role are assumed to have been customized to support the XYZ Systems as a browser client.
All workflows are hosted on the ABC International system.
The following elements are configured on the host system, ABC International:
The trading partner definition for XYZ Systems is the same as the definition shown in Figure1-23, with the following exceptions:
The exchange of messages between the PIP3A2_Customer and PIP3A2_Product_Supplier workflows is essentially the same as the exchange shown in Figure1-26. The only difference is that in this example, the exchange takes place within the same WebLogic Integration instance.
The processing required to support XYZ Systems as a browser client occurs in the Web application and in the PIP3A2_Private_Web_Product_Supplier workflow. This workflow now:
The following figure provides a summary of the actions performed between the time at which a message is received on the Start node and the time at which the Send Reply task of the PIP3A2_Private_Web_Product_Supplier workflow is executed.
Figure 1-29 QPA Collaboration Overview: Browser Client
File-Sharing Clients
As described in the preceding section, a trading partner that has WebLogic Integration can act as a host for other trading partners that require little or no integration with backend systems.
When a trading partner has minimal requirements for integration with backend systems, hosting the components required to allow that partner to participate as a file-sharing client is usually the appropriate solution. File-sharing clients often process a higher volume of messages than browser clients.
In the preceding section, the requirements for supporting browser clients were discussed. This section discusses the requirements for supporting file-sharing clients.
Before conversation messages can be presented to a file-sharing client, processing must occur that transforms the message into a format meaningful to the file-sharing endpoint. This processing must be hosted on behalf of the trading partner.
The following figure summarizes the elements required on the hosting trading partner.
Figure 1-30 File-Sharing Host
WebLogic Integration provides the file-sharing daemon. The file-sharing daemon synchronizes files between the incoming and outgoing directories on the local file system with the incoming and outgoing mailboxes, as follows:
An FTP client, supplied by either a customer or a third party, serves as the interface to the incoming and outgoing directories on the file system. The mechanism for transferring the message files from the incoming and outgoing directories to the file system at the file-sharing client location, and the processing required to send or reply to the messages, is implemented by the file-sharing client.
The following example summarizes the information that must be defined to support a file-sharing client.
Hosting a File-Sharing Client
In this example, the situation is the same as that described in Browser Clients: two trading partners, ABC International, a computer manufacturer, and XYZ Systems, a chip supplier, plan to participate in Query Price and Availability (QPA) transactions. In this case, ABC International has agreed to host the components required to allow XYZ Systems to participate as a file-sharing client.
The collaborative and private customer workflows, PIP3A2__Customer and PIP3A2__Private_Customer, are the same as the workflows used in the browser client example. The collaborative and private workflows, PIP3A2_Product_Supplier and PIP3A2_Private_FTP_Product_Supplier, for the product supplier role are assumed to have been customized to support XYZ Systems as a file-sharing client.
All workflows are hosted on the ABC International system.
ABC International must modify the config.xml file for the domain and edit the configuration file for the file-sharing daemon. For the required modifications, see "Configuring a Lightweight Client" in Trading Partner Lightweight Client Sample in Running the B2B Integration Samples.
The following elements are configured on the host system, ABC International:
The trading partner definition for XYZ Systems is the same as the definition shown in Figure1-23, with the following exceptions:
The exchange of messages between the PIP3A2__Customer and PIP3A2__Product Supplier workflows is essentially the same as the exchange shown in Figure1-26. The only difference is that now, this exchange takes place within the same WebLogic Integration instance.
The processing required to support XYZ Systems as a file-sharing client occurs at the file-sharing location and in the PIP3A2_Private_FTP_Product_Supplier workflow. This workflow now:
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|
