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.

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

Oracle SOA Suite 11g: uso da atividade assign no BPEL

Trabalho com desenvolvimento BPEL há alguns anos utilizando o produto da Oracle, o SOA Suite, e tenho acompanhado a sua evolução desde a versão 10g, incluindo a IDE de desenvolvimento, o JDeveloper.

Recentemente estive envolvido em um projeto e precisei utilizar em diferentes contextos o componente assign. Nas versões mais recentes do produto existe uma sensível diferença na interface para realizar as atribuições e isso me motivou a escrever esse post, na tentativa de destacar e exemplificar o uso do copy e das suas regras: copy listappend, insert after e insert before.

Nos exemplos abaixo utilizei uma VM produzida pela Oracle (disponível aqui) e configurada com:

Oracle Enterprise Linux (64-bit) EL 5 Update 5
Oracle XE Database 11.2.0
Oracle SOA Suite 11.1.1.6.0 (includes Service Bus)
Oracle BPM Suite 11.1.1.6.0
Oracle JDeveloper 11.1.1.6.0
JRockit R28.2.0-79-146777-1.6.0_29s

O valor de input utilizado nos testes foi:

<inputVariable>
    <part  name="payload">
        <ns1:OrdemServicoRequest xmlns:ns1="http://xmlns.oracle.com/DDM">
            <ns1:CodigoOS>123</ns1:CodigoOS>
            <ns1:DataAberturaOS>22/09/2012</ns1:DataAberturaOS>
            <ns1:TipoOS>OS</ns1:TipoOS>
            <ns1:StatusOS>Iniciado</ns1:StatusOS>
            <ns1:DataEncerramentoOS>25/09/2012</ns1:DataEncerramentoOS>
            <ns1:Codigocliente>12114</ns1:Codigocliente>
            <ns1:NomeCliente>José da Silva Sauro</ns1:NomeCliente>
            <ns1:EnderecosCliente>
                <ns1:EnderecoCliente>
                    <ns1:Rua>Rua 1</ns1:Rua>
                    <ns1:Numero>2</ns1:Numero>
                    <ns1:Complemento>Bairro 3</ns1:Complemento>
                    <ns1:Cidade>Longe de Tudo</ns1:Cidade>
                    <ns1:Estado>Algum</ns1:Estado>
                    <ns1:CEP>01000-000</ns1:CEP>
                </ns1:EnderecoCliente>
                <ns1:EnderecoCliente>
                    <ns1:Rua>Rua 2</ns1:Rua>
                    <ns1:Numero>3</ns1:Numero>
                    <ns1:Complemento>Bairro 4</ns1:Complemento>
                    <ns1:Cidade>Perto de Tudo</ns1:Cidade>
                    <ns1:Estado>Nenhum</ns1:Estado>
                    <ns1:CEP>02000-000</ns1:CEP>
                </ns1:EnderecoCliente>
            </ns1:EnderecosCliente>
            <ns1:EmailCliente>jose@sauro.sil</ns1:EmailCliente>
        </ns1:OrdemServicoRequest>
    </part>
</inputVariable>

 

  • Uso tradicional do copy

O uso tradicional do copy serve, entre outras coisas, para atribuição de valores para variáveis à partir de outras variáveis ou funções pré-definidas no produto (expression).

Copy tradicional

Nesse caso temos o uso do assign com o copy tradicional. Cada campo utiliza uma solução diferente: atribuição direta de variável, atribuição de valor textual e utilização de uma função pré-definida do produto (no exemplo, current-dateTime()).

O retorno dessa atribuição será:

Copy tradicional - resposta

Resultado da execução

 

  • Uso do append

O append irá inserir um elemento ao final da lista, sem alterar o conteúdo já existe. Veja o exemplo abaixo.

Nesse exemplo foi criado um elemento para ser inserido na lista de status. Depois de alimentar as informações com valores válidos, foi incluído o elemento na lista de status com a regra append.

O resultado da lista, nesse momento do exemplo, são dois elementos.

Esse é o resultado da lista com o elemento incluindo no append.

 

  • Uso do copyList

A regra copyList tem por característica eliminar todos os elementos que já existirem na lista de destino e substituir integralmente o seu conteúdo, incluindo elementos e atributos.

No nosso exemplo incluímos um terceiro assign, depois dos dois assigns dos exemplos acima, com a regra copyList. Note que o array destino continha, até então, dois elementos. Os dois foram excluídos e um novo elemento será incluído, conforme exemplo. Para deixar claro o exemplo, incluímos dois elementos utilizando o copyList. O valor final do array irá conter somente o segundo valor inserido.

copyList assign

