IBM Integration Bus, Version 10.0.0.2 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS


Checking the results of integration node management with object notification by using a custom integration application

Use object notification to determine the outcome of a request that your application made against the object.

About this task

The IBM® Integration API can notify applications whenever commands complete, or whenever changes occur to administered objects. By making use of the OBSERVER design pattern, your custom integration application can define a handle to a user-supplied object that has a specific method that is called if an object is modified or deleted, or whenever a response to a previously submitted action is returned from the integration node.

The user-supplied code must implement the AdministeredObjectListener interface. This interface defines methods that are invoked by the IBM Integration API when an event occurs on an administered object to which the listener is registered. The following methods are defined:

processModify(…)
processModify(…) is called when the administered object to which the listener is registered has one or more of its attributes modified by the integration node. The following information is included in the notification through the use of the processModify() method arguments:
  1. A handle to the AdministeredObject to which the notification refers.
  2. A list of strings that contain the key names that have been changed.
  3. A list of strings that describe new subcomponents that have been created for the object; for example, new integration servers in an integration node.
  4. A list of strings that describe subcomponents that have been removed from the object.

The format of the strings passed to the final two parameters is an internal representation of the administered object. You can turn this representation into an administered object type by using the getManagedSubcomponentFromStringRepresentation() method.

Consider the following additional information:

  1. Strings are passed within these lists to enhance performance; the IBM Integration API does not use resource instantiating administered objects, unless they are specifically requested by the calling application.
  2. The first time you call the processModify() method for a listener, the changed attributes parameter can include a complete set of attribute names for the object, if the application is using a batch method, or if the IBM Integration API is experiencing communication problems with the integration node.
processDelete(…)

processDelete(…) is called if the object with which the listener is registered is completely removed from the integration node. Supplied to processDelete(…) is one parameter - a handle to the administered object that has been deleted; when this method returns, the administered object handle might no longer be valid. At about the same time that a processDelete(…) event occurs, a processModify(…) event is sent to listeners of the deleted object's parent, to announce a change in the parent's list of subcomponents.

processActionResponse(…)
processActionResponse(…) is the event that informs the application that a previous action submitted by that application is complete. Only one processActionResponse(…) event is received for each state-changing operation issued by the custom integration application. This event contains the following items of information:
  1. A handle to the administered object for which a request was submitted.
  2. The completion code of the request.
  3. A set of zero, or more, informational (BIP) messages associated with the result.
  4. A set of (key, value) pairs that describes the submitted request in more detail. Check the documentation for information about how to parse these pairs.

To register a listener, each administered object has a registerListener() method that is used to tell the IBM Integration API to call the supplied code whenever an event occurs on that object. You can register the same AdministeredObjectListener for notifications from multiple administered objects. You can also register multiple AdministeredObjectListeners against the same administered object.

Example

The following example demonstrates this technique by registering a listener on the integration node object, and displaying a message whenever it is modified:
import com.ibm.broker.config.proxy.*;
import com.ibm.broker.config.proxy.CompletionCodeType;
import java.util.List;
import java.util.ListIterator;
import java.util.Properties;

public class MonitorBroker implements AdministeredObjectListener {

  public static void main(String[] args) {
        
    BrokerProxy b = null;
    try {
      BrokerConnectionParameters bcp =
         new IntegrationNodeConnectionParameters(
           "localhost",
           4414);
      b = BrokerProxy.getInstance(bcp);   
    } catch (ConfigManagerProxyException cmpex) {
      System.out.println("Error connecting: "+cmpex);
    }
        
    if (b != null) {
      System.out.println("Connected to integration node");
      listenForChanges(b);
      b.disconnect();
    }
  }

  private static void listenForChanges(AdministeredObject obj)
  {
    if (obj != null) {
      obj.registerListener(new MonitorBroker());
      while(true) {
        // thread could do something else here instead
        try {
          Thread.sleep(10000);
        } catch (InterruptedException ex) {
          // ignore
        }
      }
    }
  }
  
  public void processActionResponse(AdministeredObject obj,
                                    CompletionCodeType cc,
                                    List bipMessages,
                                    Properties refProperties) {
    // Event ignored in this example
  }
  
  public void processDelete(AdministeredObject deletedObject) {
         // Event ignored in this example
  }
  
  public void processModify(AdministeredObject affectedObject,
                            List changedAttributes,
                            List newChildren,
                            List removedChildren) {
    try {
      System.out.println(affectedObject+" has changed:");
      ListIterator e = changedAttributes.listIterator();
      while (e.hasNext()) {
        String changedAttribute = (String) e.next();
        System.out.println("Changed: "+changedAttribute);
      }
      ListIterator e2 = newChildren.listIterator();
      while (e2.hasNext()) {
        String newChildStr = (String) e2.next();
        AdministeredObject newChild =
          affectedObject.getManagedSubcomponentFromStringRepresentation(newChildStr);
        System.out.println("New child: "+newChild);
      }
      ListIterator e3 = removedChildren.listIterator();
      while (e3.hasNext()) {
        String remChildStr = (String) e3.next();
        AdministeredObject removedChild =
          affectedObject.getManagedSubcomponentFromStringRepresentation(remChildStr);
        System.out.println("Removed child: "+removedChild);
      }
    } catch (ConfigManagerProxyPropertyNotInitializedException ex) {
      ex.printStackTrace();
    }
  }
}

The listenForChanges() method attempts to register an instance of the MonitorBroker class for notifications of integration node changes. If successful, the main thread pauses indefinitely to prevent the application from ending when the method returns. When the listener is registered, whenever the integration node changes (for example, if an integration server is added), the processModify() method is called. This method displays details of each notification on the screen.

You must register separate listeners for each administered object on which you want to receive notifications. You can use the same listener instance for multiple administered objects.

You can stop receiving notifications in three ways:
  • AdministeredObject.deregisterListener(AdministeredObjectListener)
  • ConfigManagerProxy.deregisterListeners()
  • ConfigManagerProxy.disconnect()

The first method de-registers a single listener from a single administered object; the other two methods deregister all listeners connected with that BrokerProxy instance. In addition, the final method shows that all listeners are implicitly removed when connection to the integration node is stopped.

You can also implement the AdvancedAdministeredObjectListener interface which, when registered, yields additional information to applications.


ae33090_.htm | Last updated 2015-09-24 12:52:41