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