Desmistificando o uso de gateways em BPMN

Existem duas questões relacionadas a BPMN que precisam ser consideradas na utilização da notação: as regras da especificação e a lógica do processo.

As regras da especificação são relativamente fáceis de aplicar já que são bastante claras. Elas definem como são os símbolos, como podem se conectar e o que significam. As dúvidas mais frequentes geralmente estão relacionadas a como aplicá-las para representar as particularidades da lógica do processo de negócio que estamos mapeando.

Recentemente recebemos algumas dúvidas de um leitor do nosso blog sobre a aplicação de gateways, cujas respostas compartilharemos aqui, guiados por esses dois aspectos e mais alguns cuidados de boas práticas.

1) Existe alguma restrição em começar um processo com um evento de inicio e logo depois um gateway?

Um diagrama BPMN de processo em que o primeiro elemento do processo após o início é um gateway.

Pela especificação não. O uso do gateway paralelo após o evento de início neste processo de exemplo enviado pelo leitor é perfeitamente aplicável. Qual seria a razão de se criar um impedimento a  tarefas realizadas em paralelo quando um processo inicie - o que na verdade pode representar um excelente ganho de desempenho no processo ao se reduzir a sua duração?

Entretantopode haver restrição no caso do uso de gateway baseado em dados, como o Inclusivo ou o Exclusivo. Mas é uma restrição lógica: como esses gateways testam um dado para determinar o roteamento do processo, a informação precisa ter sido gerada antes. Assim, na maior parte das vezes, antes do gateway será necessário uma atividade que forneça essa informação. Mas nem sempre. Por exemplo: se o processo começar com um evento de mensagem, pode-se presumir que a informação seja obtida da mensagem recebida ao iniciar o processo. Quando estamos modelando, precisamos pensar nisso.

Portanto, a restrição não é de regra de uso do elemento, mas está associada à lógica do processo mapeado.

 

2. Como fazer quando se deparar com vários gateways em sequência? É correto encadear gateway?

Um diagrama de processo em BPMN com gateways encadeados.

Também não há nenhuma regra restringindo o encadeamento de gateways, mas fazer isso pode tornar a leitura do diagrama mais complexa, além de serem mais elementos agregados no diagrama (quando ele começar a ficar grande, qualquer elemento a menos pode significar uma bela economia !)

A única observação que faço sobre este tipo de diagrama é lembrar que gateways não precisam ser binários (com apenas duas saídas). As melhores práticas de uso da notação recomendam inclusive que se evite utilizar perguntas na definição de gateways porque elas tendem a gerar resultados do tipo “Sim”/”Não”. Em vez disso, recomendamos usar uma regra avaliativa.

Por exemplo: digamos que uma tarefa de avaliação possa resultar em: aprovação, aprovação com restrições ou reprovação, e que cada resultado leve a uma sequência de ações diferentes no fluxo.

Em vez de usar um gateway “Aprovado?” que levaria a resultados “Sim” e “Não“, e então no caso de “Sim” incluir outro gateway que verifica se “Possui restrições?” (ou seja, dois gateways encadeados), poderíamos simplificar em um único gateway, que cuja regra poderia ser testar o “Resultado da avaliação“, com três saídas: “Aprovado“, “Aprovado com restrições” e “Reprovado“, cada uma direcionando ao fluxo de ações que devem se seguir. O exemplo abaixo ilustra os dois casos.

A mesma orientação poderia se aplicar ao exemplo enviado pelo leitor, mas como essa é uma questão associada à lógica do processo e as sequências que saem dos gateways não estão nomeadas, seria necessário avaliar o caso com mais cuidado.

