Advanced Configuration Tasks

This section introduces the advanced features of the B2B integration functionality provided by WebLogic Integration. A roadmap to detailed information about these features is also provided. The section includes the following topics:

• Overview of Advanced Features

• XPath Expressions in Routing and Filtering

• Configuring Router and Filter Expressions

• Custom Logic Plug-Ins

• Trading Partner Extended Properties

 

---

Overview of Advanced Features

Logic plug-ins are Java classes that are invoked when WebLogic Integration is started. At run time, they intercept, process, and output business messages. The advanced features associated with logic plug-ins include:

• Routing and filtering of business messages
  The built-in XOCP router and XOCP filter logic plug-ins support customer-defined XPath router and filter expressions. Based on the XPath router and filter expressions defined, you can control the flow of XOCP business messages exchanged among trading partners as follows:

  • The XPath router logic plug-in can modify the list of recipients for an XOCP business message.

  • The XPath filter logic plug-in can determine whether an XOCP business message is sent to a trading partner.

  Note: The use of XPath router and filter expressions for routing messages to trading partners is a special feature of the XOCP business protocol.

• Custom logic plug-ins
  By default, a chain of built-in, business protocol-specific logic plug-ins is associated with each business protocol routing and filtering function. Custom logic plug-ins can be defined and inserted, where required, in either the routing or filtering chain. These custom plug-ins can perform a wide range of services besides routing and filtering.

In addition, the B2B integration functionality provided by WebLogic Integration supports the specification of extended properties for trading partners. These extended properties can be used by:

• XPath routing and filtering expressions

• Custom logic plug-ins

• External applications

 

---

XPath Expressions in Routing and Filtering

Note: The XOCP protocol is deprecated as of this release of WebLogic Integration. For information about the features that are replacing XOCP, see the BEA WebLogic Integration Release Notes.

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:

• XPath Expressions added when the business message is assembled
  Message XPath router expressions can be associated directly with a message. When an XOCP message is assembled, the field for the trading partner recipient can be left blank, or populated with a name or an XPath expression. For example, with the extended functionality provided by the B2B integration plug-in, the WebLogic Integration Studio allows you to specify either a trading partner name or an XPath expression when you configure the routing expression for a send business message action. (For details, see Sending and Receiving Business Messages in Creating Workflows for B2B Integration.)

• XPath expressions associated with a trading partner
  Trading partner XPath router expressions and trading partner XPath filter expressions can be associated with a trading partner through the B2B Console.

• XPath expressions associated with a business protocol definition
  Business protocol XPath router expressions and business protocol XPath filter expressions can be associated with the XOCP business protocol definition through the B2B Console.

  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 the trading partner sender and recipients, as identified by any conversation definition and collaboration protocol agreements. Any defined XPath router expressions use the XPath syntax to select a subset of trading partners from the set of 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 message processing and routing on an XOCP hub delivery channel.

Figure 3-1 Message Processing in XOCP Hub Delivery Channel

 

As noted, when an incoming message is received by a hub delivery channel, the conversation definition and any associated collaboration agreements that have been 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) that defines two roles: buyer and supplier. For trading partner 1 (TP1), a hub delivery channel, tp1-hub-dc, is defined. For each of the other four trading partners (TP2, TP3, TP4, and TP5) a spoke delivery channel is defined: tp2-spoke-dc, tp3-spoke-dc, tp4-spoke-dc, and tp5-spoke-dc. The following collaboration agreements are defined on TP1:

• TP1 (tp1-hub-dc) is assigned to the QPA role of supplier.
  TP2 (tp2-spoke-dc) is assigned to the QPA role of buyer.

• TP1 (tp1-hub-dc) is assigned to the QPA role of buyer.
  TP3 (tp3-spoke-dc) is assigned to the QPA role of supplier.
  TP4 (tp4-spoke-dc) is assigned to the QPA role of supplier.
  TP5 (tp5-spoke-dc) is assigned to the QPA role of supplier.

