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.

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"]

BPMN: Diferenças entre eventos de Link, Message e Signal

Um dos componentes mais poderosos, e mais difíceis de aprender em BPMN, são os eventos e seus gatilhos (triggers). A especificação BPMN descreve diversos tipos de gatilhos para os eventos, mas não esclarece como ou quando devem ser utilizados.

De forma especial, uma dúvida comum são as diferenças entre estes três gatilhos de eventos de BPMN: link, message e signal.

Link é um elemento de ligação que ajuda a abstrair conexões de sequência em um mesmo processo. Alguns profissionais sugerem que o link seja usado para dar seguimento do desenho do processo em outra página, como em uma documentação, por exemplo. Este é um uso possível, mas dado que a maioria das ferramentas de modelagem atualmente não faz paginação (o diagrama é desenhado em uma única área de trabalho) esta não é a única situação de utilização.

Uma das principais utilidades do evento de link, ao meu ver, é a de abstrair a sequência entre atividades que estão distantes no mapeamento, evitando conectores de fluxo de sequência longos que cruzem inúmeros outros.

No exemplo, os eventos de link com o mesmo nome conectam "virtualmente" pontos distantes do processo, fazendo com que após a atividade 'Verificar condições de férias' o processo siga em sua execução, iniciando a atividade 'Avaliar solicitação de férias'. Com isso, a sobreposição de sequence flows foi evitada, deixando o processo mais legível.

O link só é usado como evento intermediário, e por significar uma sequência implícita não pode ser usado para ligar processos diferentes. Isto significa que, no caso de processos desenhados utilizando pools, não podemos usar eventos de link para fazer com que um processo em uma pool dê continuidade à execução de um outro processo, em outra pool.

Assim, a principal diferença entre o evento de link e para os de message e signal reside no fato de que o primeiro é usado para conectar a sequência de um mesmo processo, enquanto os dois outros tratam da comunicação entre processos.

Entre estes dois eventos – message e signal -, a diferença é um pouco mais discreta. Ambos podem ser utilizados para a comunicação entre processos distintos.

O evento de message é usado para a transmissão/recebimento de informações entre processos. Esta troca de informações, de acordo com a especificação BPMN, pode ocorrer por qualquer meio: verbal, escrita, via email, ou até mesmo sistemática. O foco está no aspecto de que há um emitente (demonstrado através do evento throw message) e um destinatário (demonstrado através do evento catch message). O emitente conhece o destinatário, assim como o destinatário sabe de quem receberá a mensagem (mesmo que os dois processos que se comunicam não estejam desenhados no mesmo diagrama).

Neste exemplo, há uma transmissão de informação de um processo para o outro, representado através da Comunicação do número de participantes do Processo de Inscrições para o Processo de Logística de Treinamentos.

Para mais dicas sobre como modelar corretamente diagramas com comunicação entre processos, veja a postagem BPMN: Modelando corretamente o fluxo de sequência de atividades.

Signal também pode ser utilizado para a comunicação intra e entre processos. A diferença é que enquanto a mensagem tem um destinatário específico, o sinal pode ter um emitente e inúmeros destinatários – e eles não necessariamente se conhecem. O funcionamento do signal é como um broadcast: o throw signal emitirá o sinal (como um apito) e todos os processos que estão aguardando aquele sinal (catch signal) o captarão, dando sequência aos seus fluxos.

Além disso, não há transmissão de informações no envio de sinal. Ele é realmente apenas como um apito, alertando que o evento ocorreu, e que quem estivesse aguardando por ele, agora pode prosseguir com seu processo.

Os diagramas acima demonstram um conjunto de processos sincronizados através de Signals para apoiar o Processo de Monitoramento das Linhas de Comunicação de uma operadora de crédito, que disponibliza as "maquininhas" de cartão nas lojas. O Processo de "Monitoramento da Comunicação" possui uma atividade recorrente que monitora, constantemente, se as linhas telefônicas utilizadas estão todas disponíveis. Se for identificada falha em uma linha de comunicação, o processo dispara um evento de sinal "Erros em linhas de comunicação". Esse sinal é o gatilho de disparo para dois processos: "Processo de Restabelecimento da Comunicação" e "Processo de Contingência da Comunicação". O Processo de restabelecimento inicia um conjunto de atividades para buscar o restabelecimento do serviço. Enquanto isso, o Processo de contingência aguarda algum tempo para verificar novamente se as linhas foram restabelecidas antes de iniciar as ações de contingência (possivelmente porque a contingência tem um custo mais elevado, de forma que a esperar algum tempo para o restabelecimento das linhas pode ainda ser mais viável para a empresa). Depois que as linhas forem restabelecidas pelo "Processo de Restabelecimento da Comunicação", este processo emite o sinal "Linhas de comunicação restabelecidas" e dá seguimento para o cálculo da multa com a operadora de telefonia. O sinal emitido faz com que o Processo de Contingência dê seguimento ao seu fluxo para desligar a contingência (já que a operação voltou ao normal), e também dispara o processo de "Avaliação de SLA do Cliente", no qual são analisados os clientes impactados pela falha no serviço e realiza-se a negociação de possíveis multas pela quebra do nível de serviço.

