BPM Voices: Joachim Frank: Bastidores do processamento de eventos do WebSphere Business Monitor

Confuso sobre como o processamento de eventos funciona no WebSphere ® Business Monitor? O que são expressões de filtro, predicados de correlação e contextos de monitoramento e como eles cooperam para garantir que os eventos certos atualizem as métricas certas, de forma que seus negócios reajam rapidamente? Neste artigo, Joachim Frank abre as cortinas para mostrar o que está acontecendo nos bastidores e como tudo acontece para garantir que seus negócios obtenham as informações que precisam, onde e quando precisam. Este conteúdo é parte do IBM Business Process Management Journal.

Joachim (Jim) H. Frank, Senior Software Architect, IBM

Joachim (Jim) Frank photoJoachim (Jim) H. Frank é um Arquiteto de Software Senior da IBM. Ele foi líder técnico de design e desenvolvimento do WebSphere Business Modeler e do WebSphere Business Monitor. É possível entrar em contato com Jim pelo jhfrank@us.ibm.com.


nível de autor Contribuidor do
        developerWorks

27/Out/2010 (Primeira publicação 27/Out/2010)

Às vezes, os usuários do WebSphere Business Monitor (Monitor) nos dizem que o algoritmo de processamento de eventos do programa é difícil de compreender. Em sua maioria, eles parecem confusos com o objetivo das expressões de filtro e dos predicados de correlação, pelas várias opções de entrega de evento e pela maneira como as atualizações são conduzidas em um contexto de monitoramento.

Neste artigo, ofereceremos um olhar sobre os bastidores desses conceitos. Não trataremos de pontos mais complexos do modelo de programação do Monitor, como, acionadores, cronômetros e contextos de monitoramento aninhados, mas iremos nos concentrar simplesmente nos fundamentos básicos do processamento de eventos.

Também forneceremos uma apresentação de slides para download que mostra, através de uma sequência simples, o caminho que um evento faz quando é processado pelo Monitor.

Conceitos de processamento de eventos

No núcleo do Monitor estão os objetos do observador. Um objeto do observador é criado para cada entidade que você deseja monitorar. As entidades monitoradas podem ser tangíveis, como um dispositivo, servidor ou veículo e podem ser abstratas como uma execução de processo, uma entrega de pacote ou um ciclo de vendas. O objeto do observador acompanha os eventos que relatam quaisquer alterações de estado na entidade monitorada e atualiza seu próprio estado baseado nas informações desses eventos.

Um objeto de observador usado pelo Monitor é chamado de um contexto de monitoramento ou MC porque as informações que ele coleta fornecem o contexto para monitorar uma entidade observada. Os campos de dados em um MC são chamados de métricas porque são tipicamente representados por medidas das informações sobre essa entidade que são relevantes para os negócios.

Por exemplo, vamos dizer que uma empresa de limusines queira monitorar sua frota de carros. É recomendável que a empresa use o Monitor para criar um contexto de monitoramento para cada viagem, quando iniciada. Esse contexto pode ser atualizado com informações sobre a viagem, por exemplo, o horário de entrada do passageiro, engarrafamentos e o horário de saída do passageiro, baseado em eventos recebidos das limusines na estrada. Ele pode conter métricas para a duração da viagem, atrasos ao buscar e deixar o passageiro, um índice de satisfação do cliente derivado dessas métricas, velocidade média etc.

Para estender os recursos de monitoramento, a empresa de limusines pode definir MCs para seus motoristas, com métricas de pontualidade, viagens por mês, média de satisfação do cliente etc. A empresa poderia defini-las também para os carros, com métricas como quilometragem por uso de combustível, próximo serviço planejado e mais. Esses MCs seriam objetos do observador para os motoristas e os veículos.

As métricas e inscrições de eventos de um MC são definidas pelas definições de contexto de monitoramento. Assim como um MC é um objeto de objetivo especial, sua definição é uma classe de objetivo especial que define a estrutura e o comportamento de suas instâncias.

Agora que você entende os conceitos básicos e a terminologia, vamos ver como tudo isso funciona.


Processamento de eventos por etapa

Existem três etapas para processar um evento:

  1. Filtragem - Que tipo de evento é esse?
  2. Correlação - Quais MCs estão interessados nesse evento?
  3. Atualização de MC - Quais métricas são atualizadas pelo evento e como?

Cada MC acompanha somente os tipos de eventos que pertencem à entidade que monitoram.

No exemplo da empresa de limusines, os MCs de viagem acompanhavam eventos que relatam despacho de viagens, entrada e saída de passageiros, trânsito carregado e acidentes de carro. A definição do MC de viagem teria cinco inscrições de eventos, uma para cada evento.