When a business message from TP2 is sent to the supplier role, and it is received on tp1-hub-dc, the collaboration agreement in which tp1-hub-dc is assigned the buyer role is identified. That collaboration agreement is then 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 contains identifying information and properties for both the sender (TP1) and the recipients (TP3, TP4, and TP5).

Any XPath router expressions that are defined are 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 be appended to the results of the previous expression. For additional information about how 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), no other element of the document is changed. In other words, all XPath router expressions are used to select from the set of trading partners that was originally included.

Once the XOCP router logic plug-in finishes processing and messages are routed to the specified trading partners, the XPath filter logic plug-in generates an XML message-context document for each outgoing business message.

If XPath filter expressions are defined, they are evaluated against the message-context document generated by the XOCP filter to determine whether the business message should be sent 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 other 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, XPath router and filter expressions can reference user-defined extended properties. (For a discussion of extended properties for trading partners, see Trading Partner Extended Properties.)

XPath Router Expression Processing

XPath router expressions fall into three categories. Each expression is configured to replace or to be appended to the results of the previous XPath expression. The expressions are processed in the following order:

1. Message XPath router expressions
   Message XPath router expressions are included in the business message. They always apply to the routing of that business message.

2. Trading Partner XPath router expressions
   Trading partner XPath router expressions are associated with the sending trading partner. They apply to all messages sent by that trading partner.

3. Business Protocol XPath router expressions
   Business protocol XPath router expressions apply to all incoming business messages using a particular protocol.

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. Expressions of the same type are processed in the order listed in the B2B Console.

XPath Filter Expression Processing

WebLogic Integration supports XPath filter expressions for two entities: trading partners and business protocols. Expressions are evaluated in the following order:

1. Trading Partner XPath filter expressions
   These expressions are associated with the recipient trading partner. They apply to all messages sent to that trading partner.

2. Business Protocol XPath filter expressions
   These expressions apply to all outgoing business messages using the specified protocol.

If you define more than one XPath filter expression for a trading partner or a business protocol, all the XPath filter expressions for trading partners are evaluated before those for business protocols. Processing continues until an expression evaluates to false, or until all expressions are processed. Expressions of the same type are processed in the order listed in the B2B Console.

 

---

Configuring Router and Filter Expressions

You can configure XPath router and filter expressions for both trading partners and business protocols from the B2B Console. To configure XPath router and filter expressions for a trading partner, complete the following steps:

1. In the B2B Console, open the Trading Partner page and select the Advanced tab. Two nested tabs, XOCP Filters & Routers and Extended Properties, are displayed.

2. Select the nested XOCP Filters & Routers tab. It is displayed as shown in the following figure.

Note: The XOCP protocol is deprecated as of this release of WebLogic Integration. For information about the features that are replacing XOCP, see the BEA WebLogic Integration Release Notes.

Figure 3-2 XOCP Filters & Routers Tab

 

From the XOCP Filters & Routers tab you can configure and order required XPath expressions. The detailed information required to perform these tasks is provided by online help. See Getting Help.

A Filters & Routers tab that is identical to the preceding tab is available when you select the Configuration tab on the XOCP business protocol definition page. Only the context differs for the two pages (the tab available from the XOCP business protocol definition page is used to define filters and routers that apply to all messages, not just those that apply to a particular trading partner).

Additional Information

For more information about routing and filtering business messages, the structure of message-context documents, and creating XPath expressions, see "Routing and Filtering Business Messages" in Programming Logic Plug-Ins for B2B Integration.

 

---

Custom Logic Plug-Ins

Note: Logic plug-ins are used primarily for hub-and-spoke configurations based on the XOCP protocol, which is deprecated as of this release of WebLogic Integration. For information about the features that are replacing XOCP, see the BEA WebLogic Integration Release Notes.

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:

• Router logic plug-in
  This logic plug-in processes incoming business messages and generates the message-context document that is used in the processing. By default, this logic plug-in is the first in the router chain. The XOCP router logic plug-in for a hub delivery channel can modify the list of trading partner recipients based on XPath router expressions, as described in XPath Expressions in Routing and Filtering.

