Looplex Knowledge Base

Fundamentos do Flowable

Componentes básicos do Flowable

O Flowable é composto por alguns componentes básicos que formam a lógica dos fluxos de trabalho:

Cases (Casos)

Utilizam a estrutura de CMMN (Case Management Model Notation). Em resumo, cada Case tem uma ou mais fases que a compoem, sendo cada fase composta por um ou mais processos;

Imagem da pasta 'packages'

Processes (Processos)

Utilizam a estrutura de BPMN (Business Process Management Notation). Esses são os Workflows propriamente ditos em formato de fluxogramas, contendo sempre um evento de início e um evento final necessariamente. Entre eles, tarefas podem ser cumpridas.

Imagem da pasta 'packages'

Tasks (Tarefas)

Ações que devem ser efetuadas por ação humana ou automação. Elas compõem grande parte dos processos. As Tasks podem ser basicamente:

User Tasks (Tarefas de Usuário), que são tarefas nas quais se espera que ocorra a interação humana em algum nível, como preencher um formulário, clicar em um botão ou executar qualquer outra ação prevista;
Service Tasks (Tarefas de Serviço), que são tarefas que utilizam alguma forma de serviço, como uma chamada para um serviço web ou uma aplicação automatizada, que não requer intervenção humana.

Imagem da pasta 'packages'

O Flowable conta com elementos adicionais de tarefas que podem ser utilizadas para funções específicas (como tarefas Camel, Http, Mail, regras de negócio, script, etc.) mas para a descrição conceitual que precisamos, todas podem ser consideradas como Tarefas de Seviço.

Gateways (Gateways de Decisão)

Gateways de Decisão permitem criar caminhos alternativos de decisão em um fluxo e são representados por um losango. No caso do Flowable, são utilizados Gateways de Decisão Exclusivos, ou seja, um gateway sempre possibilitará apenas a escolha de um caminho dentre uma série de alternativas, que é um losango com um “X” no meio.

Imagem da pasta 'packages'

Process Flows (Fluxos de Processo)

Process Flows são as “setas” que conectam um elemento a outro no Workflow, e sempre possuem uma origem e um destino.

Imagem da pasta 'packages'

Events (Eventos)

Podem ser de captura (catching, para dentro) ou lançamento (throwing, para fora):

Captura (catching): quando a execução de um processo alcança um evento, ele aguardará um gatilho acontecer; e
Lançamento (throwing): quando a execução de um processo alcança um evento, ele dispara um gatilho.

O BPMN pode enviar informações por meio de um payload (JSON ou XML) para um processo ou fase externa (outbound), ou ainda receber informações de fora para executar alguma ação (inbound), sempre vinculado a um Evento.

Imagem da pasta 'packages'

Construções BPMN 2.0 no Flowable

O Flowable possibilita construir BPMN 2.0, além de contar com extensões customizadas que não fazem parte da especificação BPMN 2.0 que visam facilitar a construção de algumas estruturas visando a facilidade de desenvolvimento.

-⚠️ A documentação completa acerca de definições BPMN, extensões do Flowable e sintaxe encontra-se aqui: https://www.flowable.com/open-source/docs/bpmn/ch07b-BPMN-Constructs

Nesta documentação, faremos referência a alguns elementos existentes do Flowable que serão possivelmente utilizados com maior frequência modelarmos fluxos de trabalho no ambiente Looplex. Recomendamos a leitura completa da documentação quanto aos eventos disponíveis e para referência quanto aos possíveis eventos, servindo a documentação como um guia bastante completo quanto às anotações possíveis em BPMN 2.0.

1. Eventos Sinalizadores (Signal Events)

