Seja o profissional que vai liderar a Transformação Digital nos negócios da sua empresa

A equipe da iProcess orgulhosamente apresenta o curso de
TRANSFORMAÇÃO DIGITAL ORIENTADA A PROCESSOS,
um programa de treinamento à distância criado para formar os profissionais que conduzirão as organizações para transformar os seus processos com o uso da tecnologia, aliando inovação a eficiência.

Participe desta experiência que alia a teoria à prática, com dezenas vídeo aulas, artigos e cases alinhados com demonstrações de ferramentas e exercícios práticos de modelagem e automação em soluções de diferentes fornecedores, formando conhecimento através de uma vivência que facilitará o desenvolvimento da transformação digital na sua organização.

  • Conheça os conceitos da transformação digital, as tecnologias que viabilizam esta transformação e os benefícios da sua aplicação.
  • Entenda como as plataformas de processos podem se integrar aos sistemas de informação da organização.
  • Aprenda como fazer esta transformação, estudando e aplicando técnicas e ferramentas de redesenho tecnológico, que multiplicam a eficiência dos processos com o uso da tecnologia.
  • Compreenda os principais problemas e desafios e prepare-se para a jornada da transformação digital, analisando como as áreas de negócio podem liderar este movimento.
  • Saiba como aplicar uma metodologia ágil de transformação que traga ganhos rápidos, crescentes e constantes.

Conheça mais, inscreva-se e participe!

Quero me inscrever agora

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:

5W2H: Ferramenta para a elaboração de Planos de Ação

timetoplan“Qualquer medição de desempenho deve começar com a identificação de o quê vai ser medido, o porquê de ser medido e qual valor será usado para comparação”.

Esta é uma recomendação do BPM CBOK v3.0 que culmina com a proposição de um instrumento para levantamento de medições, em forma de tabela (página 192), a serem realizadas nos processos, onde deverão ser considerados:

  • os objetivos da medição
  • os itens a medir
  • os parâmetros de comparação
  • os locais ou pontos onde as medições serão realizadas
  • o que deve ser medido
  • como serão realizadas as medições e
  • os responsáveis pelas mesmas.

É interessante perceber que BPM utiliza conceitos, termos e terminologia já consagradas e de uso tão popularizado como o 5W2H, oriundo da Gestão da Qualidade. Afinal, processos têm tudo a ver com qualidade, eficiência e desempenho. Nenhuma novidade de fato, pois BPM também assimila outros conceitos da administração, de disciplinas como a Reengenharia e Qualidade Total.

Muitas pessoas da área de processos, porém, possuem formação na área de tecnologia e tais conceitos podem não ser muito familiares. Por isso resolvemos chamar a atenção para essa ferramenta, os conceitos envolvidos e sua utilização.

5W2H é uma ferramenta para elaboração de planos de ação que, por sua simplicidade, objetividade e orientação à ação, tem sido muito utilizada em Gestão de Projetos, Análise de Negócios, Elaboração de Planos de Negócio, Planejamento Estratégico e outras disciplinas de gestão. De origem atribuída a diferentes autores, que vai desde os trabalhos de Alan G. Robinson, Rudyard Kipling, Marco Fábio Quintiliano até Aristóteles, essa ferramenta baseia-se na elaboração de um questionário formado por sete perguntas:

5W2H

As sete perguntas essenciais

Note que a sigla 5W2H origina-se nas letras iniciais das perguntas que devemos realizar.
O conceito por trás do termo significa que uma ação é influenciada por sete circunstâncias e que, ao elaborar um plano de ação, devemos responder, de modo formal, às seguintes questões:

  • O que deve ser feito? (a ação, em si);
  • Por que esta ação deve ser realizada? (o objetivo);
  • Quem deve realizar a ação? (os responsáveis);
  • Onde a ação deve ser executada? (a localização);
  • Quando a ação deve ser realizada? (tempo ou condição);
  • Como deve ser realizada a ação? (modo, meios, método, etc);
  • Quanto será o custo da ação a realizar? (custo, duração, intensidade, profundidade, nível de detalhamento, etc).