11 ideias sobre “Desmistificando o uso de gateways em BPMN

  1. Estou com uma situação semelhante a do exemplo 2 acima, porém tenho as saídas “Aprovado”, “Aprovado com restrição A” e “Aprovado com restrição B”, sendo que cada tipo de restrição direciona a um fluxo diferente, e podem ocorrer as duas simultaneamente.
    Pensei em usar um gateway inclusivo, mas vi que não daria certo pois a saída “Aprovado” não acontece simultaneamente com as outras. Nesse caso, a melhor forma é usar mesmo gateways encadeados?

  2. Olá Ana,
    Esta é uma particularidade de uso do gateway no qual a especificação não se posiciona claramente.
    Pensando no comportamento do gateway, se a sua atividade anterior garante que não ocorra a combinação de “Aprovado” com as demais saídas, isto não seria um problema, já que a lógica do gateway depende da informação que chega nele.
    Entretanto, se você quer garantir que o uso da notação elimine o risco deste tipo de interpretação, há duas opções: usar o gateway complexo (embora eu evite usá-lo pois ele pode causar mais confusão do que esclarecimento) ou como você disse, a combinação de dois gateways, sendo o primeiro para verificar se está aprovado ou se tem restrições e o segundo inclusivo verificando o tipo de restrição.
    Espero ter ajudado!

  3. Considerando que as melhores práticas não recomendariam o uso de pergunta, quando um modelo tem saída com resposta obrigatória do tipo “sim” ou “não”, ainda assim não se recomenda pergunta no gateway?

  4. Olá Elton,
    As boas práticas recomendam evitá-las justamente para instigar o analista e a equipe a considerarem que o gateway pode fazer mais do que tratar respostas binárias (sim/não). Ele testa valores, e até mesmo combinações de valores, que podem ir além de apenas duas saídas. Entretanto, não é uma restrição. Se o cenário do processo de negócio demanda que o fluxo seja roteado desta forma, não há problema em usar perguntas.

  5. Qual é o gateway que possui semântica equivalente ao gateway inclusivo (e/ou), mas que é baseado em eventos. Ou seja, se um evento for disparado, o token presente nos demais eventos não é consumido e, sim, poderá ser acionado a qualquer momento no decorrer do processo.

  6. Olá Paulo. Não há na notação BPMN um gateway intermediário que possibilite a combinação de lógica inclusiva baseado na ocorrência de um ou mais eventos. Isto porque o processo não saberá se, ao ocorrer um dos eventos conectados ao gateway, ele deve ou não esperar os outros ocorrerem para então identificar qual a combinação e fazer a variação do processo. Se você tem um cenário assim, precisará lançar mão de outros elementos para configurar o processo de forma a atendê-lo. Isso depende muito da própria lógica do processo. Se quiser nos enviar um cenário de negócio em que isto é requerido, podemos tentar ajudá-lo a representar esta situação com a notação.

  7. Alguns gestores, comentaram ao utilizar os gatway não os utiliza com uma pergunta, porém eu vi nós exemplos que é possível sim fazer perguntas, qual é o correto?

  8. Olá Carol,
    Não existe uma regra específica para o uso de gateways. A notação BPMN é bastante permissiva, ela não detemina o que, que forma ou termos devem ser usados, por isso muitos profissionais da área ajudaram a consolidar algumas boas práticas.
    Em geral, perguntas que levem a um roteamento simplificado, como aqueles com resposta “sim” e “não” costumam ser evitadas nessas práticas. Não porque seja proibido/errado, mas porque muitas vezes ele esconde uma oportunidade de deixar o processo mais claro.
    Por exemplo, um gateway com a pergunta "Aprovado?" e respostas "Sim" e "Não" à primeira vista parece usual, mas o que significa realmente “não ser aprovado“? Significa que alguém formalmente rejeitou completamente aquela avaliação e nada mais pode ser feito, terminando o processo? Ou rejeitou apenas por algum detalhe que se for corrigido poderá ser novamente avaliado? Ou talvez porque passou o tempo e ninguém fez nada, e portanto não foi de fato aprovado? Ou foi aprovado, mas com algumas restrições? Esses casos deveriam seguir o mesmo fluxo de “não aprovado“?
    Caso os caminhos a serem seguidos pelo processo precisem ser explicitados pois levam a sequências de atividades diferentes, a recomendação é que o gateway leve o nome da informação que ele verifica para fazer o roteamento. O que o gateway verifica, neste caso? Ele verifica o "Resultado da avaliação". Usando este nome para o gateway, podemos explicitar saídas para cada resultado, por exemplo: "Aprovado", "Reprovado", "Aprovado com restrições"“, "Requer revisão".

    Portanto, não é errado usar perguntas, mas é uma prática que se recomenda que seja evitada. Em alguns casos, elas fazem sentido, em outras podem estar camuflando lógicas de processo como esta.

  9. Olá Fábio. A princípio, pelas regras da notação, não precisa, embora tenha se tornado uma prática muito usual. O que determina a necessidade de adicionar um gateway para convergência não é se teve uma gateway de divergência antes, e sim se a partir de um determinado ponto do processo as atividades seguintes possuem dependência em relação ao término das atividades dos fluxos anteriores.
    Entretanto, algumas ferramentas de automação, por questões de controle sobre o fluxo, exigem que toda divergência feche de alguma forma em uma convergência, de forma que o processo tenha apenas um evento de fim. Isso é uma restrição imposta pela ferramenta, não pela notação.

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

*

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>