Como realizar projetos de BAM?

No artigo BAM – Uma visão Geral, que publicamos recentemente aqui no blog da iProcess, passamos uma visão geral do BAM (Business Activity Monitoring), onde demonstramos as características, arquitetura comum e principais cenários de uso deste tipo de ferramenta.

Talvez agora o assunto seja do seu interesse, e você acha que a sua empresa pode se beneficiar da utilização desta ferramenta.

Mas neste caso, por onde começar?

A realização de um projeto de implantação de BAM pode ser caracterizada, usualmente, pela execução das seguintes grandes etapas:

1. Definição da ferramenta de BAM a utilizar: conforme citamos no artigo anterior, existem ferramentas de BAM que fazem parte de suítes de BPMS, e outras que são produtos independentes. Dependendo do tipo de ferramenta de BAM escolhida, a integração com sistemas externos poderá ter maior ou menor flexibilidade. No caso de uma ferramenta de BAM que faz parte de uma suíte BPMS, é necessário avaliar se é possível integrar a mesma com outros sistemas, pois em alguns casos só é possível a exibição de dados relacionados apenas aos processos sendo automatizados na própria suite.

Ressaltamos que a escolha do BAM não deveria ser uma escolha de um projeto, ou seja, a empresa não vai adotar uma nova ferramenta de BAM a cada processo implantado. Deve ser uma decisão corporativa e que permanecerá a longo prazo, então a escolha do BAM deve ser cuidadosa, tendo atenção a questões como aderência às necessidades de processos de toda organização (e não apenas de uma área) e que possua interface de comunicação com o BPMS utilizado para gerenciar a execução de processos automatizados.

2. Definição dos indicadores e gráficos de monitoramento necessários: é necessário discutir funcionalmente com os usuários de negócio quais são os indicadores e dashboards de monitoramento desejados, regras de segurança e acesso as informações (ex: num dashboard que será disponibilizado para todas as unidades, pode se definir que os usuários só poderão visualizar informações relativas à sua própria unidade), bem como alertas e ações sobre os alertas (se for o caso). Usualmente, esta é uma ação que está alinhada com a própria fase de modelagem, análise e melhoria de processos, onde estão sendo discutidos os processos e seus indicadores de desempenho. Assim, deste trabalho normalmente são extraídos requisitos de BAM, que permitirão  aos usuários realizar o acompanhamento dos novos processos. É importante ressaltar, no entanto, que um projeto de BAM pode ser uma ação mais “isolada” e até independente de outras iniciativas de BPM.

3. Análise técnica da origem dos dados: definidos quais são os indicadores e dashboards desejados, é necessário verificar como estes dados podem ser obtidos para serem enviados para a ferramenta de BAM. Via de regra, além dos dados de execução dos processos provenientes do BPMS, podem ser necessários dados de diferentes sistemas de informação existentes na organização (ex: ERP, sistemas legados). Assim, é necessário envolver as equipes técnicas responsáveis por estes sistemas para avaliar como estes dados devem ser obtidos, bem como a forma de integração sugerida. É importante, para isto, conhecer as possibilidades de integração que a ferramenta de BAM oferece, pois cada uma pode disponibilizar diferentes formas de integração (ex: Web Services, Filas, etc).

4. Desenvolvimento dos dashboards: após a análise técnica da origem dos dados, é necessário realizar a construção técnica dos dashboards e alertas de monitoramento (caso existam). Esta é uma etapa que irá envolver os desenvolvedores e arquitetos que conhecem a ferramenta de BAM, bem como as equipes técnicas responsáveis pelos sistemas de origem das informações. Nesta etapa a origem dos dados pode, caso necessário, ser “simulada” através de input manual de informações diretamente na ferramenta do BAM (se a ferramenta permitir).

5. Homologação dos dashboards: finalmente, nesta etapa serão testados os dashboards pelos usuários finais, já com a integração com os sistemas de origem funcionando, para verificar que estão exibindo as informações corretamente. São também testados os alertas de monitoramento e ações de contingência definidas (se for o caso), bem como as regras de segurança e acesso às informações.

Pela nossa experiência, a fase que costuma ser mais trabalhosa é a “Análise técnica da origem dos dados”. Isto porque, com o crescimento da organização e aquisição de diversos sistemas, muitas vezes existe replicação de dados em fontes diferentes, e não há uma visão de qual é a origem mais apropriada para determinadas informações. Além disso, a falta de uma governança de TI e padrões de integração também pode dificultar a escolha da melhor forma de integração com a ferramenta de BAM.