Observe que foram incluídos 2 novos elementos usando o copyList. Somente o segundo irá aparecer no array, já que a função copyList tem por princípio eliminar todos os elementos do destino antes de alimentar a variável com os novos valores.

O resultado final da lista conterá somente o segundo elemento inserido.

copyList response

O resultado do exemplo depois do uso do copyList no último assign.

 

  • Uso do insertBefore e insertAfter

O nosso último exemplo é para demonstrar o uso do insertBefore e insertAfter. O primeiro irá incluir um elemento antes do elemento assinalado no destino e o segundo, depois.

Nesse ponto do exemplo temos somente 1 elemento na lista. No último assign incluímos dois novos elementos: um utilizando insertBefore e outro utilizando insertAfter. Veja abaixo o resultado desse array.

O resultado final da lista será:

O resultado da lista com os valores incluídos antes e depois do elemento que já estava na lista.

 

A atividade assign é uma ótima opção para atribuição de valores às variáveis, muitas vezes eliminando a necessidade de uma transformação. Conhecer bem as suas regras ajuda a tirar proveito de todos os recursos envolvidos.

Um detalhe, por experiência de projeto, é que essa janela pode se tornar muito lenta no caso de utilização de schemas (XSD) que ficam armazenados em servidores remotos e no MDS. Esperemos que isso melhore nas próximas versões do produto.

O projeto utilizado no exemplo está disponível para download no link abaixo:

  • [download id="1"]

Orquestrar é uma arte

Recentemente perdi o sono com um pensamento que me intrigou positivamente. Fiquei impressionado por ter constatado algo tão simples e, ao mesmo tempo, tão interessante.

Trabalho com orquestração de webservices há mais de 2 anos. Também sou músico amador há pelo menos 25 e talvez, até o momento, eu nunca tivesse feito uma relação entre as duas coisas.

Ora, a coisa é simples! Imaginemos uma orquestra musical. Nela, o maestro é responsável por determinar o tempo da música, o seu pulso. Os gestos que ele faz determinam a textura da música, ou seja, se as notas vão ser mais suaves ou mais duras; e a amplitude da regência determina o volume (forte ou piano), quando a música deve crescer e quando deve diminuir; em suma, a interpretação dinâmica.

Além disso o maestro é quem dá as entradas para os músicos (já que nem todas as músicas começam e terminam com todos os instrumentos tocando ao mesmo tempo) e também determina o fechamento da música de forma que todos os músicos possam parar de tocar na hora certa.

A maioria dos maestros faz uma regência bem parecida, mas as diferenças são adaptáveis, dependendo do seu costume e dos ensaios.

O maestro, porém, não pode fazer tudo sozinho. Ele é o ‘regente’ e é quem deve ter a capacidade de contagiar sua orquestra. Mas não é ele que, no fim, irá gerar o som… É aí que entra o papel dos músicos e dos seus instrumentos. Se os músicos são bons o resultado é fabuloso!! Igualmente, se os músicos são limitados, não há maestro que faça milagres… E, por mais fantástico que seja um instrumento, se o musicista não é tão competente assim, o resultado pode ser desastroso. E vice-versa.

Se não bastasse, ainda devemos pensar em utilizar o instrumento certo para a tarefa certa, e este deve estar devidamente afinado. Não posso utilizar uma flauta no lugar de um baixo, por exemplo.

Algo semelhante ocorre na orquestração de sistemas. A orquestração é capaz de integrar sistemas de forma melodiosa e harmônica. Ela dita o ritmo da integração, invocando o serviço certo no momento certo, informando as entradas de cada serviço. Mas esse ‘maestro’ é totalmente dependente do serviço, o nosso músico, ao ponto de limitar-se à tarefa de realizar uma requisição e obter ou não uma resposta.

Esse exemplo também nos ajuda a visualizar os papéis envolvidos num processo de orquestração. Se pensarmos que a orquestração é como o maestro e os serviços são como os músicos, fica muito claro entender a separação entre a lógica da orquestração e a lógica de negócio: assim como o maestro não toca nenhum instrumento, a lógica de negócio não deve ser implementada junto com a lógica de orquestração e sim em serviços separados para serem orquestrados.

É fundamental, também, escolher o instrumento certo para tocar o trecho correto. O instrumento errado ou desafinado pode comprometer toda a orquestração, toda a peça. Da mesma forma que o serviço chamado na hora errada poderá comprometer os resultados da orquestração.


Chego à conclusão que orquestrar é uma arte!! E é por isso eu tenho tanto prazer em desenvolver esse tipo de trabalho!

Respostas sobre o webinar: A orquestração para integração de sistemas

Recentemente tive a oportunidade de apresentar um webinar pela iProcess sobre “A orquestração como instrumento para integrar sistemas”, que apresentou conceitos de SOA, BPEL e orquestração de webservices, além de apresentar uma breve introdução sobre como desenvolver projetos de integração utilizando orquestração.

