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.

29 ideias sobre “BPMN: Diferenças entre eventos de Link, Message e Signal

  1. Kelly,
    Parabéns pelas postagens, sempre claras e objetivas. Este blog é referência aos praticantes de BPM.

    Salvo engano de minha parte, os eventos com a bordas escuras são os de recebimento e os de bordas claras são de lançamento? Desta forma, faço apenas uma correção nos eventos dos três exemplos.

    Abs
    Analista de Processos
    Pós graduando em BPM pela PUC Minas

  2. Olá Felipe Luan, na verdade a aplicação da notação está correta nos exemplos. O que define que o evento é de envio (throw) ou recebimento (catch) é a cor do ícone, e não a borda do evento.
    Assim, o evento de mensagem com envelope escuro indica que este evento envia a mensagem, enquanto o evento com envelope claro indica que ele recebe a mensagem. Da mesma forma, a cor da seta nos eventos de link, e do triângulo nos eventos de sinal é que indicará qual envia e qual recebe.
    A borda dos eventos indica: se ele é evento de início (borda simples), se ele é intermediário (borda dupla) ou se ele é de fim (borda grossa, ou preenchida).
    Abraço!

  3. Pingback: Um guia BPMN (IV): Eventos Intermediários | Blog da iProcess

  4. Parabéns pela didática !

    Esclareceu parte da dúvida que tenho no uso de Signal/Message/Link. Entretanto, segue dúvidas:

    1. Pegando como exemplo o envio do Signal “Linhas de comunicação restabelecidas”, a notação que define o fim dos outros processos que são chamados é o de Fim ? (no bizagi o sinal na cor vermelha).

    2. Há uma dúvida lendo o fluxo, como saber que ao fim dos processos “Processo de Contingência de Comunicação” e “Processo de Avaliação do SLA do cliente” ele retorna para onde iniciou o sinal ? No caso, voltar para “Processo de Restabelecimento de Comunicação.”

    Obrigado pela atenção.

  5. Olá Adriano, agradecemos pela sua mensagem.

    Em relação às suas dúvidas, tentarei esclarecer:

    1. Sim. Para qualquer processo em execução, o término do mesmo só ocorre quando atingir o seu respectivo evento de fim, independente de como foram iniciados. A única exceção é no caso de processos interrompidos por um Event Subprocess cujo evento de início é interrupting (mas então é como se o fluxo do processo seguisse por aquele subprocesso, até que ele também atinja o seu evento de fim). Para mais informações sobre event subprocess, veja este artigo: http://blog.iprocess.com.br/2013/02/bpmn-modelando-processos-de-negocio-com-elementos-avancados-parte-iv.

    2. Na verdade não há retorno para onde iniciou o sinal. O sinal é enviado, os processos detectam a emissão do sinal e são disparados, e cada um segue seu caminho. Não há mais interação entre os processos, a menos que outros eventos intermediários ou de fim emitam sinais de volta para o processo que os disparou ou mesmo eventos de envio de mensagem (que seria mais apropriado, já que neste caso a mensagem tem um destinatário, que é o processo que disparou esses eventos), o que não é o caso do exemplo. A idéia do uso do evento de signal é justamente essa, em que não há compromisso de “retorno”.

    Espero ter solucionado suas dúvidas.

  6. Fiquei com uma dúvida, como se representa a comunicação entre duas áreas dentro da mesma pool? Existem muitos casos que a continuidade do processo por uma outra área depende do envio de uma informação de outra área e isso considerado dentro da mesma pool. A exemplo de uma área que faz agendamento e depois o processo continua na outra área. Obrigado, texto excelente.

  7. Olá Bruno, você pode conectar as tarefas diretamente uma à outra.
    Por exemplo: digamos que um ator (assistente) de uma lane elabora um relatório que é analisado pelor um participante de uma outra lane na mesma pool (analista). Obviamente, esse relatório elaborado pelo assistente tem que ser enviado ao analista para que ele possa analisá-lo.
    Em BPMN, a própria seta de sequência (sequence flow) que conecta uma tarefa à outra representa que a saída (produto) da tarefa predecessora é a entrada para a tarefa seguinte. Esse envio da saída de uma tarefa para a entrada da outra está implicito através do conector.
    Assim, neste caso, a tarefa “elaborar relatório de custos” pode ser conectada por um conector de sequência diretamente à do participante seguinte, que seria, digamos “analisar relatório”.
    Se para o processo que você está modelando é importante que o participante da primeira tarefa saiba que ele deve enviar o relatório por email ao participante seguinte, então você pode colocar isso nas instruções da tarefa (os passos realizados para executá-la).

  8. Interessante Kelly, entendi como funciona. No caso estava utilizando um evento de mensagem toda vez que ocorria o envio de uma mensagem para outra lane (colocando o evento e dizendo ” Mensagem recebida”) utilizando o conector de fluxo. Acho que trouxe essa mania do EPC, apesar de eu ter visto esse erro em vários fluxos. Vale um tópico nesse sentido o que acha? Novamente agradeço a ajuda.

  9. Vale sim Bruno, essa dúvida é recorrente.
    Também noto isso acontecendo muito nas modelagens realizadas por profissionais que saem do EPC e vão para o BPMN. Acredito que seja o costume de ter um “estado” intermediário entre as atividades, que existe em EPC (já que essa notação é direcionada ao controle da cadeia de eventos, como diz o próprio nome). Como o “de-para” não é algo muito direto entre as notações, essas pequenas adaptações acabam acontecendo.
    No nosso curso de Mapeamento de Processos com BPMN 2.0 – Prático e Avançado (www.iprocesseducation.com.br/ipe04.html), quando temos participantes do mundo EPC, buscamos tratar essas diferenças discutindo essas dúvidas em aula, e sempre gera algumas discussões bastante interessantes.

  10. Parabéns Kelly e equipe Iprocess, pelo apoio o site de vocês é uma referência para nós. Gostaria de tirar uma dúvida, o evento de link pode ser utilizado em diferentes subprocessos do mesmo processo ou para isto deveria utilizar eventos de message ou signal? Obrigada

  11. Oi Sangelly, que bom que nosso blog tem contribuído para apoiá-los nas dúvidas do dia a dia da gestão por processos.
    Sobre a questão que você mandou, o evento de link só pode ser usado no fluxo de um mesmo processo. Quando um subprocesso precisa se “ligar” ao processo pai, ou seja fazer com que o processo pai siga em algum determinado ponto do seu fluxo (não necessariamente seu término) isso para a notação BPMN é uma comunicação entre processos. Para isso, deve ser usado o elemento de esclalação (escallation). Se o subprocesso vai parar (terminar) para voltar ao processo pai, um simples elemento de fim “none” é suficiente para representar isso.

  12. Parabéns pelo blog.
    Quando um processo não cabe em uma página, como devo recorrer?
    Utilizo eventos de Link? Devo criar subprocessos como forma de impedir que o processo não caiba na página?
    Obrigado.

  13. Kelly, satisfação.

    Uma última dúvida:
    Segundo a notação BPMN 2.0, faz-se obrigatório o uso de conectores de mensagem para ligar elementos intermediários do tipo mensagem à outro processo ou a alguma entidade externa? Seria um equívoco representar os elementos por si mesmos indicando mensagens recebidas e/ou enviadas sem, necessariamente, indicar de onde vem essas mensagens?

    Um grande abraço!

  14. Paulo, não precisa ser a última – para nós é uma satisfação contribuir com a comunidade de BPM :)
    Em relação à sua dúvida do uso do elemento de conector de mensagem (message flow) – ele não é obrigatório. Você pode sim modelar processos focando apenas na lógica do fluxo do processo de negócio, sem ressaltar a comunicação dele com outros processos (que é o propósito deste elemento).
    Neste arquivo que faz parte do material oficial da OMG sobre a notação BPMN: BPMN 2.0 by Example (http://www.omg.org/spec/BPMN/20100601/10-06-02.pdf) tem um exemplo bom para confirmar seu entendimento, o “11.2 The Travel Booking Diagram”. Note que existem diversos eventos de início, intermediários e de fim que enviam e recebem mensagem, mas onde não há a representação do fluxo de mensagem.

  15. Nossa, Kelly.

    Muito obrigado. Você e os profissionais IProcess têm contribuído, de forma significativa e admirável para o advento do guia BPMN para os que não possuem acesso. Isso é de se admirar!

    Mais uma vez, obrigado!

  16. Olá Kelly;

    Muito bom o seu material e didaticamnete perfeito…Muito elucidador.

    Uma Pergunta: Qual é a melhor maneira de mapaear um fluxo entre particpantes (pools) diferentes. Através de Flox message? Neste caso posso “linkar” diratamente com o pool ou a melhor maneira seria linkar com ujma taraefa dentro do pool (tarefa do Pool A –> tarfe ado Pool B). ???

  17. Olá Kelly, boa tarde!

    Pode me esclarecer se posso criar vários elementos de sinal “emitindo” e apenas um “recebendo” o sinal?

    Outra dúvida, estou modelando um processo complexo, que envolve vários atores, e muitas vezes ao atingir uma determinada condição preciso “reiniciar o fluxo” (não havendo um fim e sim uma repetição das atividades). Como posso fazer isso seguindo a notação? Como são muitos os retornos, ligar a seta de sequência na primeira atividade do processo está inviável.

    Desde já obrigada.
    Haline.

  18. Olá Haline,
    Sim, você pode ter vários eventos de envio do tipo sinal (throw signal event) que são capturados em um mesmo elemento de captura do sinal (catch signal event). Apenas tenha em mente que cada vez que o sinal for emitido, o sinal de captura será acionado (se for um evento de início para um processo, ou se for um evento intermediário e estiver aguardando o sinal).

    Quanto ao processo que tem diversos pontos de retorno, talvez a melhor abordagem seja utilizar a combinação de eventos de link.

  19. Kelly, boa tarde!

    Minha dúvida é a seguinte estou no mesmo processo só que os atores são pool separadas pois é uma interface entre empresas distintas.
    Eu tenho um looping em que o processo deve ser reiniciado desde o início.
    Qual o melhor evento pra essa representação?

    Att,

    Alexandre

  20. Oi Alexandre, pela sua descrição entendo que, se são pools separadas, não tem muita escapatória a não ser usar os message flows. Sem uma visão do diagrama que você está tentando criar fica difícil sugerir qualquer outra abordagem.

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>