Aproveitando o clima da Copa do Mundo no Brasil, vamos exemplificar elaborando um plano de ação para organizar um evento de confraternização mensal para os funcionários de uma empresa, com o tema do campeonato mundial, em uma hipotética final entre Brasil e Argentina. (clique para ampliar)

Final Brasil x Argentina

Final Brasil x Argentina

Está claro que a ordem dos eventos pode ser alterada de acordo o tipo de evento, de organização, de contratação e etc. Colocamos as ações do plano em ordem cronológica (coluna Data) considerando uma possível dependência entre atividades. Mas essa é apenas uma abordagem.

É possível verificar, também, que as colunas “Custo” e “Local” não são tão úteis nesse caso, por ser um plano simples e por haver pouca variação nessas variáveis. Devemos considerar todas as sete circunstâncias descritas para elaborar o plano de ação, mas em casos em que uma destas circunstâncias seja fixa (como uma mesma data de realização, por exemplo) podemos deixar de representá-la em uma coluna de nossa tabela.

Da mesma forma, pode haver situações em que sejam necessárias ou desejáveis informações adicionais em nossa tabela. Além das circunstâncias normais, previstas na ferramenta 5W2H, podemos adicionar informações não necessariamente ligada às circunstâncias, mas que qualificam a própria ação ou seus resultados.

No exemplo abaixo, baseado na tabela  para levantamento de medições do BPM CBOK citada no início do artigo, percebe-se uma correspondência dos nomes dos atributos de medição com as questões do 5W2H:

Tabela para levantamento de medições

Levantamento de medições com 5W2H

No exemplo, as perguntas “O quê”, “Por quê”, “Onde”, “Como” e “Quem” são respondidas pelos atributos “Item a medir” + ” O que medir”, “Objetivo da medição”, “Onde medir”,  “Como será medido” e “Responsável pela medição”, respectivamente.

Note que foram suprimidas as questões “Quando” – visto que a medição deverá ser executada automaticamente pelo processo ou sistema – e “Quanto”, pois não se aplicam a este caso. Também foram adicionados dois atributos de medição que não corresponde a nenhuma das 7 questões da ferramenta: “parâmetro de comparação” e “polaridade do indicador”.

Se você ainda não utiliza 5W2H em suas tarefas diárias, comece a pensar quais os planos de ação você poderia formalizar com esta ferramenta e coloque em prática na primeira oportunidade. Você perceberá que se trata de um excelente modo de formalização do planejamento, detalhamento da ação, comunicação de prazos e responsabilidades. E lembre-se de compartilhar nos comentários as suas experiências e dicas.

Desafios intangíveis da implantação SOA – compartilhando experiências

Apesar da Arquitetura Orientada a Serviços não ser novidade, com inúmeros livros, artigos e materiais publicados sobre o tema, verificamos no decorrer da experiência em projetos que existe ainda uma grande discrepância na compreensão do conceito que existe por trás dessa sigla. Com frequência vemos “SOA” sendo usado para descrever uma camada com serviços de integração, muitas vezes ponto a ponto, desconsiderando totalmente a riqueza de critérios relacionados ao conceito.

Essa distância entre proposição e aplicação não é exclusividade de SOA. No desenvolvimento ágil de software, por exemplo, muitos projetistas e empresas afirmam usar SCRUM, enquanto possuem somente um grande backlog de tarefas e um quadro kamban com a lista de TO DO, DOING, DONE. Muitas vezes utilizam-se desse artifício para justificar uma documentação precária. Mas isso é um outro assunto. :)

Em projetos de integração, quando é necessária uma camada – obviamente – de integração, comumente usa-se o termo camada SOA para defini-la. Mas sem um alinhamento arquitetural apropriado, esta camada acaba se restringindo simplesmente a um aplicativo cuja função é fazer com que dois ou mais sistemas possam trocar informações entre si. Isso por si só não caracteriza SOA e não gera nenhum benefício e nem ganho tangível para a organização. Esta distorção do conceito pode causar uma grande antipatia por parte de clientes e usuários. Assim, em algumas situações, chega-se ao ponto que, basta ouvir falar em ‘SOA’, que a rejeição é certa!