Signal também pode ser utilizado para a sincronização de um processo com múltiplas instâncias de um outro processo. É o caso do excelente exemplo apresentado no artigo A case for BPMN Signal, por Anatoly Belychook no blog Process is the Main Thing.

Resumindo:

  • Link events são usados para abstrair sequência de atividades em um mesmo diagrama de processo, e por isso só podem conectar uma ponta de um processo a outra de um mesmo processo.
  • Message events são usados para abstrair a comunicação entre processos, e portanto não devem ser utilizados para demonstrar sequência de atividades. Os eventos de message possuem emitente e destinatário conhecidos.
  • Signal events são usados para realizar broadcast de sinal, onde o emitente envia o sinal sem conhecer seus destinatários.

Qual o melhor BPMS do Mercado?

Frequentemente, clientes e prospects perguntam aos consultores da iProcess qual é a melhor ferramenta de BPMS existente hoje no mercado. Infelizmente não existe uma resposta única para esta questão e a dificuldade em respondê-la advém de inúmeros fatores.

Nesse post procuramos elencar alguns dos motivos pelas quais a escolha de uma plataforma de BPM é uma escolha tão difícil.

  1. Por ser uma escolha corporativa: soluções de BPMS não são soluções departamentais: assim como os processos, que possuem uma natureza transversal na organização, uma solução de BPMS tende a ser utilizada por toda a organização.
  2. Pela necessidade de atender diferentes necessidades: sendo uma escolha corporativa, a escolha da solução de BPMS deve atender a um conjunto amplo de demandas: caso contrário, corre-se o risco de se deixar alguma necessidade organizacional à descoberta. Isso exige que um amplo levantamento de expectativas deve ser realizado antes da sua seleção, de modo a evitar uma quebra de expectativa após a escolha da solução.
  3. Pelo enorme conjunto de funcionalidades disponíveis: Existem hoje mapeados na iProcess mais de 600 requisitos que podem ser avaliados na escolha de uma ferramenta de BPMS. Obviamente nenhuma ferramenta atende a estes 600 requisitos, e tão pouco é comum as empresas terem demandas tão complexas a ponto de necessitar todos estes requisitos sejam atendidos como obrigatórios. Desta forma, o casamento entre o que a empresa precisa e o que a plataforma disponibiliza é um fator crítico de sucesso na escolha da plataforma.
  4. Pelo número de alternativas que existem hoje no mercado: Existem hoje centenas de ferramentas de BPMS disponíveis no mercado. Só no Brasil são fabricadas dezenas, sem contar tantas outras que possuem escritórios de representação instalados no país.
  5. Pelo enfoque dado pelo fabricante ao conceber o seu produto: Via de regra os produtos de BPMS possuem categorias de funcionalidades que se destacam dos demais devido a forma como surgiu o produto. Produtos de BPMS se originaram de diferentes segmentos tecnológicos, tais como a gestão de conteúdo, a colaboração, a integração entre sistemas, a edição de formulários, …
  6. Pela enorme variação de valores financeiros envolvidos: Existem atualmente produtos para todos os bolsos e gostos: desde aqueles que são totalmente gratuítos (mas que possuem contratos de suporte e manutenção) até aqueles cujo o licenciamento pode chegar à centena de milhares de dólares. A forma de licenciamento também tem o impacto direto na sua precificação, sendo os tipos mais comuns as licenças por usuário ou processador.
  7. Pelas plataformas tecnológicas existentes na organização: As plataformas tecnológicas disponíveis dentro da organização podem facilitar ou inviabilizar a escolha de uma plataforma de BPM. Questões como, por exemplo, o sistema operacional utilizado nos computadores clientes e servidores (Windows, Linux, Unix, …); o banco de dados da organização (Oracle, DB2, Postgress, SQL Server, …); o servidor de aplicação disponível (IIS, Apache, WebLogic, Websphere, …); a linguagem de desenvolvimento utilizada (Java, .NET, PHP, …) podem ser fundamentais na análise de aderência de uma ferramenta de BPMS à plataforma atual.

