BPMN: Diferenças entre eventos de Link, Message e Signal

Um dos componentes mais poderosos, e mais difíceis de aprender em BPMN, são os eventos e seus gatilhos (triggers). A especificação BPMN descreve diversos tipos de gatilhos para os eventos, mas não esclarece como ou quando devem ser utilizados.

De forma especial, uma dúvida comum são as diferenças entre estes três gatilhos de eventos de BPMN: link, message e signal.

Link é um elemento de ligação que ajuda a abstrair conexões de sequência em um mesmo processo. Alguns profissionais sugerem que o link seja usado para dar seguimento do desenho do processo em outra página, como em uma documentação, por exemplo. Este é um uso possível, mas dado que a maioria das ferramentas de modelagem atualmente não faz paginação (o diagrama é desenhado em uma única área de trabalho) esta não é a única situação de utilização.

Uma das principais utilidades do evento de link, ao meu ver, é a de abstrair a sequência entre atividades que estão distantes no mapeamento, evitando conectores de fluxo de sequência longos que cruzem inúmeros outros.

No exemplo, os eventos de link com o mesmo nome conectam "virtualmente" pontos distantes do processo, fazendo com que após a atividade 'Verificar condições de férias' o processo siga em sua execução, iniciando a atividade 'Avaliar solicitação de férias'. Com isso, a sobreposição de sequence flows foi evitada, deixando o processo mais legível.

O link só é usado como evento intermediário, e por significar uma sequência implícita não pode ser usado para ligar processos diferentes. Isto significa que, no caso de processos desenhados utilizando pools, não podemos usar eventos de link para fazer com que um processo em uma pool dê continuidade à execução de um outro processo, em outra pool.

Assim, a principal diferença entre o evento de link e para os de message e signal reside no fato de que o primeiro é usado para conectar a sequência de um mesmo processo, enquanto os dois outros tratam da comunicação entre processos.

Entre estes dois eventos – message e signal -, a diferença é um pouco mais discreta. Ambos podem ser utilizados para a comunicação entre processos distintos.

O evento de message é usado para a transmissão/recebimento de informações entre processos. Esta troca de informações, de acordo com a especificação BPMN, pode ocorrer por qualquer meio: verbal, escrita, via email, ou até mesmo sistemática. O foco está no aspecto de que há um emitente (demonstrado através do evento throw message) e um destinatário (demonstrado através do evento catch message). O emitente conhece o destinatário, assim como o destinatário sabe de quem receberá a mensagem (mesmo que os dois processos que se comunicam não estejam desenhados no mesmo diagrama).

Neste exemplo, há uma transmissão de informação de um processo para o outro, representado através da Comunicação do número de participantes do Processo de Inscrições para o Processo de Logística de Treinamentos.

Para mais dicas sobre como modelar corretamente diagramas com comunicação entre processos, veja a postagem BPMN: Modelando corretamente o fluxo de sequência de atividades.

Signal também pode ser utilizado para a comunicação intra e entre processos. A diferença é que enquanto a mensagem tem um destinatário específico, o sinal pode ter um emitente e inúmeros destinatários – e eles não necessariamente se conhecem. O funcionamento do signal é como um broadcast: o throw signal emitirá o sinal (como um apito) e todos os processos que estão aguardando aquele sinal (catch signal) o captarão, dando sequência aos seus fluxos.

Além disso, não há transmissão de informações no envio de sinal. Ele é realmente apenas como um apito, alertando que o evento ocorreu, e que quem estivesse aguardando por ele, agora pode prosseguir com seu processo.

