Blog da iProcess - Compartilhando conhecimento em BPM e RPA

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.

64 respostas

  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

    1. 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!

  2. 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.

    1. 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: https://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.

  3. 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.

    1. 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).

  4. 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.

  5. 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.

  6. 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

    1. 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.

  7. 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.

  8. 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!

    1. 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 (https://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.

  9. 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!

  10. 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). ???

    1. Olá Sildenir, o artigo Um guia para iniciar estudos em BPMN (VI): Swimlanes e Artefatos fala sobre comunicação entre pools e tem exemplos dos dois casos, recomendo a leitura para eslcarecer a sua dúvida :)

  11. 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.

    1. 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.

  12. 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

    1. 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.

  13. Olá, sou nova na modelagem de processos e gostaria de saber o que é uma instância em um processo.

    Desde já agradeço!

    1. Olá Suellen, bem vinda ao mundo BPM!
      Uma instância de processo é um caso, ou uma ocorrência de um processo.
      Você tem um modelo definindo as atividades que podem ser executadas do início até o fim, gerando um resultado do processo. E cada vez que você executa um processo baseado neste modelo, está executando uma instância dele.
      Espero ter ajudado a esclarecer sua dúvida!

  14. Estou com dificuldade de entender a diferença entre os eventos intermediários de mensagem (catch e throw), com as tarefas de mensagem… Quando usar um ou outro?

    Sei que essa pergunta não está totalmente ligada a esse post, mas ficaria muito agradecido se vocês pudessem tirar essa dúvida.

    Obrigado !

  15. Olá Kelly,

    Estou com uma dúvida em um desenho, quando eu tenho um gateway exclusivo, por exemplo, e a resposta deve levar para outra atividade do fluxo que já foi desenhada e para não termos os conectores passando por todo o desenho, estou usando o evento intermediario link, porém, não tenho certeza se podemos fazer dessa forma, onde a saída do gateway exclusivo seja para um Link (intermediário). Por favor, pode esclarecer?
    Se for para exemplificar pelo seu primeiro fluxo, seria, na resposta do gateway “Data solicitada não disponível” direcionar para evento intermediario sem a tarefa “Verificar condições de férias”.

  16. Olá Kelly! Parabenizo pelas postagens e exemplos. Como dito por outros colegas, também me recorro como referência às postagens do blog da IProcess.

    Gostaria que me esclarecesse em qual situação devo utilizar os eventos de envio e recebimento de mensagem para comunicar com outro processo e em qual situação devo utilizar um fluxo de mensagem saindo de uma atividade de um processo para o outro, com o consequente retorno do fluxo de mensagem do processo externo para a atividade que o enviou.

    1. Olá Adriano, agradecemos sua visita e contribuições!
      Existem algumas semelhanças e diferenças no uso de eventos de mensagem ou tarefas enviando/recebendo mensagens. Confira neste artigo: https://blog.iprocess.com.br/2014/04/desmistificando-tipos-de-tarefas-em-bpmn-tarefas-de-envio-e-recebimento/ (veja que ao final falamos sobre as diferenças entre estes dois métodos de troca de mensagens).
      Um outro artigo complementar interessante pode ser este: https://blog.iprocess.com.br/2012/05/bpmn-modelando-corretamente-o-fluxo-de-sequencia-de-atividades/

  17. Bom Dia..!! Kelly..!!
    Estamos trabalhando com modelagem na SEFAZ/AL e temos hoje um desenho que achamos a necessidade de inserir um evento de “Link” para ligar partes do Processo.
    Inserimos os nomes como descrito na notação, porem ainda permanece na validação o erro.
    “There Should be a Catch Link event with the name ‘1 Notificar Contribuinte’ in the process.”

    Como podemos corrigir??? Sendo que os nomes estão iguais e colocamos exatamente o Lançar e receber..!!

    1. olá Giovani,
      Vamos revisar aqui as regras para confirmar o entendimento, ok? Os eventos de link são usados em pares e devem ter o mesmo nome.
      Um deles é o que lança o evento (throw), simbolizado com a seta escura. Ele deve estar na ponta de “saída” da ligação.
      O outro é o que captura o evento (catch), simbolizado com a seta branca. No Bizagi, basta clicar com botão direito e desmarcar a opção “lança o evento”. Ele é o que captura o link continuando o fluxo.
      Ambos tem que fazer parte do mesmo processo (mesmo fluxo), logo se você estiver usando swimlanes eles devem estar na mesma piscina (pool). Se estão em piscinas diferentes, são processos diferentes, e daí deve-se usar evento de comunicação, não evento de ligação.

      No primeiro exemplo deste artigo você vai notar isso: o símbolo que lança o link para continuação está com o símbolo escuro, e o que captura para continuar o andamento do processo está com símbolo branco. Ambos têm o mesmo nome e fazem parte do mesmo fluxo (no exemplo não foram usadas swimlanes).

    2. Bom Dia..!! Agradeço imensamente a resposta. Nos ajudou muito. Mas logo em seguida ao envio do questionamento conseguimos entender que os Links só funcionam no mesmo processo. Mas a sua explicação é excelente.

      Parabens..!!

  18. Bom dia!

    Fiz uma alteração na metodologia BPM, onde estou mapeando processos em duas Piscinais diferentes no mesmo diagrama.

    Mapeei as piscinas como se fosse um ciclo de vida, onde suas lanes foram mapeadas como sendo fases do ciclo de vida, e os subprocessos ali presentes foram mapeados de modo que cada subprocesso representasse um Processo no contexto em questão

    Basicamente fiz as seguintes alterações
    Piscina -> Ciclo de vida
    Lane -> Fases do ciclo de vida
    Subprocessos -> Processos que fazem parte do contexto

    Como estou mapeando os processos de duas piscinas diferentes que se comunicam acabei tendo dificuldade de representar a comunicação entre os processos entre as duas piscinas, seria correto utilizar o evento de Link para representar comunicações entre as duas piscinas?

    1. Olá Gabriel,
      Obrigada por sua visita e questionamento.
      Na notação BPMN, cada piscina é um processo, e a comunicação entre processos deve ser por mensagem.
      O link serve para conectar partes de um mesmo processo (por exemplo, uma ponta distante do fluxo que precisa se conectar a um elemento que está numa outra ponta do diagrama). Links devem ser usados com MUITA PARCIMÔNIA porque se seu diagrama começa a precisar deles, é porque provavelmente ele está grande demais.
      Se você estiver usando o Bizagi Modeler, gostaria de sugerir que em vez de dividir o ciclo de vida em lanes, utilize para isso o elemento “Milestone”. Ele não é da notação BPMN, mas foi uma adaptação criada pela Bizagi justamente para este propósito. =)

    1. Oi Alessandra,
      Se o subprocesso faz parte do fluxo do processo principal, então você não precisa do sinal – o proprio processo principal o acionará.
      Entretanto, se ele não está ligado no fluxo principal, mas pode ser acionado por ele devido a um sinal, você pode incluí-lo no diagrama usando um subprocesso eventual (Event SubProcess).

  19. Kelly, bom dia!

    No caso das interfaces entre macrofluxos ou entre processos distintos, como eu poderia fazer a ligação? Nem sempre os processos que compõem um macroprocesso, possuem uma sequência lógica e usar elementos como o de “escalação”, talvez não fosse o mais correto. Poderia não utilizar elementos de BPMN e somente inserir as interfaces como objeto de análise nos relatórios dos processos?

    Muito Obrigada!

    1. Oi Miriam,
      Entendo a sua colocação.
      Em muitos casos um processo contribui indiretamente mas não está ligado diretametne ao processo que estamos modelando.
      Esta pode ser uma opção sim. Talvez uma matriz que ajude a indicar quais processos contribuem a ele pode ser importante também, pois em uma revisão do processo é bom saber quem é impactado direta ou indiretamente.
      De qualquer forma, aqui vai uma sugestão de outro artigo que trata da correlação/contribuição entre processos para a composição de um processo de mais alto nível que pode ser interessante para sua leitura.
      BPMN: demonstrando a continuidade de processos

  20. Meu processo inicia em uma 01 – pool, após sua sequência ele é direcionado para uma segunda 02 – pool, na segunda 02 – pool pode ocorrer a necessidade de voltar para uma atividade da primeira 01 – pool, qual o evento devo utilizar para indicar esse retorno para 01 – pool, pensei em criar um evento de início e de fim. Mas a primeira 01 – pool já possui um evento de início, o que iria criar múltiplos evento de início.

    1. Olá Francisco, você está descrevendo um caso de comunicação entre processos, já que cada pool contém um processo.
      Neste caso, use sempre eventos do tipo envio/recebimento de mensagens.
      Avalie também se realmente é necessário separar o fluxo em pools distintas. Às vezes ficamos presos na ideia das estruturas funcionais da empresa e acabamos dividindo um processo em várias pools, picotando a fluidez da geração de valor. Avalie se não é este o caso, talvez seja mais benéfico contar com um processo integrado em uma única pool.
      Sugiro dar uma conferida neste webinar, que pode ajudar a esclarecer algumas dúvidas sobre essa continuidade de fluxo de atividades: Webinares iProcess 2015 – BPMN: Modelando a comunicação entre processos

  21. Boa dia, Kelly Sganderla.
    Excelente abordagem!
    Gostaria de colocar uma dúvida referente a um “erro” apresentado em uma modelagem em que foi utilizado o Software Visio: o processo não coube em uma só página e foi preciso criar um link de saída e, logo em seguida, link de entrada, para dar continuidade ao fluxo. Mas, ao fazer a verificação do diagrama, o programa retornou o seguintes erros de regra:
    Página 1: Evento de início, sem o correspondente evento de final.
    Página 2: Evento de final, sem o correspondente evento de início.
    Ou seja, mesmo existindo a forma de início na primeira página e forma de fim de processo na segunda página, mesmo assim mostrou “erro” de regra.
    O que poderia ser?

    1. Olá Oswaldo, não tenho utilizado o MS Visio nas versões mais recentes, mas provavelmente a ferramenta não está interpretando que os fluxos nas duas páginas tratam do mesmo processo. Seria interessante verificar se há alguma configuração que permita estabelecer essa ligação entre as piscinas dos diagramas nas duas páginas.
      Ou talvez a ferramenta realmente não permita mais essa abordagem. A especificação determina como os elementos devem ser interpretados em um nível conceitual, mas as regras de implementação e validação podem acabar variando de uma ferramenta para outra.

  22. Bom dia, Kelly Sganderla!
    Parabéns pela forma simples como escreve, isso não é simples!!! rsrsrs
    Por gentileza, pode ajudar-me quanto a dúvida abaixo?
    Em um sistema computadorizado, após o usuário selecionar uma condição A ou B e em seguida pressionar a tecla “protocolar” a tarefa X é disparada para área Z ou Y, conforme condição selecionada.
    Pensei em utilizar um evento intermediário de sinal na saída da tarefa “Protocolar”, mas a entrada em cada área será distinta, embora seja disparado um único sinal. É possível na notação BPMN a saída de único sinal representar entradas diferentes em raias diferentes? Em caso negativo, tem alguma sugestão de desenho?

    1. Boa tarde! Pensei na possibilidade de utilizar um gateway baseado em eventos e ligar a este 02 eventos de sinal, um para cada área. Acredito que assim a solução não fere a regra bpmn.

    2. Olá Kel, acho que no seu caso o melhor seria usar um gateway exclusivo que verifica qual tecla foi acionada e com isso poder enviar sinais diferentes.
      O gateway baseado em eventos não seria adequado aqui pois esse tipo gateway “espera” que um dos eventos aconteça para então dar andamento ao processo e no seu caso é o contrário, você quer lançar eventos diferentes de acordo com uma condição.

  23. Olá, Kelly! Tenho acompanhado o blog e quero agradecer pelos conteúdos.
    Tenho uma dúvida quanto ao evento de sinal. Posso utilizá-lo para indicar uma informação que deve ser passada para outra pessoa no mesmo processo? Exemplo: o caixa da loja, ao confirmar o pagamento no banco, verifica que não houve o depósito e aí manda um sinal para o vendedor, que entrará em contato com o cliente. Faz sentido?

    1. Olá Victória, obrigada por seu comentário!
      No caso em que você citou, o melhor seria realmente ter um gateway após a tarefa do caixa da loja, que leve a uma nova tarefa de contato com o cliente feita pelo vendedor, pois uma depende diretamente do resultado da outra.
      O evento de sinal só faz sentido para acionar um outro processo em função de algo que ocorreu em um determinado fluxo, o que não seria bem o caso da sua descrição. Espero ter esclarecido sua dúvida!

  24. Oi Kelly, boa tarde!

    Quando a transferência de informação acontece entre dois sistemas o evento de mensagem também pode ser usado?

    Ex: o ERP processa um pagamento de fornecedor e o meu sistema de compras precisa receber essa informação para atualizar o painel do requisitante [No estilo acompanhe sua requisição] com a informação que o fornecedor já foi pago.

    1. olá Bruno, se você tem uma integração automática entre os dois sistemas neste ponto do processo, eu recomendaria usar a tarefa de serviço (service task). Considere que não é apenas um dado enviado – possivelmtente há um processamento aí em que os dados são preparados, submetidos, recebidos e armazenados pelo sistema de compras (talvez até alguma transformação de dados aconteça antes do armazenamento). O evento de mensagem só sinaliza que há envio ou há recebimento da parte do processo, sem indicar que há processamento da informação. Processamento é trabalho, trabalho sempre deve ser representado por tarefas :)

  25. Olá boa tarde. Conteúdo excelente. Muito esclarecedor. Seguem algumas dúvidas, se puder ajudar, agradeço:
    1 – Qual evento final que uso ao finalizar um processo que vai em seguida ter uma ação que vai começar outro processo, como por exemplo encerrando um chamado e abrindo outro para iniciar o próximo processo. Pensei em colocar uma tarefa “Encerrar chamado” e o fim de evento com o símbolo de mensagem e descrever abaixo o que será feito, porém não sei se esta correto.

    2 – Quando inicio uma tarefa por exemplo com o recebimento de um e-mail do cliente. Caso queira colocar um evento inicial com o símbolo de mensagem e descrever abaixo Solicitação do cliente. Esta correto?

    1. Olá Vani,
      que bom que os nossos artigos estão sendo úteis para apoiá-la no uso adequado da notação!
      Para o seu primeiro caso, a recomendação seria usar evento de fim com mensagem (mas é importante que o processo seguinte, que é iniciado por ele, tenha também um evento de recebimento de mensagem com o mesmo nome!). Outra forma de fazer isso é criar um modelo de nivel mais alto que seria o processo orquestrador, garantindo a sequência dos processos. Veja as vantagens das duas abordagens (comunicação ou orquestração de processos) nesse artigo: BPMN: Modelando a comunicação entre processos.

      A sua segunda questão está correta, na verdade, qualquer processo que começa com a chegada de uma informação (seja um e-mail, sms, mensagem no whatsapp, telefonema, etc) se o que faz o processo começar é a chegada de uma informação, então o tipo de evento de início a usar é o evento de mensagem.
      Isso porque a notação BPMN presume que um outro processo (que no caso pode ser o processo do cliente, por exemplo) enviou uma mensagem para o seu processo, fazendo com que ele inicie.

      Um abraço e bom trabalho por aí ;)

Deixe um comentário para adriano Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

MAIS VISTOS

Como transformar as ideias de mudança para um processo TO BE em ações efetivas, controladas... (continuar lendo)
Veja agora as ações que foram realizadas através das doações de todos os participantes deste... (continuar lendo)
Participe deste evento exclusive e gratuIto e se prepare para as transformações que IA irá... (continuar lendo)

Inscreva-se na nossa Newsletter

seers cmp badge