Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários

No artigo anterior iniciamos o estudo dos eventos, detalhando os principais tipos de gatilhos para eventos de início e fim de processo.

O evento intermediário (Intermediate event) sinaliza um ponto no decorrer do processo no qual é previsto que um fato irá ocorrer.

Eventos intermediários podem ser tanto do tipo catch (aguardam a ocorrência do fato para que o processo continue) quando do tipo throw (geram a ocorrência do fato e dão continuidade ao processo).

Em geral os eventos intermediários são conectados ao processo através de conectores de fluxo de sequência, dando o contexto de que ocorrem durante o processo. Entretanto, um evento intermediário também pode ser definido para ocorrer durante uma tarefa tarefa específica. Neste caso, o evento intermediário é anexado à borda da atividade, como mostrado em alguns exemplos abaixo.

Os tipos de evento intermediário mais comuns são:

Tempo ou Prazo (Timer)
Utilizado para representar um fato relacionado a uma condição temporal, como uma data específica (ex. 01 de janeiro), uma data relativa (próxima terça-feira), um intervalo de tempo (em sete dias) ou uma situação de espera de tempo.

O evento de timer é simbolizado por um relógio.

Quando utilizado no fluxo do processo, o evento intermediário de timer representa que o processo deverá parar naquele ponto do processo e aguardar que a condição de tempo se torne verdadeira.

Neste exemplo, quando a tarefa “Preparar viagem” for finalizada, o processo realizará uma pausa aguardando a data de início da viagem. Só então o processo continuará, iniciando a tarefa “Realizar viagem”.

Quando utilizado na borda de uma atividade, o evento intermediário de timer representa que que, enquanto a atividade estiver em execução, o evento poderá acontecer, e neste caso, o fluxo desenhado a partir do evento será executado. Neste caso, o evento intermediário poderá ser de dois tipos:

Timer interrupting
Se o evento ocorrer enquanto a atividade estava sendo executada, ela será interrompida, e o fluxo seguirá pelo conector que se origina no evento.
A borda do evento é dupla e lisa.
No exemplo ao lado, se a atividade “Confirmar recebimento de mercadorias” for concluída  antes da data de entrega prevista, o processo seguirá sua execução pelo fluxo normal do processo. Entretanto, se a data de entrega prevista for atingida e o recebimento das mercadorias não tiver sido confirmado, a tarefa é automaticamente cancelada e o fluxo que sai do evento de timer é disparado, dando início à atividade “Cancelar o pedido”. A atividade de “Confirmar recebimento de mercadorias” não poderá mais ser realizada pois foi interrompida.

 

Timer non-interrupting
Se o evento ocorrer enquanto a atividade estava sendo executada, um fluxo paralelo será iniciado a partir do conector que se origina no evento, mas a tarefa permanece aguardando a sua execução.
A borda do evento é dupla e tracejada.
No exemplo ao lado, se o após dois dias úteis a tarefa “Avaliar pedido” ainda não tiver sido finalizada, o fluxo iniciado no evento é disparado, iniciando a tarefa “Receber aviso de atraso na avaliação”. A atividade de avaliar pedido, entretanto, poderá ser realizada normalmente, dando sequência ao fluxo normal do processo. Se a tarefa “Avaliar pedido” for finalizada antes da ocorrência dos dois dias úteis, então a atividade “Receber aviso de atraso na avaliação” não acontecerá.

 

Condicional (Conditional)
Utilizado para representar um fato relacionado a uma condição de negócio, pausando o processo até que ela se torne verdadeira.

No exemplo ao lado, ações são compradas e então o processo aguarda até que a condição “Valor de venda atingido” se torne verdadeira, dando continuidade ao processo e iniciando a tarefa “Vender ações”.

O evento do tipo conditional também pode ser conectado à borda de atividades como demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting. Neste caso, o evento será acionado quando a condição de negócio associada se torne verdadeira.

 

Mensagem (Message)
Eventos intermediários de tipo message são utilizados para demonstrar um ponto do processo onde ocorre uma comunicação com um outro processo ou agente externo.

O evento de “throw message” tem como símbolo um envelope preto e sinaliza o envio da comunicação, enquanto o evento do tipo “catch message” tem como símbolo um envelope branco e sinaliza o recebimento da mesma.

