Prosseguindo com nosso estudo de elementos avançados, neste terceiro artigo da série abordaremos um dos elementos mais utilizados no fluxo de um processo de negócio: os Gateways.
Gateways
Gateways são os elementos de BPMN responsáveis por controlar iterações do fluxo, criando caminhos alternativos ou paralelos no mapeamento do processo ou unificando fluxos para continuação em uma mesma sequência de atividades.
No artigo Um guia para iniciar estudos em BPMN (II): Gateways, vimos também que o gateway é conectado ao fluxo através de setas de fluxo de sequência e é representado visualmente por um losango. O símbolo interno do losango identifica a interpretação lógica representada. Para um estudo completo sobre os gateways indicamos a leitura deste artigo.
Com foco em elementos avançados falaremos sobre dois dos cinco diferentes gateways.
Exclusive Event-Based Gateway
O desvio condicionado por evento é semelhante ao Gateway exclusivo (Databased Exclusive Gateway): indica pontos do processo em que o gateway exclusivo não se baseia em dados de processo, mas sim sobre as mensagens ou eventos externos. Esta forma é usada para exercer controle sobre a execução de determinadas atividades que ficam disponíveis até que um dos eventos sejam executados.
No gateway condicionado por um evento específico, normalmente o recebimento de uma mensagem determina o caminho que será tomado. Basicamente a decisão é tomada por um outro participante, com base em dados que não são visíveis ao processo e, assim, exigindo o uso do gateway baseada em eventos.
Podemos imaginar: quando nosso processo chegou ao evento baseado em gateway, vamos esperar até que algo aconteça. O evento geralmente é disparado por terceiros (por exemplo, o nosso cliente envia o pagamento para nós). Abaixo é a porta baseada em eventos típicos. Enviamos uma cotação para o cliente, aguardando o cliente confirmar o pedido. Se o cliente envia a confirmação, vamos preparar as mercadorias para o cliente. Se não receber qualquer confirmação do cliente após 15 dias, o pedido é cancelado. Veja o processo abaixo.
Complex
Gateway complexo é usado para modelar o comportamento de sincronização complexa. É sempre indicado que antes de utilizar o gateway complexo, tente usar a combinação de tipos diferentes de gateways.
Uma Activation Condition Expression (Expressão de ativação de condição) é usada para descrever o comportamento preciso do gateway complexo.
Por exemplo, essa expressão poderia especificar que os tokens em três dos cinco fluxos de sequência de entrada são necessários para ativar o gateway do processo abaixo.
Obrigado a todos e até nosso próximo artigo!
Confira todos os artigos deste guia de BPMN: Modelando processos de negócio com elementos avançados:
- BPMN: Modelando processos de negócio com elementos avançados (Parte I): Marcadores de Atividades
- BPMN: Modelando processos de negócio com elementos avançados (Parte II): Continuação Marcadores de Atividades
- BPMN: Modelando processos de negócio com elementos avançados (Parte III): Gateways (você está aqui)
- BPMN: Modelando processos de negócio com elementos avançados (Parte IV): Subprocesso de eventos
20 Responses
Prezado Bom dia, eu tenho uma dúvida.
Eu tenho um processo de decisão aqui na empresa de qual modalidade escolher para seguir o processo, ou seja, vou solicitar uma análise de balancete mais para cada tipo de empresa eu tenho um subprocesso de análise é diferente.
Ex. atividade analise de balancete, vem a pergunta regime da empresa, para cada regime eu tenho um sub processo de análise Simples, Lucro presumido, Lucro Real, Real mensal, Real Trimestral. É escolhido um e os outros são cancelados.
Qual Gateway eu poderia usar antes e depois?
Obrigado,
Olá Cleiton,
Primeiramente gostaria de agradecer por sua participação em nosso blog e também pedir desculpas pela demora na resposta.
Bom, vamos lá!
Supomos que o Processo de Análise de Balancete inicie com a verificação e/ou cadastro dos dados da empresa em questão, nesta atividade deverá ser informada o tipo de empresa (Ex. categoria jurídica ou porte da empresa). Esta informação será utilizada para que o gateway, que virá na sequência do fluxo, possa interpretar o caminho que o fluxo seguirá no processo.
É importante entender que este gateway indiferente do seu tipo NUNCA toma decisões, como falamos no artigo, ele apenas aponta a direção que o fluxo deverá seguir levando em conta a informação que lhe foi passada. No caso deste processo poderia ser a informação do porte da empresa (por exemplo).
Levando em conta sua informação, que apenas um sub-processo é executado, temos a representação de um gateway exclusivo (Databased Exclusive Gateway), representando uma condição de fluxo exclusiva, em que apenas um dos caminhos criados a partir do gateway será seguido, de acordo com uma informação a ser testada (porte da empresa). Este gateway é representado visualmente por um losango vazio ou com um marcador de “x”.
Este gateway realiza a leitura do porte da empresa e direciona para o sub-processo indicado.
Poderíamos dizer que se o porte da empresa é “Super Simples” o gateway direcionaria para o “Sub-Processo de Análise Simples”, descartando todas as outras alternativas.
Além de realizar separação dos fluxos, o gateway também pode unificar fluxos distintos em uma única sequência de atividades. Neste caso, o gateway exclusivo implica no entendimento que, dos caminhos que convergem a ele, o primeiro que chegar dará continuidade no fluxo do processo.
Portanto teríamos no fluxo do seu processo dois gateways exclusivos, um divergente e outro convergente.
Espero ter ajudado e caso ainda tenha dúvidas fico a disposição.
Grande abraço!
Olá, em primeiro lugar, parabéns pelo blog, os artigos são objetivos e muito úteis para o aprendizado.
Tenho algumas dúvidas, poderia ajudar, por favor?
1) Uma das últimas tarefas ao final de um processo é enviar uma pesquisa de satisfação para o cliente. Se ele responder, prossigo o fluxo registrando comentários do cliente e encerrando o processo. Se ele não responder em 1 semana, encerro o processo. Qual gateway utilizar? Fiquei em dúvida porque pode ocorrer um caminho e/ou outro caminho, mas qualquer combinação prossegue o fluxo. Teria que ser um gateway inclusivo baseado em eventos… Existe?
2) No caso citado anteriormente, digamos que após seis meses o cliente responda a pesquisa de satisfação. Pela condição imposta, o prazo de uma semana terá se esgotado e o processo encerrado. Mas é preciso registrar o resultado da pesquisa. Como represento isso no diagrama?
3) Não entendi a explicação sobre o gateway complexo. Seria possível dar um exemplo?
Muito obrigado.
Olá Dario.
Para sua pergunta 1), ao que você descreve o ideal seria mesmo usar um gateway baseado em eventos. Entretanto, não é um comportamento inclusivo. Ele é exclusivo: espera a resposta do cliente ou uma semana, o que ocorrer primeiro, certo? Se o cliente responder dentro do período de uma semana, ele seguirá por este fluxo e encerrará o processo. Senão, a outra opção será exclusivamente o esgotamento do prazo, que também encerrará o processo.
Para a pergunta 2) infelizmente não há na notação um elemento para representar a reativação de um processo que já foi encerrado. se há mais trabalho do que o registro da pesquisa em seu processo, talvez tenha que considerar a criação de um processo ativado pela chegada da pesquisa preenchida.
Quanto ao gateway complexo, ele é de fato difícil de exemplificar. Entendemos que a equipe que criou a notação BPMN o inventou como um “coringa”, que possa ser usado quando nenhum dos outros for aplicável. A ideia por trás dele é que a lógica para decidir qual (ou quais) fluxos de saída serão executados é muito complexa para ser representada com os demais. Digamos que o gateway mapeie as saídas A, B, C e D e você pode ter combinações (o que o caracterizaria como inclusivo) porém não qualquer tipo de combinação. Por exemplo: poderia ter as combinações “A e B”, “A e C”, A e D”, A, B e D”, e “A, C e D” mas nunca uma combinação que envolva as saídas B e C juntas. Na prática até hoje não identificamos situação em que tivesse que ser usado este gateway.
Boa tarde.
Gostaria de saber se o gateway exclusivo baseado em eventos pode ser usado também para convergência de fluxos. Tenho uma situação em que meu processo aguarda por uma manifestação externa, que pode ocorrer em um determinado limite de prazo, e segue quando a mesma chega ou quando o prazo é expirado. Em ambos os casos, o fluxo é seguido com uma atividade de avaliação de cenário. Representei a ramificação com o gateway exclusivo baseado em eventos, dividindo o fluxo para um evento de recebimento e um de tempo. Preciso convergir para a atividade Avaliar Cenário. Devo usar o mesmo gateway?
Olá Rafael. Para esclarecer sua dúvida: o gateway exclusivo baseado em eventos é usado apenas para divergência de fluxos. Para unificá-los, você pode usar um gateway exclusivo comum, já que a lógica de convergência de fluxo é a mesma: fluxo exclusivo.
Ok, Kelly, muito obrigado!
Lendo a documentação do Bizagi(https://help.bizagi.com/processmodeler/en/index.html?gateways.htm), o símbolo aqui apresentado lá encontra-se com nome “event based gateway”, sendo outro o símbolo para “exclusive event based gateway”. A tradução para português do nome do símbolo está adequada?
Abelardo, a especificação BPMN oficial é apenas em inglês, e as traduções para português são livres. Por isso, podem variar entre autores e ferramentas.
Mesmo nos termos em inglês, algumas ferramentas fazem adaptações. Na dúvida, recomendamos sempre pesquisar o elemento na especificação oficial pelo seu nome original (em inglês).
Boa Tarde,
Tenho um fluxo de liberação de licenças e tenho 7 tipos de licenças, gostaria de saber se tem como ter 7 saídas como por exemplo essa ilustração do gateway complexo, ou se teria que criar um fluxo para cada licença (sendo que só muda a descrição mais o fluxo é o mesmo).
Olá Priscilla. Você pode ter sim sete saídas de um gateway, embora isso pareça pouco usual e talvez deixe.
Mas se todas elas apontam para o mesmo fluxo, ou seja, todos os tipos de licenças levam para o mesmo caminho, qual o sentido de aplicar um gateway neste ponto do processo?
Bom dia! Primeiro, parabéns pelo blog, estou começando na área de processos e é a ele que recorro na maior parte de minhas dúvidas.
A respeito do Gateway Complexo: na convergência, se as regras do negócio permite que ao finalizar três caminhos de cinco disponíveis o processo pode seguir, os dois que não foram finalizados serão desabilitados?
O gateway complexo, na convergência, deverá ter uma regra determinando seu andamento. Se for aplicada esta lógica de que bastam três dos cinco caminhos para seguir o processo, e a divisão do fluxo foi feita por um gateway paralelo (todos os caminhos foram habilitados mas apenas 3 bastam para seguir), o gateway dará andamento com a condição, mas ainda pode ocorrer dos outros dois caminhos chegarem posteriormente. Para garantir o término do processo, deve ser usado um evento final do tipo terminate.
Isto está descrito na especificação formal da notação. Veja este exemplo, extraído diretamente da especificação formal da notação:
Olá Kelly, tudo bem?
Durante o mapeamento de um processo, identificamos uma situação em que foi necessária a utilização de um gateway baseado em evento paralelo. Por tudo que li sobre este tipo de gateway, inclusive no material da OMG, percebi que ele se assemelha mais ao gateway inclusivo comum do que ao gateway paralelo comum, uma vez que nem todos os eventos previstos necessariamente irão ocorrer, fazendo com que nem todos os fluxos sejam ativados. Na visão de vocês, essa interpretação está correta? Caso esteja, o gateway mais indicado para convergir os fluxos iniciados pelo gateway baseado em evento paralelo seria o gateway inclusivo? Ou deveríamos utilizar o gateway paralelo na convergência, já que a simbologia e a nomenclatura dele é a mesma? Obrigado!
Oi Tiago,
Para uso no meio do fluxo (intermediário) não há gateway baseado em eventos paralelo. Este evento que você citou é apenas para disparo de processos, e sinceramente não recomendaria usá-lo na modelagem porque pode ser bastante confuso para as pessoas entenderem (e acho que poucas ferramentas BPMS de fato o implementam).
Se você precisa fazer uma restrição no seu processo entre as atividades A e B de forma que a tarefa B só aconteça depois que dois (ou mais) eventos aconteçam, você pode criar, entre A e B, um fluxo paralelo com gateway paralelo comum, e para cada saída adicionar o evento a ser monitorado. Cada evento conecta sua saída a um gateway paralelo de convergência (unificação) do fluxo e então deste segue para a atividade B.
Com isso, você garante que todos os eventos aconteceram antes de seguir para a próxima tarefa, e que ela não iniciará antes que todos eles tenham ocorrido.
Certo, Kelly! Avaliando melhor, vimos que realmente é possível desenhar o modelo utilizando elementos mais simples (gateways paralelo e exclusivo comuns). Muito obrigado!
Olá, Kelly,
Gostaria de sua ajuda para representar uma situação que pode ocorrer me qualquer tempo do processo e, caso ocorra, altera o fluxo. Na prática, recebo uma solicitação, processo esta solicitação visando a sua concessão, mas nos decorrer deste processamento, em qualquer momento, pode chegar uma informação de outros processos que são acionados de forma independente, que faça com que eu suspenda essa solicitação de imediato. Não sei em qual momento devo representar esta chegada da informação que altere meu fluxo.
Olá Marcos,
Pela sua descrição, parece que a melhor forma de representar este cenário no seu diagrama será usando um Subprocesso Eventual (Event Subprocess).
Confira algumas dicas de como ele funciona e como deve ser modelado no artigo BPMN: Modelando processos de negócio com elementos avançados (Parte IV).
Olá Kelly… estou com dúvida de como representar uma situação num processo. A área imprime a documentação e coleta fisicamente a assinatura de várias áreas… mas não tem uma ordem definida de quem assina primeiro e pode ser que em um projeto uma área assine mas no outro essa área não assine (pq depende do objeto do projeto). Como consigo representar essa situação? Obrigada!
Oi Polyane! Olha, acho que se você tentar modelar todos os fluxos possíveis, vai sair uma maçaroca né?
Quem sabe usar uma tarefa com múltipla execução? Após a tarefa de imprimir a documentação, represente em uma raia chamada “Áreas aprovadoras” (ou algo assim) uma tarefa “Assinar documentos”. Use na tarefa um marcador de execução múltipla. Se as aprovações são sequenciais (uma por vez) você pode usar o loop. Se as aprovações são em paralelo (os documentos são distribuídos para várias áreas e cada uma assina um documento, sendo que o processo segue quando todas as assinaturas foram coletadas), você pode usar um marcador de múltiplo paralelo (três tracinhos).
Coloque na descrição dessa tarefa a regra, regimento ou política que determina como se dá a regra de definição dos aprovadores (deve ter algum documento com as regras que definem quem assina o quê, quando e em que ordem né? que tal referenciar esse documento? Se ele não existe, que tal criar?)