Uma inscrição de evento contém um filtro, que é uma expressão booleana que avalia como verdadeiros os eventos que acompanha e como falsos os eventos restantes. A única regra para definir um filtro é que ele precisa permitir que os eventos do tipo desejado passem e bloqueiem todos os outros. Por motivos de desempenho, os filtros devem ser o menor possível, em outras palavras, eles devem ser apenas complexos o suficiente para identificar um tipo de evento entre a variedade de eventos esperados.

Por exemplo, se um evento contém um atributo xsi:type que identifica sua carga útil, e diferentes tipos de eventos têm diferentes tipos, pode ser necessário apenas testar esse atributo. Mas, se um tipo único genérico de evento é usado para relatar as ocorrências de diferentes tipos (o que pode ser determinado apenas pelo exame do conteúdo do evento), o filtro precisa testar os campos adicionais.

No exemplo da limusine, se os carros sempre relataram o status da viagem usando um evento cujo tipo de carga útil é limo:TripStatus (em que limo representa um namespace) eventos de despacho, entrada e saída são distinguidos através de um campo event nature, o campo event nature terá de ser testado junto com o atributo xsi:type para determinar o tipo dos eventos que foram recebidos.

Depois de um evento ter passado por um filtro de inscrição, seu predicado de correlação é avaliado para verificar se há um MC. Os predicados de correlação tipicamente comparam um valor da chave no evento, como um identificador exclusivo de viagem, com uma métrica que contenha a mesma chave. Se um MC correspondente for localizado, esse MC pode receber um evento para processamento adicional. Se não, um novo contexto de MC pode ser criado.

Mas e se isso não for o desejado? Digamos, por exemplo, que um evento de entrada de passageiro chega e nenhum MC correspondente é localizado. Neste caso, não é recomendável a criação de um novo MC, mas, em vez disso, a criação de uma condição de erro que indique que o evento de "carro despachado" (que deveria ter ocorrido primeiro e criado o MC) não foi recebido. Da mesma maneira, se um evento de "carro despachado" chegar e um MC para a mesma viagem for localizado, isso seria inesperado e indicaria um erro. Novamente, seria recomendável a criação de um erro e não a entrega de um evento de despacho duplicado no contexto já existente.

Como se pode ver, é importante ser capaz de controlar o algoritmo de correlação de evento. É possível fazer isso definindo as configurações de entrega de evento. Cada inscrição de evento tem três configurações, que cobrem os casos de nenhum, um e vários MCs preenchendo o predicado de correlação. A tabela a seguir mostra essas configurações.

Configurações de entrega de evento
Nenhuma correspondênciaUma correspondênciaMúltiplas correspondências
Ignorar Ignorar Ignorar
Tratar como erro Tratar como erro Tratar como erro
Criar novo MC Entregar para o (único) MC correspondente Entregar para qualquer MC correspondente
Retroceder todas as mudanças e tentar processar este evento novamente mais tarde Entregar todos os MCs correspondentes

Depois do processamento de correlação ter identificado MCs para a entrega de eventos, o estado do processamento é atualizado de acordo com o conteúdo do evento.

Para entender como isso funciona, pense em um MC como uma planilha, cujas células são métricas. Para cada métrica, a definição do MC estabelece um ou mais mapas que configuram seus valores. Os mapas são como fórmulas de planilhas. Um mapa pode depender de uma inscrição de evento.

Quando um evento é entregue para um MC, todos os mapas que dependem do recebimento da inscrição são executados e suas métricas de destino são atualizadas com os resultados. As atualizações adicionais são, então, processadas em cascata, como em uma planilha: mapas que dependem das métricas atualizadas atualizam seus destinos e assim por diante. A cascata sempre terminará porque o gráfico de dependência definido pelos mapas não pode ter ciclos. Por exemplo, se a métrica B depende da métrica A, então a métrica A não pode depende da métrica B.


Veja a apresentação de slides

Se o ensaio que fizemos aqui parecer sem graça ou se desejar simplesmente obter uma revisão visual e interessante do que aprendeu, dê uma olhada na apresentação de slides "Processamento de Eventos" fornecida com este artigo. Ela mostra as etapas do processo que descrevemos neste artigo usando gráficos simples e uma sequência fácil de entender.


Resumo

Espero que este artigo e os slides que o acompanham ajudem a compreender melhor os conceitos por trás do processamento de eventos no WebSphere Business Monitor.


Download

DescriçãoNomeTamanho
Slide show demoepdemo.pdf299KB

Recursos

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere, Lotus
ArticleID=556647
ArticleTitle=BPM Voices: Joachim Frank: Bastidores do processamento de eventos do WebSphere Business Monitor
publish-date=10272010