WebSphere Message Broker, Versão 8.0.0.5 Sistemas operacionais: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte as informações sobre a versão mais recente do produto em IBM Integration Bus, Versão 9.0

Navegando Brokers e Recursos do Broker em um Aplicativo CMP

Explore o status e os atributos do broker ao qual seu aplicativo CMP está conectado e descubra informações sobre seus recursos.

Antes de começar

Antes de iniciar esta etapa, é necessário ter concluído Conectando-se a um Broker a partir de um Aplicativo CMP.

Cada recurso que o broker pode controlar é representado como um único objeto no CMP API. Um aplicativo pode solicitar o status e outras informações sobre os seguintes objetos:
  • Brokers
  • Grupos de execução
  • fluxos de mensagens
  • Log de administração
  • Log de Atividades
  • Armazenamentos de captura de dados

O CMP também trata dos conjuntos de mensagens implementados; estes recursos são manipulados como atributos de grupos de execução implementados.

Coletivamente conhecidos como objetos administrados, esses objetos fornecem a maioria da interface para o broker e é, portanto, fundamental para um entendimento do CMP.

Cada objeto administrado é uma instância de uma classe Java™ que descreve o tipo de objeto subjacente no broker. As classes Java principais são mostradas na tabela a seguir.
Classe Java Função da Classe
BrokerProxy Descreve brokers.
ExecutionGroupProxy Descreve grupos de execução.
MessageFlowProxy Descreve fluxos de mensagens que já foram implementados em grupos de execução; não descreve fluxos de mensagens no Perspectiva do Desenvolvimento de Aplicativos do Intermediário do WebSphere Message Broker Toolkit.
LogProxy Representa o log da atividade administrativa recente no broker, para todos os usuários.
ActivityLogProxy Representa um log do fluxo de mensagens recentes e atividade do recurso.
DataCaptureProxy Representa dados que são mantidos em um armazenamento de dados do broker. Os dados recuperados são contidos em objetos DataCaptureEntry.
Cada objeto administrado descreve um único objeto que pode ser controlado pelo broker. Por exemplo, cada grupo de execução em um broker possui uma instância de ExecutionGroupProxy que o representa no aplicativo.

O objeto LogProxy inclui mensagens, criadas como objetos LogEntry, que registram mudanças recentes feitas nos objetos administrados. Estas mensagens incluem as seguintes informações:

O objeto ActivityLogProxy inclui mensagens, criadas como objetos ActivityLogEntry, que registram atividades recentes de alto nível, envolvendo fluxos de mensagens e suas interações com recursos externos. Para obter mais informações sobre essas mensagens, consulte Usando Logs de Atividades. Log de Atividades são gerados para fluxos de mensagens e para tipos de recursos específicos.

Você pode recuperar um objeto ActivityLogProxy para um fluxo de mensagens de um objeto MessageFlowProxy. Para obter um objeto ActivityLogProxy para um tipo de recurso, use o objeto ResourceManagerProxy. Chame o método getActivityLog() no objeto MessageFlowProxy ou o objeto ResourceManagerProxy. Veja informações adicionais na publicação Trabalhando com Log de Atividade em um Aplicativo CMP.

É possível usar o objeto AdminQueueProxy para examinar que itens de trabalho estão em andamento ou estão aguardando para processamento pelo broker. O código a seguir mostra como é possível acessar a fila:

BrokerConnectionParameters bcp =
		new MQBrokerConnectionParameters("localhost", 1414, "QMGR");
BrokerProxy b = BrokerProxy.getInstance(bcp);
AdminQueueProxy l = b.getAdministrationQueue();

Um conjunto de métodos públicos está disponível para cada objeto administrado, que aplicativos podem usar para consultar e manipular propriedades do broker subjacente ao qual a instância faz referência. Para acessar um objeto administrado através de sua API, seu aplicativo deve primeiro solicitar um identificador para esse objeto a partir do objeto que o possui logicamente.

