- Introdução
- Introdução
- Modelagem de processos
- Noções Básicas sobre Modelagem de Processos
- Abertura da tela de modelagem
- Modelagem de seu processo
- Alinhamento e conexão de elementos BPMN
- Autopilot™ para Maestro (pré-visualização)
- Implementação de processos
- Depuração
- Simulação
- Publicação e atualização de processos agênticos
- Cenários de implementação comuns
- Extração e validação de documentos
- Operações do processo
- Monitoramento de processo
- Informações de referência

Guia do usuário do Maestro
Subprocesso do evento
Visão geral
Um subprocesso de evento permite que você reaja a eventos no escopo do processo ou subprocesso. Ela não está conectada ao fluxo de sequência principal.
Em vez disso, o mecanismo o aciona quando um evento de início configurado ocorre enquanto o escopo delimitador está ativo.
Use um subprocesso de evento quando você quiser:
- Centralize a lógica de tratamento de erros relacionada.
- Evite duplicar eventos de erro de limite em várias tarefas.
- Controlar comportamento no escopo do processo ou subprocesso.
- Rear a mensagens externas no runtime.
- Execute a lógica de recuperação, registro em log ou notificação de forma consistente.
No Maestro, um subprocesso de evento pode começar com:
- um erro ao iniciar o evento
- um evento de início de mensagem
Erro ao iniciar o evento
Um evento de início 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 catch-all.
Quando um erro de BPMN é gerado, o mecanismo avalia os subprocessos de evento correspondentes no mesmo escopo antes de avaliar os eventos de erro de limite. Essa ordem de avaliação dá ao evento prioridade do subprocesso.
Comportamento de execução
Um evento de início de erro está sempre interrompendo.
Quando o erro ocorre, o mecanismo:
- Dispara o subprocesso do evento.
- Cancela o processo ou escopo do subprocesso de encerramento.
- Interrompe todos os caminhos ativos dentro desse escopo.
Use um evento de início de erro quando o erro invalida a execução atual.
Exemplos reais:
- Uma autorização de pagamento falha devido à detecção de fraude.
- Uma validação de conformidade obrigatória falha durante a integração.
- Uma dependência crítica do sistema não está disponí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 erro de limite a tarefas individuais. | Você define um subprocesso de evento no escopo do processo ou subprocesso. |
| Você geralmente duplica uma 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 torna-se 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 sobre modelos existentes
O mecanismo altera o comportamento apenas se você adicionar um subprocesso de evento ao mesmo escopo.
- Os modelos que usam apenas eventos de erro de limite continuam a se comportar como antes.
- Se você adicionar um subprocesso de evento, ele lidará 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 avaliará o subprocesso do 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 geral.
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 geral.
Evento de início da mensagem
Um evento de início de mensagem dispara o subprocesso de evento quando o mecanismo recebe a mensagem configurada enquanto o escopo de encerramento está ativo.
Comportamento de execução
O mecanismo escuta a mensagem configurada enquanto o escopo de encerramento está ativo. Quando recebe a mensagem, ele dispara o subprocesso de evento de acordo com sua configuração com ou sem interrupção.
Os eventos de início 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 manuseio de mensagens dentro do fluxo de sequência principal. | Você define um subprocesso de evento no escopo do processo ou subprocesso. |
| Você deve rotear 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 ser disparado a qualquer momento enquanto o escopo estiver ativo. |
| A lógica de processamento de mensagens fica fortemente afiliada à estrutura do fluxo principal. | A lógica de processamento de mensagens permanece independente do fluxo de sequência principal. |
| A alteração do comportamento da mensagem pode exigir a reestruturação do fluxo principal. | Você pode atualizar o processamento de mensagens sem modificar o fluxo principal. |
| O fluxo principal sempre pausa no evento de mensagem. | Você pode configurar o evento de início de mensagem como com interrupção ou sem interrupção. |
Impacto sobre modelos existentes
O mecanismo altera o comportamento apenas se você adicionar um evento de início 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 de início de mensagem, o mecanismo escuta a mensagem configurada enquanto o escopo de encerramento está ativo.
- Se você configurar o evento de início de mensagem como interrupção, o mecanismo cancelará o escopo de encerramento quando receber a mensagem.
- Se você configurá-lo como sem interrupção, o mecanismo iniciará o subprocesso de evento em paralelo e permitirá que o fluxo principal continue.
Não configure vários eventos de início de mensagem com a mesma referência de mensagem no mesmo escopo.
Com interrupção versus sem interrupção
Você pode configurar um evento de início de mensagem como com interrupção ou sem interrupção.
Interrompendo
Quando o mecanismo recebe a mensagem, ele:
- Dispara o subprocesso do evento.
- Cancela o processo ou escopo do subprocesso de encerramento.
- Interrompe todos os caminhos ativos dentro desse escopo.
Use um evento de início de mensagem de interrupção quando a mensagem representar um sinal externo que deve interromper a execução atual.
Exemplos reais:
- Um cliente cancela um pedido enquanto ele está sendo processado.
- Um regulatório envia uma instrução de interrupção do processamento.
- Um sistema pai envia um comando de rescisão.
Sem interrupção
Quando o mecanismo recebe a mensagem, ele:
- Dispara o subprocesso do evento.
- Mantém o escopo de encerramento ativo.
- Executa o subprocesso de evento em paralelo.
- Permite que o processo principal continue.
Use um evento de início de mensagem sem interrupção quando a mensagem deve disparar uma lógica adicional sem interromper o fluxo principal.
Exemplos reais:
- Um cliente atualiza os detalhes de contato enquanto a integração continua.
- Um sistema parceiro envia metadados adicionais.
- Uma mensagem de notificação aciona o registro de auditoria.
- Visão geral
- Erro ao iniciar o evento
- Comportamento de execução
- Tratamento de erros sem e com um subprocesso de evento
- Impacto sobre modelos existentes
- Regras de configuração
- Evento de início da mensagem
- Comportamento de execução
- Tratamento de mensagens sem e com um subprocesso de evento
- Impacto sobre modelos existentes
- Com interrupção versus sem interrupção