Untergeordnete Workflow-Ausführungen - AWS Flow Framework für Java

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Untergeordnete Workflow-Ausführungen

In den bisherigen Beispielen wurde die Workflow-Ausführung direkt in einer Anwendung gestartet. Eine Workflow-Ausführung kann jedoch auch innerhalb eines Workflows gestartet werden, indem für den generierten Client die Workflow-Eintrittspunktmethode aufgerufen wird. Wenn eine Workflow-Ausführung im Kontext der Ausführung eines anderen Workflows gestartet wird, ist das eine untergeordnete Workflow-Ausführung. Damit können Sie komplexe Workflows in kleinere Einheiten unterteilen und gegebenenfalls in verschiedenen Workflows einsetzen. Sie können zum Beispiel einen Workflow zur Zahlungsabwicklung erstellen und über den Workflow zur Abwicklung des Bestellvorgangs aufrufen.

Die untergeordnete Workflow-Ausführung erfolgt semantisch genauso wie ein eigenständiger Workflow – mit Ausnahme der folgenden Unterschiede:

  1. Wenn der übergeordnete Workflow aufgrund einer expliziten Aktion des Benutzers beendet wird, z. B. durch Aufrufen derTerminateWorkflowExecutionAmazon SWF SWF-API oder wird aufgrund eines Timeouts beendet - dann wird das Schicksal der Ausführung des untergeordneten Workflows durch eine untergeordnete Richtlinie bestimmt. Sie können diese untergeordnete Richtlinie so einrichten, dass die Ausführung des untergeordneten Workflows beendet, abgebrochen oder verworfen (läuft weiter) wird.

  2. Die Ausgabe des untergeordneten Workflows (Rückgabewert der Eintrittspunktmethode) kann von der übergeordneten Workflow-Ausführung genau so wie der mit einer asynchronen Methode zurückgegebene Promise<T> verwendet werden. Bei eigenständigen Ausführungen hingegen muss die Anwendung die Ausgabe mithilfe von Amazon SWF SWF-APIs abrufen.

Im folgenden Beispiel erstellt der OrderProcessor-Workflow einen untergeordneten Workflow PaymentProcessor:

@Workflow @WorkflowRegistrationOptions(defaultExecutionStartToCloseTimeoutSeconds = 60, defaultTaskStartToCloseTimeoutSeconds = 10) public interface OrderProcessor { @Execute(version = "1.0") void processOrder(Order order); } public class OrderProcessorImpl implements OrderProcessor { PaymentProcessorClientFactory factory = new PaymentProcessorClientFactoryImpl(); @Override public void processOrder(Order order) { float amount = order.getAmount(); CardInfo cardInfo = order.getCardInfo(); PaymentProcessorClient childWorkflowClient = factory.getClient(); childWorkflowClient.processPayment(amount, cardInfo); } } @Workflow @WorkflowRegistrationOptions(defaultExecutionStartToCloseTimeoutSeconds = 60, defaultTaskStartToCloseTimeoutSeconds = 10) public interface PaymentProcessor { @Execute(version = "1.0") void processPayment(float amount, CardInfo cardInfo); } public class PaymentProcessorImpl implements PaymentProcessor { PaymentActivitiesClient activitiesClient = new PaymentActivitiesClientImpl(); @Override public void processPayment(float amount, CardInfo cardInfo) { Promise<PaymentType> payType = activitiesClient.getPaymentType(cardInfo); switch(payType.get()) { case Visa: activitiesClient.processVisa(amount, cardInfo); break; case Amex: activitiesClient.processAmex(amount, cardInfo); break; default: throw new UnSupportedPaymentTypeException(); } } } @Activities(version = "1.0") @ActivityRegistrationOptions(defaultTaskScheduleToStartTimeoutSeconds = 3600, defaultTaskStartToCloseTimeoutSeconds = 3600) public interface PaymentActivities { PaymentType getPaymentType(CardInfo cardInfo); void processVisa(float amount, CardInfo cardInfo); void processAmex(float amount, CardInfo cardInfo); }