Tratamento de falhas em processos automatizados no Oracle BPM

Processos automatizados com a utilização de Suítes de BPM (BPMS) podem trazer grandes benefícios para a organização através do controle e gerenciamento da execução das atividades, além da possibilidade de acionar ações em outros sistemas de informação da organização, como gravar ou obter dados importantes para as tarefas do processo.

Na implantação de uma solução automatizada, um dos aspectos técnicos mais importantes a serem planejados está relacionado ao gerenciamento das falhas que podem acontecer no decorrer da execução do processo.

Isto é fundamental para garantir que, em caso de falhas, o problema possa ser resolvido ou mitigado, evitando que o processo fique parado.

No Oracle BPM, existem situações em que você poderá encontrar problemas inesperados que levam seu processo automatizado a falhar. Uma destas situações são erros de sistemas na execução de um processo.

Erros de sistema são consequências de uma falha no software ou hardware onde o BPMN está rodando. Pode ser ocasionado por várias causas. Alguns exemplos de causas de erros de sistemas são:

  • Falha na conexão com o Banco de dados
  • Perda de conectividade
  • Problema com o disco rígido
  • Indisponibilidade de serviço sendo invocado

Para recuperar os erros de sistema é possível utilizar no Enterprise Manager a opção de recuperação de falhas.

Neste post será descrito um exemplo de como definir a política de erros para processos com problemas, que permitem intervenção de usuário.

Neste exemplo, é definida uma política de falhas onde a mesma será recuperada manualmente pelo Administrador. Por exemplo,  em um processo de compras, o usuário cadastra o orçamento solicitado pelo cliente informando os dados do cliente (endereço, cep, CPF/CNPJ) e dados da compra (produtos desejados e quantidades). Neste momento todos os itens solicitados no orçamento estão em estoque. O usuário envia este orçamento ao cliente e aguarda o retorno positivo ou negativo. Caso o retorno seja positivo, o processo segue seu fluxo normal. Uma tarefa de serviço automática é chamada para verificar se ainda existem os itens solicitados em estoque. Porém, o serviço que faz a validação do estoque estava fora do ar no momento em que o processo precisou. Com isso, gerou-se uma falha no fluxo do processo.

No Oracle BPM, são necessários dois arquivos para definir o que deve acontecer quando ocorre um erro na execução do processo BPMN:

  • fault-policies.xml
  • fault-bindings.xml

O uso destes arquivos devem ser configurados no composite do processo BPM e adicionados no diretório do processo.

No Oracle BPM 11g…

No Oracle BPM 11g, basta criar manualmente os dois arquivos dentro do diretório do processo (conforme figura abaixo).

Diretório - arquivos

Exemplo da configuração no composite.xml:

<component name="PocAprovadores">
    <implementation.bpmn src="processes/PocAprovadores.bpmn"/>
    <property name="oracle.composite.faultPolicyFile">fault-policies.xml</property>
    <property name="oracle.composite.faultBindingFile">fault-bindings.xml</property>
</component>

A ação de intervenção de usuário é definida com a tag ora-humam-intervention no arquivo fault-policies.xml. Sem a política de falhas, as instancias BPMN não irão gerar falhas recuperáveis:

<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <faultPolicy version="1.0" id="DefaultPolicy"
                xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
                xmlns:xs="http://www.w3.org/2001/XMLSchema"
                xmlns="http://schemas.oracle.com/bpel/faultpolicy"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <Conditions>
      <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
                  name="bpelx:bindingFault">
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
       <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
                  name="bpelx:remoteFault">
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
       <faultName xmlns:task="http://xmlns.oracle.com/bpel/workflow/taskService"
                  name="task:operationErroredFault">
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
       <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
                  name="bpelx:selectionFailure">
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
       <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
                  name="bpelx:runtimeFault">
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
       <faultName>
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
   </Conditions>
   <Actions>
           <Action id="ora-human-intervention">
               <humanIntervention/>
           </Action>
           <Action id="ora-rethrow-fault">
                <rethrowFault/>
           </Action>
           <Action id="ora-terminate">
                <abort/>
           </Action>
           <Action id="ora-replay-scope">
                <replayScope/>
           </Action>
           <Action id="ora-retry">
               <retry>
                   <retryCount>5</retryCount>
                   <retryInterval>10</retryInterval>
                   <exponentialBackoff/>
                   <retryFailureAction ref="ora-human-intervention"/>
               </retry>
           </Action>
   </Actions>
   </faultPolicy>
</faultPolicies>

Onde “retryCount” é a quantidade de vezes que vai tentar recuperar o erro, “retryInterval” é o tempo programador de intervalo entre as tentativas de recuperação do erro, “retryFailureAction“ é a ação que será tomada se todas as tentativas de recuperação de erros falharem.

O arquivo fault-bindings associa a política de falhas definidas no arquivo fault-policies.xml ao composite do processo:

<faultPolicyBindings version="1.0"
                    xmlns="http://schemas.oracle.com/bpel/faultpolicy"
                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <composite faultPolicy="DefaultPolicy"/>
</faultPolicyBindings>

Uma vez definida a intervenção de usuário como ação, é possível recuperar as falhas no Enterprise Manager.

NO ORACLE BPM 12c…

No Oracle BPM 12c, existe uma nova opção da criação do arquivo fault-policies pelo JDeveloper.  Toda vez que é criado um arquivo fault-policies pelo editor, você basicamente está criando um novo arquivo XML com a política de falhas padrão. Ou seja, criando o arquivo fault-policies.xml na pasta do processo.

Através do JDeveloper, este arquivo pode ser configurado pelo editor de forma amigável.