Podemos notar então que, no que se refere as macro etapas necessárias, um projeto de implementação de BAM não difere muito de projetos convencionais de implementação de TI. Porém, olhando no detalhe, é possível perceber que um projeto BAM tem diversas características e desafios próprios, que exigem uma equipe com conhecimentos específicos, sem falar na mudança cultural que a adoção da ferramenta pode trazer para a organização.

Abaixo, listamos alguns cuidados básicos que devem ser tomados durante a realização de um projeto de BAM:

  • Limitar o número de gráficos num dashboard: tente limitar o número máximo de gráficos num mesmo relatório,  para um desempenho mais otimizado e melhor ocupação da área disponível. Um número máximo de 4 a 6 gráficos por dashboard é geralmente recomendado.
  • Usar filtros: utilize quando possível filtros, de forma que o usuário possa restringir a quantidade de dados sendo exibida e assim minimizar os recursos de processamento necessários.
  • Avaliar a necessidade de histórico de dados: evite armazenar dados antigos na ferramenta de BAM, para fins de histórico. Caso realmente necessário, considere a criação de um repositório específico para este fim. Mas lembre-se que uma ferramenta de BAM tem o foco no presente (informação em tempo real) e não para ser uma referência para avaliações históricas.
  • Utilizar o recurso de drill-down: o termo drill-down (em português “detalhar”) refere-se à ação de clicar em alguma seção de um gráfico para obter o detalhamento de informações referente àquela seção. Podemos pensar, por exemplo, num gráfico de pizza que mostra a quantidade de solicitações em aberto por região do país. Ao clicar numa fatia, o usuário é direcionado para uma lista de solicitações especificamente daquela região. Assim, procure construir os seus dashboards de maneira a mostrar inicialmente apenas as informações mais abrangentes e relevantes, para que os usuários possam ter um rápido entendimento da situação atual. E então disponibilize a navegação drill-down para níveis com maior detalhamento, que poderão ser consultados se o usuário achar necessário.
  • Avaliar o ambiente de exibição dos dashboards: deve ser avaliado de que forma os dashboards serão acessados. Serão acessados através de desktops e notebooks? Ou através de telas maiores? Frequentemente os dashboards são previstos para serem exibidos em telões/televisores, posicionados em lugares estratégicos no ambiente de trabalho, de maneira que possam ser vistos a uma certa distancia pelos usuários. Então, se for este o caso, será necessário limitar a quantidade de gráficos e  informações sendo exibidas, prestando atenção a detalhes como resolução da tela, disposição dos gráficos, tamanho e cores das fontes utilizadas.

Como vimos, os projetos de BAM tem suas próprias características e desafios, que devem ser levados em consideração durante o planejamento. Levando estes fatores em consideração, não temos dúvida que uma ferramenta de BAM pode se tornar uma ferramenta de inestimável valor para o acompanhamento do seu negócio!

Você se interessou pelo assunto? Falamos mais de BAM no nosso treinamento “Modelagem de Processos para Automação” e oferecemos um treinamento específico da ferramenta “Oracle BAM“. Ambos os cursos são oferecidos pela iProcess Education.

Quando usar o OSB, Oracle BPEL ou Oracle BPM

Estivemos presentes no Oracle Open World Brasil 2012 e tivemos a oportunidade de ter uma agradável conversa com um consultor da Oracle sobre uma dúvida recorrente entre os nossos clientes. Por mais que saibamos para ‘que serve’ cada produto, muitas vezes, em projetos de automação de processos e de integração de sistemas, existe a dúvida: quando utilizar OSB, Oracle BPEL e Oracle BPM?

Usando do expertise da iProcess e da Oracle buscamos alguns pontos que podem ajudar na tomada de decisão. São eles:

  • BPEL e BPM possuem a auditoria completa da execução da instância de orquestração e do processo automatizado. Assim, se o serviço precisa de auditoria, sugere-se escolher um deles. OSB não tem esse requisito.
  • O seu projeto vai produzir eventos que irão ser integrados ao Oracle BAM? BPEL e BPM possuem esse recurso e o desenvolvimento é rápido e fácil com ele. OSB, não.
  • É necessário utilizar o error hospital, incluindo a ressubmissão de mensagens etrace completo no caso de erro? Essa também é uma característica do BPEL e BPM.
  • BPEL/BPM são stateful (guarda o estado do processo) e OSB é stateless (não guarda o estado do processo). Ou seja, caso seja necessário ter uma execução de longa duração (de alguns minutos a vários dias) que aguarde eventos intermediários e tome decisões baseado no estado atual do processo e mais os dados do evento recebido, deve-se utilizar BPEL/BPM. Caso a execução leve apenas alguns segundos e todas as decisões ocorram apenas com base nos dados recebidos no momento da chamada, pode-se utilizar OSB. Para saber mais sobre stateless/stateful, veja esse artigo.
  • O projeto prevê a existência de tarefas humanas? Opte por BPM. O BPEL também é uma alternativa (já que a infraestrutura do SOA Suite é a mesma para ambos). OSB não possui esse recurso.
  • Entre BPM e BPEL, qual escolher? Ambos são ótimas soluções. No caso de não haver grande diferença entre um e outro, hoje em dia sugere-se utilizar o BPM pela simplicidade no aprendizado e na pouca quantidade de código envolvido. O BPEL ainda necessita um conhecimento mais aprofundado de XML e seus correlatos. Outro ponto é que BPM usa BPMN como notação para representar o fluxo do processo, que é muito mais facil de ser compreendida pelo negócio tanto no desenho do processo a ser automatizado quanto no acompanhamento da execução das instâncias.
