Backend

BPM – Camunda

Praticamente toda a implementação de software feita por você faz parte de algo maior, e se juntará a outras partes para daí sim gerar valor a sua empresa. Quanto mais peças adicionamos nesse quebra-cabeça, mais difícil pode ser de termos a visão do todo, e cada vez mais desenhos e documentações acabam ficando para trás enquanto a parte técnica segue evoluindo. 

Chega o momento onde precisamos juntar diferentes áreas da organização para discutir uma nova regra de negócio ou mostrar o estado atual do processo, e você se pergunta se faz sentido compartilhar o seu código fonte num telão ou discutir em cima daquela documentação que já não representa o que está rodando de fato. 

E se eu pudesse mapear todas essas peças de forma que tanto a área de negócio quanto a área técnica conseguissem entender e sugerir ajustes, e garantir que esse desenho não se perdesse? Que ele de fato fizesse parte do executável, e assim não ficasse pegando poeira numa wiki da vida? 

É exatamente isso o que fazemos quando passamos a utilizar BPM no dia a dia. 

O HypeFlame Talks #3 Camunda BPM foi sobre este assunto! Assista aqui:

O que é? 

BPM, Business Process Management, é a metodologia que visa auxiliar no mapeamento, gestão e melhoria de processos de uma organização. Com ela temos uma forma padronizada de representar ações, eventos e papeis de cada um, do início ao fim em um processo de negócio, também chamado de Processo Ponta a Ponta.  

Assim como no desenvolvimento de qualquer software, onde você segue os padrões e utiliza métodos e sintaxe disponibilizados pela linguagem que está usando, aqui nós temos o BPMN (Business Process Model and Notation), que é praticamente a linguagem utilizada no mapeamento de processos. 

Com a BPMN, você tem uma lista de elementos onde cada um representa um tipo de atividade ou evento no teu processo.  Para um melhor entendimento, podemos separar os principais elementos do BPMN em três categorias: atividades, eventos e gateways de desvio. 

BPMN – Atividades 

Uma atividade é qualquer parte do trabalho que é feito ao longo do processo de negócio. Seja um trabalho manual, também chamado de Tarefa Humana, como analisar e aprovar/reprovar uma documentação, ou então algo já automatizado como chamar um serviço para cadastrar a pessoa, por exemplo. O ideal aqui é separar o processo em quantas atividades forem necessárias, onde cada uma representa a menor porção possível de trabalho que faça o processo avançar. 

Em BPMN, as atividades são representadas por retângulos, e podem ter diversos tipos como já exemplificado acima, sendo tarefas humana (user task), tarefas de serviço (service task) e chamadas para um outro subprocesso (call activity). 

BPMN – Eventos 

Um evento simboliza algo que aconteceu ou que devemos esperar acontecer para dar seguimento no processo. Pode ser o envio ou recebimento de uma mensagem (message event), aguardar algum tempo em um temporizador (timer event) antes de seguir ou mesmo indicar que um erro ocorreu (error event).  

Em BPMN, os eventos são representados por círculos. Estes podem ser eventos de início (borda simples), intermediários (borda dupla) e fim (borda mais grossa). Cada um deles pode ainda ser especializado em alguns subtipos, podendo indicar que o processo começa por um agendamento, ou mesmo aguarda o recebimento de uma mensagem e finaliza gerando um evento de erro, por exemplo. 

Podemos identificar, dentre os eventos de um processo, quais estão disparando algo e quais estão aguardando algo ocorrer simplesmente pelo seu preenchimento. Um evento de mensagem sem preenchimento de cor significa que estamos aguardando a mensagem para seguir. Um evento de mensagem com preenchimento de cor significa que estamos disparando a mensagem e seguindo. 

BPMN – Gateways de Desvio 

Um gateway de desvio é um ponto no qual o processo se divide. O fluxo pode seguir por um ou outro caminho, dependendo de uma decisão, ou mesmo seguir por vários caminhos em paralelo até se juntar novamente e seguir como um só. 

Em BPMN, os gateways de desvio são representados por losangos. Temos aqui também vários tipos de gateway como exemplificado acima, sendo os principais o exclusivo (exclusive gateway) e o paralelo (parallel gateway), utilizados para indicar que o processo seguirá por apenas um caminho ou por todos em paralelo, respectivamente.  Temos ainda o gateway de eventos (Event based gateway) também muito utilizado para aguardar múltiplos eventos, sendo que o primeiro deles que ocorrer fará o processo continuar, sem esperar os demais. 