Fault-Policies Oracle 12 c As falhas são categorizadas na seção “Fault Handler” em “System faults” – bindings faults, mediator faults and remote faults – e “Service Faults” – uma lista de falhas definidas pelo WSDL que seu composite utiliza.

Para cada tratamento de exceção é possível selecionar uma ação padrão, da lista de ações definidas.

Nota: assim como no 11g, para que o processo identifique e use o tratamento de erros, é preciso criar manualmente o arquivo fault-bindings.xml e relacionar a política criada.

Também é preciso configurar manualmente os arquivos de tratamentos de falhas no composite.xml.


Referências:

Certificações para profissionais de Processos de Negócio

Crédito da foto: albertogp123 - via photopin.com (cc)O mercado de profissionais para atuar em iniciativas de Gestão por Processos está bastante aquecido. Não há uma pesquisa formal, mas uma percepção geral de que bons profissionais que atuem em iniciativas de processos estão fazendo falta no mercado.

Esta área de atuação ainda está se consolidando em muitas organizações, e o grupo de profissionais que se envolvem nestas iniciativas variam bastante não apenas de acordo com o porte da empresa, mas também com o nível de maturidade da organização das práticas de gestão de processos.

Por isto mesmo, as certificações para validar conhecimentos e experiência de profissionais da área têm ganhado grande importância.

Certified Business Process Professional (CBPP)

A certificação CBPP é uma das que mais vem crescendo no Brasil, impulsionada principalmente pela forte presença do capítulo brasileiro da Association of Business Process Management Professionals – ABPMP (www.abpmp-br.org), a instituição certificadora. A certificação CBPP está para o profissional de processos assim como o PMP (e respectivamente o PMI) está para profissionais de projetos.

O objetivo desta certificação é validar o conhecimento e experiência do profissional em iniciativas relacionadas à gestão de processos. Por este motivo, para realizar o exame do CBPP existem pré-requisitos que precisam ser atendidos, como ter experiência comprovada em iniciativas de gerenciamento de processos. Ao se inscrever para o exame, o profissional recebe uma cópia impressa do Corpo Comum de Conhecimento em BPM (o BPM CBOK), que encontra-se na versão 3 e já está traduzido para o português.

O exame é baseado principalmente no conteúdo desta obra, mas requer também realizar algumas análises sobre as questões que em geral são obtidas com base na vivência. Para fazer o exame precisa também participar do evento BPM Boot Camp, que são 3 dias de discussão sobre os temas do CBOK (o que também ajuda a fazer uma revisão geral do conteúdo). O exame costuma ser na manhã do quarto dia. A prova é em português e sua realização é presencial mas o profissional responde no próprio computador e o resultado sai na hora.

A CBPP é uma certificação única e renovável a cada três anos; uma forma da ABPMP garantir que o profissional certificado está se atualizando e continua exercendo as práticas de BPM. Embora o exame seja realizado pela ABPMP do Brasil, a certificação tem valor internacional.

Informações sobre a certificação:
http://www.abpmp-br.org/certificacao-cbpp/
Informações sobre a entidade certificadora:
http://abpmp-br.org/
Lista de profissionais certificados (no Brasil):
http://www.abpmp-br.org/profissionais-certificados/

 * Atualização: links para o site da abpmp-br atualizados em junho/2016.

OMG Certified Expert in BPM (OCEB 2)

A certificação OCEB é uma certificação concedida pela Object Management Group, a OMG (www.omg.org). A OMG é uma entidade padronizadora, responsável por diversos padrões técnicos. Os mais conhecidos pela área de tecnologia são o UML e CORBA, mas esta organização mantém centenas de especificações técnicas de linguagens, notações e padrões para diversas aplicações.

O foco da certificação OCEB portanto não está na experiência do profissional em processos, mas a verificação do seu conhecimento e domínio sobre conceitos e padrões, em especial os mantidos pela OMG para processos de negócio, como: Business Motivation Model (BMM),  Process Model and Notation – BPMN, Business Process Definition Metamodel (BPDM), Case Management Model and Notation (CMMN) entre outros. Também são tratados frameworks de qualidade e governança como SOX, COBIT, ITIL, Six Sigma e Lean.

A certificação OCEB é na verdade dividida em cinco titulações distribuídas em três níveis. A certificação básica é a OCEB Fundamental. Os dois níveis seguintes são segmentados em conhecimentos técnicos ou de negócio: Business Intermediate e Technical Intermediate, e então Business Advanced e Technical Advanced. Assim, para o profissional poder confirmar domínio e conhecimento sobre todos os aspectos de BPM, sob a perspectiva da OMG, precisará passar por cinco exames, ou então poderá escolher uma linha específica (negócio ou técnico) e realizar três exames até obter o nível avançado.

Para fazer o exame não há pré-requisitos. Basta estudar a bibliografia relacionada ao respectivo exame, realizar a aquisição do voucher e na data marcada vai ao local fazer o exame. A prova é em inglês.

Recentemente a OMG anunicou a OCEB 2. Isto porque até agosto de 2013 o exame ainda era baseado na especificação da notação BPMN v1.1. Assim, a OCEB 2 é, na verdade, a atualização da certificação para verificar conhecimentos sobre a BPMN 2.0, que é a sua especificação mais recente (veja neste vídeo em nosso canal do youtube o que mudou com a nova versão de BPMN).

Informações sobre a certificação:
http://www.omg.org/oceb-2/
Informações sobre a entidade certificadora:
http://www.omg.org/
Lista de profissionais certificados:
http://www.omg.org/cgi-bin/searchcert.cgi

 

