|
|
|
|
|
|
Configuration Requirements
This section presents selected WebLogic Collaborate configurations and provides examples that summarize the configuration requirements for typical participants.
It includes the following topics:
The material in this section applies to configurations that use WebLogic Process Integrator workflows to manage conversations between trading partners. If you are using the WebLogic Collaborate API to develop applications to exchange business messages, see Programming BEA WebLogic Collaborate Messaging Applications.
If you are using logic plug-ins to add functionality to a collaboration, see Programming BEA WebLogic Collaborate Logic Plug-Ins.
Configuration Overview
The sections that follow describe what you need to know to set up some of the basic configurations supported by WebLogic Collaborate. These basic configurations illustrate the concepts required for more complex scenarios. In addition to basic WebLogic Collaborate parameter settings (for example, server name, description, and preferences), the following must be configured:
The following figure provides an overview of the configuration and the relationships between the entities. The view presented illustrates how the information is organized in the WebLogic Collaborate Administration Console. For a summary of how the information is stored in the repository, see Working with the Repository.
Figure 2-1 WebLogic Collaborate Configuration Overview
As shown in the preceding figure, each delivery channel is associated with a document exchange, which defines the business protocol binding for the delivery channel. The settings available are dependent on the selected protocol. The following figure summarizes each type. Figure 2-2 Document Exchange Business Protocol Bindings
In the sections that follow, the configuration requirements for participants in selected example applications are presented. These examples do not take into account how the required elements were added to the WebLogic Collaborate configuration. Keep in mind that the required 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 Business Collaborations.
XOCP Applications
The following sections provide background information about the configuration of XOCP delivery channels and present examples that illustrate how to configure WebLogic Collaborate 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 either a:
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 is assigned to the role of buyer in another collaboration agreement for the same conversation definition, messages will be handled as follows:
As can be seen, 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 adhere to a hub-and-spoke configuration with regard to the configuration of 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 illustrating these two basic XOCP arrangements are described in the following sections. The principles illustrated in the examples can be employed 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 Collaborate to participate in Query Price and Availability (QPA) transactions. ABC International will be the buyer and the initiator of each transaction, and the XOCP protocol will be used to exchange messages. Both trading partners have WebLogic Collaborate installed.
The sections that follow provide an example of how to:
It is assumed that the required private and collaborative (public) workflows have been created. For the purposes of this example, the collaborative workflows are named QPA_Public_Supplier and QPA_Public_Buyer. For information about using the WebLogic Collaborate plug-in with WebLogic Process Integrator to create collaborative workflows, see Creating Workflows for BEA WebLogic Collaborate.
Trading Partners
Trading partner definitions for both ABC International and XYZ Systems must be configured.
Note: For simplicity, SSL or signature certificates are not used in the examples presented in this section. For information about the security configuration requirements, see Using BEA WebLogic Collaborate Security.
The requirements for the ABC International trading partner in the ABC WebLogic Collaborate configuration are summarized in the following figure.
Note that the trading partner type 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 has an associated URI which serves as the delivery channel endpoint (http://abc.com/xocp-hub-transport and http://abc.com/xocp-spoke-transport).
Figure 2-3 ABC International Trading Partner Definition in the ABC Configuration
The requirements for the ABC International trading partner in the XYZ WebLogic Collaborate configuration are summarized in the following figure. Figure 2-4 ABC International Trading Partner Definition in the XYZ Configuration
In this case the trading partner type 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 has an associated URI which serves as the delivery channel endpoint (http://abc.com/xocp-hub-transport). The requirements for the XYZ Systems trading partner in the ABC WebLogic Collaborate configuration are summarized in the following figure. Figure 2-5 XYZ Systems Trading Partner Definition in the ABC International Configuration
In this case the trading partner type 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 has an associated URI which serves as the delivery channel endpoint (http://xyz.com/xocp-spoke-transport). The requirements for the XYZ Systems trading partner in the XYZ WebLogic Collaborate configuration are exactly the same as those just listed, with the exception of trading partner type. Trading partner type is set to Local in the XYZ WebLogic Collaborate configuration. Conversation Definitions The requirements for the Query Price and Availability (QPA) conversation definition in the ABC WebLogic Collaborate configuration are summarized in the following figure. Figure 2-6 Conversation Definition for QPA
The conversation definition in the XYZ WebLogic Collaborate configuration is the same, with the exception of the WebLogic Process Integrator (WLPI) organization, which reflects the structure used at XYZ Systems. Collaboration Agreements The collaboration agreement shown in the following figure is required only in the ABC WebLogic Collaborate 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 2-7 Collaboration Agreement ABC-ABC
The collaboration agreement shown in the following figure is required in both the ABC and XYZ WebLogic Collaborate configurations. Figure 2-8 Collaboration Agreement ABC-XYZ
How It Works The following figure summarizes how WebLogic Collaborate supports the exchange of Query Price and Availability (QPA) messages between ABC International and XYZ Systems. Figure 2-9 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 will act 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 rather acts as a mediator in the transactions between ABC International and the suppliers. ABC International will be the buyer and the initiator of each transaction and the XOCP protocol will be used to exchange messages. All participants have WebLogic Collaborate installed. The sections that follow provide an example of how to:
The ABC International hub delivery channel (XOCP-hub-dc) receives the message to the supplier role. As described in XOCP Hub and Spoke Delivery Channels, any collaboration agreements in which XOCP-hub-dc is assigned the role buyer are identified. 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 to the buyer role. Any collaboration agreements in which XOCP-hub-dc is assigned the role of supplier are identified. 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. For the purposes of this example, the collaborative workflows are named QPA_Public_Supplier and QPA_Public_Buyer. For information on using the WebLogic Collaborate plug-in with WebLogic Process Integrator to create collaborative workflows, see Creating Workflows for BEA WebLogic Collaborate.
Trading Partners
Trading partners must be configured as follows:
Note: For simplicity, SSL or signature certificates are not used in the examples presented in this section. For information about the security configuration requirements, see Using BEA WebLogic Collaborate Security.
The IntCo trading partner definition required in the ABC, TUV, and XYZ WebLogic Collaborate configurations is summarized in the following figure.
Figure 2-10 IntCo Trading Partner Definition in the ABC, TUV, and XYZ Configurations
Note that the trading partner type 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 has an associated URI which serves as the delivery channel endpoint (http://intco.com/xocp-hub-transport). The requirements for the IntCo trading partner definition in the IntCo WebLogic Collaborate configuration are exactly the same as those just listed, with the exception of trading partner type. Trading partner type is set to Local in the IntCo WebLogic Collaborate configuration. ABC International, TUV Corporation, and XYZ Systems must each configure a trading partner definition for themselves. The TUV Corporation trading partner definition required in the TUV Corporation configuration is summarized in the following figure. Figure 2-11 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 has an associated URI which 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 2-12 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 has an associated URI which 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 2-13 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 has an associated URI which 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 Collaborate 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 Collaborate configuration. Conversation Definitions The requirements for the Query Price and Availability (QPA) conversation definition in the IntCo WebLogic Collaborate configuration are summarized in the following figure. Figure 2-14 Conversation Definition for QPA
The conversation definition in the ABC, TUV, and XYZ WebLogic Collaborate configurations is the same, with the exception of the WebLogic Process Integrator (WLPI) organization, which reflects the structure used at each respective company. Collaboration Agreements The collaboration agreement shown in the following figure is required in the IntCo WebLogic Collaborate configuration to allow the IntCo hub delivery channel to act as a proxy for the buyer role, as described in XOCP Hub and Spoke Delivery Channels. Figure 2-15 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. For example, the collaboration agreement required in the TUV configuration is shown in the following figure. Figure 2-16 Collaboration Agreement TUV-IntCo
The agreement required in the XYZ configuration is shown in the following figure. Figure 2-17 Collaboration Agreement XYZ-IntCo
The collaboration agreement shown in the following figure is required in the IntCo WebLogic Collaborate configuration to allow the IntCo hub delivery channel to act as a proxy for the supplier role as described in XOCP Hub and Spoke Delivery Channels. Figure 2-18 Collaboration Agreement IntCo-to-Buyer
The agreement shown in the preceding figure is also required in the ABC configuration. How It Works The following figure summarizes how the exchange of Query Price and Availability messages between ABC International and the two suppliers, TUV Corporation and XYZ Systems are mediated by IntCo. Figure 2-19 QPA Collaboration Overview: XOCP Mediated
The message sent to the supplier role by the Send QPA action of the ABC QPA_Public_Buyer workflow is sent to the IntCo hub delivery channel based on the collaboration agreement defined in the ABC configuration. Upon receipt of the message to the supplier role on the IntCo hub delivery channel (XOCP-hub-dc), any collaboration agreement for the Query-Price conversation definition in which XOCP-hub-dc is assigned the role buyer are identified. One collaboration agreement, Query-Price IntCo-to-Supplier, meets the criteria. Based on 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 channel based on the collaboration agreement defined in the respective configurations. Upon receipt of a message to the buyer role on the IntCo hub delivery channel (XOCP-hub-dc), any collaboration agreement for the Query-Price conversation definition in which XOCP-hub-dc is assigned the role supplier are identified. One collaboration agreement, Query-Price IntCo-to-Buyer, meets the criteria. Based on that agreement, the messages are 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 described in XOCP Peer-to-Peer Messaging, where two trading partners, ABC International, a computer manufacturer, and XYZ Systems, a chip supplier, plan to use WebLogic Collaborate to participate in Query Price and Availability (QPA) transactions. In this case, the trading partners will be using the RosettaNet protocol and employing PIP 3A2 to carry out the public processes.
Trading partners participating in 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 Collaborate distribution has been customized and connected to private processes that interact with internal systems as required. For the purposes of this example, the collaborative workflows are named PIP3A2_Supplier and PIP3A2__Buyer.
For general information on using the WebLogic Collaborate plug-in with WebLogic Process Integrator to create collaborative workflows, see Creating Workflows for BEA WebLogic Collaborate. For information specific customizing the PIP templates provided with WebLogic Collaborate and configuring RosettaNet security, see Implementing RosettaNet for BEA WebLogic Collaborate.
The sections that follow provide an example of how to:
The Environment
Before you can support RosettaNet messaging in a domain, you must do the following:
The WebLogic Server runtime directory is the parent directory of the confg/domain_name domain directory. For example, for the custom domain, <BEA_Home>/wlintegration2.0/collaborate/config/mydomain, the WebLogic Server runtime directory is <BEA_Home>/wlintegration2.0/collaborate. Therefore, to support RosettaNet messaging in the custom domain, copy the DTDs from <BEA_Home>/wlintegration2.0/collaborate/rosettanet/dtds
to <BEA_Home>/wlintegration2.0/collaborate.
For example, for the custom domain, <BEA_Home>/wlintegration2.0/collaborate/config/mydomain, the WebLogic Server runtime directory is <BEA_Home>/wlintegration2.0/collaborate. Therefore, to support RosettaNet messaging in the custom domain, copy the <BEA_Home>/wlintegration2.0/collaborate/rosettanet/schemas directory to <BEA_Home>/wlintegration2.0/collaborate.
When you have made the required changes, the DTDs should be in the weblogic_server_runtime directory, and the structure for the domain should appear as shown in the following figure.
Figure 2-20 RosettaNet Directories
Trading Partners Trading partner definitions for both ABC International and XYZ Systems must be configured. Note: For simplicity, SSL or signature certificates are not used in the examples presented in this section. For information about the security configuration requirements, see Using BEA WebLogic Collaborate Security. The requirements for the ABC International trading partner in the ABC configuration are summarized in the following figure. Figure 2-21 ABC International Trading Partner Definition in the ABC 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 has an associated URI which serves as the delivery channel endpoint (http://abc.com/rosettanet-transport). The requirements for the ABC International trading partner in the XYZ WebLogic Collaborate configuration are exactly the same as those just listed, with the exception of trading partner type. Trading partner type is set to Remote in the XYZ WebLogic Collaborate configuration. The requirements for the XYZ Systems trading partner in the XYZ WebLogic Collaborate configuration are summarized in the following figure. Figure 2-22 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 has an associated URI which serves as the delivery channel endpoint (http://xyz.com/rosettanet-transport). The requirements for the XYZ Systems trading partner in the ABC WebLogic Collaborate configuration are exactly the same as those just listed, with the exception of trading partner type. Trading partner type is set to Local in the ABC WebLogic Collaborate configuration. Conversation Definitions The requirements for the Query Price and Availability (QPA) conversation definition in the ABC WebLogic Collaborate configuration are summarized in the following figure. Figure 2-23 Conversation Definition for PIP 3A2
The conversation definition in the XYZ WebLogic Collaborate configuration is the same, with the exception of the WebLogic Process Integrator (WLPI) organization, which reflects the structure used at XYZ Systems. Collaboration Agreements The collaboration agreement shown in the following figure is required in both the ABC and XYZ WebLogic Collaborate configurations. Figure 2-24 Collaboration Agreement Query-Price-PIP3A2-ABC-XYZ
How It Works The following figure summarizes how WebLogic Collaborate supports the exchange of Query Price and Availability messages between ABC International and XYZ Systems using RosettaNet 2.0. Figure 2-25 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 Collaborate, cXML security, and using the cXML API, see Implementing cXML for BEA WebLogic Collaborate.
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, constitute the PunchOutSetup transaction.
The structure of each document adheres to the cXML DTD for the 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 2-26 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. Table 2-1 cXML 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 end point. This processing must be hosted on behalf of the trading partner.
The following figure summarizes the elements required on the hosting trading partner.
Figure 2-27 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 Collaborate distribution. It provides the interface to mailboxes, supports the creation and removal of mailboxes, and the allows Browser clients to adminster stored messages. The CreatemboxTag is used to create mailboxes. The mailboxes must be named as follows:
WebLogic Process Integrator workflows provide the interface between the mailboxes and WebLogic Collaborate. 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 Collaborate 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 Using BEA WebLogic Collaborate Samples.
Once you have developed the JSP pages required, and modified the other components as described, the components can packaged in a Web Application aRchive (WAR) file and deployed as required on WebLogic Server.
The following example summarizes the configuration required to support a browser client.
Hosting a Browser Client
In this example, the situation is the same as described in RosettaNet Applications, where 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 browser client.
The collaborative and private buyer workflows, PIP3A2_Buyer and PIP3A2_Private_Buyer, are the same as in the RosettaNet example. The collaborative and private workflows, PIP3A2_Supplier and PIP3A2_Private_WebSupplier, for the supplier role are assumed to have been customized as required 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 Figure 2-22, with the following exceptions:
The exchange of messages between the PIP3A2__Buyer and PIP3A2__Supplier workflows is essentially the same as the exchange shown in Figure 2-25. The only difference is that in this example, the exchange takes place within the same WebLogic Collaborate instance.
The processing required to support XYZ Systems as a browser client occurs in the Web application and in the PIP3A2_Private_WebSupplier workflow. This workflow now:
The following figure provides a summary of the actions between the receipt of a message on the Start node and the Send Reply task of the PIP3A2_Private_WebSupplier workflow.
Figure 2-28 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 not 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 end point. This processing must be hosted on behalf of the trading partner.
The following figure summarizes the elements required on the hosting trading partner.
Figure 2-29 File-Sharing Host
WebLogic Collaborate 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:
A customer or third party supplied FTP client 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 configuration required to support a file-sharing client.
Hosting a File-Sharing Client
In this example, the situation is the same as described in Browser Clients, where 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 buyer workflows, PIP3A2__Buyer and PIP3A2__Private_Buyer, are the same as in the browser client example. The collaborative and private workflows, PIP3A2_Supplier and PIP3A2_Private_FTPSupplier, for the supplier role are assumed to have been customized as required to support the 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 File-Sharing Client" in Trading Partner Lightweight Client Sample of Using BEA WebLogic Collaborate Samples.
The following elements are configured on the host system, ABC International:
Trading partner definition for XYZ Systems is the same as the definition shown in Figure 2-22, with the following exceptions:
The exchange of messages between the PIP3A2__Buyer and PIP3A2__Supplier workflows is essentially the same as the exchange shown in Figure 2-25. The only difference is that now, this exchange takes place within the same WebLogic Collaborate instance.
The processing required to support XYZ Systems as a file-sharing client occurs at the file-sharing location and in the PIP3A2_Private_WebSupplier workflow. This workflow now:
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|
