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:

Caso de Sucesso – Aumento da produtividade e efetividade nos negócios do SICREDI com a adoção de SOA e BPM

Marcio Lermen, gerente de tecnologia do Sicredi

Durante o Oracle Open World 2012 em São Paulo, Marcio Lermen, gerente de tecnologia do Sicredi, apresentou como caso de sucesso a adoção da suíte de SOA e BPM da Oracle para a automação dos processos da organização e o uso do Oracle Exalogic como plataforma de hardware e software para dar alta performance a esta suíte.

De acordo com Marcio, a escolha destas tecnologias foi feita dado o desafio que o Sicredi tinha quanto a decisões e processos manuais em um cenário de negócio complexo, em que os processos estão distribuídos entre as cooperativas do sistema. A adoção destas tecnologias viabilizou o redesenho e automação dos processos, apresentando excelentes ganhos no controle da execução dos processos.

Dentre os benefícios obtidos com esta adoção, foi mencionado o ganho de tempo na execução de um processo. Em alguns casos, a automação de um processo (que antes era ad-hoc e feito via envio de e-mails e trocas de telefonemas) fez com que o ciclo de vida do mesmo, que costumava levar vários dias, pudesse ser realizado no mesmo dia. Além disto, foi mencionado o ganho de desempenho com o uso do Oracle Exalogic, que chegou na ordem de 4 a 6 vezes. Segundo Márcio, para conseguir esta performance foi preciso que todos os serviços envolvidos estivessem dentro do Exalogic.

Como pontos importantes apresentados por ele, foram citados os seguintes fatores:

  • o mapeamento e desenho do processo as-is e to-be antes da automação do mesmo;
  • a definição dos pontos onde serão gerados indicadores (que serão enviados ao BAM na execução) durante a definição do processo;
  • a quebra do processo principal em subprocessos menores, inclusive para facilitar o controle de versão e o desenvolvimento;
  • governança SOA, contendo uma arquitetura bem definida, além da necessidade de uma garantia de que a mesma será utilizada dentro dos projetos.

Foram mostrados alguns exemplos de processos criados utilizando Oracle BPM, sendo que muitos deles foram mapeados e criados em parceria com a iProcess.

É um orgulho para nós poder fazer parte de cases de sucesso em BPM do sicredi.

Governança SOA – A chave para o sucesso de uma implantação

Esse é o quinto de uma série de artigos do nosso blog que estão abordando o tema SOA, conceito antigo e atual que está enraizado nas atividades cotidianas da iProcess.

No primeiro post nós respondemos à pergunta: o que é SOA? Já no segundo definimos o que é um serviço e, no terceiro, trouxemos algumas estratégias que podem ser utilizadas na definição e na escolha de bons serviços candidatos.

O post seguinte abordou a relação entre SOA e BPM para garantir o sucesso da automação de processos. Neste artigo falaremos sobre Governança SOA como chave para o sucesso de uma implantação.

 

Objetivo: alinhamento com o negócio
A governança SOA consiste na definição de processos que garantam que os objetivos de SOA e da área de TI sejam atingidos. Para isso, a iniciativa deve:

  • definir um conjunto de instrumentos gerenciais que a instituição estabelece para garantir o sucesso e a sustentabilidade da iniciativa SOA;
  • definir claramente papéis e responsabilidades.;
  • avaliar a criação de estruturas destinadas a gerir a iniciativa de SOA.

Se os processos de governança não forem claros, a iniciativa SOA cairá em descrédito e rapidamente fracassará. Nesse sentido, seu principal desafio é gerencial e não técnico, e o ponto central sempre será o alinhamento dos processos com o negócio.

Os processos de governança
De acordo com a experiência da iProcess e a literatura disponível, podemos citar alguns dos principais processos de governança a serem criados. São eles:

  • capacitação das equipes em SOA;
  • identificação dos possíveis serviços a serem criados do ponto de vista corporativo (portfólio de serviços);
  • desenvolvimento de novos serviços;
  • análise do aproveitamento dos serviços existentes;
  • modificação/evolução dos serviços existentes;
  • desativação de serviços;
  • garantia do desempenho e estabilidade dos serviços em operação;
  • estimular/recompensar o reuso e a criação de novos serviços que tragam ganhos;
  • gestão da arquitetura corporativa (mesmo se a definição não precisa partir de SOA, SOA precisa disto);
  • planejamento das iniciativas SOA;
  • gestão de projetos SOA;
  • gestão da inovação;
  • definição de metodologia e padrões;
  • gestão dos acordos de nível de serviço (SLA).

