Filipe Ferraz Salgado Orientador: Francisco Reverbel Tipo de Trabalho: Estágio Supervisionado Após a criação do pacote com a versão 3.1 do jBPM, surgiu.

Apresentação em tema: "Filipe Ferraz Salgado Orientador: Francisco Reverbel Tipo de Trabalho: Estágio Supervisionado Após a criação do pacote com a versão 3.1 do jBPM, surgiu."— Transcrição da apresentação:

1 Filipe Ferraz Salgado Orientador: Francisco Reverbel Tipo de Trabalho: Estágio Supervisionado Após a criação do pacote com a versão 3.1 do jBPM, surgiu a necessidade de atualizarmos o sistema efetivamente. Como alguns erros de execução ocorreram e suas correções nem sempre eram simples devido ao modo como estava a arquitetura da parte de workflow, resolvemos refazer toda essa parte do sistema. Pode-se dizer que foi a fase em que mais aprendemos sobre o jBPM, pois tivemos que compreender mais detalhadamente como era a especificação utilizada (jPDL) para que o WFMS entendesse a descrição formal, como designar tarefas, tempo de duração para cada estado (timers),... Assim, além de conseguirmos atualizar a versão sistema, refatoramos o código, ficando mais fácil a sua utilização. Implantação Resumo A idéia inicial desse trabalho realizado na empresa Murah Technologies era, primeiramente, estudar os conceitos envolvidos (BPM, workflow, jBPM) e, em seguida, avaliar a possibilidade de uma substituição da versão 2.0 pela 3.1 do JBoss jBPM, gerando um pacote com o código do ConteXpress, sistema de gestão eletrônica de documentos, utilizando a nova versão. Mas depois de comprovada tal possibilidade, surgiu a necessidade de fazer a substituição para utilizar a nova versão. Introdução Business Process Management (BPM) e workflow são termos comumente confundidos, apesar de workflow ser mais utilizado. A diferença é que BPM tem uma maior abrangência do que workflow, ou seja, vai além do nível técnico, abordando também assuntos de caráter organizacional. Por outro lado, workflow se restringe mais à interação homem-computador propriamente dita, ou melhor, às interfaces do sistema. Assim sendo, temos os sistemas que gerenciam workflow, Workflow Management Systems (WFMS), que mantêm o controle de cada execução e, mais do que isso, atribuem tarefas a pessoas e/ou programas. Mas para conseguirem realizar tal controle, esses sistemas precisam saber como é fluxo de cada processo. Para isso, eles recebem uma descrição formal de como são os processos, que pode ser entendida como uma máquina finita de estados. Tendo isso em mente, podemos identificar três situações onde pode-se utilizar um WFMS: 1.Uma opção é usar como uma plataforma de EAI (enterprise application integration) de forma que integre várias aplicações de uma empresa, como, por exemplo, gerenciamento de clientes, entrada de pedidos, emissão de contas. 2. Outra opção é criar um workflow com tarefas destinadas às pessoas. Assim, ao invés de fazer os procedimentos por escrito, pode-se criar definições de processos que farão os processos automatizados. 3.A última opção é adicionar o workflow em uma aplicação de forma que fique transparente para o usuário. O workflow passa a ser apenas mais um componente da aplicação. Conclusões Workflow pode ser entendido como uma máquina finita de estados que segue uma descrição formal, que é escrita de acordo com uma especificação. Hoje em dia existem muitas especificações, o que dificulta a escolha de uma determinada ferramenta, já que ela tem que seguir uma especificação. O jBPM é apenas uma dessas ferramentas e, apesar de possuir uma especificação própria (jPDL), tem suas vantagens: sua utilização é simples, permite que desenvolvedores e usuários (analistas) se entendam e é open source. Sobre os resultados práticos, posso dizer que está sendo interessante trabalhar com workflow, pois tive que conhecer novas ferramentas e o jBPM está satisfazendo nossas expectativas, permitindo que alcancemos nossos objetivos. Referências http://www.jboss.com/products/jbpm/stateofworkflow Como foi descrito inicialmente, o intuito da primeira parte do trabalho era criar um pacote com o código do sistema ConteXPress utilizando a versão 3.1 do JBoss jBPM, comprovando assim, a viabilidade da substituição da versão utilizada (2.0) pela versão mais recente. Para alcançar tal objetivo, foi necessário um estudo sobre as principais ferramentas envolvidas como o framework Struts, as JSPs e o próprio jBPM. Gerando a nova versão WFMS Em um WFMS podem ser identificadas 4 interfaces principais: a primeira é a de Definição, através da qual o desenvolvedor pode colocar a definição à disposição, ou seja, em uso; a segunda é a de Execução, que permite aos jBPM Hoje em dia existem vários sistemas que gerenciam workflow, o JBoss jBPM é apenas um deles, mas foi o escolhido por melhor se adaptar às necessidades da Murah Technologies. Além de ser um projeto sustentado pelo grupo JBoss, o que já traz uma boa confiabilidade, outras características do jBPM fizeram com que ele fosse o escolhido: Open Source Desenvolvido em Java Estabilidade MySQL Por outro lado, o jBPM possui uma especificação própria, a jPDL (jBPM Process Definition Language), mas isso não criou problemas, pois ela era bem descrita no User Guide, documento que foi bastante requisitado durante o desenvolvimento, justamente para sabermos como era a descrição formal que esse WFMS necessitava para que conseguisse gerenciar as tarefas de maneira correta. usuários e sistemas agirem nas execuções dos processos. A terceira interface, de Aplicação, permite ao WFMS interagir com sistemas externos; e por fim, a interface de Monitoração, que auxilia os responsáveis pelo processo através dos logs. Com relação ao conteúdo das definições de processos, existem também 4 camadas que o caracterizam: a camada de Estado que simplesmente especifica os estados e o fluxo do processo. A camada de Contexto permite que o desenvolvedor armazene dados para uma determinada execução do processo. A terceira camada, de lógica de programação, é responsável pelas ações (envio de e-mails, atualizar banco de dados). A última camada é a de interface do usuário, que cuida das interações do usuário com o sistema. Apesar de existirem boas ferramentas de workflow no mercado, seus padrões ainda estão em desenvolvimento, ou seja, ainda não existem especificações definidas de como têm que ser as definições dos processos, pelo contrário, existem muitas delas hoje em dia, e cabe a cada ferramenta de workflow escolher qual irá seguir, o que pode dificultar a integração entre sistemas. Nos últimos anos algumas tentativas têm sido feitas no sentido de padronizar tais especificações, como a Workflow Management Coalition (WfMC) e a especificação XPDL.