bam - quick development overview - energia cria … · os restantes sistemas têm regras já...

BAM - Quick Development Overview Business Event e RTView

v2.0

DSI/DIS – Arquitetura Aplicacional Arquitectura Transversal

2 © 2013 Galp Energia SA. Direitos Reservados

Direitos Autorais

Confidencialidade

Documento inédito com todos os direitos reservados. A inscrição “© 2011 Galp Energia SA. Direitos Reservados” foi atribuída a este documento para, em caso de publicação acidental, proteger os direitos da Galp Energia SA. Nenhuma parte deste documento pode ser reproduzida sob qualquer forma, inclusive fotocópia ou transmissão electrónica para qualquer computador, sem o prévio consentimento escrito da Galp Energia SA.

As informações contidas neste documento são confidenciais e da propriedade exclusiva da Galp Energia SA, não podendo ser utilizadas, divulgadas, ou cedidas a terceiras partes, sem o prévio consentimento escrito da Galp Energia SA.

Controlo


Introdução

O presente documento tem como objectivo indicar os desenvolvimentos necessários para que se consiga integrar com a plataforma BAM existente na GALP.


Requisitos

Para que seja possivel intergrar com o BAM, é necessario o seguinte:

•Todos os serviços do processo a monitorizar esteja registado no catálogo de serviços.

•Caso seja um serviço extra-tibco, este deverá ser capaz de utilizar o Log Unificado.

•Conhecimentos de TIBCO Business Evens para desenvolver as maquinas de estados

•Conhecimentos de TIBCO Rtview para elaboração dos ecras a disponibilizar ao negócio.

•Caso seja necessário o desenvolvimento de novas sondas de sistemas, é necessário conhecimentos de TIBCO Hawk.


Breves regras da Arquitectura


Arquitectura - Serviços

Todos os serviços existentes na GALP terão de ser univocamente identificados através da chave composta:

• Dominio

• Tipo

• Serviço

• Acção

Informação sobre como estes campos deverão ser preenchidos deverá ser vista no documento de Arquitectura Geral da GALP.


Arquitectura – Log Unificado

A utilização do Log Unificado deverá ser obrigatóriamente realizada através das regras existentes na GALP Energia.

Os serviços desenvolvidos em TIBCO estão automáticamente habilitados para a utilização do Log Unificado.

Os restantes sistemas têm regras já definidas pela arquitectura. Para mais informações sobre como utilizar o log unficado recomenda-se a leitura do documento sobre o mesmo.


Arquitectura – Processo de negócio

É considerado um processo de negócio a invocação de um ou mais serviços, por uma ordem pré-definida, com o objectivo de realizar uma necessidade da empresa.

Para que um processo de negócio seja passível de integrar no BAM, todos os serviços que fazem parte do processo de negócio, deverão obrigatóriamente enviar a chave única (primary key) que identifica cada evento do processo

•Ex: na monitorização de um processo de facturas, podemos considerar o número da factura como a chave de correlação (primary key).

•Assim sendo, todos os serviços do processo terão de obrigatóriamente ser capazes de enviar como chave de negócio o número da factura.


Desenvolvimento


Desenvolvimento: Serviços

A plataforma BAM é “alimentada” pelo resultado da invocação dos serviços existentes na GALP, ou seja, sempre que um serviço é invocado este deverá enviar um evento , através do log unificado, com todos os dados necessários à sua correlação.

Para que um serviço seja passivel de ser utilizado num processo de negócio, a chave primária de correlação (primary key), tem de ser correctamente identificada durante o desenvolvimento.

•Para serviços novos (não existentes) o trabalho de desenvolvimento adicional é desprezável caso o sistema onde o serviço se encontre já utilize o Log Unificado.

•Para serviços já existentes, o projecto terá que validar se as chaves publicadas são suficientes para identificar os eventos únivocamente ao longo de todo o processo.

• Se forem suficientes então não existe trabalho adicional a nivel de desenvolvimento de serviços

• Caso não sejam então será necessário alterar o desenvolvimento, adicionando as chaves em falta.


Desenvolvimento: Serviços – Chaves de negócio

Actualmente, somente as chaves de negócio enviadas no 1º step é que são passiveis de ser utilizadas como regras na maquina de estados.

O 1º step também tem acesso ao Header de mensageria tecnica interno da GALP (A informação disponibilizada no header, está disponivel no documento de arquitectura)

Esta funcionalidade deverá ser tida em conta durante a análise.

Ex: caso um processo possa ter varios destinos, o 1º serviço do processo (1º step) terá de ser capaz de enviar todas a informação necessária para que se possa ter acesso a essa informação durante a execução da maquina de estados.


Desenvolvimento: Business Events

Devido à existencia da framework BAM de desenvolvimento, a criação de uma maquina de estados no Business Events limita-se a identificar quais as transições que são efectuadas e porque ordem

A figura acima, apresenta uma maquina de estados real.

O desenvolvimento normalmente limita-se pela inserção da ordem de invocação dos serviços nas transições da maquina de estados.

Contudo, certos processos poderão ser mais complexos (identificar múltiplos destinos para a mesma maquina, regras especiais, etc). nestes casos recomenda-se uma primeira reunião com a equipa de arquitectura para ajudar a estimar o esforço de desenvolvimento dos mesmos.


Desenvolvimento: RTview

• Um template de fundo que poderá ser utilizado em todos os processos a serem desenvolvidos.

• Uma caixa para apresentação do estado da tarefa a monitorizar ( 1 ou mais serviços, aplicações, etc.)

•Uma caixa para apresentação do estado da tarefa em modo gráfico

A existencia de uma framework RTView facilita o desenvolvimento dos ecrãs a apresentar para o negócio, COM:

1

2

3

1

2

3

O desenvolvimento limita-se a desenhar um processo percetivel para o negócio e indicar que serviço(s) deverá ficar em cada caixa


Desenvolvimento: Rtview Exemplo

A figura à direita apresenta o ecrã rtview correspondente à maquina de estados da factura apresentada neste documento.

Na figura verifica-se que, embora a maquina de estados tenha 5 estados distintos (5 serviços que identificam um processo), a informação dos serviços está estão agrupada em somente 3 sistemas

•SAP-PI, TIBCO e Business Connect (unicas caixas com valores)

As restantes caixas identificam os sistemas onde o processo se conecta, mesmo sabendo que estes não enviam eventos.

O objectivo é permitir que um utilizador de negócio entenda mais facilmente o processo completo.


Definição de Alertas e SLA’s de Processos

Para a definição de SLA’s de Processos (e também de serviços) bem como para a definição de alertas é somente necessário efetuar a sua definição em conjunto com os negócios, equipas de manutenção e DSI e efetuar a parametrização dos dados na ferramenta disponibilizada para o efeito.

Assim, não há necessidade de qualquer programação.

bam - quick development overview - energia cria … · os restantes sistemas têm regras já...

Documents