A escolha certa de uma plataforma de BPM passa por uma análise detalhada de cada um destes fatores. É importante ter em mente que a escolha inadequada de uma solução de BPMS pode inviabilizar a execução de alguns processos de negócio da sua organização e, em última análise, até mesmo as suas iniciativas de gestão por processos.

[Atualizado] Leia também: ferramentas BPMS livres ou de baixo custo são sempre mais baratas do que as ferramentas pagas?

Até lá.

Configurando um ambiente de desenvolvimento mais produtivo

Quando planejamos a implantação de uma nova tecnologia, de um novo sistema, é comum nos preocuparmos diretamente com os recursos de hardware e software que serão requeridos nos computadores servidores envolvidos. Porém, um ponto que poucos lembram-se de planejar previamente diz respeito aos recursos que as equipes de desenvolvimento e manutenção irão demandar.

Para além dos produtos diretamente relacionados ao sistema implantado, que outros aplicativos podem ajudar um técnico a ser mais produtivo em suas tarefas? Nesta hora, nada melhor do que trocar experiências, conversar com quem vive essa realidade no dia-a-dia.

Este é o motivador deste post: trocar experiências!

Não temos porém a pretenção de determinar quais são os melhores softwares, tampouco, ao citarmos um aplicativo específico, não queremos dizer que seus concorrentes são menos qualificados. O que estamos nos propondo a fazer é, na verdade, apresentar uma coleção que acreditamos atender adequadamente a maioria das necessidades de trabalho dos técnicos envolvidos com automação de processos e com desenvolvimento de sistemas de um modo geral.

Nota: é importante atentar para as políticas de licenciamento de cada software! Nem todo programa que pode ser instalado gratuitamente permite o seu uso para fins comerciais. Não nos responsabilizamos e tampouco estimulamos usos indevidos. Tampouco temos qualquer relação comercial com os fabricantes e distribuidores dos aplicativos citados.

 

Bom, vamos ao que interessa!

Confira a lista de aplicativos que sugerimos, considerando as plataformas Windows e Linux. Aguardamos contribuições e outras sugestões nos comentários.

Para facilitar, vamos agrupar as sugestões em aplicativos básicos, técnicos, segurança e desenvolvimento.

Aplicativos básicos:

  • Primeiramente é importante definir o sistema operacional a ser utilizado. O Windows 7 Professional é uma ótima opção nessa plataforma e, em Linux, as distribuições Fedora e Ubuntu são recomendadas (mas muitas outras também são adequadas).

** Adicionalmente, o Firefox mostra-se como uma opção bastante interessante para desenvolvedores pela grande quantidade de plugins disponíveis para estender suas funcionalidades. Dentre esses, podemos destacar o Webdeveloper e o Firebug, especialmente úteis para depurar os componentes Javascript das suas páginas.

  • Compactador de arquivos 7-zip, para Windows.
  • PDF XChange é um bom leitor deste tipo de arquivo, pois é leve e permite a inclusão de comentários e marcações. No Linux, ele pode ser instalado utilizando o Wine, citado mais adiante (Okular e Evince são bons leitores também para Linux). Claro, há também a opção de utilizar o Adobe Reader (para Windows e Linux), mas este é bastante “pesado”. Já para geração de PDFs, o pdfCreator é uma ótima opção para Windows, e o Cups-PDF para Linux atende a necessidade.
  • Para edições simples de imagens, recomendamos o Paint.net para Windows ou o Gimp (Windows e Linux), e o Gadwin Printscreen (Windows) para produzir cópias de telas (a maioria dos ambientes Linux possui opção nativa para tal).
  • Para comunicação, Skype para videoconferências e para chat o Pidgin (Windows e Linux), que suporta em um só aplicativo contas do MSN, GTalk e de outros serviços.
  • Instale o cliente do Dropbox para compartilhar facilmente arquivos entre diferentes computadores, ou mesmo entre toda a equipe de desenvolvimento.

Aplicativos técnicos:

  • Para Linux, há muitos pequenos programas de linha de comando úteis para diversas tarefas. Em ambiente Windows, podemos utilizar boa partes desses comandos utilizando o Cygwin! Por exemplo, nada como poder utilizar o comando tail para acompanhar um arquivo de log e, com o Cygwin, isso é possível mesmo em Windows.
  • No Windows, podemos conectar em um ambiente Linux remoto utilizando o Putty ou XShell, e podemos até mesmo executar localmente programas gráficos que estão instalados em um ambiente Linux remoto se utilizarmos o XMing. E o contrário também é verdadeiro: podemos instalar e executar alguns aplicativos Windows em ambiente Linux, instalando o Wine. Se o aplicativo não for dependente de bibliotecas muito específicas, tem uma boa chance de funcionar muito bem! E, para conectar remotamente em uma máquina Windows a partir do Linux, utilize o Vinagre, um cliente Remote Desktop e VNC leve e adequado.
  • Para controle de versões SVN, instale no Windows o Tortoise SVN, que integra-se muito bem ao Windows Explorer. Existe também o projeto Tortoise GIT para este outro controle de versões. Bem menos explorado e conhecido, o sistema de controle de versões Bazaar é uma opção bastante interessante para manter versionados arquivos locais sem depender de um servidor específico para tal. Pode ser utilizado, por exemplo, para manter versões locais mais frequentes, sem, no entanto, submeter versões para o sistema centralizado da empresa, onde espera-se que sejam entregues apenas versões estáveis dos códigos-fonte.
  • Para comparação de arquivos, recomendamos WinMerge para Windows e Meld para Linux.
  • Para editar arquivos texto no Windows, esqueça o Notepad! Instale o Notepad++, que possui diversos recursos e plugins disponíveis.
  • Instale o Wireshark (Windows e Linux) para interceptar e monitorar o tráfego de rede.

Segurança:

  • Utilize o TrueCrypt principalmente para proteger pendrives e HDs externos, mas o mesmo pode ser utilizado também para criptografar discos rígidos dos seus computadores. ** Adicionalmente, em Linux, é possível criptografar o disco rígido facilmente utilizando LVM.
  • Especialmente em ambiente Windows, tenha um bom antivirus instalado! O McAfee é bastante eficiente, mas tem custo de licença e consome bastante recursos do computador. Já o Comodo tem a vantagem de ser uma suite com antivirus, antimalware e firewall, e gratuita. Para Linux, o Avast é uma boa opção de antivirus para uso pessoal, enquanto que o Clamav é o mais famoso e de uso gratuito. Já o ipTables é o firewall padrão (boa parte das distribuições geralmente contam com um aplicativo gráfico de firewall baseado em iptables). Ainda para Windows, pode-se também fazer uso das próprias ferramentas da Microsoft: Windows Firewall e o Security Essentials como antivirus.
  • Também não esqueça de ter uma opção de software para backup, especialmente se trabalhar em home-office ou se viaja muito com notebook. A maioria desses serviços é pago, mas seu custo caiu muito nos últimos anos. Algumas opções de empresas que disponibilizam serviço de backup remoto são: CrashPlan, Carbonite e Mozzy – estes dois últimos somente para Windows, o primeiro para múltiplas plataformas.

Desenvolvimento:

  • Para acesso e programação em banco de dados Oracle, utilize o Oracle Sqldeveloper. Para banco de dados SQL Server, utilize as próprias ferramentas  Microsoft.
  • Para desenvolvimento, depende muito do gosto do programador, mas Eclipse e Netbeans são ótimas IDEs.
  • Para teste e simulação de webservices, o SoapUI é uma excelente ferramenta.
  • Para automação de build e deploy, principalmente em Java mas também em outras linguagens e plataformas, utilize Ant e Maven.
  • Para virtualização de servidores, o VirtualBox é uma ótima opção, pois permite inclusive criar snapshots. Mais limitado, o VMware Player também serve para executar máquinas virtuais facilmente.

Bom, ficamos por aqui. Compartilhando esta lista de aplicativos, esperamos ajudar a facilitar o processo de escolha de ferramentas para as diversas necessidades e demandas de software que surgem em um ambiente de desenvolvimento.

Aguardamos comentários e sugestões de outros aplicativos que podem ajudar a tornar o nosso dia-a-dia mais produtivo ;-)