Por exemplo, como os brokers possuem grupos de execução logicamente, para obter um identificador para o grupo de execução EG1 em execução no broker B1, o aplicativo deve solicitar ao objeto BrokerProxy representado por B1 um identificador para o objeto ExecutionGroupProxy representado por EG1.

Em um objeto BrokerProxy que se refere ao broker B1, o aplicativo pode chamar métodos que fazem o broker revelar seu estado de execução ou fazem com que ele inicie todos os seus fluxos de mensagens. É possível gravar aplicativos para rastrear as alterações que são feitas nos objetos do broker lendo as mensagens mantidas como objetos LogEntry.

No exemplo a seguir, um identificador é solicitado para o objeto BrokerProxy. O BrokerProxy é logicamente a raiz da árvore de objetos administrados, portanto, seu aplicativo pode acessar todos os outros objetos no broker direta ou indiretamente.

O broker possui diretamente os grupos de execução, portanto, os aplicativos podem chamar um método no objeto BrokerProxy para obter um identificador para os objetos ExecutionGroupProxy. De forma semelhante, o grupo de execução contém logicamente o conjunto de todos os fluxos de mensagens, portanto, o aplicativo pode chamar métodos no objeto ExecutionGroupProxy para acessar os objetos MessageFlowProxy.

A hierarquia completa destes relacionamentos de acessar é mostrada no diagrama a seguir.
O diagrama é descrito no texto circundante.
Cada objeto com um asterisco depois de seu nome é herdado da classe DeployedObjectGroupProxy e, portanto, possui objetos-filhos adicionais, conforme mostrado no diagrama a seguir.
O diagrama é descrito no texto circundante.

O aplicativo a seguir atravessa a hierarquia de objetos administrados para descobrir o estado de execução de um fluxo de mensagens implementado. O aplicativo assume que fluxo de mensagens MF1 é implementado em EG1 no broker B1; é possível substituir estes valores no código por outros valores que sejam válidos no broker.

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("Erro conectando: "+cmpex);
    }
        
    if (b != null) {
      System.out.println("Conectado ao 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("Fluxo"+flowName+" em " + 
            egName+" on "+b.getName()+" está em ");

          if (isRunning) {
            System.out.println("execução");
          } else {
            System.out.println("interrompido");
          }
        } else {
          System.err.println("Nenhum fluxo "+flowName);
        }
      } else {
        System.err.println("Nenhum exegrp "+egName+"!");
      }
        
    } catch(ConfigManagerProxyPropertyNotInitializedException
                                                      ex) {
      System.err.println("Comms problem! "+ex);
    }
  }
}
O método displayMessageFlowRunState() executa a maior parte do trabalho. Este método usa o identificador BrokerProxy válido obtido anteriormente e descobre o estado de execução do fluxo de mensagens da seguinte maneira:
  1. A instância BrokerProxy é usada para obter um identificador para o objeto ExecutionGroupProxy com o nome descrito pela cadeia egName
  2. Se um grupo de execução válido for retornado, a instância ExecutionGroupProxy é usada para obter manipulação para o objeto MessageFlowProxy com o nome descrito pela cadeia flowName.
  3. Se um fluxo de mensagens válido for retornado, o estado de execução do objeto MessageFlowProxy será consultado e o resultado será exibido.

O aplicativo não tem de conhecer os nomes dos objetos que ele pode manipular. Cada objeto administrado contém métodos para retornar conjuntos de objetos que ele possui logicamente. O exemplo a seguir demonstra esta técnica consultando os nomes de todos os grupos de execução dentro do broker.

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("Erro conectando: "+cmpex);
    }
        
    if (b != null) {
      System.out.println("Conectado ao 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("Localizado EG: "+thisEG.getName());
      }
    } catch(ConfigManagerProxyPropertyNotInitializedException
                                                      ex) {
        System.err.println("Comms problem! "+ex);
    }
  }
}

O método-chave é BrokerProxy.getExecutionGroups(Properties). Quando fornecido com um argumento nulo, este método retorna uma enumeração de todos os objetos ExecutionGroupProxy no broker. O aplicativo usa este método para consultar cada ExecutionGroupProxy por vez e exibir seu nome.

