Navigating integration node and integration node resources in a custom integration application

Explore the status and attributes of the integration node that your custom integration application is connected to, and discover information about its resources.

Before you begin

You must have completed Connecting to an integration node from a custom integration application.

About this task

Each resource that the integration node can control is represented as a single object in the IBM Integration API. A custom integration application can request status and other information about the following objects:
  • Integration nodes
  • Integration servers
  • Deployed message flows

The IBM Integration API also handles deployed message sets; these resources are handled as attributes of deployed integration servers.

Collectively known as administered objects, these objects provide most of the interface to the integration node, and are therefore fundamental to an understanding of the IBM Integration API.

Each administered object is an instance of a Java™ class that describes the underlying type of object in the integration node. The main Java classes are shown in the following table.
Java class Class function
ApplicationProxy Describes applications that have been deployed to integration servers.
IntegrationNodeProxy Describes integration nodes.
IntegrationServerProxy Describes integration servers.
MessageFlowProxy Describes message flows that have already been deployed to integration servers through an application, REST API, or integration service; it does not describe message flows in the Integration Development perspective of the IBM App Connect Enterprise Toolkit.
RestApiProxy Describes the REST API application details that have been deployed to an integration server.
ServiceProxy Describes the integration service details that have been deployed to an integration server.
SharedLibraryProxy Describes the shared library details that have been deployed to an integration server.
StaticLibraryProxy Describes the static library details that have been deployed to an integration server through an application, REST API, or integration service.
SubFlowProxy Describes subflows that have already been deployed to integration servers through an application, REST API, or integration service.
Each administered object describes a single object that can be controlled by the integration node. For example, every integration server within an integration node has one IntegrationServerProxy instance that represents it within the application.

A set of public methods is available for each administered object, which applications can use to inquire and manipulate properties of the underlying integration node to which the instance refers. To access an administered object through its API, your application must first request a handle to that object from the object that logically owns it.

For example, because integration nodes logically own integration servers, to gain a handle to integration server EG1 running on integration node B1, the application must ask the IntegrationNodeProxy object represented by B1 for a handle to the IntegrationServerProxy object represented by EG1.

On a IntegrationNodeProxy object that refers to integration node B1, the application can call methods that cause the integration node to reveal its run-state, or cause it to start all its message flows. You can write applications to track the changes that are made to the integration node objects by reading the messages maintained as LogEntry objects.

In the following example, a handle is requested to the IntegrationNodeProxy object. The IntegrationNodeProxy is logically the root of the administered object tree, therefore your application can access all other objects in the integration node directly, or indirectly.

The integration node directly owns the integration servers, therefore applications can call a method on the IntegrationNodeProxy object to gain a handle to the IntegrationServerProxy objects. Similarly, the integration server logically contains the set of all message flows, therefore the application can call methods on the IntegrationServerProxy object to access the MessageFlowProxy objects.

Each object with an asterisk after its name inherits from the DeployedObjectGroupProxy class, and therefore has further child objects.

The following application traverses the administered object hierarchy to discover the run-state of a deployed message flow. The application assumes that message flow MF1 is deployed to EG1 on integration node B1; you can substitute these values in the code for other values that are valid in the integration node.

import com.ibm.integration.admin.proxy.*;

public class GetMessageFlowRunState {

  public static void main(String[] args) {
        
    IntegrationNodeProxy node = new IntegrationNodeProxy("localhost",4414,"","",false);

    System.out.println("Getting message flow status of MF1 in the default application");
      displayMessageFlowRunState(node, "Server1", "MF1");
    }
        
