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.

Timeout de atividades humanas no Oracle BPM

A necessidade de estipular prazos para que as tarefas humanas sejam realizadas é uma  característica constante nos processos automatizados.

Leia nesse artigo técnico um passo-a-passo de como implementar o uso de timeout no produto Oracle BPM 11g.

1. Timeout com expiração da tarefa

Se o objetivo é expirar a tarefa, retirando-a da lista de trabalho do usuário, o timeout pode ser setado diretamente nas configurações da tarefa humana, conforme segue:

A configuração deste tipo de timeout é semelhante no caso de tarefas humanas no Oracle BPEL 11g.

 

1.1. Definindo o timeout

Edite o arquivo .task de definição da tarefa. Conforme exibido na Figura 1 abaixo, na definição da tarefa, na aba “Deadlines” configure para expirar conforme um número fixo de dias, horas ou minutos a partir do início da tarefa; ou relativo a algum parâmetro definido no processo.

Note que a duração de tempo relativo em XML é expressa no formato P0Y0M0DT0H0M0S (http://www.w3schools.com/Schema/schema_dtypes_date.asp). Por exemplo, P2D equivale a 2 dias, e PT60S equivale a 60 segundos.

Se for preciso fazer cálculos com datas para calcular o timeout, existem no produto funções XPath para fazer adição ou subtração de durações de tempo com datas.

configuração do timeout na tarefa humana

Figura 1: configuração do timeout na tarefa humana

1.2. Avaliando no processo como a tarefa foi encerrada

Quando a tarefa é encerrada por timeout, seu status é alterado para expirada e o processo segue adiante. Então, se for preciso tomar alguma ação ou rota específica quando ocorrer o timeout, é preciso verificar nos dados de retorno como a tarefa foi encerrada.

Primeiro, é preciso salvar os dados de execução da tarefa em um dataobject, como exibido na Figura 2 abaixo:

mapeando o retorno dos dados da tarefa

Figura 2: mapeando o retorno dos dados da tarefa

Depois, numa tarefa de script extraia o valor do estado da tarefa com a expressão XPath:
string(bpmn:getDataObject(‘taskExec’)/ns:systemAttributes/ns:state)

Se o valor do estado for igual a EXPIRED, a tarefa foi encerrada por timeout ;-)

2. Timeout sem expiração da tarefa

É comum também que seja preciso implementar controle de timeout em uma tarefa, sem no entanto encerrá-la. Por exemplo, para enviar um email de aviso de atraso.

Nesse caso, não configure o timeout na aba ”Deadlines” da definição da tarefa. Ao invés disso, adicione um evento de timer de borda na tarefa humana, como mostra a Figura 3 a seguir:

timer de borda

Figura 3: timer de borda

Se o prazo de expiração for único, o timer pode por exemplo ser implementado como a adição de uma determinada duração a data atual no momento de criação da atividade:

xp20:add-dayTimeDuration-to-dateTime(string(xp20:current-dateTime()),concat(‘PT’,string(bpmn:getDataObject(‘timeout’)),’S'))

Se o timeout deve ser com base em uma data fixa, configure o timer como sendo do tipo Time Date, como mostra a figura abaixo.

timer de data fixa

Figura 4: timer de data fixa

Deixe desmarcada a opção “Interrupting Event” se a tarefa NÃO deve ser encerrada ao estourar o timeout. Se marcar essa opção a tarefa será interrompida quando ocorrer o timeout!

Se o timeout deve ser executado diversas vezes, ciclicamente, então é só marcar o timer como “Cycle” e lembrar que ele não deve ser do tipo “interrupting”:

timeout cíclico

Figura 5: timeout cíclico

Lembre-se que sendo do tipo cíclico, o valor da expressão que tem de ser setado é novamente uma duração. Por exemplo:
concat(‘PT’,string(bpmn:getDataObject(‘timeout’)),’S')

 

* Observação: as cópias de tela apresentadas são baseadas no produto Oracle BPM 11g – versão 11.1.1.4, porém as configurações citadas são igualmente válidas nas versões posteriores do produto, apenas variando um pouco o estilo das caixas de diálogo.