No exemplo acima, o Processo de Logística de Treinamentos prevê uma atividade para “Alugar sala de treinamento”. Após alugar a sala, o processo aguarda uma “Comunicação do número de Participantes”. Quando esta comunicação for recebida, a próxima atividade poderá ser iniciada, providenciando cadeiras e mesas para os participantes do treinamento cujas inscrições foram confirmadas.

Este exemplo apresenta o Processo de Inscrições de Treinamento, no qual há uma tarefa para receber as fichas de inscrição e então uma atividade para “Verificar inscrições pagas”. Quando as inscrições pagas forem verificadas, o processo poderá comunicar o número de participantes que estão inscritos, enviando uma mensagem (que será recebida no processo demonstrado anteriormente, no evento com o mesmo nome). Após, o processo segue, iniciando a tarefa de “Providenciar impressão dos certificados”.

A identificação de que a mensagem enviada por um processo é a mesma recebida em outro processo deve ser explicitada utilizando-se a mesma descrição para o elemento.

É possível ainda demonstrar visualmente esta comunicação, colocando-se os dois processos em um mesmo diagrama BPMN e apresentando como esta mensagem flui de um processo para o outro. Neste caso, utiliza-se um conector especial para demonstrar essa ligação entre processos através da troca de mensagens (envio e recebimento): o conector de fluxo de mensagem (message flow).

O conector de fluxo de mensagem pode ser usado apenas para conectar elementos de envio e recebimento de mensagem, e caracteriza-se por uma linha tracejada com uma seta vazada apontando para o destino da mensagem.

É importante ressaltar que para o BPMN, uma comunicação é realizada sempre para fora do processo, nunca entre eventos de mensagem de um mesmo processo.

O evento do tipo mensagem também pode ser utilizado à borda de atividades como demonstrado anteriormente no tipo timer, podendo ser interrupting ou non-interrupting. Neste caso, o evento será sempre “catch”, aguardando a chegada de uma mensagem, e será acionado se a mensagem for recebida enquanto a atividade estiver sendo executada.

Ligação (Link)
Eventos intermediários de link representam uma ligação entre pontos distantes de um mesmo do processo.

Este elemento é utilizado frequentemente em processos cujo número de atividades é muito grande e há pontos do processo que estão visualmente distantes ou bloqueados. Assim, para evitar a sobreposição de conectores de fluxo de sequência, pode-se utilizar este evento, criando uma “ponte virtual” entre pontas do fluxo do processo.

O evento de “throw” link tem como símbolo uma seta preta e sinaliza a ponta de origem da ligação, enquando o evento do tipo “catch” tem como símbolo uma seta branca e sinaliza o destino da mesma.

O exemplo acima apresenta um exemplo de uso de eventos de ligação (link). Observe que há dois eventos de ligação com o mesmo nome: “Continuar negociação”. O primeiro tem a seta preta, indicando a origem da ligação, e o segundo a seta branca, indicando o destino da ligação. Com isso, a leitura que se faz deste diagrama é de que após a realização da atividade “Verificar condições de férias” o processo dá sequência ao fluxo iniciando a tarefa “Avaliar solicitação de férias”.

Para entender melhor o uso de eventos de mensagem e link, leia também estes artigos:

No próximo artigo, um elemento fundamental para a abstação de conjuntos de tarefas na estruturação de diagramas de processos com níveis de profundidade e granularidade diferentes: os subprocessos.


Confira todos os artigos deste guia de BPMN Nível 1:

23 ideias sobre “Um guia para iniciar estudos em BPMN (IV): Eventos Intermediários

  1. Pingback: BPMN: Modelando processos de negócio com elementos avançados (Parte IV) | Blog da iProcess

  2. Parabéns pela iniciativa. Acabei de fazer um treinamento BPMN na Trainning Education e este blog está complementando com dicas e muita informação interessante principalmente pra quem está dando os primeiros passos. Gostei muito !

  3. Parabéns. Seu site tem sido bastante útil para mim, tendo em vista que tomei conhecimento do BPM há apenas alguns meses atrás e sempre o consulto para tirar algumas dúvidas.

  4. Sei que o a matéria é antiga mas os problemas continuam nos dias atuais, me deparei com uma dúvida na hora de modelar um processo, tenho uma atividade e preciso usar um evento intermediário condicional para ir para outra atividade. A dúvida é a seguinte: Ao usar um evento condicional na borda de uma atividade, essa atividade é executada primeiro e depois se verifica a condição, ou primeiro se verifica a condição e caso não seja satisfeita a atividade onde está o evento é executada?

    Parabéns pelo blog e por tudo que há nele, tem me ajudado muito!

    Obrigado!

  5. Olá Augusto, agradecemos sua visita ao nosso blog! Para nós da iProcess é uma grande satisfação saber que o conhecimento que compartilhamos está contribuindo para o crescimento de outros profissionais envolvidos em iniciativas de processos de negócio.

    A resposta à sua pergunta “ao usar um evento condicional na borda da atividade, essa atividade é executada primeiro e depois se verifica a condição, ou primeiro se verifica a condição e caso não seja satisfeita a atividade onde está o evento e caso não esteja satisfeita a atividade onde está o evento é executada”, é:
    nem um, nem outro.

    O evento de borda é usado para controlar eventos que podem ocorrer enquanto a atividade está sendo executada.

    Veja no artigo que temos exemplo de um evento de timer na borda. No caso do interrupting: se o evento ocorrer enquanto a atividade estava sendo executada, ela (a atividade) será interrompida, e o fluxo seguirá pelo conector que se origina no evento.
    Já no caso do evento de borda ser non-interrupting: se o evento ocorrer enquanto a atividade estava sendo executada, um fluxo paralelo será iniciado a partir do conector que se origina no evento, mas a tarefa permanece aguardando a sua execução.
    Se, durante a execução da atividade, o evento não acontecer (no caso do exemplo, se a tarefa “Confirmar recebimento de mercadorias” for concluída antes que a data de prazo da entrega seja atingido), a atividade é executada e concluída normalmente, seguindo por seu caminho normal modelado no fluxo.

    Esse comportamento vale para qualquer tipo de evento conectado à borda de um atividade seja ele uma mensagem, condição, escalamento, erro… (você pode conferir que tipos de eventos podem ser usados em bordas de atividades em nosso Guia de referência rápida BPMN 2.0, disponível em http://blog.iprocess.com.br/2013/11/novidade-guia-de-referencia-bpmn-2-0-da-iprocess/).

  6. Olá!
    Uma atividade pode conter mais do que um evento intermediário na borda? Como por exemplo, em uma imobiliária, a tarefa de “divulgar imóvel” pode ser interrompida, caso: 1. o cliente solicite; 2. o imóvel seja alugado. Portanto, ao meu ver, tal tarefa deveria receber dois eventos intermediários na borda, que seriam, “Condicional” (no caso de imóvel alugado) e “Mensagem” (no caso da solicitação do cliente).
    Posso representar através dos conectores de borda, na respectiva quantidade?

    Att.

  7. Olá Paulo,
    Sim, uma atividade pode ter tantos eventos de borda quantos forem necessários pelo processo de negócio.
    Seu exemplo está bem especificado e esta modelagem seria correta.

  8. Parabéns pelo blog! É muito instrutivo.

    Caso tenhamos um processo para gestão de incidentes que possui várias atividades a serem executadas e um tratamento de exceção por tempo limite para atendimento. Repare que este tempo limite não é de uma atividade específica, mas do processo como um todo, isto é, após a chegada de um incidente, se ele não for atendido em 1h (por exemplo), o processo deve ser interrompido e certa atividade deve ser executada. Como representar isto em BPMN já que não seria correto por um evento intermediário de borda em cada atividade do processo?

  9. Olá Alexandre,
    Você pode modelar isso de duas formas:
    Uma delas é colocando o conjunto de tarefas que precisam ter seu tempo monitorado dentro de um subprocesso e colocar o evento de controle de tempo na borda do subprocesso. Assim, se o timeout ocorrer durante a execução das tarefas que estão dentro do subprocesso, todas são interrompidas e o fluxo seguirá pelo conector de sequência que sai da borda do subbprocesso.
    A outra forma de modelar isso seria, no caso de *todo* o subprocesso estar condicionado a este prazo, usar um event subprocess com evento de início disparado pelo prazo determinado. Assim, se o timeout ocorrer, o processo é interrompido onde quer que esteja, e o fluxo modelado dentro do event subprocess passa a ser executado.

  10. Kelly, fui testar o event subprocess (subprocesso eventual) no Bizage, e percebi que o subprocesso criado impede a criação de raias como ocorre com um subprocesso incorporado. Isso está correto?
    Se for assim, todas as atividades contidas num subprocesso eventual só poderão ser executadas por um mesmo responsável e desta forma tal subprocesso deverá ser criado dentro da raia correta no processo “pai” para poder explicitar quem é esse responsável.

  11. Boa tarde, primeiramente parabéns pelo blog pois é muito show, pra min que estou iniciando essa semana estudos com bpmn esse blog é super completo. Como sou iniciante fiquei com uma duvida.Qual a diferencia de eu usar um gateways exclusivo e um evento intermediário do tipo conditional. Não sei se teria alguma relação entre os dois!

    Muito obrigado!

  12. Olá Thiago, em nome da equipe de autores do Blog da iProcess agradeço sua mensagem Ficamos muito motivados em compartilhar nosso expertise e conhecimento com novos profissionais na área.
    Existe uma diferença de natureza dos dois componentes da sua dúvida.
    Os gateways tem função de roteamento. Eles são como placas na estrada que apontam o caminho para onde o fluxo deve seguir de acordo com uma decisão (informação) que já existe. Por exemplo: um gateway exclusivo pode rotear um processo com base no tipo de uma solicitação. Se for uma solicitação simples, levar para a atividade “A”; se for uma solicitação média vai para a atividade “B” e se for uma solicitação complexa vai para a atividade “C”. O valor que caracteriza o tipo de solicitação é uma informação que já existe e foi obtida em algum momento anterior do processo – seja como entrada para o processo iniciar ou em alguma tarefa anterior ao gateway em que alguem definiu que, para aquele processo em andamento, o tipo de solicitação é uma dessas opções.
    Já os eventos intermediários, independente do gatilho, são uma representação de que o processo precisa aguardar que um evento externo ao processo ocorra. Se for um gatilho de tempo (evento de timer) em que precisamos esperar uma semana, por exemplo, o processo chega no evento, espera passar o prazo e quando ele ocorrer (quando a data do prazo se tornar verdadeira) ele libera o processo e vai para a próxima atividade. Não existe variação de roteamento, como no caso do gateway. O mesmo vale para o evento condicional, que é usado para representar uma condição lógica (booleana) em que em um determinado momento é falso mas quando se tornar verdadeiro o processo seguirá. Como a maior parte das situações de condição estão atreladas a tempo ou comunicação (mensagem ou sinal) é difícil encontrar um exemplo de uso deste elemento que não seja muito particular de um processo, por isso vou usar um exemplo lúdico. Pense no preparo de uma pizza congelada. Você recebe como entrada para o processo a pizza congelada, faz uma atividade de ligar o forno, mas só pode fazer a próxima atividade de colocar a pizza no forno quando o forno tiver atingido a temperatura adequada (180º). Assim, antes desta tarefa, coloca o evento condicional de que o forno tem que estar na temperatura adequada. Quando o processo for exeutado, você terá feito a primeira tarefa, e chegando ao evento o forno ainda não estará na temperatura (ou seja, a condição ainda não é verdadeira). O processo terá que esperar até que a temperatura seja atingida e a condição do evento se torne verdadeira, fazendo com que o processo siga para as próximas atividades. Espero que os exemplos tenham ajudado!

  13. Olá,

    Parabens pela série de artigos sobre BPMN. Acho que você ja deve ter percebido que produziu um material atemporal e que quase quatro anos após a publicação ainda continua ajudando muita gente.

    Obrigado!

  14. Bom, tem cerca de um ano que utilizo o blog do Iprocess como forme de complemento a documentação e seus exemplos e explicações são sensacionais.
    Parabéns.

    Gostaria de retirar uma dúvida, qual a diferença entre uma tarefa de envio e um evento de envio (mensagens)? Sempre confundo.

  15. Olá Henrique!
    Em nome do time da iProcess gostaria de agradecer seu comentário, ele nos deixa bastante empolgados em seguir compartilhando nossa experiência através do blog para apoiar os profissionais de BPM brasileiros.
    Sobre sua dúvida, sugiro que leia este artigo, onde falamos justamente sobre as tarefas de envio e recebimento e suas diferenças em relação aos eventos de mensagem: http://blog.iprocess.com.br/2014/04/desmistificando-tipos-de-tarefas-em-bpmn-tarefas-de-envio-e-recebimento/

  16. O blog é show! Parabéns!

    Gostaria de saber se posso utilizar link saindo uma setinha dele?
    Tenho uma atividade, coloco o simbolo do link, e coloco uma outra atividade em seguida, saindo a seta dele?

    Obrigada!

  17. Olá Mariana!
    O evento de link throw (lançamento do link, o evento com icone preto) não pode ter fluxo sequência saindo dele, pois este fluxo de sequência está justamente implícito pelo link. No seu processo (na mesma pool) você deverá ter um outro link do tipo catch (captura do link, o evento com icone branco) que será o ponto de onde seu fluxo de processo continua. A partir deste, sim, você deverá ter um fluxo de sequência que dá andamento ao processo.

  18. Olá, boa tarde!

    Estou em dúvida sobre qual a forma correta de indicar o início de um processo, que pode ser iniciado por três entradas distintas, cada uma em uma área (lane) diferente.
    Há um início principal (o mais comum) que indiquei como início do processo (star event), e as duas outras entradas indiquei como evento intermediário/multiplo (intermediate event/event multiplo). Está correto?

  19. Antes de tudo, parabéns pelo material. Conceitualmente, para o BPMN podemos ter 2 tasks com o mesmo nome em uma raia ? Ex: “Enviar mensagem”
    Não seria mais apropriado sempre uma distinção entre as tarefas de forma que sejam absolutamente únicas em escopo e aplicação ? Como por exemplo: “Comunicar gerentes” e “Comunicar equipe” ao invés de “Enviar Mensagem” para ambos os casos ?
    Levanto esta questão pois, apesar de me policiar quanto a isto, não cheguei a encontrar um artigo que descreva isto como sendo uma boa prática.

  20. Olá Ricardo, obrigada por seu feedback e contribuição.
    Há uma situação sim em que duas tarefas podem constar no processo com o mesmo nome: é quando elas representam, em pontos diferentes do fluxo, a realização de um mesmo trabalho (tem o mesmo tipo de entrada, fazem o mesmo tipo de processamento e geram o mesmo tipo de saida). Por exemplo, considere em um processo automatizado uma sequência de tarefas em que, sempre que alguém adiciona um documento em alguma tarefa humana, a tarefa seguinte aciona um serviço para arquivar digitalmente o documento. É a mesma tarefa (arquivar o documento), que tem o mesmo tipo de entrada, realiza o mesmo procedimento e gera o mesmo resultado (o documento arquivado) em momentos distintos do processo. Como é a mesma tarefa, pode ter o mesmo nome. Há, inclusive uma categoria de atividade chamada “call activity” para representar o reuso da tarefa. Basicamente a primeira ocorrência dela seria uma global task, em que é feita a definição da tarefa. E então, a cada reuso ela seria apenas referenciada (não precisaria detalhar novamente pois seria apenas uma “cópia”), através da call activity.
    Entretanto, se a entrada, o seu processamento e o resultado forem diferentes, usar o mesmo nome para a tarefa pode gerar confusão. Neste caso, embora não haja nenhuma regra que impeça uma modelagem desta forma, uma prática adequada seria usar nomes mais específicos que realize a distinção deste trabalho, como você bem exemplificou em sua questão :)

  21. Ola Joseane! Existe mais de uma forma de representar isso, embora geralmente envolvem utilização de elementos complexos que muitas vezes mais dificultam do que facilitam a interpretação do processo.
    Mas para ajudá-la nesta questão, acho importante comentar que o evento não tem uma “lane” proprietária. Você pode colocá-lo em qualquer lane do processo, pois ele não diz em que area o processo começa, apenas que começou. As lanes representam quem faz o trabalho (atividades). Assim geralmente o evento de início é colocado junto da primeira tarefa.
    No seu caso, se a primeira tarefa pode ser diferente de acordo com a área no qual o processo “inicia” então sugiro colocar um evento de início na lane onde é mais comum, seguido de um gateway que verifique qual a origem do processo e então de acordo com o resultado, apontar para a tarefa na respectiva lane.
    Mas se a tarefa de início é única, então pode ser interessante utilizar um evento de início simples na mesma lane, e adicionar à descrição do evento as possíveis origens para a informação que faz com que o processo comece.

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>