Signale

Signale ermöglichen es Ihnen, Informationen in eine laufende Workflow-Ausführung einzufügen. In manchen Szenarien empfiehlt es sich, einer laufenden Workflow-Ausführung Informationen hinzuzufügen, um ihr mitzuteilen, dass Änderungen aufgetreten sind oder sie über ein externes Ereignis zu informieren. Jeder Prozess kann einer offenen Workflow-Ausführung ein Signal senden. So kann beispielsweise eine Workflow-Ausführung einer anderen ein Signal senden.

Anmerkung

Der Versuch ein Signal an eine Workflow-Ausführung zu senden, die nicht offen ist, resultiert in ein Fehlschlagen von SignalWorkflowExecution aufgrund von UnknownResourceFault.

Um Signale zu verwenden, definieren Sie den Signalnamen und die Daten, die an das Signal übergeben werden sollen, falls vorhanden. Dann programmieren Sie den Entscheider so, dass er das Signalereignis (WorkflowExecutionSignaled) in der Historie erkennt und es entsprechend verarbeitet. Wenn ein Prozess eine Workflow-Ausführung signalisieren möchte, ruft er Amazon SWF auf (mithilfe der SignalWorkflowExecutionAktion oder, im Fall eines Entscheiders, anhand der SignalExternalWorkflowExecutionEntscheidung), das die Kennung für die Ziel-Workflow-Ausführung, den Signalnamen und die Signaldaten angibt. Amazon SWF empfängt dann das Signal, zeichnet es in der Historie der Ziel-Workflow-Ausführung auf und plant dafür eine Entscheidungsaufgabe. Wenn der Entscheider die Entscheidungsaufgabe empfängt, empfängt er auch das Signal im Workflow-Ausführungsverlauf. Daraufhin kann der Entscheider basierend auf dem Signal und dessen Daten die entsprechenden Aktionen einleiten.

Manchmal empfiehlt es sich, auf ein Signal zu warten. Beispielsweise könnte ein Benutzer eine Bestellung stornieren, indem er ein Signal sendet, jedoch nur innerhalb einer Stunde nach der Bestellung. Amazon SWF verfügt nicht über ein Primitiv, das es einem Entscheider ermöglicht, auf ein Signal vom Service zu warten. Die Pausenfunktionalität muss vom Entscheider selbst implementiert werden. Um Pausieren zu können, muss der Entscheider mithilfe der StartTimer-Entscheidung einen Timer starten, der die Dauer festlegt, die der Entscheider auf das Signal wartet, während er gleichzeitig Entscheidungsaufgaben abfragt. Wenn der Entscheider eine Entscheidungsaufgabe empfängt, sollte er den Verlauf überprüfen, um zu sehen, ob das Signal empfangen oder der Timer aktiviert wurde. Wurde das Signal empfangen, sollte der Entscheider den Timer deaktivieren. Wird der Timer jedoch aktiviert, heißt das, dass das Signal nicht innerhalb des festgelegten Zeitraums ankam. Befolgen Sie zusammenfassend die folgenden Schritte, um auf ein bestimmtes Signal zu warten.

1. Erstellen Sie einen Timer für die Zeitspanne, die der Entscheider warten soll.

2. Wenn eine Entscheidungsaufgabe empfangen wurde, sollten Sie den Verlauf überprüfen, um zu sehen, ob das Signal eingetroffen ist oder der Timer aktiviert wurde.

3. Ist das Signal eingetroffen, deaktivieren Sie den Timer anhand einer CancelTimer-Entscheidung und bearbeiten Sie das Signal. Abhängig vom Zeitpunkt kann der Verlauf sowohl TimerFired- als auch WorkflowExecutionSignaled-Ereignisse umfassen. In diesen Fällen können Sie anhand der relativen Reihenfolge der Ereignisse im Verlauf feststellen, welches Ereignis zuerst eintrat.

4. Wenn der Timer vor dem Empfang eines Signals aktiviert wurde, bedeutet das, dass der Zeitraum überschritten wurde, die der Entscheider auf das Signal wartet. Sie können die Ausführung fehlschlagen lassen oder entsprechend Ihrem Anwendungsfall eine andere Logik anwenden.

In Fällen, in denen ein Workflow storniert werden sollte — zum Beispiel, wenn die Bestellung selbst vom Kunden storniert wurde —, sollte dieRequestCancelWorkflowExecution Aktion verwendet werden, anstatt ein Signal an den Workflow zu senden.

Nachfolgend finden Sie einige Anwendungsbeispiele für Signale:

• Pausieren der Workflow-Ausführungen bis ein Signal empfangen wird (z. B. auf eine Bestandslieferung warten).

• Bereitstellen von Informationen für eine Workflow-Ausführung, die die Logik beeinflusst, mit der der Entscheider Entscheidungen tätigt. Dies empfiehlt sich für Workflows, die von externen Ereignissen beeinflusst werden (z. B. der Verkauf von Aktien nachdem der Markt geschlossen ist).

• Aktualisieren der Workflow-Ausführung, wenn Sie Änderungen erwarten (z. B. Ändern der Bestellmengen nachdem eine Bestellung aufgegeben wurde und bevor sie versendet wird).

Im folgenden Beispiel wird der Workflow-Ausführung ein Signal zum Stornieren einer Bestellung gesendet.

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"}

War die Workflow-Ausführung wie folgt aussieht, gibt Amazon SWF eine erfolgreiche Antwort zurück, die etwa wie folgt aussieht. Amazon SWF generiert eine Entscheidungsaufgabe, um den Entscheider über die Verarbeitung des Signals zu informieren.

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