Os diagramas acima demonstram um conjunto de processos sincronizados através de Signals para apoiar o Processo de Monitoramento das Linhas de Comunicação de uma operadora de crédito, que disponibliza as "maquininhas" de cartão nas lojas. O Processo de "Monitoramento da Comunicação" possui uma atividade recorrente que monitora, constantemente, se as linhas telefônicas utilizadas estão todas disponíveis. Se for identificada falha em uma linha de comunicação, o processo dispara um evento de sinal "Erros em linhas de comunicação". Esse sinal é o gatilho de disparo para dois processos: "Processo de Restabelecimento da Comunicação" e "Processo de Contingência da Comunicação". O Processo de restabelecimento inicia um conjunto de atividades para buscar o restabelecimento do serviço. Enquanto isso, o Processo de contingência aguarda algum tempo para verificar novamente se as linhas foram restabelecidas antes de iniciar as ações de contingência (possivelmente porque a contingência tem um custo mais elevado, de forma que a esperar algum tempo para o restabelecimento das linhas pode ainda ser mais viável para a empresa). Depois que as linhas forem restabelecidas pelo "Processo de Restabelecimento da Comunicação", este processo emite o sinal "Linhas de comunicação restabelecidas" e dá seguimento para o cálculo da multa com a operadora de telefonia. O sinal emitido faz com que o Processo de Contingência dê seguimento ao seu fluxo para desligar a contingência (já que a operação voltou ao normal), e também dispara o processo de "Avaliação de SLA do Cliente", no qual são analisados os clientes impactados pela falha no serviço e realiza-se a negociação de possíveis multas pela quebra do nível de serviço.

Signal também pode ser utilizado para a sincronização de um processo com múltiplas instâncias de um outro processo. É o caso do excelente exemplo apresentado no artigo A case for BPMN Signal, por Anatoly Belychook no blog Process is the Main Thing.

Resumindo:

  • Link events são usados para abstrair sequência de atividades em um mesmo diagrama de processo, e por isso só podem conectar uma ponta de um processo a outra de um mesmo processo.
  • Message events são usados para abstrair a comunicação entre processos, e portanto não devem ser utilizados para demonstrar sequência de atividades. Os eventos de message possuem emitente e destinatário conhecidos.
  • Signal events são usados para realizar broadcast de sinal, onde o emitente envia o sinal sem conhecer seus destinatários.

BPMN: Modelando corretamente o fluxo de sequência de atividades

Em seis anos de estudo da notação, quatro destes realizando treinamentos na área, uma situação recorrente que percebo na compreensão da notação BPMN está em uma confusão relacionada ao fluxo de sequência de atividades de um processo e o fluxo de mensagens da comunicação do processo com agentes externos.

O fluxo de atividades é desenhado pela sequência das atividades de um processo de negócio. Ele é representado através do conector sequence flow. Este objeto de conexão liga dois elementos de fluxo de processo (eventos, gateways ou atividades). O objeto na origem do conector é a atividade predecessora, e o objeto de destino do conector (para onde a seta aponta) é a atividade sucessora.
Este conector implica no entendimento que a atividade sucessora ocorrerá após a atividade predecessora ser concluída.

BPMN - fluxo de sequencia de atividades (foco) - material de treinamento da iProcess - direitos reservados

Existe uma sequência entre as atividades "Solicitar Cotação de Passagem ou Hotel" e "Avaliar Cotações Recebidas", pois estas atividades estão conectadas por um sequence flow.

O fluxo de mensagens representa a comunicação entre dois processos, ou duas entidades representadas por pools diferentes (já que cada entidade tem o seu processo).  Ele não representa a sequência de ações realizadas pelo processo, mas simplesmente quem envia e quem recebe uma informação relevante naquele ponto do processo. O Fluxo de mensagens é representado através do conector message flow. Este objeto de conexão liga dois elementos do tipo eventos de mensagem ou atividades. O objeto na origem do conector é o remetente e o objeto de destino do conector (para onde a seta aponta) é o destinatário, ou receptor.
Este conector implica no entendimento de que esta comunicação acontece durante a execução da atividade de origem da comunicação.

BPMN - fluxo de mensagens (foco) - material de treinamento da iProcess - direitos reservados

Existe uma comunicação com o agente externo "Agência de Viagens" na atividade "Solicitar Cotação de Passagem ou Hotel" do Processo de Viagem, porque há uma conexão de message flow entre elas.

Você consegue perceber a distinção do que cada um destes fluxos representa?