Estrutura de trabalho
A governança também define, se necessário, as estruturas de trabalho para a sua equipe. Ela poderá conter um escritório SOA, uma área específica de arquitetura ou um núcleo de conhecimento. Também poderá centralizar a supervisão dos projetos SOA.

Outra opção é implantar um Centro de Excelência SOA. Trata-se de um comitê que conta com a presença de um conselho de especialistas no assunto (técnicos e de negócio) que auxiliam na tomada de decisão e encaminhamento das atividades de SOA.

Responsabilidades
Algumas das atividades que são responsabilidade da equipe de governança são:

  • gerência do repositório de serviços;
  • gerência do registro de serviços;
  • gerência da reutilização de serviços;
  • definição de boas práticas e metodologias;
  • treinamentos e atualização.

No caso de empresas que estão no estágio inicial de implantação de SOA, não é necessário pensar numa grande infraestrutura ou em soluções muito sofisticada para realizar as atividades de governança. A wiki corporativa ou mesmo planilhas podem ser suficientes para gerenciar e publicar as informações de governança.

Entre os documentos fundamentais a serem criados pela equipe de governança, sugere-se começar com a lista de serviços. Se essa informação não estiver disponível, existe um grande risco da não reutilização dos serviços já existentes.

SOA X Confiança
O sucesso de uma iniciativa SOA é baseada na confiança, já que quem consome os serviços conhece somente a sua interface e desconhece como ele foi implementado.

Nesse sentido temos um grande desafio de implantar SOA no Brasil, onde existe uma cultura muito forte da desconfiança no relacionamento entre desconhecidos. Se você não conhece tudo no detalhe, a premissa é desconfiar. É importante levar isso em consideração na hora organizar as ações de governança, inclusive criando alternativas para que isso não seja motivo de fracasso.

SOA – A relação com BPM no sucesso da automação de processos

Esse é o quarto de uma série de artigos do nosso blog que estão abordando o tema SOA, conceito antigo e atual que está enraizado nas atividades cotidianas da iProcess.

No primeiro post nós respondemos à pergunta: o que é SOA? Já no segundo definimos o que é um serviço e, no terceiro, trouxemos algumas estratégias que podem ser utilizadas na definição e na escolha de bons serviços candidatos.

Nesse post vamos abordar a relação entre SOA e BPM para garantir o sucesso da automação de processos.

Mercado está mais exigente
O mercado hoje está cada vez mais desenvolvido, informado, informatizado e em busca de soluções capazes de traduzir em resultados eficazes e eficientes as necessidades de empresas e seus clientes. Grandes são os investimentos em pessoal, sistemas e infraestrutura (incluindo a nuvem) que, muitas vezes, não revertem em resultados positivos.

Também não é raro encontrarmos empresas que possuem um grande emaranhado de sistemas que não são capazes de trocar informações entre si, ou processos administrativos que devem se adaptar a sistemas informatizados que não refletem a cultura e a realidade da empresa. O processo inverso – pessoas tendo que se adaptar a sistemas – também tem efeitos técnicos e humanos sérios, comprometendo as atividades e os resultados corporativos como um todo. Tudo isso sem falarmos dos sistemas redundantes e da montanha de dados de difícil (ou impossível) acesso, que impossibilitam o retorno esperado pelos gestores, que necessitam de relatórios detalhados e atualizados para tomar decisões mais acertadas.

Confusões
Existe um pouco de confusão quando falamos de BPM e SOA, seja acidentalmente, por desconhecimento dos conceitos, seja intencional, visando a promoção de produtos e serviços. Vemos alguns fabricantes de software afirmarem que “a nossa plataforma de SOA inclui ótimas ferramentas de mapeamento e redesenho de processos” ou então afirmam que “a nossa plataforma de BPM inclui um fantástico ESB”. Já algumas pessoas afirmam que “SOA deve iniciar com o redesenho dos processos“.

Relação de SOA com BPM
SOA (arquitetura orientada a serviços) e BPM (gerenciamento de processos de negócio) nascem em resposta à essas necessidades empresariais, tanto para a área de TI (SOA) quanto para a área de negócio (BPM). Ambas não foram criadas ontem (existem há pelo menos 15 anos). Então por que, agora, se fala tanto da relação entre as elas? Vejamos.

SOA é uma filosofia de TI que visa facilitar a integração entre sistemas orientando a criação e disponibilização de soluções modulares e fracamente acopladas baseadas no conceito de serviços.

SOA ajuda a TI a pensar as soluções de tecnologia de forma integrada mas com baixo acoplamento (sistemas com pouca dependência de outras funções e aplicações). Também ajuda a organizar os sistemas e as soluções corporativas, já que é a TI que deve pensar a melhor maneira de resolver os problemas do negócio (veja mais no artigo SOA – Arquitetura Orientada a Serviços).

BPM é um modelo de gestão dos processos de negócio que necessita de ferramentas de TI como apoio. É fundamental nas mãos de profissionais da área de negócio que querem aperfeiçoar os seus processos internos e garantir qualidade na entrega dos serviços.

E aqui temos a principal relação entre SOA e BPM, entre TI e negócio: um precisa do outro, um depende do outro. A TI não pode implantar sistemas sem conhecer o negócio. Já a área de negócio não pode implantar nada sem o suporte da TI.

A TI não pode implantar sistemas sem conhecer o negócio. Já a área de negócio não pode implantar nada sem suporte da TI.

Normalmente BPM é uma iniciativa da área de negócio que quer organizar os seus processos e pede auxílio à TI para fazer isso de forma automatizada. Já SOA costuma ser uma iniciativa da área de TI, com o objetivo de melhorar a sua eficácia.

BPM facilita e orienta a definição do portfólio de serviços, já que:

  • processos são consumidores de serviços;
  • serviços são atividades/funções de negócio e, portanto, fazem parte de algum processo;
  • é o método natural e alinhado ao negócio;
  • permite rastreabilidade (matriz processo x serviço);
  • possui um crescimento incremental.

A conclusão, assim, é óbvia: o alinhamento entre a área de negócio e a de TI é certamente o melhor case de sucesso para a empresa. Podemos inclusive citar alguns dos benefícios desse ‘casamento’:

Abaixo temos uma imagem que ajuda a compreender melhor a relação entre SOA e BPM, que vai do alto nível do modelo de negócio até o baixo nível da infraestrutura:

Nessa imagem fica claro que a colaboração entre a TI e a área de negócio é a fórmula mágica do sucesso. Isso requer que a TI invista tempo para aprender e compreender profundamente as necessidades da área de negócio e a área de negócio desenhe seus processos da forma mais coerente, detalhada e transparante possível e auxilie a TI na sua implementação.

Essa colaboração alinhada certamente tratá benefícios para toda a empresa, em todos os níveis – do administrativo ao gerencial.

SOA – Escolhendo e definindo bons serviços candidatos

Esse é o terceiro de uma série de artigos do nosso blog que estão abordando o tema SOA, conceito antigo e moderno que está enraizado nas atividades cotidianas da iProcess.

No primeiro post nós respondemos à pergunta: o que é SOA? Já no segundo definimos o que é um serviço.

Nesse terceiro post gostaríamos de trazer algumas estratégias que podem ser utilizadas na definição e na escolha de bons serviços candidatos.

 

Ciclo de desenvolvimento de serviços
O desenvolvimento em uma arquitetura orientada a serviços pressupõe algumas mudanças na forma com que tradicionalmente se faz o desenvolvimento orientado a sistemas.

O ciclo de desenvolvimento de serviços envolve:

Ciclo de Desenvolvimento de Serviços

Normalmente vemos que a descoberta de serviços nasce da necessidade de aprimorar alguma função ou processo de negócio. Nesse sentido, os candidatos a serviços de negócio são:

Candidatos a serviços de negócio

Existem duas abordagens comumente utilizadas na descoberta de serviços. Vamos ver abaixo.

  • Abordagem top-down: Essa abordagem identifica a necessidade de um serviço através da análise de processos de negócio ou das interações com entidades externas. Ela normalmente é realizada pelo analista de negócio em conjunto com arquiteto de sistemas e tem como principal benefício o alinhamento mais natural com o negócio. Se o serviço (ou as capacidades necessárias) já existir em um sistema legado, será necessário procurá-lo e extraí-lo. Se o serviço ainda não existir, é necessário construí-lo.
  • Abordagem bottom-up: serviços (ou capacidades) identificados através dos pontos de integração entre sistemas ou das funcionalidades já disponíveis nos sistemas atuais. Nessa abordagem corre-se o risco de criar serviços que não representam uma função de negócio ou que tenham acoplamento com a implementação. Porém, pode ser uma boa opção quando existem muitos problemas de integração spaghetti ou se deseja preparar para substituição de algum sistema de back-end.

 

Modelagem e projeto de serviços

Na hora de modelar e projetar um serviço, o primeiro passo é ajustar a sua granularidade, adequando-o a um modelo de níveis (camadas) de serviços que tenha sido definido pela sua corporação. Por exemplo:

  • Básicos (acesso a dados, funções mais simples);
  • Serviços compostos (orquestração, funções mais complexas);
  • Processos de negócio, workflows.

Outra possibilidade é classificar os serviços por área ou processo de negócio. De acordo com a granularidade, pode ser necessário quebrar em vários serviços, reunir com outros, reorganizar, etc.

 