• Router enqueue logic plug-in
  This logic plug-in adds business messages to the router message queue. By default, this logic plug-in is the last in the router chain.

• Filter logic plug-in
  This logic plug-in processes outgoing business messages and generates the message-context document that is used in processing outgoing messages. By default, this logic plug-in is the only one in the filter chain. The XOCP filter logic plug-in for a hub delivery channel can use any defined XPath filter expressions to determine whether to send a message, as described in XPath Expressions in Routing and Filtering.

The following table describes built-in logic plug-ins.

Table 3-1 Business Protocol Logic Plug-Ins  

Protocol	Processing Chain	Logic Plug-In
XOCP	Router	XOCP router
		XOCP router enqueue
	Filter	XOCP filter
RosettaNet	Router	RosettaNet router
		RosettaNet router enqueue
	Filter	RosettaNet filter
cXML	Router	cXML router
		cXML router enqueue
	Filter	cXML filter

Custom logic plug-ins can be developed and added to either a router or a filter processing chain for a business protocol. Inclusion in such a processing chain, however, does not necessarily limit the functionality of a logic plug-in. Although custom logic plug-ins are associated with one of these two types of processing chain, they are not required to perform routing or filtering services. Thus, 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 develop a custom logic plug-in, you must add a definition for it to a business protocol definition router or filter chain. To do so, open the WebLogic Integration B2B Console and complete the following procedure:

1. Create a definition for the logic plug-in, specifying the following properties:

   • Name of the logic plug-in

   • Plug-in type (router chain or filter chain)

   • Java class that implements the logic plug-in interface

   • Parameter name/value pairs to be used for initializing the Java class

   To create a logic plug-in definition:

   1. Select Logic Plug-Ins from the navigation tree. The Logic Plug-Ins page is displayed in the right pane.

   2. Select Create a New Logic Plug-In. The logic plug-in page is displayed. It includes fields in which you can specify the required properties.

2. Add the logic plug-in definition to the business protocol definition and specify the position of the logic plug-in in the router or filter chain.

   Step 2 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 a logic plug-in to a business protocol router or filter processing chain:

1. Select a business protocol from the navigation tree. Two high-level tabs, Configuration and Notes, are displayed in the right pane.

2. From the Configuration tab, select the nested Filters & Routers tab. It is displayed as shown in the following figure.

   Figure 3-3 Filters & Routers Tab for Business Protocols

   
    

From the Filters & Routers tab you can select and order any required logic plug-ins that are available. The detailed information required to perform these tasks is provided by online help. See Getting Help.

Additional Information

For more information about the logic plug-in API, and for guidelines for developing and deploying custom logic plug-ins, see Programming Logic Plug-Ins for B2B Integration.

 

---

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 B2B Console. Once added, these properties are included in any message-context documents generated by the business protocol router and filter logic plug-ins as uniquely named extended property sets.

Extended property sets are modeled in the repository so they can be retrieved as subtrees within an XML document. These XML subtrees appear in the message-context XML document generated by the built-in router and filter logic-plug-ins. XPath expressions can reference these extended properties. The root elements of each extended property set associated with a given trading partner are 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="[e-mail]" 
phone="[phone]">
<address>123 ABC Street., Anytown, CA 95131</address>
<extended-property-set name="ABC Contact">
	<business-contact>Joe Smith</business-contact>
	<phone type="work">[phone]</phone>
	<phone type="cell">[phone]</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:

1. Select a trading partner from the navigation tree. Four high-level tabs (Configuration, Monitoring, Notes, and Advanced) are displayed in the right pane.

2. Select the Advanced tab. Two tabs (XOCP Filters & Routers and Extended Properties) are nested on the Advanced tab.

3. Select the Extended Properties tab. It is displayed as shown in the following figure.

   Figure 3-4 Trading Partner Extended Properties Tab

   
    

Using this tab you can set the required extended properties. The detailed information required to perform these tasks is provided by online help. See Getting Help.

Additional Information

For more information about the structure of message-context documents and creating XPath expressions to reference extended properties, see Programming Logic Plug-Ins for B2B Integration.