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 alors que l'étendue englobante est active.

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

• Centraliser la logique de gestion des erreurs connexe.
• Éviter de dupliquer les événements d'erreur de limite sur plusieurs tâches.
• Contrôler le comportement à l'étendue du processus ou du sous-processus.
• Réagir aux messages externes lors du runtime.
• Exécuter 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 :

• un événement d'erreur au démarrage
• un événement de massage au démarrage

Démarrer l'événement - Erreur

Un événement d'erreur au démarrage 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 un événement générique.

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

Comportement de l’exécution

Un événement d'erreur au démarrage interrompt toujours le processus.

Lorsque l'erreur se produit, le moteur :

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

Utilisez un événement d'erreur au démarrage lorsque l'erreur invalide l'exécution actuelle.

Exemples concrets :

• Une autorisation de paiement échoue en raison de la détection d'une fraude.
• Une validation de la conformité obligatoire échoue pendant l'intégration.
• Une dépendance système critique est indisponible.

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 de limite à des tâches individuelles.	Vous définissez un sous-processus d'événement à l'étendue du processus ou du sous-processus.
Vous dupliquez souvent une logique d'erreur similaire sur plusieurs tâches.	Vous centralisez la logique de gestion des erreurs connexe 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 plus difficile à mesure que le modèle grandit.	La maintenance devient plus simple, car vous mettez à jour la logique d'erreur en un seul endroit.

Impact sur les modèles existants

Le moteur modifie le comportement uniquement si vous ajoutez un sous-processus d'événement à la même étendue.

• Les modèles qui utilisent uniquement des événements d'erreur de 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 des événements d'erreur de limite dans la même étendue.
• Si aucun événement d'erreur de 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 de 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 générique.

Pour une tâche donnée :

• Utilisez un seul événement d’erreur de limite par code d’erreur.
• Utilisez un seul événement d'erreur de limite générique.

Démarrer l'événement - Message

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

Comportement de l’exécution

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

Les événements de message au démarrage 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élisez la gestion des messages à l'intérieur du flux de séquence principal.	Vous définissez un sous-processus d'événement à l'étendue du processus ou du sous-processus.
Vous devez acheminer le flux principal via des événements d'interception de messages intermédiaires.	Le moteur écoute le message tant que l'étendue est active.
Le processus principal doit atteindre explicitement l'événement de message pour y réagir.	Le sous-processus d'événement peut se déclencher à tout moment tant que 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 sequence principal.
La modification du comportement du message peut nécessiter la restructuration du flux principal.	Vous pouvez mettre à jour la gestion des messages sans modifier le flux principal.
Le flux principal est toujours mis en pause lors de l'événement de message.	Vous pouvez configurer l'événement de message au démarrage comme étant interruptif ou non interruptif.

Impact sur les modèles existants

Le moteur modifie le comportement uniquement si vous ajoutez un événement de message au démarrage à l'intérieur d'un sous-processus d'événement.

• Les modèles qui n’utilisent pas un sous-processus d’événement continuent de se comporter comme avant.
• Une fois que vous ajoutez un événement de message au démarrage, le moteur écoute le message configuré tant que l'étendue englobante est active.
• Si vous configurez l’événement de message au démarrage comme étant interruptif, le moteur annule l’étendue englobante lorsqu’il reçoit le message.
• Si vous le configurez comme non interruptif, le moteur démarre le sous-processus d'événements en parallèle et permet au flux principal de continuer.

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

Interruptif vs non interruptif

Vous pouvez configurer un événement de message de démarrage comme étant interruptif ou non interruptif.

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 englobant.
• Arrête tous les chemins actifs dans cette étendue.

Utilisez un événement de message de démarrage interruptif 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 en cours de traitement.
• Un régulateur envoie une instruction d'arrêt du traitement.
• Un système parent envoie une commande d'arrêt.

Non interruptif

Lorsque le moteur reçoit le message, il :

• Déclenche le sous-processus d'événement.
• Maintient l’étendue englobante active.
• Exécute le sous-processus événement en parallèle.
• Permet au processus principal de continuer.

Utilisez un événement de message au démarrage non interruptif 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 d'audit.