Sous-processus d’événement

Vue d'ensemble (Overview)

Un sous-processus d'événement vous permet de réagir aux événements au niveau de l'étendue du processus ou du sous-processus. Il n'est pas connecté au flux de séquence principal.

Au lieu de cela, le moteur le déclenche lorsqu'un événement de démarrage configuré se produit pendant que l'étendue incluse est active.

Utilisez un sous-processus d'événement lorsque vous souhaitez :

• centralisez la logique de gestion des erreurs liées.
• Évitez de dupliquer les événements d'erreur limités dans plusieurs tâches.
• Comportement de contrôle au niveau du processus ou du sous-processus.
• Répondez à des messages externes au moment du runtime.
• Exécutez la logique de récupération, de journalisation ou de notification de manière cohérente.

Dans Maestro, un sous-processus d'événement peut commencer par :

• une erreur de démarrage d'événement
• un événement de démarrage par message

Démarrer l'événement - Erreur

Un événement de démarrage d'erreur déclenche le sous-processus d'événement lorsqu'une erreur BPMN se produit et que le code d'erreur correspond, ou lorsque l'événement est configuré comme suit.

Lorsqu'une erreur BPMN est générée, le moteur évalue les sous-processus d'événement correspondants dans la même étendue avant d'évaluer les événements d'erreur limites. Cet ordre d’évaluation donne la priorité au sous-processus d’événement.

Comportement d’exécution

Un événement de démarrage d'erreur interrompt toujours.

Lorsque l'erreur se produit, le moteur :

• Déclenche le sous-processus d'événement.
• Annule l’étendue du processus ou du sous-processus.
• Arrête tous les chemins actifs dans cette étendue.

Utilisez un événement de démarrage par erreur lorsque l'erreur invalide l'exécution en cours.

Exemples concrets :

• Une autorisation de paiement échoue en raison de la détection d’une fraude.
• Une validation de conformité obligatoire échoue lors de l’intégration.
• Une dépendance système critique n’est pas disponible.

Gestion des erreurs sans et avec un sous-processus d’événement

Sans sous-processus d’événement	Avec un sous-processus d’événement
Vous joignez des événements d'erreur limites à des tâches spécifiques.	Vous définissez un sous-processus d’événement au niveau de l’étendue du processus ou du sous-processus.
Vous avez souvent dupliqué une logique d’erreur similaire sur plusieurs tâches.	Vous centralisez la logique de gestion des erreurs liées en un seul endroit.
Chaque tâche contrôle sa propre gestion des erreurs.	L'étendue contrôle la gestion des erreurs pour toutes les tâches qu'elle contient.
La maintenance devient difficile à mesure que le modèle évolue.	La maintenance devient plus simple, car vous mettez à jour la logique d'erreur en un seul endroit.

Impact sur les modèles existants

Le comportement du moteur ne change que si vous ajoutez un sous-processus d'événement à la même étendue.

• Les modèles qui utilisent uniquement des événements d’erreur limite continuent de se comporter comme avant.
• Si vous ajoutez un sous-processus d'événement, il gère les erreurs génériques qui ne sont pas gérées par les événements d'erreur de limite dans la même étendue.
• Si aucun événement d'erreur limite ne correspond à une erreur générée, le moteur évalue le sous-processus de l'événement.

Ne configurez pas à la fois un événement d’erreur limite et un sous-processus d’événement pour gérer la même référence d’erreur dans la même étendue.

Règles de configuration

Pour une étendue donnée (processus ou sous-processus) :

• Utilisez un seul sous-processus d’événement par code d’erreur.
• Utilisez un seul sous-processus d'événement catch-all.

Pour une tâche donnée :

• Utilisez un seul événement de limite par code d’erreur.
• Utilisez un seul événement d'erreur de limite Catch-All.

Démarrer l'événement - Message

Un événement de démarrage par message déclenche le sous-processus d'événement lorsque le moteur reçoit le message configuré alors que l'étendue incluse est active.

Comportement d’exécution

Le moteur écoute le message configuré pendant que l'étendue incluse est active. Lorsqu'il reçoit le message, il déclenche le sous-processus d'événement en fonction de sa configuration avec interruption ou sans interruption.

Les événements de début de message ne remplacent pas ou ne prennent pas la priorité sur les autres événements de message. Chaque événement de message réagit indépendamment en fonction de son étendue et de sa configuration.

Gestion des messages sans et avec un sous-processus d’événement

Sans sous-processus d’événement	Avec un sous-processus d’événement
Vous modèlez la gestion des messages à l'intérieur du flux de séquence principal.	Vous définissez un sous-processus d’événement au niveau de l’étendue du processus ou du sous-processus.
Vous devez acheminer le flux principal via des événements intermédiaires de capture de message.	Le moteur écoute le message pendant que l'étendue est active.
Le processus principal doit explicitement accéder à l'événement de message pour y répondre.	Le sous-processus d'événement peut se déclencher à tout moment lorsque l'étendue est active.
La logique de gestion des messages devient étroitement couplée à la structure de flux principale.	La logique de gestion des messages reste indépendante du flux de séquence principal.
La modification du comportement du message peut nécessiter une restructurer le flux principal.	Vous pouvez mettre à jour la gestion des messages sans modifier le flux principal.
Le flux principal s’interrompt toujours au moment de l’événement de message.	Vous pouvez configurer l'événement de démarrage par message sur une interruption ou sans interruption.

Impact sur les modèles existants

Le comportement du moteur ne change que si vous ajoutez un message de démarrage d'événement dans un sous-processus d'événement.

• Les modèles qui n’utilisent pas de sous-processus d’événement continuent de se comporter comme avant.
• Une fois que vous avez ajouté un événement de démarrage par message, le moteur écoute le message configuré pendant que l'étendue incluse est active.
• Si vous configurez l'événement de démarrage par message comme interrompant, le moteur annule l'étendue englobant lorsqu'il reçoit le message.
• Si vous le configurez comme sans interruption, le moteur démarre le sous-processus d'événement en parallèle et permet au flux principal de se poursuivre.

Ne configurez pas plusieurs événements de début de message avec la même référence de message dans la même étendue.

Interrompre ou sans interruption

Vous pouvez configurer un événement de démarrage sur message comme interrompant ou sans interruption.

Interruption

Lorsque le moteur reçoit le message, il :

• Déclenche le sous-processus d'événement.
• Annule l’étendue du processus ou du sous-processus.
• Arrête tous les chemins actifs dans cette étendue.

Utilisez un événement de démarrage par message d'interruption lorsque le message représente un signal externe qui doit arrêter l'exécution en cours.

Exemples concrets :

• Un client annule une commande pendant qu’elle est traitée.
• Un secteur de réglementation envoie une instruction de refus de traitement.
• Un système parent envoie une commande de fin d'exécution.

Sans interruption

Lorsque le moteur reçoit le message, il :

• Déclenche le sous-processus d'événement.
• Maintient l'étendue activée.
• Exécute le sous-processus d’événement en parallèle.
• Permet de poursuivre le processus principal.

Utilisez un événement de démarrage de message sans interruption lorsque le message doit déclencher une logique supplémentaire sans interrompre le flux principal.

Exemples concrets :

• Un client met à jour ses coordonnées pendant que l’intégration se poursuit.
• Un système partenaire envoie des métadonnées supplémentaires.
• Un message de notification déclenche la journalisation de l'audit.