    private static void displayMessageFlowRunState(
                                 IntegrationNodeProxy node,
                                 String serverName,
                                 String flowName) {
    try {
      IntegrationServerProxy server =
        node.getIntegrationServerByName(serverName);

      if (server != null) {
        MessageFlowProxy mf = 
          server.getDefaultApplication(true).getMessageFlowByName(flowName,"",false);
          /* locate the message flow from the default application. boolean flag indicates */
          /* if we need to fresh the model or use the cache one from proxy. */ 

        if (mf != null) {
          boolean isRunning = mf.getMessageFlowModel(false).getActive().isRunning();
          System.out.print("Flow "+flowName+" on " + 
            serverName+" on "+server.getName()+" is ");

          if (isRunning) {
            System.out.println("running");
          } else {
            System.out.println("stopped");
          }
        } else {
          System.err.println("No such flow "+flowName);
        }
      } else {
        System.err.println("No such integration server "+serverName+"!");
      }
        
    } catch(IntegrationAdminException ex) {
      System.err.println("Comms problem! "+ex);
    }
  }
}
The method displayMessageFlowRunState() does most of the work. This method takes the valid IntegrationNodeProxy handle gained previously, and discovers the run-state of the message flow in the following way:
  1. The IntegrationNodeProxy instance is used to gain a handle to the IntegrationServerProxy object with the name described by the string serverName
  2. If a valid integration server is returned, the IntegrationServerProxy instance is used to gain a handle to the MessageFlowProxy object with the name described by the string flowName.
  3. If a valid message flow is returned, the run-state of the MessageFlowProxy object is queried, and the result is displayed.

The application does not have to know the names of objects that it can manipulate. Each administered object contains methods to return sets of objects that it logically owns. The following example demonstrates this technique by looking up the names of all integration servers within the integration node.

import java.util.List;

import com.ibm.integration.admin.proxy.IntegrationAdminException;
import com.ibm.integration.admin.proxy.IntegrationNodeProxy;
import com.ibm.integration.admin.proxy.IntegrationServerProxy;

public class DisplayIntegrationServerNames {

  public static void main(String[] args) {
        
    IntegrationNodeProxy node = new IntegrationNodeProxy("localhost",4414,"","",false);

    System.out.println("Get the Integration Server Names");
    displayIntegrationServerNames(node); 
   }
private static void displayIntegrationServerNames(IntegrationNodeProxy node)
  {
    try {
      List<IntegrationServerProxy> serverNames = node.getAllIntegrationServers();
      if (serverNames != null)
      {
        for(IntegrationServerProxy name: serverNames)
          {  
          System.out.println("Found : "+name.getName());
          }  
        }
      else
      { // no servers found or a Rest call returned a bad response
        // check the status of the last http response  
        int status = node.getLastHttpResponse().getStatusCode(); 
      if (node.getLastHttpResponse().getStatusCode() == 200)
        {
          System.out.println("No servers Found");
        }
      else
        {
          System.out.println("Http response from Integration Node is "+status);
          System.out.println("Http response reason: "+node.getLastHttpResponse().getReason());
        }
      }

      } catch(IntegrationAdminException ex) {
      System.err.println("Comms problem! "+ex);  
    }
  }
}
The properties of any proxy are obtained by calling a getxxxxModel method call, where xxx is the current proxy object being used. The model class is a representation of the JSON response message returned from the REST calls. The following example shows how to obtain the process identifier of an integration node and an integration server:
import com.ibm.integration.admin.model.IntegrationNodeModel;
import com.ibm.integration.admin.model.IntegrationServerModel;
import com.ibm.integration.admin.proxy.*;


public class GetProperties {

  public static void main(String[] args) {

    IntegrationNodeProxy node = new IntegrationNodeProxy("localhost",4414,"","",false);
    try {
      IntegrationNodeModel nodeModel = node.getIntegrationNodeModel(true);
      System.out.println("Node Process ID: "+nodeModel.getActive().getProcessId());

      IntegrationServerProxy server = node.getIntegrationServerByName("Server1");
      IntegrationServerModel serverModel = server.getIntegrationServerModel(true);
      System.out.println("Server Process ID: "+serverModel.getActive().getProcessId());
    } catch (IntegrationAdminException e) {
      System.out.println("Error connecting: "+e);
    }
  }
}
Each proxy class caches the last model that was obtained from the REST call. Subsequent calls return the cached value from the proxy. If you want the model to be updated, set the refresh flag on the call to true, which causes the proxy to discard the cached version and obtain the latest properties.