Outras certificações para profissionais em BPM

Embora CBPP e OCEB sejam as principais certificações conhecidas no mercado, existem outras entidades internacionais que oferecem certificação para profissionais de processos, em geral concedidos por entidades educacionais.

Estas certificações tem se apresentado pouco expressivas na comunidade de BPM, sobretudo no Brasil. Algumas delas são:

  • Certified BPM Professional (CBPMPSM), concedida pelo BPMInstute.org, é baseada em literatura indicada no site. Os exames são presenciais e acontecem nos eventos realizados pela organização na Austrália, Europa e Estados Unidos (http://www.bpminstitute.org/certification).
  • Certified Professional in Business Process Management (CPBPM), titulação obtida através do programa educacional em gestão de processos de negócio da Villanova University (http://www.villanovau.com/online-certificates/bpm-certificate.aspx).
  • Certification in Business Process Management (P.BPM), certificação concedida pela instituição educacional BPM Council e International BPM Institute (http://www.bpmcouncil.org/).

 

Certificações profissionais em soluções de BPM (BPMS)

Com a expansão da utilização das soluções para automatização e gerenciamento de processos de negócio, os fornecedores de produtos perceberam a necessidade de formar e certificar profissionais que demonstrem conhecimento profundo e domínio das ferramentas que compoem o produto.

Estas certificações também são bastante valorosas, sobretudo para os profissionais envolvidos no desenvolvimento das soluções com um produto específico. Em geral são certificações bastante técnicas, muito mais focadas em como o profissional interpreta uma situação de negócio e identifica, dentro das capacidades do produto, a melhor forma de implementá-la. Dependendo do fornecedor, a verificação deste conhecimento pode ser realizado através da comprovação de implementação de processos, desenvolvimento de um case enviado pelo fornecedor, exame de conhecimentos teóricos e arquiteturais e até mesmo apresentação de atestados da empresa que teve soluções implementadas pelo profissional.

Conhece outras certificações que não foram citadas? Ajude-nos a manter esta postagem atualizada enviando links para as certificações que você conhece através dos comentários deste artigo.

 


Você sabia que a iProcess conta com uma equipe especializada e certificada internacionalmente?
Confira nossas certificações corporativas e profissionais no site:
www.iprocess.com.br/quem-somos/certificacoes/

Atualizando processos do Oracle BPM – Versão 11.1.1.4 para 11.1.1.6

Uma situação recorrente em qualquer plataforma é a migração das aplicações existentes para as versões mais novas. A plataforma Oracle SOA, na qual o Oracle BPM esta incluído, procura manter ao máximo a compatibilidade entre as versões. Entretanto, em algumas situações são necessárias mudanças em configurações e/ou código na migração dos projetos para uma versão mais recente. Este é o caso dos projetos de processos na migração da versão 11.1.1.4 para 11.1.1.6.

Na migração entre estas versões, usualmente são necessárias três alterações nas configurações dos projetos ADF, e uma alteração na configuração do processo:

  • Remoção das bibliotecas: adflibWorklistComponents e bpm-workflow-datacontrol.
  • Forçar o uso da versão 11.1.1 dos componentes ‘oracle.soa.worklist.webapp’.
  • Alterar o plano de configuração (config_plan) arrumando o atributo ‘port’ para o padrão antigo.
  • Forçar uso da geração de binários Java 1.6 (opcional).
Remoção das bibliotecas:
Na versão 11.1.1.6 já existem algumas das bibliotecas que em versões anteriores precisavam ir no pacote WAR do projeto. Para evitar conflito, é necessário remover as mesmas do pacote do projeto:
1) Clicar no projeto da UI com o botão direito e ir em propriedades:
2) Selecionar implantação no menu da esquerda e clicar no botão editar:
3) Desmarcar as bibliotecas: adflibWorklistComponents e bpm-workflow-datacontrol e clicar em Ok:
Forçar o uso da versão 11.1.1 dos componentes:
Os componentes  ‘oracle.soa.worklist.webapp’ gerados pela pela versão 11.1.1.4  usam a versão 11.1.1 desta biblioteca. Assim, para evitar a re-geração dos ADF, é necessário forçar este uso para evitar conflito entre componentes de versões diferentes não compatíveis num mesmo projeto.
No diretório do projeto da UI em ADF editar o arquivo ‘public_html\WEB-INF\weblogic.xml’ e adicionar a configuração:
 <library-ref>
    <library-name>oracle.soa.worklist.webapp</library-name>
    <specification-version>11.1.1</specification-version>
  </library-ref>
Alterar o plano de configuração:
Os processos gerados pela versão 11.1.1.4 usam um padrão de nomenclatura onde no WSDL concreto é inserido o sufixo ‘_pt’ no atributo ‘porttype’. Este comportamento pode ser visto pelo EM.
Para manter a compatibilidade entre instâncias de processos que já estão executando a versão do processo 11.1.1.4 e a nova versão do processo gerada pela 11.1.1.6, é necessário alterar esta propriedade no plano de configuração inserido o sufixo _pt, deixando com o mesmo caminho da versão 11.1.1.4:
Forçar o uso da geração de binários Java 1.6:
Caso o ambiente do Oracle SOA no servidor esteja usando Java 1.6 e for alterado o JDeveloper para usar o Java 1.7, é necessário configurar os projetos para produzirem classes Java 1.6, garantindo a integridade dos binários com a versão do servidor.
Na configuração dos projetos em compilador, selecionar código fonte 1.6:

Oracle SOA Suite – Build e Deploy multi-ambiente utilizando scripts ANT

Depois de alguns anos de experiência utilizando o Oracle SOA Suite 11g em diferentes projetos, a iProcess elaborou uma solução para build e deploy dos projetos BPEL e BPM utilizando scripts ANT customizados que, em parte, são disponibilizados pela própria Oracle e, em partes, foram adaptados pela empresa. O post de hoje apresenta essa solução, além de disponibilizar um pacote de scripts de exemplo.

Antes, porém, vamos ‘chover no molhado’ e conceituar simplesmente build e deploy. Vimos, pela experiência de projeto, que nem sempre isso é claro para todos.

  • build: é o ato de ‘empacotar’ o projeto. Todo o projeto será incluído num único arquivo (basicamente um ZIP) que, posteriormente, será enviado para o servidor onde será feita a disponibilização.
  • deploy: é o ato de disponibilizar o projeto ‘empacotado’ no servidor. Para isso, obviamente, serão necessárias as informações do servidor de destino. Note que o nosso post irá tratar bastante desse assunto, já que existem possibilidades de deploy customizados para diferentes ambientes.

Ainda, antes de apresentarmos a solução, queremos responder à pergunta: por que criamos essa opção utilizando scripts ANT? Não seria mais simples continuar realizando o build + deploy via JDeveloper?

Vamos relacionar algumas justificativas:

  • deploy em vários ambientes: é comum em projetos de integração e automação de processos a necessidade de trabalharmos com diferentes ambientes (desenvolvimento, testes, homologação, produção). O projeto é o mesmo. O que mudam são os enpoints dos serviços e informações específicas de conexões, JCA’s, etc. Nesses casos a utilização de arquivos de configuração que contenham as informações dos enpoints e dos outros dados personalizados por ambiente simplifica a vida da pessoa responsável por instalar o projeto nos vários destinos (homologação/produção), bastando selecionar o ambiente destino e realizar o deploy para ele.
  • faça o build uma vez e o deploy muitas vezes: promover o mesmo build para vários ambientes é algo extremamente valioso. Isso dá a garantia de que exatamente o mesmo projeto que foi testado no ambiente X será testado nos ambientes Y, Z… Caso contrário, se algo tiver que ser alterado no projeto depois de já tê-lo testado em algum ambiente (mesmo que essa informação seja o endpoint de algum serviço) sempre existirá a possibilidade de algo estar diferente (inclusive um novo defeito), colocando em risco todos os testes que já foram realizados até então.

Feito. Vamos ao que interessa. Abaixo está descrito o padrão utilizado pela iProcess para build/deploy dos projetos no SOA Suite. A descrição inclui o uso de projetos BPM e HumanTasks. Agradecemos ao Rafael Andrade pela grande contribuição na organização desse material.

A estrutura de diretórios abaixo tem como objetivo permitir que projetos SOA/BPM sejam preparados, desde o seu desenvolvimento, para serem migrados entre os diversos ambientes existentes (desenvolvimento, homologação, produção, etc) sem a necessidade de efetuar ajustes nos projetos durante o build/deploy em cada ambiente específico. Será mais simples ver a descrição desses tópicos com o projeto em mãos. Clique aqui para realizar o download.

 sca
 |-- bin
 |    |-- ear
 |    |-- templates
 |    |     |-- form_application
 |    |     |     |-- application.xml
 |    |     |     |-- build.xml
 |    |     |     |-- build-wars.xml
 |    |     |     |-- local_build.properties
 |    |     |-- form_project
 |    |     |     |-- build.xml
 |    |     |     |-- local_build.properties
 |    |     |-- soa_project
 |    |     |     |-- build.xml
 |    |     |     |-- build-customize.xml
 |    |     |     |-- local_build.properties
 |    |-- war
 |    |-- .adf
 |    |     |-- META-INF
 |    |     |    |-- adf-config.xml.seed.local
 |    |     |    |-- adf-config.xml.seed.server
 |    |-- build_ENV.properties
 |    |-- custom-build.xml
 |    |-- custom-build-app.xml
 |    |-- custom-build-app-common.xml
 |    |-- custom-build-app-mod.xml
 |    |-- custom-build-app-mod-common.xml
 |    |-- custom-build-common.xml
 |    |-- developer_build.properties
 |    |-- global_build.properties
 |-- projects
 |    |-- forms
 |    |      |-- <aplication 1>
 |    |      |      |-- <project 1>
 |    |      |      |-- <project 2>
 |    |      |-- <aplication 2>
 |    |      |      |-- <project 1>
 |    |      |      |-- <project 2>
 |    |-- soa
 |    |      |-- <project 1>
 |    |      |-- <project 2>
 |-- shared
 |    |-- mds
 |    |    |-- apps
 |    |    |    |-- <project name>
 |    |    |    |      |-- fault-policies
 |    |    |    |      |    |-- <fault policies files>
 |    |    |    |      |-- xsd
 |    |    |    |      |    |-- <directories and XSD files>
 |    |-- build.xml
 |    |-- local_build.properties
 |    |-- shared.jpr