Além disso, devem-se identificar as entidades conceituais relevantes para a empresa e suas interrelações, criando um modelo conceitual corporativo, independente das tecnologias ou sistemas já existentes.

São exemplos de entidades conceituais: Cliente, Proposta, Produto, Ordem de Compra, Item de Compra, Nota Fiscal, Centro de Custo, Funcionário.

Sugere-se também a criação de um repositório com esses modelos de dados corporativos e suas respectivas descrições de estruturas XML (esquemas XML), já que o modelo conceitual é a base para o projeto de serviços.

Poderá ocorrer que a aplicação que implementa um serviço já existente não se encaixe no modelo conceitual. Nesse caso, será preciso criar um elemento de adaptação.

 

A seguir deverá ser definido o projeto da interface. É importante salientar que a chave para um projeto duradouro de contrato de serviço é pensar apenas no negócio. A interface sempre deve ser definida antes da implementação do serviço. O nome do serviço, entradas, saídas, exceções e comportamento devem ser descritos somente em função dos termos de negócio, abstraindo implementações. Também, devem ser utilizados os esquemas XML dos tipos de dados do modelo corporativo e a interface do serviço deve ser descrita através de um arquivo no padrão WSDL – Web Services Description Language.

 

Nesse ponto, nos perguntamos: como nomear um serviço? Comprar ou vender? Notificar ou receber notificação?

A regra geral é: identifique o serviço do ponto de vista do consumidor. O consumidor pode ser sua própria empresa (solicitar compra de material) ou uma entidade externa (solicitar proposta). Se possível, utilize um meio-termo (registrar, cadastrar, criar), mas assegure-se de não gerar ambiguidades.

E as entradas e saídas de um serviço, como identificá-las?

Utilizar sempre as entidades do modelo conceitual. Resista à tentação de colocar IDs como parâmetros do serviço. Esta é uma abordagem vinculada à implementação relacional. Ex.: ID requisição → Requisição

 

Muito importante lembrar que, ao expor novas funcionalidades como serviços, serão necessários novos tratamentos de segurança. Não é mais possível contar com a segurança da aplicação, uma vez que o serviço é um ente independente. Será preciso definir:

  • quem pode executar quais serviços;
  • mensagens a serem criptografadas;
  • integração de diretórios de usuários e perfis.

Alguns dos padrões emergentes para segurança de serviços são o WS-Security, WS-Policy e SAML (Security Assertion Markup Language).

 

Existem, ainda, requisitos não-funcionais que devem ser levados em consideração. Embora os acordos de nível de serviço (SLA) sejam um aspecto gerencial, que normalmente devem ser negociados pelo gestor da TI com a área ou entidade cliente, a identificação dos requisitos de qualidade precisa ser feita o quanto antes. Aspectos como desempenho, escalabilidade e disponibilidade devem ser derivados dos requisitos do negócio e podem ser elicitados com as técnicas tradicionais da Engenharia de Requisitos. O projeto da implementação deve prover a capacidade de atender os níveis desejados.

 

Ao final da modelagem, você precisará responder afirmativamente as seguintes perguntas:

  • o serviço provê uma função de negócio?
  • o serviço é auto-condido, independente?
  • o serviço é reutilizável?
  • o serviço pode ser utilizado em uma composição?
  • o serviço esconde todos os detalhes de implementação?
  • o serviço utiliza apenas entidades conceituais na definição?

E por último responda se a interface do serviço teria que sofrer alterações se a implementação mudar. É a garantia que a modelagem do seu serviço foi realizada de maneira correta!

 

Identificando bons serviços candidatos
A definição do portfólio de serviços deve considerar os seguintes pontos:

  • redundância atual da funcionalidade;
  • quantidade de sistemas fortemente acoplados à funcionalidade;
  • volume esperado de modificações na funcionalidade;
  • grau de agilidade necessária na execução das modificações;
  • perspectiva de reutilização do serviço;
  • complexidade de fatorar o serviço dos sistemas atuais (impacto nos sistemas legados).

Uma função que só é chamada uma vez por um único sistema não é candidata e uma função que é chamada por vários sistemas é uma ótima candidata.

 

Mas, então, e na hora de criar um novo software, como identificar o que é candidato para se transformar em um novo serviço? Em primeiro lugar é fundamental entender o processo de negócio no momento de desenhar a solução de software e olhar além das fronteiras do projeto em questão. Tente identificar o que outros consumidores do seu sistema irão precisar.

No caso de softwares já existentes, verifique o que pode virar serviço, olhando para as funcionalidades internas e externas.

 

Dessa maneira será possível ter serviços consistentes e que correspondam às reais necessidades da sua empresa.