Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual

Em sua riqueza de elementos para a representação de processos de negócio, a notação BPMN traz uma classificação de tipos de tarefas.

Elas ajudam a identificar a forma como a tarefa deve ser executada:

Estes elementos e seus comportamentos esperados estão descritos na especificação BPMN (disponível em http://www.omg.org/spec/BPMN/Current). Apesar disto, a identificação de quando usar cada tipo de tarefa ainda é alvo de alguma ambiguidade.

Em uma série de três artigos, trataremos estes tipos de tarefas com mais detalhes para esclarecer as dúvidas comuns. Para facilitar o entendimento, trataremos os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefa abstrata

A tarefa abstrata (abstract task) é a tarefa sem tipo específico.

Tarefa abstrata (abstract task)

Sobre ela, a especificação diz:

“Uma tarefa sem nenhum tipo de especificação é chamada tarefa abstrata (Abstract Task) (ela era referenciada como None Task em BPMN 1.2).” (pag. 154)

Ou seja, a tarefa abstrata (abstract task) pode ser utilizada em modelagens cujo tipo de tarefa ainda não está definido ou em casos onde a tipificação da tarefa simplesmente não se faz necessária. É o caso dos processos executados manualmente.

Um processo de negócio modelado com tarefas abstratas.

Tarefas de interação humana

Para representar tarefas cuja execução envolve a atuação de pessoas em um processo, BPMN sugere dois tipos de tarefa: a user task (tarefa de usuário) e a manual task (tarefa manual).

Tarefa manual (manual task) e Tarefa de usuário (user task)

O que a especificação diz sobre estes tipos de tarefa:

“Uma Tarefa de Usuário (User Task) é uma tarefa típica de “workflow” onde um ator humano desempenha a tarefa com a assistência de uma aplicação de software e é disponibilizada através de uma lista de de trabalho ou outra forma de gerenciamento semelhante. ” (pág 160)

“Uma Tarefa Manual (Manual Task) é uma tarefa que é esperada que seja executada sem o suporte de nenhuma aplicação de execução de processos de negócio ou outra aplicação. Um exemplo disso pode ser um técnico de telefonia instalando um telefone no endereço de um cliente.” (pág 161)

“10.3.4.1 Tarefas com o envolvimento humano
Em muitos fluxos de trabalho, o envolvimento humano é necessário para executar certas tarefas especificadas no modelo de fluxo de trabalho. BPMN especifica dois tipos de tarefas com o envolvimento humano, a Tarefa Manual (Manual Task) e a Tarefa de Usuário (User Task).
A tarefa de usuário é executada e gerenciada por um motor de execução de processos de negócio. Atributos relativos ao envolvimento humano, como as pessoas envolvidas e a renderização de interfaces de usuário (UI) podem ser especificados em grande detalhe.(…)
Uma tarefa manual é uma tarefa que não é gerenciada por qualquer mecanismo de processo de negócio. Ela pode ser considerada como uma tarefa não gerenciada, não gerenciada no sentido de que o motor de processos de negócio não acompanha o início e o fim de tal tarefa.
Um exemplo disso poderia ser uma instrução de papel como base para um técnico de telefonia instalar um telefone em um local do cliente.” (pág 165)

 

Ou seja, uma user task (tarefa de usuário) é a tarefa que é executada através de uma aplicação e gerenciada por uma lista de trabalho(1). Em outras palavras, é a tarefa realizada através de uma aplicação, como um BPMS (Business Process Management Suite), uma aplicação de workflow, uma ferramenta de gestão de cronograma ou qualquer outro sistema que apoie o controle do processo.

Já as tarefas manuais (manual task) são aquelas executadas no mundo físico, sem o controle por parte de uma aplicação.

Aqui há uma confusão comum na interpretação do “uso de uma aplicação”, inclusive replicada em literatura. Para entender claramente a diferença entre elas, é preciso compreender que o que define se uma tarefa é user ou manual task não é se usamos alguma ferramenta para executá-la, e sim se há um sistema controlando a sua execução.

Isto quer dizer que, se temos por exemplo um processo de venda de produtos que é todo executado manualmente, mas em uma determinada atividade uma planilha eletrônica é usada para calcular o valor a ser cobrado do cliente, e um e-mail é enviado ao cliente com o orçamento do produto, ainda assim (apesar de usar uma aplicação de planilha e o software de e-mail para o trabalho) esta será uma tarefa manual, pois não há controle nem gestão sobre quem faz, quando iniciou e quando concluiu a tarefa.

Mesmo utilizando ferramentas como planilha eletrônica e email, ainda assim a tarefa "Apresentar orçamento" neste processo é manual.

Numa modelagem de processo que não será automatizado, e que portanto são pessoas que lerão e interpretarão o modelo, não faz muito sentido essa diferenciação, já que as pessoas, ao lerem a documentação do processo, têm condições de interpretar o modelo mesmo que os tipos de tarefas não estejam esclarecidos.

Na modelagem para automatização, entretanto, isso é muito importante. A tarefa de usuário é aquela em que o processo deve aguardar que um usuário informe o resultado do trabalho, registrando que a mesma foi concluída para então dar seguimento ao fluxo do processo. Já sobre a tarefa manual o sistema não tem nenhum controle, então mesmo que ela seja incluída no modelo, ele “passará batido” por ela.

Por exemplo:
Considere novamente o processo de atendimento de chamado, no qual há uma atividade para um técnico de telefonia para realizar uma visita técnica ao cliente, e que este processo terá sua execução controlada por uma aplicação (por exemplo um BPMS).

Neste processo, podemos ter dois cenários:

Cenário 1: O Técnico acessa uma lista de tarefas, com todos os chamados a realizar, identifica o chamado que está executando e finaliza a tarefa. Com isso, o sistema identifica que a mesma foi concluída e segue o fluxo disponibilizando a próxima tarefa ao respectivo ator responsável. Neste caso, a tarefa está sendo controlada pelo sistema (seu início e fechamento), portanto é modelada como uma tarefa de usuário.

Cenário 2: O Técnico não acessa o sistema. Ele pode, por exemplo, receber ao início do dia uma lista impressa com todos os clientes a visitar. A cada visita, o cliente assina o papel confirmando que o atendimento foi realizado. Ao fim do dia, quando o técnico retorna para a empresa, ele entrega a lista ao Atendente, que então verifica se o atendimento foi realizado e registra no sistema o resultado do atendimento. Neste caso, a tarefa do técnico é modelada como uma tarefa manual, para que fique visível aos que olham o modelo em que momento o mesmo realiza seu trabalho (e que, do ponto de vista do processo de negócio, existe uma dependência da tarefa de "Verificar resultado do serviço" em relação à "Realizar visita técnica", mas o sistema não controla o início nem o fim do trabalho realizado.

Assim, concluímos que, na modelagem com a notação BPMN, o tipo de tarefa não é definido pelo uso de sistemas para realizá-la, e sim se há alguma aplicação sendo utilizada para controlá-la.

_______

(1) Processos podem ser controlados por aplicações de diferentes tipos. Isto já foi tema deste blog no artigo Gerenciando a execução de processos com (ou sem) um BPMS.

 


Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

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

Os desafios da homologação de Processos Automatizados

O avanço do BPM trouxe muitos benefícios para as organizações, porém trouxe também alguns novos desafios. Para os usuários finais, isso gerou uma grande mudança cultural que, se não for corretamente encaminhada, pode colocar em risco toda a iniciativa BPM. Engana-se, porém, quem pensa que os usuários finais são os únicos que se depararam com mudanças importantes na adoção de BPM. Também a equipe de TI passou a ter novos desafios, e hoje iremos falar de um destes: a homologação da automação de processos.

A homologação de sistemas tradicionais de TI é um processo bem conhecido que envolve, em linhas gerais, a criação e a execução de roteiros de testes pelos testadores e usuários de negócio. Ao longo do tempo, uma série de ferramentas e metodologias surgiram para facilitar este processo, envolvendo desde a automação dos testes através de ferramentas específicas para este fim, até metodologias como Test Driven Development (TDD), que modificam significativamente o processo de desenvolvimento convencional.

Grande parte das homologações dos sistemas convencionais possuem em comum a existência de uma tela que deve ser homologada, ou seja, uma interface que é a “cara” do sistema para os usuários finais. Estas telas podem eventualmente ter grande complexidade, envolver múltiplos passos para execução e outros complicadores, mas o processo de homologação de um sistema convencional é normalmente bem direto: devem ser testadas todas as interações do usuário com as telas, e se certificar que o sistema está respondendo da forma esperada.

Esta forma de realizar os testes ainda continua válida no caso de homologação de automação de processos, e ainda existirão telas que deverão ser homologadas (nos casos em que usuários interagem com o processo), mas existem diferenças importantes. A principal delas diz respeito ao “coração” da automação de processos, que é o fluxo automatizado que deve ser testado. No lugar de ter apenas uma ou mais telas que precisam ser testadas, agora o principal foco dos testes passa a ser o processo automatizado em si, ou seja, a execução das tarefas seguindo o fluxo desenhado. Isto traz uma série de dificuldades bem específicas, e abaixo listamos algumas das mais importantes:

  • Um processo automatizado, muitas vezes, é iniciado por outro sistema. Nestes casos é preciso simular o disparo do processo manualmente, utilizando por exemplo ferramentas de testes de serviços (ex: SoapUI), que não são muito amigáveis para usuários finais. Nestes casos, também é preciso montar manualmente diferentes versões do que costumamos chamar de dados de entrada do processo, ou seja, os dados que serão exibidos e manipulados durante a execução do processo. Cada uma destas versões tratará de um diferente cenário previsto nos roteiros de testes.
  • Diferente de uma tela de sistema convencional, que via de regra pode ser homologada por um único usuário, um processo automatizado é composto de atividades enviadas para usuários diferentes, muitas vezes pertencentes a diferentes setores da organização. Desta forma, diversos usuários de negócio precisarão ser envolvidos no processo de homologação, cada um testando as atividades que lhe competem. Isto gera uma série de questões adicionais que precisam ser previstas em tempo de planejamento, como por exemplo, os tempos de espera que um determinado usuário poderá ter durante o dia, enquanto aguarda que os fluxos em execução atinjam o estágio em que este usuário participa do processo.
  • Embora sejam executados por diferentes papéis e eventualmente setores da organização, deve-se garantir a integridade e a perfeita execução do processo automatizado como um todo: isso exige um perfil que precisará acompanhar a execução do processo entre os diversos papéis/setores, e garantir a correta execução de todos os caminhos previstos. Envolve ações como, por exemplo, garantir a integridade dos dados sendo manipulados de uma atividade para outra, e garantir que o encaminhamento feito na atividade anterior executou o andamento correto no processo.
  • Muitas vezes, durante a execução do processo automatizado, existem integrações automáticas que não tem uma “interface” visível para os usuários. Por exemplo, são integrações que gravam e/ou obtêm informações em banco de dados e sistemas legados, usualmente via invocação de serviços. Nestes casos é preciso testar estas integrações manualmente durante a execução do processo, utilizando ferramentas mais técnicas (ex: a própria ferramenta de administração do BPMS), que no geral são pouco amigáveis para usuários finais. Nestes casos a homologação destas integrações tende a ser “delegada” para perfis mais técnicos do projeto, como analistas e testadores, visto que dificilmente um usuário de negócio terá o conhecimento ou perfil necessário para fazer estas verificações.
  • Em muitos casos, as aplicações acessadas para apoiar a realização das atividades foram construídas especificamente para serem invocadas através do processo. Logo, nestes casos é necessário ter preocupações adicionais de testes de segurança destas aplicações, como por exemplo:
    • Garantir que uma determinada aplicação só conseguirá ser acessada através da atividade específica que a invoca, e que não poderá ser acessada através de artifícios como, por exemplo, colar a url no navegador;
    • Garantir que somente os usuários dos papéis que estão atribuídos à atividade terão acesso aquela determinada instância de processo.

Como vimos, a homologação de automação de processos traz novos desafios em relação à homologação de sistemas convencionais, e precisa desta forma ser adequadamente planejada e estimada no cronograma do projeto.

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:

Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!

Recentemente um de nossos leitores nos escreveu sobre seu entusiasmo em iniciar uma experiência prática em BPM. Ele compartilhou conosco um desenho de processo (que discutiremos neste artigo, com a permissão do leitor) cujo objetivo era ser automatizado com dois propósitos: servir como base para a monografia e também validar o BPMS como tecnologia para automatizar processos na empresa de varejo no qual atua na área de TI.

O argumento da escolha do Processo de Pré-venda para esta primeira experiência foi: que fosse pequeno (poucas atividades) para viabilizar a automação no curto tempo para a monografia, mas que ao ser desenvolvido seria usado como piloto para provar a tecnologia na empresa e, dando certo, o processo evoluiria para as etapas seguintes da venda. Portanto, havia uma expectativa de que a automatização dele pudesse demonstrar bons resultados para a organização, a ponto de convencê-los que valeria a pena investir na adoção da solução e a implementação do restante do processo (e eventualmente de expandir a iniciativa para todos os processos da organização).

Embora ter processos executados e controlados por um BPMS (ou um motor de workflow) possa ser parte do ciclo da gestão por processos, não significa que a empresa tenha adotado Business Process Management como filosofia de gestão. Mas, dependendo do contexto organizacional, muitas vezes a iniciativa nasce dentro da TI, em situações como esta.

A questão é: seria este um bom processo para demonstrar resultados iniciais que possam alavancar uma iniciativa maior BPM (e em uma monografia, apresentar resultados satisfatórios)?

É aqui que este artigo realmente começa :-)

A notação BPMN é excelente para representar atividades de um processo de negócio. Mas a especificação não esclarece exatamente o que é o escopo de um processo de negócio, e nem o nível de granularidade, ou mesmo um método de uso. Apenas dispõe os elementos e as regras de uso visando uma padronização no entendimento de um processo mapeado.

Analisamos juntos o processo e percebemos que este diagrama não é um processo de negócio. É apenas uma parte dele, praticamente o fluxo de ações de uma atividade.

Os benefícios típicos da automatização aparecem quando o processo de negócio :
– Envolve mais de uma área da empresa (melhoria da comunicação)
– Permite extrair indicadores que demonstrem o desempenho do processo (melhoria do controle)
– Deve ser controlado para que sua execução siga integralmente o fluxo modelado
-Possibilita  apresentar informações de tempo do processo que possam apoiar as decisões que levarão à sua evolução (quanto tempo o processo leva hoje e quais atividades devem sofrer alguma melhoria para que esse tempo possa ser reduzido).
[Veja mais sobre benefícios típicos da automação de processos no artigo de Paulo Capiotti, Benefícios da Automação de Processos]

Ao analisar o diagrama, desaconselhamos a sua automatização, pois a mesma não obterá nenhum benefício significativo. Justificamos isto apontando alguns argumentos que usamos quando estamos avaliando a viabilidade/ganho ao se automatizar um processo para um cliente:

I. Este processo tem apenas um usuário. No diagrama original há duas lanes, a do vendedor e a do cliente, mas o fato é que o único a interagir diretamente com a interface humana do BPMS, neste caso, será o vendedor. Se ajustarmos o diagrama para representar apenas as atividades que serão automatizadas (conforme abaixo) e colocando o cliente em uma outra pool (já que ele não irá interagir diretamente com o BPMS) isto se torna bastante visível:

II. Todos estes passos acontecem em um curto espaço de tempo. Pelas tarefas mapeadas, percebe-se que elas ocorrem com o cliente ali, na frente do vendedor. Neste caso, ao automatizar cada uma destas tarefas separadamente, poderá gerar um impacto negativo no aspecto da interface, porque para cada “passo” o usuário (vendedor) terá que: procurar a tarefa na lista de trabalho, clicar para abrir, realizar as ações necessárias na tela, finalizar a tarefa (para que o BPMS registre que aquela tarefa foi concluída e verifique qual a nova tarefa, criando um novo item na lista de trabalho), aguardar o refresh da lista de trabalho e então realizar novamente estes passos para cada uma das atividades do fluxo. Em termos de usabilidade, isso se torna desgastante para o usuário porque faz com que ele tenha que dar inúmeros cliques para fazer uma sequência de ações que possivelmente poderia ser condensada em uma única tela. Em outras palavras, esta sequência de ações poderia compor um Caso de Uso (artefato típido da análise de sistemas tradicional).

III. Além disso, se este processo já é executado manualmente, possivelmente há alguma flexibilização na ordem em que estas tarefas ocorrem (por exemplo, em algum caso o vendedor poderia verificar o cadastro do cliente antes de incluir os itens de compra). É importante considerar isso, pois ao automatizar o fluxo no BPMS, ele sempre será executado como foi modelado. Isso implica que nada pode ser feito antes nem depois do previsto – tudo tem que seguir a ordem das tarefas no diagrama. O que é tradicionalmente um benefício da automatização de processos (garantia da integridade da execução), neste caso poderia ser um aspecto negativo, pois não é o engessamento das etapas que queremos (e toda vez que algo precisar ser levemente diferente os usuários dirão que não é possível porque “o sistema não permite”).

Então percebemos que o processo escolhido é, na verdade, apenas uma atividade de um processo de negócio muito maior.

Fica fácil nesta análise perceber que o sucesso de projetos pilotos para a adoção de um sistema de gestão de processos não depende apenas da qualidade do produto, mas também da escolha de um processo com tarefas que possam efetivamente demonstrar bons resultados.

Ao leitor, sugerimos ampliar um pouco mais a abrangência do processo – o que não significa necessariamente que será mais trabalho. Para um piloto como este, recomendamos mapear, em um nivel macro, todo o processo (não apenas esta etapa da pré-venda), e como primeiro esforço de automação identificar pontos de controle que poderiam ser automatizados (seis ou sete tarefas onde o processo muda de status ou há alguma alteração na rota do fluxo).

Alguns desses pontos de controle podem até ser obtidos de sistemas que já existem hoje na empresa, o que demonstraria ainda mais benefícios na automatização do processo. Por exemplo, no sistema que controla os pedidos, fazer com que o processo siga adiante quando a entrega for despachada. Poderia ser agregado ao processo uma tarefa de serviço para buscar essa informação no sistema.

Com um piloto assim, os indicadores podem demonstrar informações muito mais significativas para a organização do que conhecer, por exemplo, quantos minutos está levando a pré-venda. Será possível identificar onde ocorrem os gargalos, que estapas são críticas e estão atrasando o processo, possivelmente até instigar a empresa em investir na análise,  melhoria e medições mais abrangentes, e quiçá em adotar por completo uma filosofia de gestão por processos.