O argumento Properties do método BrokerProxy.getExecutionGroups(Properties) pode ser usado para especificar exatamente as características dos grupos de execução buscados. O aplicativo pode usar esse argumento para quase todos os métodos que retornam objetos administrados e é uma maneira poderosa de filtrar esses objetos com os quais o aplicativo precisa trabalhar.

Exemplos das características que podem ser usadas para filtrar consultas de objetos são o estado de execução e a descrição abreviada, além de propriedades mais óbvias como o nome e UUID. Para gravar a lógica para atingir as consultas filtradas, você deve entender como cada objeto administrado armazena suas informações.

As propriedades de cada objeto administrado são armazenadas localmente dentro do objeto usando uma tabela hash, em que cada propriedade é representada como uma tupla {chave, valor}. Cada chave é o nome de um atributo (por exemplo, nome) e cada valor é o valor (por exemplo, BROKER1).

Cada nome da chave deve ser expresso usando uma constante da classe AttributeConstants (com.ibm.broker.config.proxy). Um conjunto completo de chaves e possíveis valores para cada objeto administrado é descrito na documentação Java para a classe AttributesConstant ou usando a função Mostrar Tabela de Propriedade Bruta para este Objeto no aplicativo de amostra do Exercitador de API do CMP. O último exibe a lista completa de pares {chave, valor} para cada objeto administrado.

O argumento Propriedades que é fornecido para os métodos de consulta é um conjunto dos pares {chave, valor} que devem existir em cada objeto administrado na enumeração retornada. Considere o seguinte fragmento de código:

Properties p = new Properties();
        
p.setProperty(AttributeConstants.OBJECT_RUNSTATE_PROPERTY,
              AttributeConstants.OBJECT_RUNSTATE_RUNNING);

Enumeration<MessageFlowProxy> mf = executionGroup.getMessageFlows(p);

Desde que a variável executionGroup seja um objeto ExecutionGroupProxy válido, a enumeração retornada conterá somente fluxos de mensagens ativos (ou seja, OBJECT_RUN_STATE_PROPERTY igual a OBJECT_RUNSTATE_RUNNING).

Quando a filtragem de propriedade é aplicada a um método que retorna um único objeto administrado ao invés de uma enumeração de objetos, apenas o primeiro resultado é retornado (o que não é determinante se mais de uma correspondência se aplicar). Portanto, o código a seguir:
Properties p = new Properties();
p.setProperty(AttributeConstants.NAME_PROPERTY,
              "EG1");
ExecutionGroupProxy eg1 = brokerProxy.getExecutionGroup(p);
é uma alternativa para a seguinte instrução:
ExecutionGroupProxy eg1 = brokerProxy.getTopicByName("EG1");

Se múltiplos pares {chave, valor} forem incluídos em um filtro de propriedade, todas as propriedades deverão estar presentes no objeto-filho para um objeto corresponder. Se você desejar um método para executar uma lógica OR, ou uma lógica NOT, em um filtro, deverá gravar o código do aplicativo específico para este propósito.

Quando AdministeredObjects são instanciados pela primeira vez em um aplicativo, o CMP API solicita ao broker o conjunto atual de propriedades para esse objeto. Esta ação ocorre de forma assíncrona, portanto, na primeira vez em que uma propriedade for solicitada, o CMP API poderá pausar enquanto espera que as informações sejam fornecidas pelo broker. Se as informações não chegarem dentro de um certo tempo (por exemplo, se o broker não estiver executando), será emitido um ConfigManagerProxyPropertyNotInitializedException. Seu aplicativo pode controlar o tempo máximo que o CMP API aguarda usando o método BrokerProxy.setRetryCharacteristics().

Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

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

        
        Última atualização:
        
        Última atualização: 2015-02-28 18:31:16


Tópico de TarefaTópico de Tarefa | Versão 8.0.0.5 | be43040_