Explore el estado y los atributos del intermediario al que la aplicación del CMP está conectada, y descubra información sobre sus recursos.
Antes de empezar
Antes de iniciar este paso, ha de haber completado lo indicado en el apartado Conexión a un intermediario desde una aplicación de CMP.
El CMP también maneja conjuntos de mensajes desplegados; estos recursos se manejan como atributos de grupos de ejecución desplegados.
Conocidos colectivamente como objetos administrados, estos objetos proporcionan la mayoría de la interfaz del intermediario y, por tanto, resultan fundamentales para comprender el CMP.
Clase Java | Función de clase |
---|---|
BrokerProxy | Describe intermediarios. |
ExecutionGroupProxy | Describe grupos de ejecución. |
MessageFlowProxy | Describe los flujos de mensajes que ya se han desplegado en grupos de ejecución; no describe los flujos de mensajes de la perspectiva Desarrollo de aplicaciones de intermediario de WebSphere Message Broker Toolkit. |
LogProxy | Representa el registro de la actividad administrativa reciente en el intermediario, para todos los usuarios. |
ActivityLogProxy | Representa un registro de flujo de mensajes y actividad de recursos recientes. |
DataCaptureProxy | Representa datos que se mantienen en un almacén de datos de intermediario. Los datos recuperados están contenidos en objetos DataCaptureEntry. |
El objeto LogProxy incluye mensajes, creados como objetos LogEntry, que registran los cambios recientes realizados en los objetos administrados. Estos mensajes incluyen la siguiente información:
El objeto ActivityLogProxy incluye mensajes, creados como objetos ActivityLogEntry, que registran las actividades recientes de alto nivel relacionadas con los flujos de mensajes y sus interacciones con recursos externos. Para obtener más información sobre estos mensajes consulte Utilización de Registros de actividades. Los registros de actividades se generan para flujos de mensajes y para tipos de recursos específicos.
Puede recuperar un objeto ActivityLogProxy para un flujo de mensajes desde un objeto MessageFlowProxy. Para obtener un objeto ActivityLogProxy para un tipo de recurso, utilice el objeto ResourceManagerProxy. Invoque el método getActivityLog() en el objeto MessageFlowProxy o el objeto ResourceManagerProxy. Para obtener información adicional, consulte el apartado Trabajar con registros de actividades en una aplicación CMP.
Puede utilizar el objeto AdminQueueProxy para examinar los elementos de trabajo que están en curso o los que están a la espera de proceso por parte del intermediario. El código siguiente muestra cómo puede acceder a la cola:
BrokerConnectionParameters bcp =
new MQBrokerConnectionParameters("localhost", 1414, "QMGR");
BrokerProxy b = BrokerProxy.getInstance(bcp);
AdminQueueProxy l = b.getAdministrationQueue();
Hay disponible un conjunto de métodos públicos para cada objeto administrado, que las aplicaciones pueden utilizar para consultar y manipular propiedades del intermediario subyacente al que hace referencia la instancia. Para acceder a un objeto administrado por medio de su API, la aplicación debe solicitar primero un manejador para dicho objeto desde el objeto que sea propietario del mismo lógicamente.
Por ejemplo, puesto que los intermediarios poseen de forma lógica los grupos de ejecución, para conseguir un manejador para el grupo de ejecución EG1 que se ejecuta en el intermediario B1 la aplicación debe pedir al objeto BrokerProxy representado por B1 un manejador para el objeto ExecutionGroupProxy representado por EG1.
En un objeto BrokerProxy que haga referencia al intermediario B1, la aplicación puede llamar a métodos que hagan que el intermediario revele su estado de ejecución o que hagan que inicie todos sus flujos de mensajes. Puede escribir aplicaciones para realizar el seguimiento de los cambios que se realizan en los objetos del intermediario leyendo los mensajes que se conservan como objetos LogEntry.
En el ejemplo siguiente, se solicita un manejador al objeto BrokerProxy. El objeto BrokerProxy es lógicamente la raíz del árbol de objetos administrado, por lo tanto, su aplicación puede acceder a todos los demás objetos del intermediario, directa o indirectamente.
El intermediario es el propietario directo de los grupos de ejecución y, por tanto, las aplicaciones pueden llamar a un método en el objeto BrokerProxy para conseguir un manejador para los objetos ExecutionGroupProxy. De forma parecida, el grupo de ejecución contiene lógicamente el conjunto de todos los flujos de mensajes y, por tanto, la aplicación puede llamar a métodos en el objeto ExecutionGroupProxy, para poder acceder a los objetos MessageFlowProxy.
La siguiente aplicación recorre la jerarquía de objetos administrados para descubrir el estado de ejecución de un flujo de mensajes desplegado. La aplicación presupone que el flujo de mensajes MF1 se ha desplegado para EG1 en el intermediario B1; puede sustituir estos valores en el código por otros valores que sean válidos en el intermediario.
import com.ibm.broker.config.proxy.*;
public class GetMessageFlowRunState {
public static void main(String[] args) {
BrokerProxy b = null;
try {
BrokerConnectionParameters bcp =
new MQBrokerConnectionParameters(
"localhost",
1414,
"");
b = BrokerProxy.getInstance(bcp);
} catch (ConfigManagerProxyException cmpex) {
System.out.println("Error connecting: "+cmpex);
}
if (b != null) {
System.out.println("Connected to broker!");
displayMessageFlowRunState(b, "EG1", "MF1");
b.disconnect();
}
}
private static void displayMessageFlowRunState(
BrokerProxy b,
String egName,
String flowName) {
try {
ExecutionGroupProxy eg =
b.getExecutionGroupByName(egName);
if (eg != null) {
MessageFlowProxy mf =
eg.getMessageFlowByName(flowName);
if (mf != null) {
boolean isRunning = mf.isRunning();
System.out.print("Flow "+flowName+" on " +
egName+" on "+b.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 exegrp "+egName+"!");
}
} catch(ConfigManagerProxyPropertyNotInitializedException
ex) {
System.err.println("Comms problem! "+ex);
}
}
}
No es necesario que la aplicación conozca los nombres de los objetos que puede manipular. Cada objeto administrado contiene métodos para devolver conjuntos de objetos que posee de forma lógica. El siguiente ejemplo demuestra esta técnica buscando los nombres de todos los grupos de ejecución que hay dentro del intermediario.
import java.util.Enumeration;
import com.ibm.broker.config.proxy.*;
public class DisplayExecutionGroupNames {
public static void main(String[] args) {
BrokerProxy b = null;
try {
BrokerConnectionParameters bcp =
new MQBrokerConnectionParameters(
"localhost",
1414,
"");
b = BrokerProxy.getInstance(bcp);
} catch (ConfigManagerProxyException cmpex) {
System.out.println("Error connecting: "+cmpex);
}
if (b != null) {
System.out.println("Connected to broker!");
displayExecutionGroupNames(b);
b.disconnect();
}
}
private static void displayExecutionGroupNames(BrokerProxy b)
{
try {
Enumeration<ExecutionGroupProxy> allEGs = b.getExecutionGroups(null);
while (allEGs.hasMoreElements()) {
ExecutionGroupProxy thisEG =
allEGs.nextElement();
System.out.println("Found EG: "+thisEG.getName());
}
} catch(ConfigManagerProxyPropertyNotInitializedException
ex) {
System.err.println("Comms problem! "+ex);
}
}
}
El método clave es BrokerProxy.getExecutionGroups(Properties). Cuando se suministra con un argumento nulo, este método devuelve una enumeración de todos los objetos ExecutionGroupProxy del intermediario. La aplicación utiliza este método para mirar, por turnos, en cada ExecutionGroupProxy y mostrar su nombre.
Se puede utilizar el argumento BrokerProxy.getExecutionGroups(Properties) para especificar con exactitud las características de los grupos de ejecución que se han buscado. La aplicación puede utilizar este argumento para casi todos los métodos que devuelven objetos administrados y es una forma eficiente de filtrar los objetos con los que la aplicación debe trabajar.
Ejemplos de las características que se pueden utilizar para filtrar búsquedas de objetos son el estado de ejecución y la descripción corta, así como propiedades más obvias como, por ejemplo, el nombre y el UUID. Para escribir lógica para llevar a cabo búsquedas filtradas, se debe conocer la forma en que cada objeto almacena su información.
Las propiedades de cada objeto administrado se almacenan localmente dentro del objeto, utilizando una tabla hash en la que cada propiedad se representa como un tuple {key, value}. Cada clave es el nombre de un atributo (por ejemplo, name) y cada valor es el valor (por ejemplo, BROKER1).
Cada nombre de clave debe expresarse utilizando una constante desde la clase AttributeConstants (com.ibm.broker.config.proxy). Se describe un conjunto completo de claves en la documentación de Java correspondiente a la clase AttributesConstant o utilizando la función Mostrar tabla de propiedades sin procesar para este objeto en la aplicación de ejemplo Prácticas con API de CMP. Este último visualiza la lista completa de pares {key, value} para cada objeto administrado.
El argumento Properties suministrado para los métodos de visualización es un conjunto de los pares {key, value} que han de existir en cada objeto administrado en la enumeración que se devuelve. Observe el fragmento de código siguiente:
Properties p = new Properties();
p.setProperty(AttributeConstants.OBJECT_RUNSTATE_PROPERTY,
AttributeConstants.OBJECT_RUNSTATE_RUNNING);
Enumeration<MessageFlowProxy> mf = executionGroup.getMessageFlows(p);
Siempre que la variable executionGroup sea un objeto ExecutionGroupProxy válido, la enumeración devuelta contiene sólo flujos de mensajes activos (es decir, OBJECT_RUN_STATE_PROPERTY es igual a OBJECT_RUNSTATE_RUNNING).
Properties p = new Properties();
p.setProperty(AttributeConstants.NAME_PROPERTY,
"EG1");
ExecutionGroupProxy eg1 = brokerProxy.getExecutionGroup(p);
es una alternativa a la sentencia siguiente:ExecutionGroupProxy eg1 = brokerProxy.getTopicByName("EG1");
Si se añaden varios pares {key, value} a un filtro de propiedad, todas las propiedades habrán de estar presentes en el objeto hijo para que un objeto coincida. Si desea que un método realice un OR lógico, o un NOT lógico, en un filtro, deberá escribir un código de aplicación con este objetivo.
La primera vez que se crean instancias para los AdministeredObjects en una aplicación, el API de CMP pide al intermediario el conjunto de propiedades actual para dicho objeto. Esta acción se produce de forma asíncrona y, por tanto, la primera vez que se solicita una propiedad, el API de CMP se puede colocar en pausa mientras espera a que el intermediario suministre la información. Si la información no llega tras un tiempo determinado (por ejemplo, si no se está ejecutando el intermediario), se genera una excepción ConfigManagerProxyPropertyNotInitializedException. La aplicación puede controlar el tiempo máximo que espera la API de CMP utilizando el método BrokerProxy.setRetryCharacteristics().