Você pode rever o webinar no canal do Youtube da iProcess ou nos links abaixo:

Ao final do webinar recebemos algumas perguntas dos nossos participantes. Procurei resumir abaixo em principais idéias, levando em consideração que alguns assuntos são amplos e seria impossível esgotar o argumento nas respostas. Deixo aos leitores completarem com seus comentários e percepções.

1) Quais são as principais vantagens da utilização de BPEL em relação ao desenvolvimento de um serviço orquestrador, escrito em Java por exemplo?

Entendo, com essa pergunta, que estamos falando da utilização de um produto que implementa o SOA/BPEL. Vou pegar como exemplo o Oracle SOA Suite 11g, que inclusive foi desenvolvido em Java.

Falemos, então, de vantagens e desvantagens da utilização desse tipo de produto.

VANTAGENS

  •  a principal vantagem é poder contar com uma infraestrutura de middleware pronta (estilo caixa-preta) que possibilita o rápido desenvolvimento de soluções complexas, além de incluir o controle de instâncias de curta e longa duração, a disponibilização de adaptadores para conexão direta a diferentes serviços (banco de dados, AQ, MQ, JMS, arquivos, webservices, etc), monitoramento do ambiente, ferramentas de configuração, etc;
  • a possibilidade de implementar rapidamente processos de negócio bem definidos;
  • no caso do Oracle SOA Suite, é possível utilizar toda a infraestrutura disponibilizada pela suite, que inclui, além do BPEL, componentes de business rules, tarefas humanas (human task), mediator e BPM.

DESVANTAGENS

  • quando trabalhamos em projetos que exigem alta-disponibilidade, grandes quantidades de operações por minuto, cloud-computing, grande quantidade de serviços, entre outros desafios, o middleware deixa de ser uma caixa-preta e passa a ser uma caixa-cinza, exigindo do time de arquitetura, desenvolvimento, infraestrutura e suporte um conhecimento profundo do produto, o que nem sempre é fácil;
  • o custo do produto costuma ser alto;
  • o middleware é um produto que inclui muitas camadas (sistema operacional, máquina virtual [Java, por exemplo], banco de dados, conexões diversas, além de utilização de memória, disco, processador, temperatura). Em ambientes de produção tudo isso deve ser controlado. Nem sempre é fácil identificar rapidamente quando um problema ocorre, exigindo novamente grande conhecimento do produto.

 

 

2) Quando vai ser feita a implantação de uma orquestração, espera-se que já esteja implementada uma arquitetura orientada a serviço?

Não necessariamente. Como foi comentado durante a apresentação, uma boa orquestração prevê a descrição do processo de negócio que será orquestrado e todos os pontos de orquestração bem definidos.

Porém já tivemos casos de orquestração que utilizavam somente troca de arquivos, conexões a banco de dados e filas e acesso direto a API’s de outros sistemas utilizados pela empresa, sem que existisse, de fato, uma arquitetura orientada a serviço na empresa.

É certo, porém, que os projetos que podem contar com esse pré-requisito acabam utilizando melhor todos os recursos que a orquestração dispõe, desde o controle das instâncias, erros e execuções até o completo monitoramento do ambiente como um todo.

3) É comum construir orquestração de serviços e “expor” essa orquestração dentro de um ESB?

Já atuei em projetos que nem sequer utilizavam ESB e outros que expunham sempre um serviço no ESB. Na minha visão isso depende da arquitetura que será utilizada no projeto.

4) Gostaria que o Eduardo comentasse mais sobre os papéis dos projetos e a interação entre eles.

Durante a apresentação utilizamos a imagem abaixo:

Falando um pouco sobre a função de cada um desses papéis:

  • Arquiteto de integração: ele será responsável por desenhar toda a solução técnica da integração e definir quais serão os padrões utilizados. É papel do arquiteto, também, desenhar os diagramas de componentização das integrações.
  • Analista de processo: irá trabalhar junto aos usuários de negócio na definição dos processos que serão orquestrados e na definição da estrutura de dados.
  • Desenvolvedores e técnicos de infraestrutura que farão o desenvolvimento das integrações propriamente ditas.

Nos projetos nos quais trabalhei a figura do arquiteto foi essencial. Ele deve ter clara a visão do todo e entender realmente o problema, definindo quais recursos de TI serão utilizados na integração. Além dele, o analista de processo tem um papel fundamental na compreensão e na documentação dos processos que serão automatizados e orquestrados, cabendo aos desenvolvedores uma boa implementação e aos técnicos de infraestrutura a garantia de que o middleware estará bem configurado para suportar a solução.