Diretórios:
sca: diretório raiz dos projetos SOA/BPM. Este diretório e toda a sua estrutura interna deve ser criado no sistema de controle de versões do projeto.

  • bin: diretório onde estão localizados os scripts de build/deploy e os arquivos de configuração
  • ear: arquivos utilizados na geração do EAR que representa a aplicação Java contendo os módulos web com os formulários das human tasks do projeto. Tanto a estrutura de diretórios interna quanto os arquivos existentes nela são apenas utilizados na geração do EAR, não devendo ser alterados.
  • templates: diretório contendo os templates de arquivos que devem ser copiados para os projetos de acordo com a situação
  • form_application: arquivos que devem ser copiados para o diretório da aplicação Java que conterá os formulários das human tasks. Alguns arquivos devem ser customizados, conforme descrito abaixo.
  • application.xml: arquivo que descreve os módulos da aplicação Java. Deve ser copiado para a pasta raiz de cada aplicação Java, devendo ser customizado a medida que os projetos dos formulários forem sendo criados.
  • build.xml: arquivo que deve ser copiado para a pasta raiz de todas as aplicações Java. Este arquivo contém os imports e referencias para que seja possível fazer build e deploy de cada aplicação.
  • build-wars.xml: arquivo que deve ser copiado para a pasta raiz de todas as aplicações Java, devendo ser customizado a medida que os projetos dos formulários forem sendo criados para conter uma chamada para o build de cada um dos projetos que compõe a aplicação.
  • local_build.properties: arquivo de properties que deve ser copiado para a pasta raiz de todas as aplicações Java, devendo ser customizado para conter o nome da aplicação que deve ser criada. O nome informado neste arquivo deve ser o mesmo informado na tag display-name do arquivo application.xml.
  • form_project: arquivos que devem ser copiados para o diretório dos projetos de formulários das Human Tasks. Alguns arquivos devem ser customizados, conforme descrito abaixo.
  • build.xml: arquivo que deve ser copiado para a pasta raiz do projeto de formulário da Human Task. Este arquivo contém os imports e referencias para que seja possível fazer build e deploy de cada projeto de formulário.
  • local_build.properties: arquivo de properties que deve ser copiado para a pasta raiz do projeto de formulário da Human Task, devendo ser customizado para conter o nome do módulo web que deve ser criado.
  • soa_project: arquivos que devem ser copiados para o diretório dos projetos SOA/BPM. Alguns arquivos devem ser customizados, conforme descrito abaixo.
  • build.xml: arquivo que deve ser copiado para a pasta raiz de todos os projetos SOA/BPM. Este arquivo contém os imports e referencias para que seja possível fazer build e deploy de cada projeto
  • build-customize.xml: arquivo que deve ser copiado para a pasta raiz dos projetos SOA/BPM quando for necessário fazer algum tipo de customização (replace de TOKENS) no configuration plan do projeto. Nestes casos, o arquivo deve ser copiado e atualizado, sendo adicionadas as tags de replace necessárias. Por padrão, os tokens @managed.server.host, @managed.server.port e @partition.name são automaticamente substituidos pelos valores do hostname, porta e partition, respectivamente, buscando dados dos arquivos build_ENV.xml e global_build.properties. Deste modo, o arquivo build-customize.xml só precisa ser criado caso algum outro token adicional precise ser substituido. Por exemplo: nome de filas, caminhos de diretórios, endereço de serviços externos invocados, etc.
  • local_build.properties: arquivo de properties que deve ser copiado para a pasta raiz dos projetos SOA/BPM quando for necessário definir alguma property específica para este projeto. Normalmente este arquivo é necessário quando apenas o configuration plan deste projeto precisa ser customizado com alguma informação que ainda não exista nos demais arquivos de properties e que faça sentido apenas para este projeto.
  • war: arquivos utilizados na geração do WAR que representa cada um dos módulos web contendo os formulários das Human Tasks. Tanto a estrutura de diretórios interna quanto os arquivos existentes nela são apenas utilizados na geração do WAR de cada projeto, não devendo ser alterados.
  • .adf/META-INF: diretório que simula o diretório de uma aplicação SOA/BPM. Neste diretório estão os arquivos necessários para acessar o MDS. Os dois arquivos contidos nesse diretório são templates que o script de deploy utiliza como base (faz uma cópia) para criar o arquivo contendo as informações que efetivamente serão utilizadas para acessar o MDS durante o deploy.
  • adf-config.xml.seed.local: arquivo contendo o template de configurações necessárias para acessar o MDS local na máquina do desenvolvedor.
  • adf-config.xml.seed.server: arquivo contendo o template de configurações necessárias para acessar diretamente o MDS do servidor.
  • build_ENV.properties: arquivo de properties que contém as informações específicas de cada ambiente (desenvolvimento, homologação, produção, por exemplo). Deve ser criado um arquivo de properties por ambiente, sendo o nome ajustado de acordo (build_dev.properties, build_hom.properties, build_prod.properties, por exemplo). Os valores internos também devem ser ajustados para refletirem os valores de cada ambiente. Utilize o arquivo build_ENV.properties como template para construção dos arquivos específicos de cada ambiente.
  • custom-build.xml: script ANT que contém os targets que são expostos para os projetos SOA/BPM. É uma espécie de wrapper para o arquivo custom-build-common.xml, expondo apenas os targets adequados para build e deploy dos projetos.
  • custom-build-app.xml: script ANT que contém os targets que são expostos para as aplicações Java. É uma espécie de wrapper para o arquivo custom-build-app-common.xml, expondo apenas os targets adequados para build e deploy das aplicações.
  • custom-build-app-common.xml: script ANT que contém todos os targets necessários para build e deploy de aplicações Java.
  • custom-build-app-mod.xml: script ANT que contém os targets que são expostos para os projetos de formulários das Human Tasks. É uma espécie de wrapper para o arquivo custom-build-app-mod-common.xml, expondo apenas os targets adequados para build e deploy dos projetos.
  • custom-build-app-mod-common.xml: script ANT que contém todos os targets necessários para build e deploy dos projetos de formulários das Human Tasks.
  • custom-build-common.xml: script ANT que contém todos os targets necessários para build e deploy de projetos SOA/BPM.
  • developer_build.properties: arquivo que contém properties específicas do ambiente de desenvolvimento de cada desenvolvedor. Após baixar toda a árvore de diretórios do sistema de controle de versões, cada desenvolvedor deve customizar este arquivo de acordo com as suas opções de builde e deploy.
  • global_build.properties: arquivo que contém as properties globais do projeto. Neste arquivo estão armazenadas as propriedades que são comuns a todos os componentes do projeto e que não variam de acordo com o ambiente.
  • projects: este diretório irá conter todos os diretórios de projetos SOA/BPM criados, bem como as aplicações e projetos Java criado para os formulários das Human Tasks. Deverão ser armazenados nele os diretórios de projeto com toda a estrutura de pastas criada pelo jDeveloper. Apenas os diretórios de projetos devem ser armazenados, não devendo ser armazenado nele o diretório da aplicação. No caso da aplicação Java que conterá os formulários das atividades humanas, o diretório criado não é o diretório da Application criado pelo jDeveloper, mas apenas um diretório simples para organizar os projetos dos formulários, com so arquivos necessários para o seu build/deploy, de modo que o diretório da application criado pelo jDeveloper não deve ser armazenado.
  • forms: diretório que irá conter as aplicações e projetos Java dos formulários das Human Tasks.
  • <APLICACAO 1>: diretório de uma aplicação Java, com os arquivos de build e deploy copiados do template
  • <PROJETO 1>: diretório de um projeto de formulário de Human Task
  • <PROJETO 2>: diretório de um projeto de formulário de Human Task
  • <…>
  • <APLICACAO 2>: diretório de uma aplicação Java, com os arquivos de build e deploy copiados do template
  • <PROJETO 1>: diretório de um projeto de formulário de Human Task
  • <PROJETO 2>: diretório de um projeto de formulário de Human Task
  • <…>
  • <…>
  • soa: diretório que irá conter os projetos SOA/BPM.
    • <PROJETO 1>: diretório de um projeto SOA/BPM
    • <PROJETO 2>: diretório de um projeto SOA/BPM
    • <…>
  • shared: diretório que contém um projeto especial onde são armazenados os arquivos comuns (policies, wsdls e xsds) que serão importados para o MDS e compartilhados pelos diversos projetos.
  • mds/apps: diretório que representa a mesma estrutura interna do MDS onde devem ser armazenados os arquivos a serem compartilhados.
  • <NOME DO PROJETO/CLIENTE/AREA>: diretório com o nome do projeto/cliente/área, utilizado apenas para organizar os arquivos compartilhados. Em vez de apenas um diretório, pode ser uma árvore inteira de diretórios e arquivos. A estrutura interna desde diretório pode ser criada de acordo com as necessidades do projeto.
  • build.xml: script ANT que contém todos os targets necessários para build e deploy de arquivos compartilhados no MDS.
  • local_build.properties: arquivo de properties específico para customizar o build/deploy dos arquivos compartilhados no MDS.
  • shared.jpr: projeto jDeveloper criado para permitir que os desenvolvedores acessem os arquivos compartilhados de maneira fácil de dentro da ferramenta de desenvolvimento. Basta abrir o projeto dentro da aplicação criada no jDeveloper para ter acesso a estrutura de diretórios dos arquivos compartilhados.

Muito bem! E agora? Como fazemos pra usar tudo isso?

  • Para cada novo projeto SOA que for criado, um arquivo build.xml precisa ser copiado do diretório /sca/bin/template para o diretório raiz do projeto;
  • Se for necessário realizar algum tipo de customização do build/deploy, os arquivos build-customize.xml e local_build.properties também precisam ser copiados;
  • Os scripts ANT necessitam obrigatoriamente que o configPlan seja criado para cada projeto. Esse arquivo de config plan deverá ter o mesmo nome do composite mais o sufixo “_configPlan” e será utilizado como modelo/template para gerar as informações específicas dos configPlans por ambiente.
    • Para criar o config plan, no JDeveloper clique com o botão direito sobre o arquivo composite.xml e selecione a opção “Generate Config Plan”. Aceite o nome padrão sugerido.
    • Substitua no arquivo de configPlan os dados que deverão ser personalizados para cada ambiente por tokens. Estes serão trocados durante o build/deploy pelas informações contidas nos arquivos de properties.
  • Os scripts ANT utilizam o build-customize.xml em conjunto com comandos de pesquisa/substituição para gerar o configPlan customizado para cada um ambiente. Se o seu projeto precisa de qualquer tipo específico de configuração por ambiente, copie esse arquivo do diretório /sca/bin/template para o diretório raiz do projeto. Em seguida, atualize-o com todas as informações de busca/substituição necessárias para o seu projeto.
    • Crei uma instrução de busca/substituição para cada token criado no configPlan.
    • Se você possui qualquer propriedade no seu projeto que precise ser personalizada por ambiente, copie o arquivo local_build.properties do diretório /sca/bin/template para o diretório raiz do projeto e inclua nele todas as propriedades personalizadas.

Uma vez que toda a estrutura de arquivos estiver criada e configurada, é possível rodar os scripts ANT diretamente dentro do JDeveloper. Veja um exemplo abaixo:

Build e Deploy

Build e Deploy

Resultado do build e Deploy

Resultado do build e Deploy

Para concluir, relacionamos abaixo alguns assuntos que não foram tratados nesse posts e que podem ser utilizados em projetos para aperfeiçoar o uso do build + deploy:

  • repositório de arquivos: o diretório sca e seus sub-diretórios podem ser gerenciados usando qualquer tipo de sistema de repositório de arquivos, como SVN, CVS, TFS, GIT, etc. Contudo, normalmente os arquivos da “SOA Application” não são salvos no repositório, já que cada desenvolver deverá criar uma “SOA Application” vazia e incluir na aplicação os projetos que desejar, que estarão disponíveis no repositório (pasta /sca/projects). Também, quando um novo projeto for criado no JDeveloper, é importante cuidar para que ele seja salvo na pasta do repositório (/sca/projects).
  • atualização dos configPlan: atenção com os arquivos de configPlan: eles deverão ser atualizados cada vez que o projeto for alterado e novos dados sensíveis forem incluídos (exemplos comuns de dados sensíveis são hostname, porta e nome da partição do servidor para onde será feito o deploy ou então as informações de hostname e porta dos serviços externos).
  • uso do DVM para controle dos endpoints: uma opção ao uso dos arquivos de properties é a utilização do DVM do próprio SOA Suite para armazenar os endpoints. Isso é totalmente possível e já foi utilizado em projetos desenvolvidos pela iProcess.
  • na minha máquina funciona: o uso de um produto como o Hudson, Maven, etc para centralizar as tarefas de build e deploy é totalmente recomendável. É possível criar tarefas específicas de build e outras de deploy. No caso do build, ele pode ser configurado, inclusive, para buscar as informações diretamente no repositório de dados (SVN, GIT, etc), aumentado a confiança no código desenvolvido e o controle sobre as versões que são implementadas nos vários ambientes. Vai evitar situações do tipo “na minha máquina funciona“.
  • MDS: se esse assunto é novo para você, caro leitor, sugiro dar uma navegada no nosso blog, específicamente nesse artigo que trata desse assunto.

Esperamos ter contribuído para a melhoria dos seus processos de build e deploy no SOA Suite 11g.

Como manter a aderência ao modelo TO BE na automatização de processos

Num ciclo BPM típico, o processo TO-BE é desenhado em conjunto com a área de negócios.  A partir daí, de acordo com um conjunto de critérios e avaliações, pode-se optar por seguir o ciclo e efetuar a automatização deste processo numa ferramenta de BPMS.

Durante a implementação e testes de processos automatizados, um dos questionamentos mais recorrentes dos usuários de negócio é de como o fluxo do processo automatizado ficou diferente da visão TO-BE que foi desenhada com a participação deles. Frequentemente existe o questionamento de que o processo automatizado ficou mais “poluido” e com “muitas caixinhas a mais” em relação ao modelo TO-BE original.

Vejamos o processo fictício abaixo, desenhado em um nível mais genérico:

Modelo de Processo TO-BEO que podemos concluir deste processo?

  • Não existe a preocupação em detalhar em nível mais baixo/operacional as atividades, e sim mostrar uma visão de alto nível do processo, para auxiliar na compreensão do mesmo como um todo;
  • Algumas atividades podem estar ocultas, ou podemos ter uma atividade que encapsule outras (caso por exemplo da atividade “Geração e Envio da OC” – possivelmente 2 atividades separadas?);
  • Não está claro se as atividades são de responsabilidade de uma pessoa ou sistema;
  • Não fica claro qual exatamente é o responsável pela atividade, pois a divisão de roles foi feita em nível departamental, e não em papéis/funções (não entrando no mérito se esta seria a melhor abordagem de modelagem).

Este processo cumpre seu papel ao mostrar em um nível mais genérico qual o processo de execução de compras da empresa. Para fins de automação, no entanto, este processo não está no nível adequado. É necessário então um trabalho de levantamento no detalhe da execução deste processo, definindo todas as atividades, responsáveis, regras de negócio, automações, etc.

Vamos agora analisar o mesmo processo anterior, mas desenhado em um nível mais analítico, já em preparação para a automação:

Modelo de Processo TO-DOPodemos notar uma série de diferenças em relação ao processo anterior:

  • Atividades que na visão TO-BE eram uma só, agora foram separadas em atividades diferentes (atividades “Geração da OC” e “Envio OC fornecedor”). Percebam que o contrário também pode ser verdadeiro, ou seja: 2 ou mais atividades no modelo TO-BE podem virar apenas uma atividade no modelo automatizado;
  • O nível de granularidade do processo mudou: em vez de lanes em nível departamental, agora temos exatamente qual o papel/função que executa cada atividade;
  • Utilizando elementos visuais, foi especificado qual o tipo de cada tarefa (humana, automática, email);
  • Foi estabelecido um controle de tempo de execução das atividades, e envio de alertas por email caso as atividades não sejam executadas no seu prazo.

Assim, um processo que no nível TO-BE tinha apenas 3 atividades, virou um processo automatizado com 11 atividades. De certa forma, é fácil entender a perplexidade dos usuários, não?

Vamos tentar entender os motivos porque isso acontece. Durante o detalhamento do processo em preparação a automação, uma série de regras de negócio e de execução do processo são definidas, regras estas que não estavam visíveis no desenho do processo TO-BE. Isso acaba gerando necessidades adicionais na modelagem do processo automatizado, como por exemplo:

  • Buscar dados de apoio numa base de dados, para exibição nas atividades do processo;
  • Fazer transformação de dados entre atividades;
  • Buscar valores de parametrização utilizados pelo processo em sistemas de Back-Office;
  • Invocar procedimentos ou serviços específicos relacionados a regras do processo (ex: serviço institucional para calcular o prazo de uma atividade);
  • Etc.

