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
- 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.
| 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. |
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);
}
}
}IntegrationNodeProxy handle
gained previously, and discovers the run-state of the message flow in the following way:- The
IntegrationNodeProxyinstance is used to gain a handle to theIntegrationServerProxyobject with the name described by the stringserverName - If a valid integration server is returned, the
IntegrationServerProxyinstance is used to gain a handle to theMessageFlowProxyobject with the name described by the stringflowName. - If a valid message flow is returned,
the run-state of the
MessageFlowProxyobject 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);
}
}
}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.