Desmistificando o uso de gateways em BPMN _ Blog da iProcess

Prévia do material em texto

Desmistificando o uso de gateways em BPMN
Kelly Sganderla - 17 de outubro de 2013
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?
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?
Entretanto, pode 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
Um diagrama BPMN de processo em que o primeiro elemento do processo após o
início é um gateway.
—
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?
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.
Um diagrama de processo em BPMN com gateways encadeados.—
20 IDEIAS SOBRE “DESMISTIFICANDO O USO DE GATEWAYS EM BPMN”
Compartilhar Enviar para um amigo Imprimir
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.
Tags: BPMN, BPMN 2.0, BPMN avançado, erros comuns BPMN, melhores práticas BPMN, modelagem de processos
Ana
em 11 de fevereiro de 2014 às 3:21 pm disse:
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?
Kelly Sganderla
em 12 de fevereiro de 2014 às 6:52 pm disse:
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!
Ana
em 17 de fevereiro de 2014 às 6:45 pm disse:
Obrigada! Fiz dessa forma mesmo, com dois gateways. Acho que ficou mais claro.
Obrigada pela atenção.
Elton Iappe
em 22 de janeiro de 2015 às 9:34 am disse:
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?
Kelly Sganderla
em 4 de fevereiro de 2015 às 1:11 pm disse:
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.
Paulo Vieira
em 25 de abril de 2015 às 7:10 pm disse:
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.
Kelly Sganderla
em 8 de junho de 2015 às 4:52 pm disse:
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.
Carol Xavier
em 3 de maio de 2016 às 10:50 am disse:
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?
Kelly Sganderla
em 4 de maio de 2016 às 10:08 am disse:
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 gatewaycom 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.
Fábio Aparecido
em 10 de junho de 2017 às 7:57 am disse:
Bom dia
Todo Gateway precisa de convergir???
Kelly Sganderla
em 28 de junho de 2017 às 11:09 pm disse:
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.
Francisco Junior
em 18 de janeiro de 2018 às 9:58 pm disse:
Olá, Kelly
Primeiramente adorei seu blog e suas explicações são bem claras. Parabéns!
Indo ao assunto, eu preciso de uma ajuda num caso. No projeto que estou desenvolvendo,
o funcionário vai até a casa do cliente, daí ele encontra 5 distintas: ele negocia a divida, ele
não negocia a divida, casa abandonada, conta duplicada e “outros”. Utilizando os gateways,
eu fico me perguntando como que eu faço desse processo gerar essas 5 condições.
Obrigado!
Kelly Sganderla
em 22 de janeiro de 2018 às 4:12 pm disse:
Olá Francisco, se entendi bem, sua dúvida se dá pelo fato do gateway ser um
elemento de quatro pontas, e se de cada ponta sair um fluxo para uma condição,
então teríamos um limite de três condições… é esta a sua questão?
Bom, na notação BPMN não existe limitação sobre o número de saídas em cada
ponta. De uma mesma ponta do gateway podem sair tantos conectores quantos
forem os casos. Então não haveria problema se, por exemplo, a ponta da esquerda
fosse usada para o conector de entrada no gateway, e todas as saídas saíssem de
apenas uma ponta. Do ponto de vista de design, é interessante apenas cuidar para
que as linhas não se sobreponham muito e que o desenho fique tão claro quanto
possível.
Outra possibilidade é usar uma combinação de dois gateways: um verificando se a
dívida foi ou não negociada, e se não foi, o segundo gateway verificaria o motivo –
se for aplicável à sua necessidade, claro. Espero ter ajudado!
Rodrigo Macedo
em 14 de junho de 2018 às 9:30 pm disse:
Estou aprendendo muito com vocês. Parabéns pelo ótimo trabalho!
Sheila
em 20 de junho de 2018 às 2:14 pm disse:
Tenho uma duvida, se por acaso o fluxo que eu estiver desenhando tenha bastante
“tarefas”, ou seja, uma longa lista de itens a ser colocados no fluxo, como a leitura do fluxo
deve ser da direita para esquerda, como posso otimizar o espaço dentro da piscina para que
não fique muito “longo” o desenho?
Kelly Sganderla
em 20 de junho de 2018 às 3:56 pm disse:
Olá Sheila, o processo pode ser descrito na direção em que você quiser: da direita
para a esquerda, para cima, para baixo, como for mais conveniente. O mais natural
é que façamos o fluxo seguir uma sequência da esquerda para a direita pois é assim
que lemos as coisas no ocidente =) mas não é uma regra rígida. É o sentido da seta
(para onde ela aponta) que determina o que será feito a seguir, e não o fato dela
estar à esquerda, à direita, acima ou abaixo.
Portanto, não há problema se você verticalizar o desenho do fluxo fazendo algumas
atividades irem para baixo ocupando espaço da página.
Entretanto, se o fluxo está muito longo, talvez seja interessante considerar se
algumas tarefas não poderiam ser reunidas em um subprocesso, de forma a abstrair
o detalhamento de algumas etapas do processo.
Antonio Carlos de Oliveira
em 17 de julho de 2018 às 7:37 pm disse:
boa noite, veja se podem me ajudar. Tenho um fluxo onde preciso distribuir documentos
para os postos I, II, III e IV. O posto I executa duas atividades (abrir e ler por exemplo), o
posto II uma atividade (imprimir), o posto III uma atividade (organizar) e o posto IV uma
atividade (arquivar). Como posso representar da melhor forma?
Considerando que o fluxo de uma atividade “distibuir documentos” segue para quaisquer
uma das atividades (abrir e ler (são duas atividades), imprimir, organizar e guardar).
Sds,
Antonio
Kelly Sganderla
em 18 de julho de 2018 às 10:57 am disse:
Olá Antonio, para melhor orientá-lo é necessário entender um pouco mais a lógica
da distribuição dessas atividades. Assim, seguem duas alternativas – veja qual
melhor se aplica ao seu caso:
1) Se todas as atividades são realizadas, mas não tem uma ordem predefinida (um
posto pode fazer uma atividade de imprimir antes do outro ler, por exemplo), então
você pode usar um gateway paralelo para dividir esse fluxo.
2) Se nem sempre todas as atividades são realizadas (dependendo do documento,
por exemplo, não precisa imprimir) então você deve dividir esse fluxo usando um
gateway inclusivo.
Julio Cesar
em 7 de agosto de 2018 às 1:21 pm disse:
Boa tarde, Kelly.
Vamos supor que eu configure uma aprovação de ponto de funcionário para um gestor e
caso esse gestor não a realize em 3 dias, a tarefa passará um outro gestor e mas ficaria
também com o anterior. Com esses 2 gestores podendo aprovar, qual seria o Gateway?
Imagino que seja inclusivo, pois o paralelo obrigaria os dois aprovarem (e só precisa de 1),
correto? Utilizo o Bonitasoft.
Kelly Sganderla
em 9 de agosto de 2018 às 10:42 pm disse:
Acho que terá que ser um gateway exclusivo, já que apenas um fará a aprovação.
Um inclusivo aguardará o outro fluxo também, se ele tiver sito ativado, mesmo que
nunca venha a ser concluído. Além disso, provavelmente será necessário criar algum
script para fazer o cancelamento automático da outra tarefa.
Como alternativa, sugiro que em vez de criar uma nova tarefa para o segundo
gestor, acione um script para incluir o segundo gestor como co-responsável da
mesma tarefa. Assim, o primeiro que responder à tarefa a encerrará, e você não terá
dois fluxos para controlar.