A “multiplicação” de atividades no modelo automatizado em relação ao modelo TO-BE está ligado, principalmente, aos seguintes fatores:

  • Nível de detalhamento do modelo TO-BE. Em linhas gerais, quanto mais detalhado um modelo TO-BE, maiores são as chances do modelo automatizado ficar semelhante;
  • Recursos e possibilidades de automação da ferramenta de BPMS. Por exemplo, se a ferramenta de BPMS oferece mecanismos nativos para alertas por email, que estejam embutidas na própria configuração das atividades humanas, todas as atividades de alerta que temos no exemplo acima não seriam necessárias, como por exemplo a atividade “Alerta para enviar OC”.
  • O diagrama TO-BE que foi modelado numa ferramenta, mas implementado em uma ferramenta diferente, pode fazer com que uma tarefa que havia sido modelada de uma determinada forma tenha que ser, por restrições e características técnicas do BPMS, implementada de forma diferente.
  • perspectiva sob a qual o processo é modelado. Se o processo TO BE foi modelado unicamente sob a perspectiva de negócio (em que o controle do processo é executado por pessoas), ou se ele foi modelado já sob a perspectiva da automatização (em que o controle do processo é realizado pelo BPMS).

Percebemos, no mercado de ferramentas de BPMS, que existe um movimento no sentido de deixar a transição do modelo TO-BE para o modelo automatizado um pouco mais suave. Na última versão do Oracle BPM 11g, por exemplo, apenas 3 tipos de atividades (humana, serviço e regra de negócio) serão exibidas por padrão na trilha de auditoria dos processos, ocultando outras atividades mais técnicas (ex: adapters, scripts) que possam estar sendo utilizadas.

Podemos ver que não existe uma solução ou resposta simples para esta questão, em virtude da quantidade de fatores envolvidos que podem gerar esta diferença dos processos TO-BE em relação aos processos automatizados.

Uma forma de minimizar este impacto é que a equipe de tecnologia (analista de sistemas) se envolva no redesenho do processo, analisando juntamente com a área de negócio as melhorias tanto sob o aspecto de negócio quanto sob o aspecto tecnológico, de forma que o analista de sistemas traga para o TO BE a perspectiva do processo automatizado.

Uso do MDS (MetaData Service) no Oracle SOA Suite

O Oracle SOA Suite, solução da Oracle para integração de sistemas e automação de processos, na sua versão 11g, trouxe muitas novidades, se compararmos com a versão 10g. Uma delas foi o MDS, ou o MetaData Service. Nesse post vamos falar sobre ele, procurando esclarecer para que serve e como utilizá-lo.

Definição
O MDS é um repositório unificado para armazenamento de arquivos (metadados) usados nos projetos do SOA Suite. Quando, por exemplo, um projeto BPEL ou BPM é implementado (deploy) os seus arquivos são armazenados no MDS.

Além disso, é possível utilizar o MDS para outros fins, como, por exemplo, compartilhar artefatos comuns entre os vários projetos, sejam eles schemas XML (XSD), arquivos EDL, DVM ou WSDL.

Porque usar o MDS para artefatos comuns?
O MDS provê maior segurança e melhor manutenção dos artefatos comuns aos projetos do SOA Suite. Existe total compatibilidade com o JDeveloper (IDE de desenvolvimento) para visualizar o conteúdo do repositório e total compatilidade do EM para a sua manutenção.

Um exemplo de situação que justifica o uso do MDS é quando um arquivo XSD é compartilhado por vários projetos, o que ocorre com certa freqüência quando utilizamos modelos canônicos. Ter uma cópia desse arquivo em cada projeto pode gerar um problema de manutenção (pensemos que, cada nova versão do arquivo deveria ser replicada 10, 20 vezes, dependendo da quantidade de projetos envolvidos na integração). Se utilizamos o MDS, os projetos envolvidos farão uma referência para ele no repositório e, sempre que o arquivo XSD for atualizado, automaticamente todos os projetos também estarão atualizados.

Como utilizar o MDS
Existem duas versões do MDS: uma armazenada em forma de arquivos e outra registrada no banco de dados (servidor). A primeira é usada para o desenvolvimento e pode ser salva, por exemplo, num repositório subversion (GIT, SVN, CVS, TFS, etc), de forma que todos os desenvolvedores tenham acesso ao conteúdo.

A versão do banco de dados, por sua vez, será aquela utilizada pelo servidor SOA Suite, que estará rodando sobre um server Weblogic. Assim será necessário implementar (deploy) o conteúdo dos arquivos no banco de dados para que o servidor tenha acesso ao conteúdo atualizado pelos desenvolvedores.

Cada projeto utiliza um padrão próprio para implantação (deploy) dos projetos no servidor SOA Suite. Esse artigo explica como criar a árvore de arquivos e como atualizar o MDS da maneira nativa, ou seja, via JDeveloper.

Uma vez que o MDS esteja configurado e com o conteúdo armazenado, a referenciação dentro do projeto é bastante simples, bastando informar, na localização, o caminho completo dentro do MDS e incluindo o prefixo oramds. Veja no exemplo:

  • Para referenciar o XSD que está no caminho apps/MyCannonical: oramds:/apps/MyCannonical.xsd
  • Para referenciar um WSDL:

 

Utilizar o MDS em projetos SOA Suite é uma opção de arquitetura que pode simplificar muito o desenvolvimento. Porém, é necessário que exista um forte controle das atualizações dos arquivos locais e do banco de dados. Trabalhar com multi-desenvolvedores também pode causar algum tipo de transtorno caso isso não ocorra.

Podem haver problemas, também, no uso compartilhado do conteúdo do repositório. Indispensável dizer que deve haver uma preocupação muito grande quando esses artefatos forem atualizados, evitando incompatibilidade com outros projetos.