Aprimore aplicativos com base em IBM Intelligent Operations Center

Como manipular atividades

O IBM Intelligent Operations Center suporta procedimentos padrão de operação. Quando um incidente ocorre, uma atividade é criada para cada etapa definida em um procedimento. Este artigo descreve como os arquitetos e desenvolvedores podem modificar artefatos existentes e desenvolver novos, para apresentar e coletar dados de um usuário como parte de uma atividade, e, então, registrá-los e propagá-los para uma atividade posterior como parte do mesmo incidente.

Aidan Clarke, IT Architect, Os compiladores IBM

Photo of Aidan ClarkeAidan é IT Architect no IBM Software Group. Ele tem mais de 30 anos de experiência no segmento de mercado de TI, principalmente em funções de desenvolvimento de software. Atualmente, ele participa da organização de Industry Solutions, trabalhando com o portfólio de produtos do IBM i2 Intelligence Analysis.



Brian Daly, Software Developer, Os compiladores IBM

Photo of Brian DalyBrian Daly é desenvolvedor de software e membro do grupo do IBM Industry Solutions Development no Technology Campus em Mulhuddart, Irlanda. Ele desenvolve novo conteúdo que estende as ofertas da Industry Solutions.



Artur Grzenkowicz, Senior Java Designer, Os compiladores IBM

Photo of Artur GrzenkowiczArtur Grzenkowicz é designer senior de Java e membro do grupo do IBM Industry Solutions Development no IBM Technology Campus em Mulhuddart, Irlanda. Atualmente, ele trabalha com o portfólio de produtos do IBM i2 Intelligence Analysis.



Kevin Keating, Software Engineer, Os compiladores IBM

Photo of Kevin KeatingKevin Keating é engenheiro de software e membro do IBM Software Group, Industry Products. Ele desenvolveu demonstrações de segurança pública usando o Intelligent Operations Center.



Vincent Kelly, Development Manager, Os compiladores IBM

Photo of Vincent KellyVincent Kelly é Gerente de desenvolvimento e trabalha no Laboratório da Irlanda com o Industry Solutions Group. Atualmente, ele está concentrado nos produtos do i2, recentemente adquiridos na área de segurança pública. Antes disso, ele desempenhou várias funções gerenciais em Desenvolvimento e Teste de IM e Lotus.



Jamie O'Leary, Software Engineer, Os compiladores IBM

Photo of Jamie O'LearyDepois de um longo período trabalhando na família de produtos Lotus Connections, desenvolvendo front-ends da web e ferramentas de procura social no Java 2 Platform, Enterprise Edition (J2EE), Jamie foi transferido para a divisão de Industry Solutions, onde desenvolveu integração backend entre aplicativos de plataforma nativa e serviços J2EE. Atualmente, Jamie desenvolve extensões de protótipo para o Intelligent Operations Center.



31/Ago/2012

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

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

(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

(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

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

Aprender

Obter produtos e tecnologias

  • Software de avaliação: descubra mais softwares de avaliação. Faça o download de uma versão de teste, trabalhe com o produto em um ambiente de sandbox online ou acesse-o na nuvem.
  • IBM Smarter City Solutions na Nuvem: O IBM Intelligent Operations Center on IBM SmartCloud oferece um serviço de assinatura direto baseado em usuário a um preço único, que inclui todos os custos, inclusive hardware, software, manutenção, suporte e networking.

Discutir

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=Segmentos de mercado
ArticleID=828876
ArticleTitle=Aprimore aplicativos com base em IBM Intelligent Operations Center
publish-date=08312012