O que muitas vezes percebo nos modelos que enviam para minha avaliação, é uma confusão na utilização do fluxo de mensagens para representar também a sequência de atividades, o que é incorreto na interpretação de um diagrama BPMN. O diagrama abaixo apresenta um exemplo deste equívoco comum:

BPMN - erro fluxo de sequencia - material de treinamento da iProcess - direitos reservados

O autor do diagrama tentou representar a sequência das atividades do processo através do fluxo de mensagens, o que é inválido para a notação BPMN.

Observe na imagem acima que não está sendo representado o fluxo de sequência de atividades entre as tarefas “Solicitar Cotação de Passagem ou Hotel” e “Avaliar Cotações Recebidas”. O autor tentou representar de forma implícita que a sequência das atividades seguirá ordem representada através do fluxo de mensagens nestas duas atividades. Este entendimento implícito não é válido para a modelagem de um processo aderente à especificação BPMN.

Por quê? Porquê nem sempre o fluxo de atividades de um processo segue o fluxo de mensagens. Além disso, a representação da troca de mensagens de um processo não precisa ser explícita (não é obrigatória) em um diagrama de processo, enquanto o fluxo das atividades é obrigatório sempre que houver dependência entre elas. Portanto, a modelagem correta para o caso apresentado acima é esta:

BPMN - solucao fluxo de sequencia - material de treinamento da iProcess - direitos reservados

Agora sim! A sequência das atividades no processo está sendo representada de forma íntegra. Se o fluxo das mensagens fosse removido (não fosse exibido), ainda assim o diagrama do processo estaria correto.

Os trechos de definições abaixo reforçam o entendimento semântico envolvido na utilização destes dois tipos de conectores (extraídas da Especificação BPMN 2.0, tradução livre desta autora):

  • Sequence Flow: Sequence Flow é usado para demonstrar a ordem em que as Atividades serão executadas em um Processo.” (p. 29)
  • “Se uma Atividade não possui Sequence Flows de entrada, a Atividade será instanciada quando o Processo ou Subprocesso que a contiver for instanciado.” (p.427)
  • “Se uma Atividade não possui Sequence Flows de saída, a Atividade será terminada sem produzir nenhum token e a semântica de término para o contenedor [Processo/Subprocesso] é aplicado” (p.427)
  • Message Flow: Message Flow é usado para mostrar o fluxo de Mensagens entre dois Participantes que estão preparados para recebê-las e enviá-las [representados através de Pools].” (p. 29)

A especificação BPMN 2.0 vai mais além quando realiza uma distinção destes fluxos em diagramas distintos: o de Processo, ou Orquestração (que representa a sequência das atividades do processo de negócio) e os de Colaboração e Conversação (que representam exclusivamente a comunicação entre processos de negócio e outros participantes externos).

Apenas para reforçar a diferença semântica existente entre estes dois elementos de BPMN, veja um outro exemplo em que o fluxo de atividades não poderia ser representado pelo fluxo de mensagens:

BPMN - exemplo de processo de tele-entrega de pizzaria

Exemplo de processo de tele-entrega de pizza (traduzido livremente do modelo "5.2 The Pizza Collaboration" em «1» BPMN 2.0 by Example).

Observe no exemplo acima como não seria possível garantir a compreensão do fluxo de atividades do processo se elas fossem representadas apenas pelos fluxos de mensagem. Além disso, note como os fluxos de cada um dos processos (do cliente e da pizzaria) são independentes um do outro: cada um tem seu evento de início, sua própria sequência de atividades e seu evento de término. É possível ler o flluxo do processo do cliente sem conhecer o processo da pizzaria, assim como é possível ler o fluxo do processo da pizzaria sem conhecer o processo do cliente. Essa independência é fundamental para uma diagramação de processos correta, e este tipo de leitura é um excelente exercício na hora de elaborar seus próprios modelos de processos.

Portanto, ao desenvolver seu modelo, lembre-se de garantir que o fluxo de atividades esteja íntegro. Onde houver dependência de execução entre as atividades do processo, a mesma deve ser representada usando o conector de sequence flow.

 «1» BPMN 2.0 by Example

 


Gostou deste artigo? Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!

Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04