Skip to main content

Introdução

Blueprint é uma palavra de tradução simples, que pode assumir significados diferentes de acordo com o contexto. No nosso contexto, da utilização do FlowBuild para o desenvolvimento de software, podemos entender a blueprint como esquema. Um esquema que representa um processo. O processo desenhado a partir da necessidade de negócio. Este processo pode ter sido desenhado utilizando, por exemplo, a notação BPMN. Assim, a Blueprint é o artefato que descreve o processo de negócio para o Flowbuild interpretar, ou seja, é um arquivo do tipo JSON passível de interpretação pelo FlowBuild.

A Blueprint é responsável por especificar todos os elementos de um processo e orquestrar os canais e serviços.

Na implementação do FlowBuild, implementamos alguns, porém não todos os elementos BMPN. Consulte a seção BPMN para mais detalhes sobre BPMN e a implementação pelo FlowBuild.

Para armazenar uma blueprint, o FlowBuild necessita de 3 informações:

  • name: O nome da blueprint. Apesar de estruturalmente o FlowBuild aceita qualquer texto, é recomendável evitar o uso de espaços e caracteres especiais.
  • description: Uma descrição da blueprint. Esse campo não influencia a execução do processo, mas é importante para identificar o que a blueprint representa.
  • blueprint_spec: o esquema de execução que será utilizado pelo FlowBuild.
ATENÇÃO

O nome do workflow é case sensitive

Blueprint Spec#

Uma blueprint é definida por um objeto com 6 atributos:

  • prepare
  • requirements
  • enviroment
  • parameters
  • lanes
  • nodes
Recomendação

A visão de negócio orientado a processos sugere que os processos em si documentam o negócio, assim todos os parâmetros de documentação devem ser utilizados para que tenhamos um melhor entendimento das blueprints. Os itens name e description servem muito mais a um olhar humano no que ao Flowbuild Engine.

Numa perspectiva de projeto com muitas blueprints, é recomendável que os nomes e descrições sejam de certa forma padronizados, para que todos os profissionais que escrevem blueprints sigam o mesmo racional.

Prepare#

É descrito como a lista de funções que devem ser executadas antes da inicialização do processo.

Requirements#

É descrito coma uma lista de packages que devem ser importados pelo FlowBuild para execução do processo. É uma forma de importar para a blueprint pacotes específicos de execução.

Exemplo:
{
"requirements": [
"core"
]
}

Environment#

O campo enviroment tem por objetivo trazer para a blueprint as variáveis de ambiente da aplicação. É possível definir quantas variáveis forem necessárias.

Essas variáveis são imutáveis e avaliadas no momento da criação do processo.

Atribui o valor da env API_KEY com o nome X-API-KEY
{
"environment": {
"X-API-KEY": "API_KEY"
}
}

Esses valores podem ser acessados através das notações de comando, usando o namespace environment.

Parameters#

Trata-se um objeto onde são definidos constantes aplicadas para aquela determinada blueprint.

Do ponto de vista do processo, são valores imutáveis (assim como as enviroments), porém são aplicáveis no escopo de uma determinada blueprint e não são influenciadas pelo ambiente da aplicação. Elas são definidas no momento da publicação de blueprint.

{
"parameters": {
"value": 10,
"name": "fulano"
}
}
EXEMPLO

O atributo max_step_number. Quando definido nos parameters da blueprint, o FlowBuild não permitirá que aquele processo exceda a quantidade de steps determinada, automaticamente interrompendo o processo caso o limite seja atingido.

Esses valores podem ser acessados através das notações de comando, usando o namespace parameters.

Lanes#

Uma lane é a expressão do controle de acesso a um conjunto de nós. Uma lane define quais regras devem ser atendidas para que um usuário tenha acesso a um determinado nó.

Do ponto de vista do BPMN, a lane é importante como elemento visual para identificar as responsabilidades de cada conjunto de tarefas. No caso do motor de execução, as lanes são relevantes em apenas duas situações: no evento de início (startNode) e nas tarefas de usuário (userTaskNode).

No caso do evento de início, as regras da lane são avaliadas para definir se o usuário tem acesso ao workflow (a rota de listagem de workflow avalia a lane de cada startNode para filtrar os workflow do usuário) e, em caso de múltiplos statNodes, a engine utiliza o acesso a lane para identificar quais dos inícios deve ser utilizado.

no caso das tarefas de usuário, a lane é importante para identificar quais os usuários tem acesso a uma determinada tarefa. Caso sua aplicação esteja configurada com listeners de Activity Managers, a partir da lane são identificados e notificados todos os usuários aptos a realizar a tarefa. Se você deseja evitar o vazamento de tarefas entre usuários, defina bem as lanes de suas tarefas de usuário.

Em uma blueprint, a lane é definida como um objeto com 3 atributos:

  • id: identificador da raia, é uma string e será referenciados pelos nós da blueprint;
  • name: nome da lane, tem a função de descrição o usuário. Este campo não é utilizado pelo FlowBuild durante a execução do processo;
  • rule: uma função que define quem tem acesso aos nós daquela determinada lane.

A rule, assim como o script da scriptTask, recebe código na sintaxe LISP. Deve ser uma função que retorna true/false dizendo se um dado usuário tem permissão de executar nodes dentro da lane.

A rule é executada contra o actor data do usuário e sempre avaliada em em tempo de execução.

Nota

É possível utilizar a notação $js no campo rule, permitindo executar funções javascript se desejado.

Exemplos de Rules de lanes#

Atualmente não existe controle para distinguir política de acesso (leitura ou ação).

Apesar das lanes não serem avaliadas para execução de systemTasks ou flowNodes, é recomendável utilizar lanes distintas para esses nós caso haja algum tipo de valor para entedimento das responsabilidades dentro da organização.

Lembre-se que as condições da lane dependem de:

  • Dados do ator
  • Regra da Lane (rule)
  • Contexto do Processo (quando aplicável): algum dado do estado do processo.

O FlowBuild não tem usuários onipotentes, caso sua lane resulte em uma condição inacessível para os usuários, o processo ficará pendente até que seja abortado ou expirado (caso haja prazo cadastrado).

Nós ou Nodes#

Um nó é a menor unidade do processo, é uma tarefa que deve ser executada.

Toda vez que um nó executado ele gera um novo estado, que é gerado e salvo ao término da execução do nó.

Existem vários tipos de nós, que estão descritos em maiores detalhes das seção nós dessa documentação.

Numa blueprint o atributo nodes é descrito como uma lista de nós que, por sua vez, é descrito como um objeto com os seguintes atributos:

  • id: definido como uma string, é o identificador do nó e deve ser único no contexto da blueprint;
  • name: nome do nó, tem uma função descritiva para o usuário que lê a blueprint. Não afeta a execução do processo, porém detém muito valor para análise futura e rastreamento;
  • lane_id: Uma string que faz referência ao id de umas das lanes da blueprint. Uma falha na referência impede a blueprint de ser publicada.
  • next: indica qual o próximo nó será executado após a execução do nó atual. Deve fazer referência a um nó da própria blueprint. A inexistência de referência impede a blueprint de ser publicada.
  • type: define o tipo de tarefa que deverá ser realizada. Veja a seção de nodeTypes para mais detalhes.
  • category: atributo exclusivo para systemTaskNodes.
  • parameters: é definido por um objeto com os parâmetros de execução do nó e dados de input (quando aplicável).
Edit this page