Conteúdo


Aprimore aplicativos com base em IBM Intelligent Operations Center

Como manipular atividades

Comments

Introduction

Diferentes domínios de negócios requerem soluções diferentes para sua supervisão operacional e suas necessidades de coordenação. Por exemplo, as necessidades exatas de um importante projeto de construção diferem radicalmente das de um centro de comando de resposta emergencial, ou de um centro de operações de um estádio de esportes.

No entanto, há muitos requisitos estruturais básicos comuns entre esses domínios:

  • Os alertas vêm do campo
  • AS equipes de resposta precisam ser organizadas
  • Os procedimentos padrão de operação precisam ser suportados
  • O desempenho precisa ser controlado por meio de indicadores-chave
  • As melhorias precisam ser feitas

O IBM Intelligent Operation Center é um ambiente de software que suporta a implementação dessas soluções fornecendo uma arquitetura que oferece suporte a esses recursos. Ele fornece diversos pontos de integração por meio dos quais as organizações de entrega de soluções podem fornecer aceleradores de domínio. O Anúncio de software dos Estados Unidos 212 - 250 do IBM Intelligent Operations Center V1.5 de 3 de julho de 2012 (consulte Temas relacionados fornece mais detalhes.

Procedimentos padrão de operação

Um procedimento padrão de operação, ou SOP, é uma coleção de etapas predeterminadas projetadas para assegurar uma resposta efetiva a um incidente por meio da coordenação de pessoas, produtos, propriedades e processos. Adicionalmente, as etapas podem ser definidas como uma série de atividades. Elas podem começar com nenhum requisito de feedback ou podem requerer algum nível de feedback antes que o SOP possa seguir para a próxima etapa. O feedback específico requerido é diferente para cada atividade.

Existem alguns requisitos comuns: o sistema precisa saber quando uma atividade iniciou e quando ela terminou; as pessoas precisam ser comunicadas; novos alertas precisam ser emitidos. O Intelligent Operations Center fornece alguns desses recursos através de sua integração com o IBM Tivoli Service Request Manager.

Um caso de uso comum de implementação de SOP, não fornecido atualmente pelo Intelligent Operations Center, é quando uma atividade exige algum feedback predefinido ou um conjunto específico de dados de um operador. Normalmente, formulários são usados para suportar esse caso de uso. O website da Federal Emergency Management Agency (FEMA) fornece uma grande variedade de formulários que cobrem diferentes atividades dentro de seu escopo (consulte Temas relacionados).

Procedimentos padrão de operação no Tivoli Service Request Manager

Três artefatos do Intelligent Operations Center são requeridos para se criar um SOP no Tivoli Service Request Manager: um procedimento padrão de operação, uma matriz seletora e um plano de resposta. O SOP é o conjunto completo de etapas e atividades que constituem um procedimento. Um exemplo de um SOP no contexto de segurança pública é mostrado na Figura 1.

Possui duas etapas, uma das quais acionará um fluxo de trabalho. As duas etapas têm funções designadas a elas (é opcional designar funções e os fluxos de trabalho).

Figura 1. Exemplo de SOP no console do Tivoli Service Request Manager
Exemplo de SOP no console do Tivoli Service Request Manager
Exemplo de SOP no console do Tivoli Service Request Manager

(Veja uma versão ampliada da Figura 1.)

O aplicativo SOP Selection Matrix é usado para desenvolver uma matriz seletora de SOP que define um valor baseado na categoria, severidade, grau de certeza e urgência do evento. A matriz e o seu valor de SOP para o SOP de ameaça de bomba é 7. Podem ser vistos na a Figura 1.

Um plano de resposta é então usado para definir um link entre o valor de seletor de SOP e um SOP a ser aplicado. Consulte a a Figura 2.

Quando um evento do Intelligent Operations Center aciona a criação de um incidente do Intelligent Operations Center no Tivoli Service Request Manager, um valor de seletor de SOP do incidente do Intelligent Operations Center é escolhido com base na matriz seletora de SOP, que, por sua vez, tem como base os parâmetros do evento. Os eventos do Intelligent Operations Center acionam o Tivoli Service Request Manager para a criação de um incidente. A aplicação dos parâmetros do evento à matriz seletora para criação de um valor de seletor e correspondência desse valor ao plano de resposta do Intelligent Operations Center determinam o SOP que é designado ao evento.

Figura 2. Exemplo de plano de resposta no console do Tivoli Service Request Manager
Exemplo de plano de resposta no console do Tivoli Service Request Manager
Exemplo de plano de resposta no console do Tivoli Service Request Manager

(Veja uma versão maior da Figura 2.)

Abordagem atual do Intelligent Operations Center ao SOP

Um incidente do Intelligent Operations Center é criado no Tivoli Service Request Manager toda vez que uma mensagem Common Alerting Protocol (CAP) do tipo de alerta é recebida. Um SOP é aplicado ao incidente e o portlet de atividades no console do Intelligent Operations Center exibe todas as atividades vinculadas.

Embora os portlets fornecidos pelo Intelligent Operations Center permitam algum nível de interação com as atividades subjacentes do Tivoli Service Request Manager, a interação é limitada e as alterações não são sempre refletidas no artefato subjacente. Para editar os incidentes e as atividades do Intelligent Operations Center de modo que as alterações sejam totalmente refletidas no Tivoli Service Request Manager, um link é fornecido pelo Intelligent Operations Center para a interface com o usuário da web do Tivoli Service Request Manager. Essa interface com o usuário não segue a abordagem geral de IU do Intelligent Operations Center e pode apresentar uma navegação difícil para usuários do Intelligent Operations Center.

Formulários

Vamos discutir uma abordagem para ampliar o Intelligent Operations Center para que ele suporte a solicitação de feedback específico da atividade como um formulário. Não iremos nos concentrar no desenvolvimento do formulário ou no cenário de negócios.

O Intelligent Operations Center requer os seguintes componentes principais para suportar formulários específicos da atividade:

  • Um registro que mantenha um relacionamento entre atividades e formulários
  • Um portlet de contêiner de formulário que reaja a seleções de atividades
  • Um mecanismo de estruturas de dados persistentes para uma instância de atividade
  • Um mecanismo para terminar uma atividade

O que se segue é a nossa abordagem de implementação desses componentes.

Nossa adição à abordagem atual

O principal caso de uso mostrou como apresentar dados específicos da atividade a usuários, reunir seus dados, persistir os dados e usá-los no contexto de uma atividade subsequente. Para suportar esse caso de uso, usamos e ampliamos a funcionalidade de alguns portlets do Intelligent Operations Center existentes.

Também recuperamos dados extras do incidente usando a sua latitude e longitude para descobrir quais recursos registrados estavam localizados próximos ao incidente. Essas informações extras foram armazenadas e vinculadas a um incidente para que pudessem ser visualizadas e modificadas por diferentes atividades como parte do mesmo incidente. Fornecemos funcionalidade extra para permitir a atualização direta do status de uma atividade, que anteriormente era feita através da interface com o usuário do Tivoli Service Request Manager usando um link fornecido pelo Intelligent Operations Center.

O diagrama da A figura 3 mostra a adição da funcionalidade de atividades ao suporte atual do Intelligent Operations Center. O lado esquerdo mostra o fluxo atual do Intelligent Operations Center e o lado direito mostra a nossa adição. Os números nas chamadas do lado direito representam a sequência das etapas que nossos componentes de software implementam. Nós as descrevemos em detalhes na próxima seção deste artigo.

Figura 3. Nossa abordagem do Intelligent Operations Center atual
Nossa abordagem do Intelligent Operations Center atual
Nossa abordagem do Intelligent Operations Center atual

Exemplo de cenário que usa nossa abordagem

A inspiração da solução apresentada veio de uma necessidade de suportar alguns procedimentos padrão de operação relacionados ao gerenciamento de emergência de mau tempo. Depois que o Intelligent Operations Center reconhece um evento que é elevado a um incidente, uma sequência de atividades será iniciada de acordo com o SOP correspondente.

Na realidade, algumas atividades podem requerer que etapas manuais sejam realizadas por diversos usuários do Intelligent Operations Center, como o operador do incidente, o comandante do incidente ou outros funcionários da segurança pública.

Veja a seguir a descrição dos acontecimentos:

  • O CAP chega
  • A atividade aparece para o operador do incidente
  • O operador seleciona a atividade correspondente
  • Um formulário é exibido, mostrando os recursos próximos ao incidente que precisam ser selecionados
  • O operador seleciona os recursos
  • A atividade é marcada como concluída
  • A próxima atividade aparece
  • O comandante do incidente vê a lista de recursos selecionados pelo operador
  • O comandante autoriza os recursos
  • A atividade é marcada como concluída

Modificações no portlet de atividades

O código do portlet de atividades padrão do Intelligent Operations Center foi clonado e modificado para suportar a funcionalidade extra. Ela permite a comunicação com o servlet que recupera dados extras da atividade.

Depois que o usuário seleciona a atividade, o portlet chama o servlet com o método dojo.xhrGet usual. A URL do servlet assume dois parâmetros: ação chamada de getActivityInformation e activityID. O operadordojo.xhrGet também carrega uma função de retorno de chamada que é chamada quando os dados são retornados do servidor. Os dados retornados estão no formato JSON. Na mesma função de retorno de chamada, a resposta analisada da chamada do servlet dojo.xhrGet é publicada com o método dojo.publish usual. Posteriormente, os dados da atividade podem ser usados por outros portlets e widgets que estão na mesma página em que o portlet de atividades é colocado. No nosso exemplo, o portlet de formulário, que descreveremos mais tarde, usa esses dados.

Servlet que recupera dados extras da atividade

Quando um usuário seleciona uma atividade no portlet de atividades modificado, o portlet de atividades publica informações sobre a atividade selecionada em um tópico Dojo. As informações publicadas no tópico devem ser capazes de identificar exclusivamente a etapa de um SOP que corresponda a essa atividade. Isso é um tipo de etapa.

Usamos uma concatenação do número da etapa com o identificador (ID) do SOP como nosso tipo de atividade, por exemplo, tipo = WCONFIRMED_20 para uma atividade que corresponde à etapa 20 em um SOP chamado de "WCONFIRMED".

Essas informações não estão disponíveis no portlet da atividade, portanto, usamos um servlet para recuperar as informações dos serviços da web do Tivoli Service Request Manager, MXWO e MXINCIDENT. Usamos os serviços da web do Tivoli Service Request Manager porque o banco de dados do Intelligent Operations Center não armazena o ID do SOP em nenhuma de suas tabelas.

O servlet toma uma lista de IDs de atividades separada por vírgulas como parâmetro e retorna um array de elementos JSON em que cada elemento contém as seguintes informações sobre uma atividade:

Tablela 1. Elementos JSON retornados pelo servlet para cada atividade.
Nome de elemento Descrição
sequenceNo O número da etapa no SOP (WOSEQUENCE do serviço da web MXWO).
ticketId O ID do incidente associado à atividade. (ORIGRECORDID do serviço da web MXWO).
activityId O ID da atividade. (WONUM no serviço da web MXWO).
SoPId O identificador do SOP. (TEMPLATEID do serviço da web MXINCIDENT).
uniqueStepIdentifier O 'tipo' da atividade que é uma concatenação de SoPId e sequenceNo.

Portlet de formulários

O portlet de formulários foi projetado para realizar o desejo de coletar e associar dados com um incidente em andamento. Ao manipular uma emergência, poderá ser necessário preencher formulários para aprovação de alocação de recursos ou para registrar informações que foram recuperadas em uma atividade e que podem alimentar outra atividade em um estágio posterior.

Para realizar essa tarefa, desenvolvemos um contêiner genérico que poderia carregar diferentes widgets ou "formulários" para inserção de dados ou exibição de dados coletados anteriormente. Associamos os próprios formulários a atividades em um procedimento padrão de operação, assim, quando uma atividade específica em um procedimento padrão de operação entrasse em vigor, o contêiner exibiria o formulário correto.

Implementation

O portlet de formulários tem duas funções principais. A primeira é agir em uma atividade selecionada exibindo o formulário correto para lidar com ela. O formulário carregado terá sua própria lógica, assim, o contêiner só precisa saber qual formulário instanciar. A segunda é terminar a atividade depois de preencher o formulário.

Instanciando um formulário

Quando uma atividade é selecionada, uma mensagem é propagada na página da web usando uma publicação Dojo. O contêiner do formulário é inscrito nessa publicação e usa as informações enviadas para determinar o formulário correto a ser carregado. Uma tabela de registro no banco de dados mapeia os IDS de atividades para nomes de classe de formulário e permite uma chamada de API que retorna o nome da classe de um widget de formulário associado à atividade selecionada. Usando a reflexão, o contêiner de formulário criará uma instância do formulário desejado e passará as informações sobre a atividade.

O ciclo de vida do formulário

Cada widget de formulário é um widget do estilo Dojo, com seu próprio modelo e coleção de APIs. Usando as informações passadas para o formulário no momento da criação, o widget pode entrar em contato com várias APIs para determinar o tipo de incidente atual, local, etc. Cada formulário pode ter funcionalidade exclusiva para permitir que ele manipule diferentes atividades. Por exemplo, é possível criar um formulário para mostrar os recursos na área do incidente, permitindo que um operador selecione os recursos desejados para lidar com uma situação. Então, o formulário pode preservar as entradas dos usuários para o backend usando chamadas de API. Esses dados preservados podem ser usados em formulários adicionais do incidente ao visualizar outras atividades. Depois que o formulário atingir seu terminal desejado, ele notificará a conclusão ao contêiner.

Terminando uma atividade

Depois que o formulário é enviado, ele retorna uma mensagem ao contêiner para informá-lo de que seu ciclo de vida foi concluído. Quando o contêiner recebe essa mensagem, ele chama uma API para terminar a atividade para a qual está exibindo o formulário atual. O contêiner ficará inativo até que uma nova atividade seja selecionada com um formulário correspondente.

Servlet que atualiza o status da atividade

Esse servlet permite que o status de uma atividade seja atualizado no Tivoli Service Request Manager. Os parâmetros passados são o activityId e o novo status. O servlet usa o serviço da web MXWO para atualizar o status da atividade especificada com o novo status especificado.

Tabelas adicionais no banco de dados

As seguintes tabelas foram incluídas no banco de dados do Intelligent Operations Center.

IOC.JSON

Durante a manipulação de um incidente, um usuário pode inserir dados em um formulário como parte de uma atividade associada ao incidente. Essa tabela registra os dados inseridos por usuários nesses formulários.

Ela possui uma linha para cada formulário preenchida por um usuário. A tabela tem os seguintes campos:

Tablela 2. Campos e descrições de IOC.JSON.
Nome do campo Descrição
ID Chave primária da tabela.
INCIDENT_ID ID do incidente.
FORM_ID Identifica um formulário em um incidente.
JSON Os dados do usuário coletados com esse formulário.

Cada instância de formulário é associada a um incidente e é exclusivamente identificável no seu contexto.

IOC.FORMID

Isso associa um tipo de formulário a uma etapa de um SIP, que é um tipo de atividade. O portlet de formulários usa essa tabela para determinar qual formulário será exibido com base em um tipo de atividade. Vimos anteriormente que o tipo de uma atividade é a concatenação do identificador do SOP e o número de sequência. A tabela tem os seguintes campos:

Tablela 3. Descrições dos campos de IOC.FORMID.
Campo Descrição
ID Chave primária da tabela.
SoP_STEP O operadortipo de etapa da atividade que é uma concatenação do SoPId e sequenceNo.
FORM_ID Identifica um tipo de formulário.

Conclusão

O IBM Intelligent Operation Center é uma plataforma de software que fornece diversos pontos de integração por meio dos quais as organizações de entrega de soluções podem fornecer aceleradores de domínio. Ilustramos uma maneira possível para que os arquitetos e desenvolvedores de software possam solucionar problemas e implementar uma solução para as atividades que suportam procedimentos padrão de operação. Baseado em produtos IBM, o Intelligent Operations Center é sólido e flexível o suficiente para incluir as implementações de que os clientes precisam.


Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Segmentos de mercado
ArticleID=828876
ArticleTitle=Aprimore aplicativos com base em IBM Intelligent Operations Center
publish-date=08312012