Tâche de Réception(Receive Task)
Une tâche qui attend l'arrivée d'un message d'un participant externe. Le jeton s'arrête à la tâche jusqu'à réception du message. Marquée d'une icône d'enveloppe ouverte (claire).
La Tâche de Réception (Receive Task) est la forme *activité* de l'attente d'un message. Elle est la contrepartie naturelle de la Tâche d'Envoi : un participant envoie, l'autre reçoit.
Deux caractéristiques la distinguent de l'événement de réception équivalent :
- En tant qu'activité, elle accepte des événements de bordure (attachez une minuterie pour temporiser l'attente) et des marqueurs de boucle / multi-instance (recevoir un message par élément).
- La spécification lui donne un attribut instantiate : une Tâche de Réception avec
instantiate = truepeut démarrer une nouvelle instance de processus à la réception du message — l'équivalent, en activité, d'un Événement de Début de Message.
Quand l'utiliser et l'éviter
Quand l'utiliser
Quand l'attente d'une réponse externe est une étape de travail suivie par l'équipe (par ex. Recevoir le devis du fournisseur, Recevoir le contrat signé).
Quand l'attente nécessite un délai d'expiration : attachez un Événement de Bordure de Minuterie pour escalader ou suivre un chemin alternatif si rien n'arrive.
Quand la réception doit apparaître dans les métriques au niveau des activités (combien de temps attendons-nous les fournisseurs ?).
Quand NE PAS l'utiliser
Pour une pause légère sans sémantique d'activité — un Événement Intermédiaire de Réception de Message est plus épuré.
Quand le message doit démarrer le processus et que vous n'avez aucune raison de préférer une activité — l'Événement de Début de Message est le choix conventionnel.
Pour une synchronisation *au sein* du même Pool — les messages n'existent qu'entre participants.
Exemple métier
Attente du devis d'un fournisseur
Ouvrez cet exemple dans l'éditeur de processus HEFLO et explorez le diagramme de l'intérieur.
Ouvrir dans l'éditeur HEFLO →Étape par étape
- Les achats ont besoin d'une cotation et envoient un appel d'offres (RFQ) au Pool Fournisseur.
- La Tâche de Réception « Recevoir le devis du fournisseur » (mise en évidence) retient le jeton : le processus attend ici jusqu'à ce que le message du fournisseur arrive par le flux de messages en pointillés.
- Quand le devis est reçu, le processus se termine avec le devis en main.
Dans un modèle de production, un Événement de Bordure de Minuterie sur la tâche de réception gérerait les fournisseurs qui ne répondent jamais.
Différences
Différence entre une Tâche de Réception et un Événement Intermédiaire de Réception de Message
Tous deux mettent le flux en pause jusqu'à l'arrivée d'un message. La Tâche de Réception est une activité — elle accepte les événements de bordure (délais d'expiration !), les marqueurs de boucle / multi-instance et apparaît dans les métriques de travail. L'Événement de Réception est atomique et plus léger. Si vous avez besoin d'un délai d'expiration sur l'attente, la tâche + bordure de minuterie est le motif idiomatique.
Tâche de Réception avec instantiate vs. Événement de Début de Message
Une Tâche de Réception avec instantiate = true peut créer une nouvelle instance de processus quand son message arrive — fonctionnellement similaire à un Événement de Début de Message. L'événement de début est le choix conventionnel et plus lisible ; la tâche de réception instanciante est rare et surtout utilisée quand la première étape doit être une activité.
FAQ
Que se passe-t-il si le message n'arrive jamais ?
Attachez un Événement de Bordure de Minuterie à la tâche de réception. À l'expiration de l'échéance, le flux prend le chemin alternatif (escalader, annuler, relancer) — avec une bordure interruptive, l'attente est abandonnée.
Comment le moteur sait-il quel message appartient à quelle instance ?
Par corrélation : une clé métier portée par le message (un numéro de commande, un identifiant de ticket) est mise en correspondance avec les instances en attente. Chaque moteur offre un mécanisme de corrélation pour cela.