Processo ponta a ponta 

Conhecendo os elementos citados acima, podemos mapear a maioria dos processos existentes. Vamos pegar por exemplo a aplicação de agendamento de alertas do seu celular. 

Olhando do ponto de vista de negócio, a aplicação deve permitir que o usuário informe uma data/hora para o alarme, aguardar esse horário e disparar o alerta. Quando ele for disparado, o usuário deve poder adiar esse alerta (função soneca) ou encerrar.  

Com o BPMN podemos representar tal processo da seguinte forma: 

Percebe o quão visual e mais prático fica de eu te explicar a ideia da aplicação, os momentos de interação com o usuário e seus desvios, quando utilizamos o diagrama em BPMN?  

Um ponto importante a ser notado no desenho acima é que, apesar de representarmos ali o processo ponta a ponta de como o agendamento e disparo do alarme ocorre, estamos chamando um sub processo para disparar o alerta em si. Isso pois existe toda uma complexidade de negócio ali que pode já ter sido resolvida para outros casos, e deixando ela encapsulada em um sub processo posso promover o reuso dessa lógica, assim como fazemos com nosso código fonte. Na aplicação de exemplo, o alerta poderia ser uma música configurada pelo usuário ou um alerta silencioso apenas vibrando por exemplo. Para o meu processo de agendamento isso não importa e eu apenas posiciono esse disparo no momento ideal.  

Agora que você já conhece os elementos visuais e está pronto para aguentar a piada de que você “arrasta caixinha” mais uma vez, agora em tecnologias mais recentes, vamos a parte que deixa isso mais interessante, que é como executar tudo isso.  

É aqui que entra uma outra sigla nessa sopa de letrinhas, o BPMS. 

BPMS – Business Process Management Suíte (ou system) 

Enquanto BPM é a metodologia e BPMN é a linguagem, BPMS é o sistema que interpreta e executa tais diagramas, o qual nos permite automatizar o processo vinculando o desenho ao meu código fonte, e visualizar o estado atual das execuções, como por exemplo, saber quais alarmes eu tenho cadastrado e aguardando a data/hora definida, no caso do processo demonstrado acima.  

Existem várias soluções de BPMS no mercado, e a que utilizamos aqui na Hypeflame se chama Camunda

Camunda 

O camunda é uma solução de BPMS open source, que provê as ferramentas para desenho/modelagem do diagrama, motor de execução e aplicativos web para visualização dos processos e listagem de tarefas humanas. 

Enquanto outras ferramentas tendem a ir para o lado mais “low code”, o camunda abraça mais o perfil do desenvolvedor, que aqui tem mais flexibilidade para desenvolver código fonte vinculado ao desenho, facilitando assim o reuso de bibliotecas que sua equipe já está habituada, aumentando a testabilidade do seu processo e permitindo diversas formas de distribuição. 