Os Signals (sinais) são eventos que são emitidos para o sistema em um escopo global e que tem o poder de acionar todos os processos que o estejam observando. É possível vincular um signal a uma instância de execução específica passando um parâmetro customizado do Flowable (flowable:scope="processInstance”).

Imagem da pasta 'packages'

Neste exemplo, após a aprovação manual das condições da nova política, há um evento de signal emitido comunicando que houve a alteração. Esse evento é voltado para fora, sendo transmitido (boardcast)

Imagem da pasta 'packages'

O sinal transmitido é capturado por outros processos que tenham um evento de captura para aquele evento.

2. Eventos de Mensagem (Message Events)

Os eventos de mensagem são eventos que fazem referência a uma mensagem, contendo um nome e um payload, e sempre dizem respeito a um único destinatário.

Imagem da pasta 'packages'

Acima um exemplo com Eventos de Mensagem que podem iniciar um processo por caminhos alternativos.

3. Eventos de Erro (Error Events)

Eventos que representam erro, podendo ser de captura (catching) ou de lançamento (throwing), e são representadas pelo ícone com representação de erro e podem ser de início ou final de processo.

Imagem da pasta 'packages'

4. Eventos de Limite (Boundary Events)

Eventos de Limite são eventos intermediários de captura linkados a uma atividade. Enquanto a atividade está rodando, o evento está “ouvindo” por um certo tipo de gatilho. Quando o evento é capturado, a atividade é interrompida e a sequência do fluxo para fora do evento é seguida.

Imagem da pasta 'packages'

No exemplo acima, temos um Evento de Limite do tipo Timer: ele é acionado quando a atividade é iniciada e ao ocorrer o evento de limite (por exemplo, certo tempo decorrido), a atividade é interrompida e o fluxo segue a partir do evento de limite especificado.

Se o Evento Limite for interruptivo ele terá linhas contínuas, enquanto um evento não interruptíve terá linhas tracejadas.

Imagem da pasta 'packages'

5. Eventos de Compensação (Compensation Boundary Events)

Eventos de Compensação são eventos intermediários que são executados tantas vezes quantas a atividade foi executada. No exemplo abaixo, o cancelamento da reserva deve ser feito para quantas vezes a atividade de efetuar reserva foi executada.

Imagem da pasta 'packages'

Tarefas para Integração

O Flowable contém uma série de tarefas pré-estabelecidas para facilitar o processo de integração com outras tecnologias, não seguindo o padrão BPMN 2.0. Com essas funcionalidades o Flowable prevê meios mais convenientes para integrar o seu fluxo de trabalho com outros serviços (e.g. email, requisições HTTP, Camel Apache, Mule, Java, Shell, Scripts, External Worker).

Apesar de gama de opções que o Flowable oferece, podemos já conduzir muitas integrações com REST APIs externas simplesmente utilizando uma Service Task e suas variações. Abaixo, temos um exemplo de uma tarefa que recebe uma ordem externa por meio do acesso à API do Flowable e lhe manda uma mensagem, bem como de um exemplo em que o Workflow ativamente acessa uma API externa para buscar as informações necessárias.

Tarefa de Mensagem (Message Task)

Nessa tarefa, que nada mais é que uma tarefa de serviço que recebe uma requisição via mensagem, faremos a captura de parâmetros para o nosso fluxo.

Imagem da pasta 'packages'

Para capturar a mensagem e entregá-la em nosso workflow, precisaremos dos seguintes parâmetros mínimos:

NO ESCOPO DO PROCESSO:

Message definition: id e name do elemento de mensagem;

NO ESCOPO DA TAREFA DE MENSAGEM

Id: id da tarefa mensagem;
Message reference: id da Message Definition especificada no escopo do processo;
Name: Nome da Tarefa

Com essas especificações definidas, podemos acionar o gatilho da tarefa enviando uma mensagem ao workflow via REST API do Flowable, como ao acionar uma Tarefa de Mensagem de Início (Message Starter Task):

Endpoint: http://localhost:8088/flowable-rest/service/runtime/process-instances
Payload: JSON contendo a propriedade message com o mesmo valor do name na Message Definition

Imagem da pasta 'packages'

Tarefa de Requisição HTTP (HTTP Service Task)

Essa tarefa permite que o seu Workflow faça uma requisição HTTP para um serviço externo (como uma API) e utilize os dados obtidos. Para utilizar uma HTTP Service Task você pode definir antes no seu Workflow um serviço de Script para definir variáveis que serão enviadas ao serviço para melhor organização e manipulação posterior.

Imagem da pasta 'packages'

Na tarefa de Script anterior definimos em nosso exemplo o seguinte:

Script format: groovy
Script: Nosso script efetivo, que no caso é compostona forma abaixo. No nosso caso, definimos uma variável chamada requestUrl para conter o endpoint do nosso serviço externo de API e a variável requestHeaders para aceitar Json.

Imagem da pasta 'packages'

Na etapa seguinte, que contém efetivamente a tarefa de requisição HTTP, temos os seguintes parâmetros:

Request method: GET
Request URL: ${requestUrl}
Request Headers: ${requestHeaders}
Response Variable Name: myPayload

No nosso exemplo, definimos um método GET para buscar informações (a depender do Endpoint que estamos usando na REST API, podemos utilizar um POST, PUT, DELETE). Ainda, definimos a Request URL e Request Headers associando as variáveis que criamos na tarefa de Script anterior. Finalmente, definimos o nome da variável que receberá o resultado da requisição para ser tratada e utilizada em etapas posteriores.

API do Flowable

O Flowable conta com uma API bem documentada, disponível em https://documentation.flowable.com/latest/develop/core-swagger/

Imagem da pasta 'packages'

A documentação oficial traz os endpoints disponíveis na API do Flowable e segue o padrão da documentação Swagger, sendo assim bastante familiar.

A partir da REST API você pode realizar chamadas diretamente para o seu endpoint e interagir, criar, enviar e receber valores dos fluxos existentes. Assim, por meio dos endpoints corretos, podemos consultar os dados gerados pelo Flowable diretamente pela REST API:

Imagem da pasta 'packages'