Certamente muitos outros aspectos devem ser considerados nessa tomada de decisão, incluindo o tempo de processamento do serviço, se ele será síncrono ou assíncrono, etc. Mas os pontos acima podem ser úteis para, ao menos, eliminar uma ou outra opção.
(Com a contribuição de Leonardo Fagundes, Kelly Sganderla e Rafael Andrade).

Exportação e importação de Objetos do Oracle BAM

A interface padrão do Oracle BAM permite criar e salvar objetos diretamente no servidor do Oracle BAM. Desta forma, não é necessário salvar os objetos em arquivo na máquina local.

Porém, em determinados momentos é necessário exportar os objetos criados no servidor atual para outro servidor (ex: para testar os dashboards criados no servidor de desenvolvimento no servidor de testes).

Neste post, aprenderemos como exportar e importar objetos criados no Oracle BAM. Todos os componentes do Oracle BAM, podem ser exportados para um arquivo XML através do comando ICOMMAND.

iCommand

O iCommand é um utilitário que permite importar e exportar os diversos componentes do Oracle BAM através do prompt do DOS.

Exemplo de comando para exportar:

 icommand type=export name=myComponent type=dataobject file=myFile.xml

Exemplo de comando para importar:

 icommand type=import file=myFile.xml

Procedimentos antes de executar os comandos de importação e exportação:

  1. Se necessário, setar o Java Home: export JAVA_HOME=/home/oracle/Middleware/home_soa11g/jdk160_11
  2. No servidor do BAM, entrar no diretorio /home/oracle/Middleware/home_soa11g/Oracle_SOA1/bam/bin e executar o comando de exportação ou importação
  3. Caso os reports a serem exportados tenham drill, os reports referenciados devem ser exportados separadamente, e importados sempre ANTES dos reports que os referenciam. Do contrário, irá ocorrer a mensagem “DrillAcross Destination Report not found.”

Mensagens de erro comuns:

  1. Se o iCommand retornar o erro “BAM-01261: Cannot connect to the Oracle BAM Server”, verificar no arquivo /home/oracle/Middleware/home_soa11g/Oracle_SOA1/bam/config/BAMICommandConfig.xml se o parâmetro “ADCServerPort” está setado com a porta no qual o BAM foi efetivamente instalado (o valor padrão é 9001). Caso seja diferente, ajustar para a porta correta e tentar novamente.

Exemplos diversos:

Exportação de reports:

Exportando a pasta “Meus Relatórios” (e todos os relatórios dentro dela):

./icommand -cmd export -name ”/private:weblogic/Report/Meus Relatórios/Coleções” -type folder -file teste.xml

Exportando a pasta “Relatórios compartilhados” (e todos os relatórios dentro dela):

./icommand -cmd export -name ”/public/Report/MainFolderInShared” -type folder -file C:\FolderExportTest2.xml

Exportando um relatório privado:

./icommand -cmd export -name ”/private:bamadmin/Report/MyReport” -type report -file C:\MyReport.xml

Exportando um relatório da pasta “Relatórios Compartilhados”:

./icommand -cmd export -name ”/public/Report/SharedReport” -type report -file C:\SharedReport.xml

Exportação de Data Objects:

Exportando um Data Object da pasta raiz:

./icommand -cmd export -name TestDataObject -file “C:\TestDataObject.xml”

Exportando um Data Object de dentro de uma pasta específica:

./icommand -cmd export -name ”/Samples/Call Center” -file “C:\CallCenter.xml”

Exportando uma pasta de Data Objects inteira:

./icommand -cmd export -name ”/public/DataObject/Colecoes/Desempenho por Marcas” -type folder -file objects.xml

Importação de objetos (reports, data objects, etc):

./icommand -cmd import -file /home/oracle/Middleware/home_soa11g/Oracle_SOA1/bam/bin/teste.xml

Para maiores informações, consulte:
http://download.oracle.com/docs/cd/E12839_01/integration.1111/e10224/bam_app_icommand.htm