Dentre as formas de distribuição, nós começamos anos atrás utilizando o Camunda em seu formato Standalone, tendo um servidor wildfly no qual rodávamos os webapps e motor da Camunda de forma centralizada, onde cada equipe podia fazer deploy de seus processos e acessa-los através de chamadas HTTP para a api rest padrão do camunda (https://docs.camunda.org/manual/7.15/reference/rest/) .  

Os metadados de todos esses processos ficavam armazenados em um banco de dados também centralizado. 

Algum tempo depois, passamos a utilizar o springboot starter da camunda, estando assim muito mais alinhado a nossa arquitetura de micro serviços, permitindo uma maior separação dos domínios como manda o bom, velho, mas nunca fora de moda DDD, e assim reutilizar outros componentes já existentes em nossa arquitetura como o próprio kubernetes, tendo agora os serviços todos rodando em docker, cada um com o seu próprio banco de dados.  

Como a clusterização do camunda ocorre no banco de dados, podemos escalar nossa aplicação sem problemas apontando mais réplicas do serviço para o mesmo banco. 

Componentes e Ferramentas Camunda 

Ao utilizar o camunda, temos a nossa disposição as seguintes ferramentas: 

Modeler: ferramenta para modelagem dos processos. É nela que você utilizará todos aqueles elementos descritos mais acima, mapeando teus processos utilizando a notação BPMN. Podemos dizer que essa será sua IDE para trabalhar com BPM. 

Você pode fazer o download do camunda modeler aqui: https://camunda.com/download/modeler/

Cockpit: aplicativo web para gerenciamento dos processos existentes em sua aplicação. Essa ferramenta geralmente está inclusa no próprio projeto que está rodando o motor de processos, mas também pode ser separada, desde que aponte para o mesmo banco de dados. 

Tasklist: aplicativo web para gerenciamento da lista de tarefas humanas que estão em aberto, nos processos executados em sua aplicação. Essa ferramenta vem junto com o cockpit, e como tal, pode ficar no mesmo projeto do motor de execução ou em projetos separados apontando para o mesmo banco de dados. 

Executando processos em micro serviços  

A partir daqui a ideia te mostrar como é simples criar um projeto springboot e rodar o camunda da forma que utilizamos aqui na Hypeflame. Para isso vou utilizar o famoso spring initializr (https://start.spring.io/).  

Lembre-se de adicionar as dependências do Spring Web e um driver de banco SQL para os metadados do camunda. Neste exemplo estarei utilizando o banco em memoria H2, o qual serve para este tutorial, mas não deve ser utilizado em produção.

 

Depois de criado, é só importar na sua IDE favorita para projetos Java.

No meu caso, tenho utilizado o IntelliJ (https://www.jetbrains.com/pt-br/idea/download/). 

Agora podemos começar a adicionar um pouco de camunda no projeto. 

Comece adicionando as seguintes dependências ao seu build.gradle: 

implementation group: 'org.camunda.bpm.springboot', name: 'camunda-bpm-spring-boot-starter', version: '7.15.0' 
implementation group: 'org.camunda.bpm.springboot', name: 'camunda-bpm-spring-boot-starter-rest', version: '7.15.0' 
implementation group: 'org.camunda.bpm.springboot', name: 'camunda-bpm-spring-boot-starter-webapp', version: '7.15.0'

A primeira delas, camunda-bpm-spring-boot-starter, é o que nos dará o motor de execução para rodar nossos processos, e acesso a todas as classes utilitárias expostas pela camunda. 

A segunda, camunda-bpm-spring-boot-starter-rest, faz com que uma api rest padrão da camunda já esteja disponível em nosso projeto. A api fornece meios de iniciar e dar manutenção nos processos e pode ser bem útil para sustentação do projeto. Segue a documentação de todos os endpoints disponíveis: https://docs.camunda.org/manual/7.15/reference/rest/ 

Por último, temos a camunda-bpm-spring-boot-starter-webapp, que nada mais é do que os web aplicativos que comentei acima: cockpit, tasklist, etc. 

Como estamos criando uma aplicação nova, é necessário configurar alguns passos iniciais, como o usuário e senha de acesso. Em um projeto final, o ideal é que você implemente algum mecanismo de segurança como a integração com o LDAP de sua empresa, por exemplo, mas aqui estaremos definindo um usuário e senha padrão no próprio projeto. Para isso, crie o arquivo application.yml na pasta resources, com o seguinte conteúdo: 

camunda.bpm: 
  admin-user: 
    id: demo 

    password: demo 
    firstName: Demo 
  filter: 
    create: All tasks 

A parte do filter servirá para termos um filtro inicial já configurado, visualizando todas as tarefas no tasklist. 

Nesse momento, ao rodar o projeto já teremos acesso aos aplicativos em nosso navegador. Basta acessar http://localhost:8080/ e você será redirecionado a página de login. 

Acessando com o usuário definido anteriormente (usuário demo, senha demo), temos uma página inicial que dá acesso as demais aplicações. 

Agora que já temos nosso camunda rodando, vamos criar um processo bem simples apenas para vê-lo em execução. 

Para isso, abra a ferramenta Camunda Modeler, e selecione a opção para criar novo BPMN Diagram (Camunda Platform) 

Com isso, teremos agora um novo diagrama iniciado, tendo apenas um evento de início já adicionado, e a paleta com os elementos a serem arrastados. 

Selecionando o evento de inicio com o mouse, um menu de contexto será exibido, facilitando a seleção do próximo item a ser adicionado. 

Clicando no elemento de atividade (retângulo), podemos ver que uma atividade foi adicionada, com uma linha entre ela e o evento de início, o que indica que ela será executada logo após o início do processo. 

Selecionando agora a atividade, um menu de contexto parecido também será exibido. Vamos agora selecionar o item de ferramenta (change type), para definir qual o tipo de atividade que queremos. 

Vamos aplicar o tipo de atividade User Task, que nada mais é do que uma tarefa humana. Perceba que agora nossa atividade possui o símbolo de tarefa humana no canto superior esquerdo. Dando um duplo clique na atividade, é possível editar o texto que aparecerá dentro dela. 

Vamos agora selecionar novamente a atividade e clicar para adicionar um evento de finalização do processo. 

Provavelmente esse será o processo mais simples que você verá na sua vida, hehe. 

Vamos definir também um nome para o processo em si. Para isso, certifique-se de que não está selecionando um elemento qualquer, clicando na área branca do diagrama. Assim, no menu da direita serão exibidas propriedades do processo como um todo. 

Vamos editar os campos Id para “meu-processo” e Name para “Meu Processo”. O campo Id servirá para referenciarmos esse processo em nosso código fonte. Já o campo Name, será o nome descritivo, que aparecerá no cockpit. 

Vamos agora salvar o arquivo na pasta resources do seu projeto. Você pode dar qualquer nome ao arquivo, desde que a extensão seja “.bpmn”

Ao rodar novamente o projeto java, os novos processos serão interpretados pelo camunda e poderão agora ser vistos pelo cockpit. 

Note que temos zero instancias de processo rodando, porém já temos agora uma definição de processo deployada, ou seja, o desenho que acabamos de fazer. 

Clicando na aba “Processos”, podemos visualizar a lista das definições, incluindo o item “Meu Processo”, conforme foi dado o nome nos passos anteriores.  

Ao clicar no nome do processo, podemos visualizar o desenho bem como informações sobre ele, o número da versão atual, id, etc. 

Vamos agora criar um novo diagrama BPMN, seguindo os passos anteriores, porém desta vez utilizando mais elementos, para que eu possa te mostrar como integrar as atividades ao código java, como prometido. 

Para tal, criei um diagrama contendo uma tarefa humana onde o usuário deverá informar sua idade. Após isso, passará por um gateway de desvio, onde caso sua idade seja acima ou igual a 18 anos, seguirá para uma atividade automática de Aprovação de cadastro. Caso seja menor de 18, seguirá então para uma atividade automática de Reprovação de cadastro. 

Notem que aqui já utilizamos start event, user task, service task, exclusive gateway e end event.  

Vamos também dar o seguinte id e name para o processo. 

Desta vez, como temos alguns elementos automáticos no desenho, se você simplesmente salvar o arquivo assim na pasta resources e rodar o projeto java novamente, teremos o seguinte erro: Could not parse BPMN process. 

Isso acontece para elementos como a Service Task e o Exclusive Gateway, temos de preencher algumas informações a mais para que a process engine saiba interpretar o desenho. 

Para resolver o problema e também automatizar parte do nosso processo, vamos definir duas classes Java com métodos a serem executados, uma para cada service task. 

Comece selecionando a service task “Aprovar Cadastro”. No menu lateral direito agora aparecerão propriedades relativas a Service task. Na caixa de seleção “Implementation” selecione a opção “Delegate Expression” e no novo campo “Delegate Expression” digite a seguinte expressão: ${aprovarCadastroDelegate}. 

Faça o mesmo para a atividade de “Reprovar Cadastro”, porém um nome diferente na expressão. 

A opção “Delegate Expression” nos permite informar uma expressão que, ao ser executada pelo camunda, informe a ele qual o Spring Bean a ser utilizado nessa atividade. Para tal, utilizamos uma linguagem de expressão chamada JUEL (https://docs.camunda.org/manual/7.15/user-guide/process-engine/expression-language/#usage-of-expression-language).  

Toda expressão em JUEL deve iniciar com um cifrão, abrir e fechar chaves, com a expressão em si dentro das chaves.  

No caso das service tasks, colocamos apenas o nome do Spring Bean a ser chamado. Nesse caso, temos de criar as classes AprovarCadastroDelegate e ReprovarCadastroDelegate as configurando como beans por meio da anotação @Component. 

package br.com.hypeflame.example.camundaspring.delegate; 
 
import org.camunda.bpm.engine.delegate.DelegateExecution; 
import org.camunda.bpm.engine.delegate.JavaDelegate; 
import org.slf4j.Logger; 
import org.slf4j.LoggerFactory; 
import org.springframework.stereotype.Component; 
 
@Component 
public class AprovarCadastroDelegate implements JavaDelegate { 
 
    private final Logger logger = LoggerFactory.getLogger(this.getClass()); 
 
    @Override 
    public void execute(DelegateExecution execution) throws Exception { 
        Integer idade = (Integer) execution.getVariable("idade"); 
        logger.info("aprovando cadastro com idade {}", idade); 
    } 
} 
package br.com.hypeflame.example.camundaspring.delegate; 
 
import org.camunda.bpm.engine.delegate.DelegateExecution; 
import org.camunda.bpm.engine.delegate.JavaDelegate; 
import org.slf4j.Logger; 
import org.slf4j.LoggerFactory; 
import org.springframework.stereotype.Component; 
 
@Component 
public class ReprovarCadastroDelegate implements JavaDelegate { 
 
    private final Logger logger = LoggerFactory.getLogger(this.getClass()); 
 
    @Override 
    public void execute(DelegateExecution execution) throws Exception { 
        Integer idade = (Integer) execution.getVariable("idade"); 
        logger.info("reprovando cadastro com idade {}", idade); 
    } 
} 

A implementação destas classes é bem simples. Para utiliza-las nas service task, implementamos a interface JavaDelegate da própria camunda, a qual exige um método “execute”. Este método é justamente o que será executado sempre que nosso processo chegar naquela atividade. Nele recebemos um parâmetro do tipo DelegateExecution, que nos dá acesso ao contexto atual da execução, ou seja, ao estado atual do processo e todos os seus dados. 

Como no diagrama temos uma atividade manual para o cliente inserir a idade, aqui nos delegates coloquei para buscar o valor da idade inserida, utilizando o método getVariable do execution recebido.  

É importante notar que o nome da variável é um texto livre e, portanto, devemos ter o cuidado de escrever o nome da variável corretamente, igual ao nome que utilizaremos mais a frente quando executarmos o processo. Aqui podemos fazer o uso de boas práticas de código como o encapsulamento desses nomes em constantes, para otimizar o reuso e evitar erros de digitação, mas vamos deixar o mais simples possível esse exemplo. 

O método execute atual está apenas exibindo um log info com a informação de se foi aprovada ou reprovada, porém aqui é onde a magia acontece, e você pode executar todo e qualquer código fonte java. Desde chamadas de serviço, acesso a bancos de dados, publicar em um tópico Kafka, etc.  

Para ir deixando marcas no projeto, salvando dados consultados em alguma chamada HTTP por exemplo, é só ir utilizando o método setVariable para salvar qualquer objeto e utilizar o getVariable para buscar esses objetos nas próximas atividades.  

Mas tenha cautela. Os dados aqui são salvos no banco SQL em um formato otimizado para metadados de processo apenas, a qual não deve ser tida como a tua base principal de negócio. Processos com muitas variáveis e objetos complexos tendem a ficar pesados. Salve apenas o necessário para fazer andar o processo, dando preferência para salvar ids e referencias que podem ser buscadas em outro banco/serviço, ao invés de salvar o objeto inteiro. 

Isso é tudo para integrarmos nosso processo ao java. Mas temos agora de configurar também as expressões do Gateway de Desvio, para que ele entenda quando seguir pelo fluxo de aprovação ou reprovação. 

Olhando bem você vai perceber que no caminho de cima, temos um risco na linha entre o gateway e a atividade. Isso significa que esse é o caminho padrão, o tão falado “caminho feliz”. Para definir ele é só selecionar a linha, clicar no ícone de ferramenta e marcar “Default Flow”. No caso de outras as expressões dos outros caminhos falharem, essa será executada. 

Então vamos agora definir a expressão restando. A que nos levará ao caminho de reprovação. 

Para tal, vamos selecionar a linha entre o gateway e a atividade de reprovação. No menu lateral aparecerão agora as opções relativas a fluxos de exclusive gateway.  

Na caixa de seleção “Condition Type” selecione “Expression” e vamos inserir a seguinte expressão também em JUEL: ${idade < 18} 

A expressão utilizada é bem simples. Perceba que estamos novamente utilizando o nome da variável “idade” para buscar o seu valor e validar se é menor que 18. Podemos montar expressões mais complexas, utilizando múltiplas variáveis etc, desde que o resultado seja sempre um booleano. Caso o resultado seja verdadeiro, o processo seguirá por esse caminho. 

Agora sim, podemos salvar o diagrama e rodar novamente nosso projeto java, pois o camunda já terá informações o suficiente para interpretar e executar nosso processo. 

Nesse momento, nosso processo está pronto para começar a receber chamadas e executar a lógica de negócio definida nele. 

Existem muitas formas de se iniciar o processo. Podemos por exemplo utilizar a API REST da própria camunda para iniciar ele através de um POST sempre que um usuário acessar minha aplicação.  

Aqui na Hypeflame nós encapsulamos os processos em APIs REST definidas em nosso micro serviço, aplicando as boas práticas de endpoints e payloads que utilizamos em qualquer outro projeto, não deixando transparecer para nossos clientes da API que por baixo utilizamos essa ou outra tecnologia. 

Sendo assim, no exemplo abaixo mostro como podemos criar um endpoint em um RestController, que receberá dados e iniciará a execução do nosso processo, fazendo uso do RuntimeService, bean exposto pela biblioteca do camunda. 

package br.com.hypeflame.example.camundaspring.api; 
 
import io.swagger.annotations.ApiOperation; 
import org.camunda.bpm.engine.RuntimeService; 
import org.springframework.beans.factory.annotation.Autowired; 
import org.springframework.web.bind.annotation.PathVariable; 
import org.springframework.web.bind.annotation.PostMapping; 
import org.springframework.web.bind.annotation.RestController; 
 
@RestController 
public class ValidacaoController { 
 
    @Autowired 
    private RuntimeService runtimeService; 
 
    @ApiOperation(value = "Executa o processo de validacao") 
    @PostMapping(value = "validacao/{idade}") 
    public String processarValidacaoIdade(@PathVariable Integer idade) { 
        return runtimeService.createProcessInstanceByKey("validacao-idade-cadastro") 
                    .setVariable("idade", idade) 
                    .execute() 
                    .getProcessInstanceId(); 
    } 
} 

Notem que ali fiz o uso do Id validação-idade-cadastro, que foi definido la no campo id no camunda modeler. Também utilizei o método setVariable do builder para já inicializar o processo passando a idade, com o mesmo nome de variável utilizados nos demais pontos (delegate e diagrama). Chamamos então o método execute, que executará de fato o processo, e retornamos o ID da instancia de processo criada por essa chamada. 

Podemos então executar nosso endpoint com o seguinte comando cURL: 

curl -X POST http://localhost:8080/validacao/18 

Após diversas chamadas, temos então os processos instanciados, aguardando conclusão da tarefa humana. 

Clicando no ID de uma das execuções, temos acesso ao contexto atual da execução, podendo visualizar/editar as variáveis, nesse caso, apenas a variável idade. 

Alternando para a aba “User Tasks” podemos ver as informações da tarefa humana na qual esse processo está parado. 

Clique no link da coluna “Task ID” e você será redirecionado para a lista de tarefas. 

Para pegarmos a tarefa para nós e podermos trabalhar nela, é necessário clicar no link “Claim” que está na lateral direita. Isso é necessário para organizar a fila, impedindo que múltiplos usuários trabalhem na mesma tarefa ao mesmo tempo e um acabe desfazendo o trabalho do outro. 

Após ter feito o claim e estar agora atuando nesta tarefa, podemos clicar no “Load Variables” para visualizar e editar as variáveis. 

Nesse caso, podemos editar o valor ou deixar o que já está preenchido. 

Ao clicar no botão “Complete” a tarefa será concluída e o processo seguirá para as próximas atividades. No exemplo acima, como o valor está definido para 18, o processo encerrará automaticamente gerando um log de Cadastro Aprovado, conforme o esperado pela expressão que definimos no gateway de desvio e código do java delegate. 

INFO 12832 --- [nio-8080-exec-2] b.c.h.e.c.d.AprovarCadastroDelegate      : aprovando cadastro com idade 18 

Conclusão 

Agora que você já conhece um pouco sobre a metodologia BPM e essa ferramenta poderosa para gestão e automação de processos que é o Camunda, inclusive a executando em formato de micro serviço podendo aproveitar todo o conhecimento já adquirido em outros projetos, o céu é o limite. 

É bem provável que você já tenha trabalhado em um ou dez projetos onde a documentação do fluxo ponta a ponta se perdeu com o tempo, ficou desatualizada, e que existia um grande esforço para adicionar novos membros a equipe por ter o código fonte como única forma de “garimpar” as regras e fluxo de negócio. 

Espero que o post tenha adicionado mais uma ferramenta no teu cinto de utilidades, e que te ajude a solucionar tais problemas no dia a dia. 

https://github.com/jradesenv/camunda-spring

%d blogueiros gostam disto: