Subprocesso do evento

Visão geral

Um subprocesso de evento permite que você reaja a eventos no escopo do processo ou subprocesso. Ele não está conectado ao fluxo de sequência principal.

Em vez disso, o mecanismo o dispara quando ocorre um evento inicial configurado enquanto o escopo circundante está ativo.

Use um subprocesso de evento quando você quiser:

• Centralizar a lógica de tratamento de erros relacionados.
• Evitar duplicar eventos de erro de limite em várias tarefas.
• Controlar o comportamento no escopo do processo ou subprocesso.
• Reagir a mensagens externas no runtime.
• Executar a lógica de recuperação, registro ou notificação de forma consistente.

No Maestro, um subprocesso de evento pode começar com:

• um evento inicial de erro
• um evento inicial de mensagem

Erro ao iniciar o evento

Um evento de inicial de erro dispara o subprocesso de evento quando ocorre um erro de BPMN e o código de erro corresponde, ou quando o evento é configurado como abrangente.

Quando um erro de BPMN é gerado, o mecanismo avalia subprocessos de evento correspondentes no mesmo escopo antes de avaliar eventos de erro de limite. Essa ordem de avaliação dá prioridade ao subprocesso de evento.

Comportamento de execução

Um evento inicial de erro é sempre interruptivo.

Quando o erro ocorre, o mecanismo:

• Dispara o subprocesso de evento.
• Cancela o escopo do processo ou subprocesso circundante.
• Interrompe todos os caminhos ativos dentro desse escopo.

Use um evento inicial de erro quando o erro invalida a execução atual.

Exemplos reais:

• Uma autorização de pagamento falha devido a uma detecção de fraude.
• Uma validação de conformidade obrigatória falha durante a integração.
• Uma dependência crítica do sistema está indisponível.

Tratamento de erros sem e com um subprocesso de evento

Sem um subprocesso de evento	Com um subprocesso de evento
Você anexa eventos de erros de limite a tarefas individuais.	Você define um subprocesso de evento no escopo do processo ou subprocesso.
Você frequentemente duplica lógica de erro semelhante em várias tarefas.	Você centraliza a lógica de tratamento de erros relacionada em um único lugar.
Cada tarefa controla seu próprio tratamento de erros.	O escopo controla o tratamento de erros para todas as tarefas dentro dele.
A manutenção se torna mais difícil à medida que o modelo cresce.	A manutenção se torna mais simples porque você atualiza a lógica de erro em um só lugar.

Impacto em modelos existentes

O mecanismo muda de comportamento apenas se você adicionar um subprocesso de evento ao mesmo escopo.

• Os modelos que usam apenas eventos de erros de limite continuam a se comportar como antes.
• Se você adicionar um subprocesso de evento, ele lida com erros genéricos que não são tratados por eventos de erro de limite no mesmo escopo.
• Se nenhum evento de erro de limite corresponder a um erro gerado, o mecanismo avalia o subprocesso de evento.

Não configure um evento de erro de limite e um subprocesso de evento para lidar com a mesma referência de erro dentro do mesmo escopo.

Regras de configuração

Para um determinado escopo (processo ou subprocesso):

• Use apenas um subprocesso de evento por código de erro.
• Use apenas um subprocesso de evento abrangente.

Para uma determinada tarefa:

• Use apenas um evento de erro de limite por código de erro.
• Use apenas um evento de erro de limite abrangente.

Evento de início da mensagem

Um evento inicial de mensagem dispara o subprocesso de evento quando o mecanismo recebe a mensagem configurada enquanto o escopo circundante está ativo.

Comportamento de execução

O mecanismo escuta a mensagem configurada enquanto o escopo circundante está ativo. Quando recebe a mensagem, dispara o subprocesso de evento de acordo com sua configuração de interrupção ou não interrupção.

Os eventos iniciais de mensagem não substituem ou têm prioridade sobre outros eventos de mensagem. Cada evento de mensagem reage de forma independente com base em seu escopo e configuração.

Tratamento de mensagens sem e com um subprocesso de evento

Sem um subprocesso de evento	Com um subprocesso de evento
Você modela o tratamento de mensagens dentro do fluxo de sequência principal.	Você define um subprocesso de evento no escopo do processo ou subprocesso.
Você deve encaminhar o fluxo principal por meio de eventos de captura de mensagem intermediários.	O mecanismo escuta a mensagem enquanto o escopo está ativo.
O processo principal deve alcançar explicitamente o evento de mensagem para reagir a ele.	O subprocesso de evento pode disparar a qualquer momento enquanto o escopo estiver ativo.
A lógica de tratamento de mensagens fica fortemente acoplada à estrutura de fluxo principal.	A lógica de tratamento de mensagens permanece independente do fluxo de sequência principal.
Alterar o comportamento de mensagens pode exigir a reestruturação do fluxo principal.	Você pode atualizar o tratamento de mensagens sem modificar o fluxo principal.
O fluxo principal sempre faz uma pausa no evento de mensagem.	Você pode configurar o evento inicial de mensagem como interruptivo ou não interruptivo.

Impacto em modelos existentes

O mecanismo altera o comportamento apenas se você adicionar um evento inicial de mensagem dentro de um subprocesso de evento.

• Os modelos que não usam um subprocesso de evento continuam a se comportar como antes.
• Depois de adicionar um evento inicial de mensagem, o mecanismo escuta a mensagem configurada enquanto o escopo circundante está ativo.
• Se você configurar o evento inicial de mensagem como interruptivo, o mecanismo cancela o escopo circundante quando recebe a mensagem.
• Se você o configurar como não interruptivo, o mecanismo inicia o subprocesso de evento em paralelo e permite que o fluxo principal continue.

Não configure vários eventos iniciais de mensagem com a mesma referência de mensagem no mesmo escopo.

Interruptivo versus não interruptivo

Você pode configurar um evento inicial de mensagem como interruptivo ou não interruptivo.

Interrompendo

Quando o mecanismo recebe a mensagem, ele:

• Dispara o subprocesso de evento.
• Cancela o escopo do processo ou subprocesso circundante.
• Interrompe todos os caminhos ativos dentro desse escopo.

Usa um evento inicial de mensagem interruptivo quando a mensagem representa um sinal externo que deve parar a execução atual.

Exemplos reais:

• Um cliente cancela um pedido enquanto ele está sendo processado.
• Um regulador envia uma instrução de interrupção de processamento.
• Um sistema pai envia um comando de término.

Não interruptivo

Quando o mecanismo recebe a mensagem, ele:

• Dispara o subprocesso de evento.
• Mantém o escopo circundante ativo.
• Executa o subprocesso de evento em paralelo.
• Permite que o processo principal continue.

Use um evento inicial de mensagem não interruptivo quando a mensagem deve disparar lógica adicional sem interromper o fluxo principal.

Exemplos reais:

• Um cliente atualiza os detalhes de contato enquanto a integração continua.
• Um sistema de parceiro envia metadados adicionais.
• Uma mensagem de notificação dispara o registro de auditoria.