|
|
|
|
|
|
Advanced Configuration Tasks
This section serves as an introduction to the more advanced features of WebLogic Collaborate and provides a roadmap to where more detailed information can be found. It includes the following topics:
Overview of Advanced Features
Logic plug-ins are Java classes that are invoked when WebLogic Collaborate is started. At run time, logic plug-ins intercept, process, and output business messages. The advanced features associated with logic plug-ins include:
Note: The use of XPATH router and filter expressions for routing messages to trading partners is a special feature of the XOCP business protocol.
In addition, WebLogic Collaborate supports the specification of trading partner extended properties. These extended properties can be used by:
XPath Expressions in Routing and Filtering
The XPath expressions used by the XOCP router and XOCP filter logic plug-ins to control the flow of business messages fall into three categories.
Note: The use of XPATH expressions for routing messages to trading partners is a special feature of the XOCP business protocol. When an application sends a message using RosettaNet or cXML the target recipient is explicitly encoded.
As described in XOCP Hub and Spoke Delivery Channels, XOCP delivery channels are configured as hub delivery channels or spoke delivery channels. When a business message is transmitted to a hub delivery channel, the XOCP router logic plug-in generates an XML message-context document. The message-context document captures properties associated with trading partner sender and recipient(s) as identified by the conversation definition and collaboration protocol agreements configured. Any XPath router expressions defined use the XPath syntax to select a set of trading partners from the trading partners and associated properties captured in the message-context document. The selected trading partners are the intended recipients of the XOCP business message.
The following figure provides a high-level overview of the message processing and routing on an XOCP hub delivery channel.
Figure 4-1 XOCP Hub Delivery Channel Message Processing
As noted, when an incoming message is received by a hub delivery channel, the conversation definition and associated collaboration agreements configured are used to identify the recipient trading partners to be included in the message-context document. For example, suppose you have a Query Price and Availability conversation definition (QPA) which defines the roles buyer and supplier. Trading partner 1 (TP1) has a delivery channel (tp1-hub-dc) defined, while trading partners 2, 3, 4, and 5 (TP2, TP3, TP4, TP5) each have a spoke delivery channel defined (tp2-spoke-dc, tp3-spoke-dc, tp4-spoke-dc, and tp5-spoke-dc). The following collaboration agreements are defined on TP1:
When a business message from TP2 is sent to the role supplier and is received on tp1-hub-dc, the collaboration agreement in which tp1-hub-dc is assigned the role buyer is identified and used to identify the trading partner recipients for the business message.
In this case, the XML message-context document generated by the XOCP router logic plug-in would contain the identifying information and properties for the sender, TP1, and the recipients, TP3, TP4, and TP5.
Any XPath router expressions defined would be used by the XOCP router logic plug-in to select trading partners from this list. The trading partners selected by the XPath expression(s) are then included in the message routing header. Each XPath expression is configured to replace or to append to the results of the previous expression. For additional information about how the XPath router expressions are processed, see XPath Router Expression Processing.
Note: Although the context attribute of the wlc element in the message-context document is updated in the course of processing by the XPath router logic plug-in (from message-router to trading-partner-router, then to hub-router), nothing else about the document is changed. In other words, all XPath router expressions are used to select from the set of trading partners originally included.
Once the XOCP router logic plug-in has completed processing and messages are routed to the trading partners identified, the XPath filter logic plug-in generates an XML message-context document for each outgoing business message. If XPath filter expressions have been defined, these are evaluated against the message-context document generated by the XOCP filter to determine whether to send the business message to a trading partner or not. XPath filter expressions must evaluate to a boolean true or false. If any expression evaluates to false, then the message is not sent and no further expressions are evaluated. If all expressions evaluate to true, the message is processed normally. The order in which these XPath filter expressions are evaluated is described in XPath Filter Expression Processing.
As noted in Overview of Advanced Features, the XPath router and filter expressions can reference user-defined extended properties. (For a discussion of trading partner extended properties, see Trading Partner Extended Properties.)
XPath Router Expression Processing
As described in the preceding section, XPath router expressions fall into three categories. The expressions are processed in the following order. Each expression is configured to replace or append to the results of the previous XPath expression.
If you define more than one trading partner XPath router expression or business protocol XPath router expression, all the trading partner XPath router expressions are evaluated before the business protocol XPath router expressions. Within the same type, expressions are processed in the order listed in the WebLogic Collaborate Administration Console.
XPath Filter Expression Processing
As described in the preceding section, XPath filter expressions fall into two categories. The expressions are evaluated in the following order.
If you define more than one trading partner XPath filter expression or business protocol XPath filter expression, the trading partner XPath filter expressions are evaluated before the business protocol XPath filter expressions. Processing continues until an expression evaluates to false or all expressions have been processed. Within the same type, expressions are processed in the order listed in the WebLogic Collaborate Administration Console.
Configuring Trading Partner and Business Protocol Router and Filter Expressions
When you select the Advanced tab in the trading partner page, then select the Filters & Routers tab, the following is displayed.
Figure 4-2 Trading Partner Filters & Routers
When you select the Configuration tab in the XOCP business protocol definition page, you are presented with an identical Filters & Routers tab (only the context is different). From the XPath Filters & Routers tab you can configure and order the XPath expressions required. The detailed information required to perform these tasks is provided in the WebLogic Collaborate Administration Console online help. Note: The information in the online help is also available as a document entitled BEA WebLogic Collaborate Administration Console Online Help
Additional Information
Additional information about routing and filtering business messages, message-context document structure, and creating XPath expressions can be found in "Routing and Filtering Business Messages" in Programming BEA WebLogic Collaborate Logic Plug-Ins.
Custom Logic Plug-Ins
As described in Overview of Advanced Features, logic plug-ins are Java classes that can intercept and process business messages at run time. Each business protocol is associated with three standard logic plug-ins:
The built-in logic plug-ins are summarized in the following table.
Table 4-1 Business Protocol Logic-Plug-Ins
Custom logic plug-ins can be developed and added to either the router or filter processing chain for a business protocol. Although custom logic plug-ins are associated with a router or filter processing chain, they need not perform routing or filtering services. For example, a custom logic plug-in might be developed to examine message content and capture information for billing purposes.
Configuring Logic Plug-Ins
After you have developed a custom logic plug-in, the logic plug-in definition must be added to a business protocol definition router or filter chain. You can add the logic plug-in from the WebLogic Collaborate Administration Console as follows:
To create a new logic plug-in definition, select Logic Plug-Ins from the navigation tree, then select Create a New Logic Plug-In. The logic plug-in page is displayed. Fields are provided which allow you to specify the properties specified in the preceding list.
This step is performed from the business protocol page as described in the following section.
Adding a Custom Logic Plug-In to a Business Protocol Router or Filter Chain
To add the logic plug-in to a business protocol router or filter processing chain, select the business protocol from the navigation tree, then select the Filters & Routers tab to display the following.
Figure 4-3 Business Protocol Filters & Routers tab
From the Filters & Routers tab you can select and order the available logic plug-ins as required. The detailed information required to perform this task is provided in the WebLogic Collaborate Administration Console online help. Note: The information in the online help is also available as a document entitled BEA WebLogic Collaborate Administration Console Online Help. Additional Information Information about the logic plug-in API and guidelines for developing and deploying custom logic plug-ins can be found in Programming BEA WebLogic Collaborate Logic Plug-Ins. 
Trading Partner Extended Properties
The default properties associated with a trading partner can be augmented to support application-specific requirements through the use of trading partner extended properties. You can add extended properties from the WebLogic Collaborate Administration Console. Once added, these properties are included in the message-context documents generated by the business protocol router and filter logic plug-ins as uniquely named extended propertys ets.
The extended property sets are modeled in the repository so that they can be retrieved as sub-trees within an XML document. These XML sub-trees appear in the generated message-context XML document generated by the built in router and filter logic-plug-ins. The XPath expressions can reference these extended properties. The root elements of each extended property set associated with a given trading partner are be inserted as the last children of the <trading-partner> element node. The following example shows an XML document generated from the repository with an extended property set:
<wlc context="message-router">
...
<trading-partner name="ABC International"
email="admin@abc.com"
phone="+1 123 456 7890">
<address>123 ABC Street., Anytown, CA 95131</address>
<extended-property-set name="ABC Contact">
<business-contact>Joe Smith</business-contact>
<phone type="work">+1 123 456 7654</phone>
<phone type="cell">+1 321 654 4567</phone>
<city>Anytown</city>
<state>California</state>
</extended-property-set>
</trading-partner>
...
</wlc>
Configuring Trading Partner Extended Properties
To add extended properties to a trading partner, select the trading partner from the navigation tree, select the Advanced tab, then select the Extended Properties tab to display the following.
Figure 4-4 Trading Partner Extended Properties
From the Extended Properties tab you can set the extended properties required. The detailed information required to perform this task is provided in the WebLogic Collaborate Administration Console online help. Note: The information in the online help is also available as a document entitled BEA WebLogic Collaborate Administration Console Online Help. Additional Information Additional information about message-context document structure and creating XPath expressions to reference extended properties can be found in Programming BEA WebLogic Collaborate Logic Plug-Ins. 
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|