Creating and Adding Logic Plug-Ins

The following sections describe how to develop logic plug-ins with WebLogic Integration:

About Logic Plug-Ins

The following sections describe logic plug-ins and related concepts:

What Are Logic Plug-Ins?

Logic plug-ins are Java classes that perform specialized processing of business messages as those messages pass through a B2B engine. They can be developed, as custom services, by WebLogic Integration providers or trading partners.

Logic plug-ins insert rules and business logic at strategic locations along the path traveled by business messages as they make their way through a WebLogic Integration B2B system. Logic plug-ins are instances of Java classes that are created when business protocols are created in WebLogic Integration. They are activated when a trading partner's delivery channel is started and invoked when a message passes through the B2B engine.

Logic plug-ins are business protocol-specific: they process only those messages that are exchanged using a particular business protocol. For example, if a particular plug-in is associated with the XOCP protocol, then it processes only XOCP business messages.

Logic Plug-In Processing Tasks

WebLogic Integration provides a router logic plug-in and a filter logic plug-in for supported business protocols. In addition to routing and filtering, custom logic plug-ins can perform a wide range of services. For example, for billing purposes, a custom logic plug-in can track the number of messages sent from each trading partner.

Logic plug-ins perform the types of tasks described in the following table.

Chains

Routers and filters consist of one or more logic plug-ins that are executed when a business message passes through the routers and filters. Multiple logic plug-ins that share the same business protocol are sequenced as a logic plug-in chain.

In a chain, logic plug-ins are processed sequentially at run time. After one logic plug-in has finished executing, the next logic plug-in in the chain is activated. Each successive logic plug-in can access any changes made previously to the shared message information as a business message is processed in the B2B engine.

The following figure shows an example chain of XOCP logic plug-ins in the router.

Figure 3-1 Sample XOCP Router Chain

In this example, only XOCP business messages trigger the logic plug-ins in the XOCP router chain. NonXOCP business messages (such as RosettaNet or cXML messages) are processed separately by the router chain associated with those business protocols.

System and Custom Logic Plug-Ins

To provide standard services for processing business messages, WebLogic Integration B2B offers the following logic plug-ins.

Logic Plug-In API

WebLogic Integration provides a logic plug-in API that allows WebLogic Integration B2B applications to:

Rules and Guidelines for Logic Plug-Ins

Logic plug-ins should conform to the following rules and guidelines:

Developing and Administering Logic Plug-Ins

Implementing a custom logic plug-in requires a combination of development and administrative tasks. The following steps describe the required procedures:

Programming Steps for Logic Plug-Ins

This section describes the programming steps that you must perform in the logic plug-in code. Although each logic plug-in processes business messages in its own way, all logic plug-ins must perform certain tasks.

To implement a logic plug-in, complete the following steps:

This section uses code excerpts from a logic plug-in that:

Step 1: Import the Necessary Packages

At a minimum, a logic plug-in needs to import the following packages:

The following listing from the SentMsgCounter.java file shows how to import the necessary packages.

Listing 3-1 Importing the Necessary Packages

import java.util.Hashtable;
import com.bea.b2b.protocol.*;
import com.bea.b2b.protocol.messaging.*;
import com.bea.eci.logging.*;
import javax.naming.*;
import javax.sql.DataSource;

// This package is needed to access the DB pool
import java.sql.*;

Step 2: Implement the PlugIn Interface

A logic plug-in needs to implement the com.bea.b2b.protocol.PlugIn interface, as shown in the following listing.

Listing 3-2 Implementing the PlugIn Interface

public class SentMsgCounter implements PlugIn
{
        ...
}

Step 3: Specify the Exception Processing Model

A PlugInException is thrown if:

The exception processing model specified in a logic plug-in determines what happens if an exception is thrown. Logic plug-ins must implement the exceptionProcessingModel method and specify one of the return values described in the following table.

If a business message is rejected, what happens next depends on the business protocol, as well as on the specified Quality of Service associated with the message. For example, the B2B application that sent the message might be notified that message delivery failed and it might then attempt to send the business message again.

The following listing shows how the SentMsgCounter plug-in implements the exceptionProcessingModel method.

Listing 3-3 Specifying the Exception Processing Model

public int exceptionProcessingModel()
{
       return EXCEPTION_CONTINUE;
}

Step 4: Implement the Process Method

To process a business message, a logic plug-in must implement the process method, which accepts the message envelope of the business message as its only parameter. In the following listing, the SentMsgCounter class begins its implementation of the process method by defining the variables that it later uses to store message properties.

Listing 3-4 Implementing the Process Method

public void process(MessageEnvelope mEnv) throws PlugInException
{
    
    String sender, conversation;
    String tRecipient;
    Connection conn = null;
    Statement stmt = null;
    Message bMsg = null;
    ...
}

Note: When processing a business message, a logic plug-in is allowed to modify only the message envelope, not the business message.

Step 5: Get the Business Message from the Message Envelope

If a logic plug-in needs to inspect the contents of a business message, it must call the getMessage method on the MessageEnvelope instance, which retrieves the business message as a Message object.

In the following listing, the SentMsgCounter class gets the business message from the message envelope by calling the getMessage method.

Listing 3-5 Retrieving the Business Message from the Message Envelope

if((bMsg = mEnv.getMessage())== null)
{
        throw new PlugInException("message is NULL");
}

Step 6: Validate the Business Message

Optionally, a logic plug-in can determine whether a message is a valid business message that should be processed, or a system message that should be ignored by the logic plug-in. To check a business message, the logic plug-in can call the isBusinessMessage method on the Message instance. In the following listing, the SentMsgCounter class uses the isBusinessMessage method.

Listing 3-6 Validating the Business Message

if (bMsg.isBusinessMessage())
{
    ...
}

Step 7: Get the Business Message Properties

Optionally, a logic plug-in can retrieve certain properties of the business message by calling methods on the MessageEnvelope or Message instance. In the following listing, the SentMsgCounter class gets the name of the conversation definition associated with the conversation in which this message was sent, the name of the sender of the business message, and the name of the recipient trading partner.

Listing 3-7 Retrieving Business Message Properties

conversation= bMsg.getConversationType().getName();
sender = mEnv.getSender();
tRecipient = mEnv.getRecipient();

Step 8: Process the Business Message as Needed

After a logic plug-in obtains the required information from the business message, it processes this information as necessary. For example, the SentMsgCounter plug-in updates the billing database with the message statistics it has collected.

Administrative Tasks

An administrator adds the logic plug-in definition to the repository by performing the following tasks from the Logic Plug-Ins tab of the WebLogic Integration B2B Console: