WebSphere Message Broker, Versión 8.0.0.5 Sistemas operativos: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte la información sobre la última versión del producto en IBM Integration Bus, Versión 9.0

Navegación por intermediarios y recursos de intermediarios en una aplicación del CMP

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.

Cada recurso que el intermediario puede controlar está representado como un único objeto en el API de CMP. Una aplicación puede solicitar información sobre el estado y los objetos siguientes:
  • Intermediarios
  • Grupos de ejecución
  • flujos de mensajes desplegados
  • Registro de administración
  • Registros de actividades
  • Almacenes de captura de datos

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.

Cada objeto administrado es una instancia de una clase Java™ que describe el tipo de objeto subyacente en el intermediario. Las clases principales de Java se muestran en la siguiente tabla.
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.
Cada objeto administrado describe un único objeto que el intermediario puede controlar. Por ejemplo, cada grupo de ejecución de un intermediario tiene una instancia ExecutionGroupProxy para lo representa dentro de la aplicación.

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 jerarquía completa de estas relaciones de acceso se muestra en el diagrama siguiente:
El diagrama se describe en el texto que lo rodea.
Cada objeto con un asterisco detrás del nombre hereda de la clase DeployedObjectGroupProxy y, por lo tanto, tiene más objetos hijo, como se muestra en el siguiente diagrama.
El diagrama se describe en el texto que lo rodea.

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);
    }
  }
}
El método displayMessageFlowRunState() realiza la mayoría de los trabajos. Este método toma el manejador válido BrokerProxy, obtenido anteriormente, y descubre el estado de ejecución del flujo de mensajes del modo siguiente:
  1. La instancia BrokerProxy se utiliza para obtener un manejador para el objeto ExecutionGroupProxy, con el nombre descrito por la serie egName.
  2. Si se devuelve un grupo de ejecución válido, se utiliza la instancia ExecutionGroupProxy para conseguir un manejador para el objeto MessageFlowProxy con el nombre descrito por la serie de caracteres flowName.
  3. Si se devuelve un flujo de mensajes válido, se consulta el estado de ejecución del objeto MessageFlowProxy y el resultado se visualiza.

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).

Cuando se aplica el filtrado de propiedades a un método que devuelve un solo objeto administrado en vez de una enumeración de objetos, sólo se devuelve el primer resultado (que no es determinante si puede aplicarse más de una coincidencia. Por lo tanto, el código siguiente:
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().

Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última actualización:
        
        Última actualización: 2015-02-28 17:01:14


Tema de tareaTema de tarea | Versión 8.0.0.5 | be43040_