Signaux

Les signaux vous permettent d'injecter des informations dans une exécution de flux de travail en cours. Dans certains scénarios, vous souhaitez parfois ajouter des informations à une exécution de flux de travail en cours d'exécution pour l'informer que quelque chose a changé ou pour l'informer d'un événement externe. N'importe quel processus peut envoyer un signal à une exécution de flux de travail ouverte. Par exemple, une exécution de flux de travail peut en signaler une autre.

Note

Toute tentative d'envoi d'un signal à une exécution de flux de travail qui n'est pas ouverte entraîne l'échec de SignalWorkflowExecution avec UnknownResourceFault.

Pour utiliser des signaux, définissez le nom du signal et les données à transmettre au signal, le cas échéant. Ensuite, programmez le décideur pour qu'il reconnaisse l'événement de signal (WorkflowExecutionSignaled) dans l'historique et traitez-le de manière appropriée. Lorsqu'un processus souhaite signaler l'exécution d'un flux de travail, il appelle Amazon SWF (à l'aide de l'SignalWorkflowExecutionaction ou, dans le cas d'un décideur, de la SignalExternalWorkflowExecutiondécision) qui spécifie l'identifiant de l'exécution du flux de travail cible, le nom du signal et les données du signal. Amazon SWF reçoit ensuite le signal, l'enregistre dans l'historique de l'exécution du flux de travail cible et planifie une tâche de décision correspondante. Lorsque le décideur reçoit la tâche de la décision, il reçoit également le signal dans l'historique d'exécution du flux de travail. Le décideur peut ensuite effectuer les actions appropriées en fonction du signal et de ses données.

Dans certains cas, vous préférez attendre de recevoir un signal avant de continuer. Par exemple, un utilisateur peut annuler une commande en envoyant un signal, mais uniquement dans l'heure qui suit la commande. Amazon SWF ne possède pas de primitive permettant à un décideur d'attendre un signal du service. Les fonctionnalités d'interruption doivent être mises en œuvre dans le décideur lui-même. Pour effectuer une interruption, le décideur doit lancer un temporisateur, à l'aide de la décision StartTimer, qui spécifie la durée pendant laquelle le décideur attendra le signal tout en continuant à rechercher des tâches de décision. Lorsque le décideur reçoit une tâche de la décision, il doit vérifier l'historique pour voir si le signal a été reçu ou si le temporisateur s'est déclenché. Si le signal a été reçu, il doit annuler le temporisateur. Toutefois, si, au lieu de cela, le temporisateur s'est déclenché, cela signifie que le signal n'est pas arrivé dans le délai spécifié. Pour résumer, si vous souhaitez attendre un signal spécifique, procédez comme suit.

1. Créez un temporisateur correspondant à la quantité de temps que le décideur doit attendre.

2. Lorsqu'une tâche de décision est reçue, vérifiez l'historique pour déterminer si le signal est arrivé ou si le temporisateur s'est déclenché.

3. Si un signal est arrivé, annulez le temporisateur via la décision CancelTimer et traitez ce signal. Selon le timing, l'historique peut contenir à la fois les événements TimerFired et WorkflowExecutionSignaled. Dans ce cas, vous pouvez compter sur l'ordre relatif des événements de l'historique afin de déterminer celui qui s'est produit en premier.

4. Si le temporisateur s'est déclenché avant la réception d'un signal, l'attente du signal a expiré au niveau du décideur. Vous pouvez mettre en échec l'exécution ou concevoir tout autre logique en fonction de vos besoins.

Dans les cas où un flux de travail doit être annulé (par exemple, la commande elle-même a été annulée par le client), l'RequestCancelWorkflowExecutionaction doit être utilisée plutôt que d'envoyer un signal au flux de travail.

Voici certains scénarios où des signaux peuvent être utilisés :

• Suspension de la progression des exécutions de flux de travail tant qu'un signal n'a pas été reçu (attente d'une expédition d'inventaire, par exemple).

• Envoi d'informations susceptibles d'avoir une incidence sur la logique de décision des décideurs à une exécution de flux de travail. Ce signal est utile pour les flux de travail soumis à des événements externes (tentative de finalisation de la vente d'une action après la fermeture de la Bourse, par exemple).

• Mise à jour d'une exécution de flux de travail lorsque vous anticipez des modifications éventuelles (modification de la quantité d'une commande après l'enregistrement de la commande et avant son envoi).

Dans l'exemple suivant, un signal est envoyé à l'exécution du flux de travail pour annuler une commande.

https://swf.us-east-1.amazonaws.com
SignalWorkflowExecution
{"domain": "867530901",
 "workflowId": "20110927-T-1",
 "runId": "f5ebbac6-941c-4342-ad69-dfd2f8be6689",
 "signalName": "CancelOrder",
 "input": "order 3553"}

Si l'exécution du flux de travail reçoit ce signal, Amazon SWF renvoie une réponse HTTP positive similaire à la suivante : Amazon SWF générera une tâche de décision pour indiquer au décideur de traiter le signal.

HTTP/1.1 200 OK
Content-Length: 0
Content-Type: application/json
x-amzn-RequestId: bf78ae15-3f0c-11e1-9914-a356b6ea8bdf