Com o tempo começamos a observar que esse é, talvez, um dos maiores limitadores para que a arquitetura orientada a serviços ganhe espaço hoje nas organizações. Sem conhecer com um pouco mais de profundidade o conceito é praticamente impossível que haja aceite da utilização desse tipo de arquitetura por parte do financiador do projetos. É difícil justificar SOA do ponto de vista tempo, custo e escopo. Pensar em criar serviços que serão reutilizáveis e outros artifícios como governança nem sempre são reconhecidos quando falamos de um cenário de TI que, atualmente, trabalha sempre com curtos prazos e projetos que já começam atrasados.

Se você também se depara com essas situações no seu dia-a-dia, queremos saber o que você faz para lidar com elas. De qualquer maneira, aproveitamos pra compartilhar algumas lições aprendidas nossas:

  1. Procure compreender o conceito de SOA. Aqui no nosso blog temos alguns artigos sobre o tema (veja esse, por exemplo). Se preferir um livro, sugerimos a literatura de Thomas Erl, especialmente dois: “SOA: Concepts, Tecnology and Design” e “SOA: Principles of Service Design“.
  2. Deixe claro o que é e o que não é SOA. Quando o seu cliente chamar a camada de integração (por exemplo, ponto a ponto) de “SOA”, esclareça que isso não é uma arquitetura orientada a serviços. Se precisar justificar, lembre-se que:
  • SOA não é
  • uma tecnologia
  • uma metodologia
  • algo que se compra e que se instala
  • um webservice
  • SOA é:
  • uma filosofia arquitetural
  • baseada no conceito do uso de serviços atômicos, independentes e com baixo acoplamento

Falando de SOA, precisamos falar também de serviços. Segundo Erl, existem oito requisitos que definem uma boa implementação de serviços para que a implantação de SOA seja satisfatória. São eles:

  • Contrato de Serviço Padronizado: serviços dentro do mesmo inventário de serviços estão em conformidade com os mesmos padrões de design de contrato.
  • Serviço com Fraco Acoplamento: os contratos de serviços exigem e impõem baixo acoplamento e estão dissociados de seu ambiente e escopo.
  • Abstração de Serviço: contratos de serviços contém apenas informações essenciais. Informações sobre os serviços são limitas ao que é publicado em contratos de serviços.
  • Reutilização de Serviço: serviços contém e expressam uma lógica agnóstica e podem ser posicionados como recursos corporativos reutilizáveis.
  • Autonomia de Serviço: serviços exercem um alto nível de controle sobre o ambiente de execução.
  • Serviço statelessness: serviços minimizam o consumo de recursos, adiando a gestão da informação do estado, quando necessário.
  • Descoberta de serviço: serviços são complementados com meta dados comunicativos, onde cada um deles pode ser efetivo.
  • Modularidade de Serviço: serviços são participantes efetivos em composições (composites), independentemente do tamanho e da complexidade da composição.

Estas são algumas informações que podem ser úteis para você que também acredita nos valores de SOA.

E nós aguardamos suas experiências. :)

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.

Encontre a turma de BPM e SOA na rede

Business Process Management (BPM) e Service Oriented Architecture (SOA) são temas de discussões em diversos canais de redes sociais.

Facilitamos a sua vida reunindo aqui links para algumas destas comunidades virtuais:

BPM Forum

É o principal forum de BPM no Brasil, com mais de 1700 inscritos. Abrange desde tópicos altamente voltados à filosofia BPM aplicada aos negócios até questões relacionadas a tecnologia:

AN.br

Esse fórum é de Analistas de Negócios, mas eventualmente são levantadas questões relacionadas a BPM:

Grupos no Linkedin

Grupos no Facebook

FreeBPM

Fórum brasileiro sobre plataformas livres de BPM:

Sites

 

E é claro, você pode acompanhar atualizações de conteúdo da iProcess através dos seguintes canais: