Workflow-Clients Aktivitäts-Clients Planungsoptionen Dynamische Clients

Aktivitäts- und Workflow-Clients

Workflow- und Aktivitäts-Clients werden von dem Framework generiert, das auf den Schnittstellen @Workflow und @Activities basiert. Es werden separate Client-Schnittstellen generiert, die Methoden und Einstellungen enthalten, die nur innerhalb des Clients Sinn ergeben. Wenn Sie mit Eclipse entwickeln, erledigt dies das Amazon SWF Eclipse-Plug-In jedes Mal, wenn Sie die Datei mit der entsprechenden Schnittstelle speichern. Der generierte Code wird im generierten Quellverzeichnis Ihres Projekts im selben Paket platziert wie die Schnittstelle.

Anmerkung

Beachten Sie, dass der von Eclipse verwendete Standardname für das Verzeichnis .apt_generated lautet. Eclipse zeigt keine Verzeichnisse, deren Namen mit beginnen. Wenn Sie im Package Explorer. Wenn Sie die generierten Dateien im Project Explorer anzeigen möchten, verwenden Sie einen anderen Verzeichnisnamen. Klicken Sie in Eclipse mit der rechten Maustaste auf das Paket im Package Explorer, wählen Sie dann Properties (Eigenschaften), Java Compiler, Annotation processing (Annotationen verarbeiten) und ändern Sie die Einstellung Generate source directory (Quellverzeichnis generieren).

Workflow-Clients

Die generierten Artefakte für den Workflow enthalten drei clientseitige Schnittstellen und die Klassen, die sie implementieren. Die generierten Clients umfassen Folgendes:

Einen asynchronen Client, der aus einer Workflow-Implementierung heraus verbraucht werden soll, die asynchrone Methoden bereitstellt, die den Workflow ausführen und Signale senden.
Einen externen Client, der verwendet werden kann, um Ausführungen zu starten, Signale zu senden und den Workflow-Status von außerhalb einer Workflow-Implementierung zu empfangen.
Einen Self-Client, der verwendet werden kann, um einen kontinuierlichen Workflow zu generieren.

So lauten z.B. die generierten Client-Schnittstellen für die Musterschnittstelle MyWorkflow wie folgt:


//Client for use from within a workflow
public interface MyWorkflowClient extends WorkflowClient
{
    Promise<Void> startMyWF(
       int a, String b);

    Promise<Void> startMyWF(
       int a, String b,
       Promise<?>... waitFor);

    Promise<Void> startMyWF(
       int a, String b,
       StartWorkflowOptions optionsOverride,
       Promise<?>... waitFor);

    Promise<Void> startMyWF(
       Promise<Integer> a,
       Promise<String> b);

    Promise<Void> startMyWF(
       Promise<Integer> a,
       Promise<String> b,
       Promise<?>... waitFor);

    Promise<Void> startMyWF(
       Promise<Integer> a,
       Promise<String> b,
       StartWorkflowOptions optionsOverride,
       Promise<?>... waitFor);

    void signal1(
      int a, int b, String c);
}

//External client for use outside workflows
public interface MyWorkflowClientExternal extends WorkflowClientExternal
{
    void startMyWF(
       int a, String b);

    void startMyWF(
       int a, String b,
       StartWorkflowOptions optionsOverride);

    void signal1(
       int a, int b, String c);

    MyWorkflowState getState();
}

//self client for creating continuous workflows
public interface MyWorkflowSelfClient extends WorkflowSelfClient
{
    void startMyWF(
       int a, String b);

    void startMyWF(
       int a, String b,
       Promise<?>... waitFor);

    void startMyWF(
       int a, String b,
       StartWorkflowOptions optionsOverride,
       Promise<?>... waitFor);

    void startMyWF(
       Promise<Integer> a,
       Promise<String> b);

    void startMyWF(
       Promise<Integer> a,
       Promise<String> b,
       Promise<?>... waitFor);

    void startMyWF(
       Promise<Integer> a,
       Promise<String> b,
       StartWorkflowOptions optionsOverride,
       Promise<?>... waitFor);

Die Schnittstellen haben eine Methodenüberladungen, die jeweils der in der Schnittstelle deklarierten Methode @Workflow entsprechen.

Der externe Client spiegelt die Methoden der Schnittstelle @Workflow mit einer zusätzlichen Methodenüberladung @Execute, die StartWorkflowOptions verwendet. Sie können mit dieser Überladung zusätzliche Optionen weiterleiten, wenn Sie eine neue Workflow-Ausführung starten. Diese Optionen ermöglichen Ihnen die Standardaufgabenliste, die Timeout-Einstellungen und die zugehörigen Tags mit der Workflow-Ausführung zu überschreiben.

Auf der anderen Seite verfügt der asynchrone Client über Methoden, die einen asynchronen Aufruf der Methode @Execute ermöglichen. Die folgenden Methodenüberladungen werden in der Client-Schnittstelle für die Methode @Execute in der Workflow-Schnittstelle generiert:

Eine Überladung, welche die ursprünglichen Argumente unverändert übernimmt. Der Rückgabetyp dieser Überladung ist Promise<Void>, wenn die ursprüngliche Methode void zurückgegeben hat; andernfalls ist es Promise<>, wie in der ursprünglichen Methode deklariert. Zum Beispiel:

Ursprüngliche Methode:
```
void startMyWF(int a, String b);
```
Generierte Methode:
```
Promise<Void> startMyWF(int a, String b);
```
Diese Überladung sollte verwendet werden, wenn alle Argumente des Workflows verfügbar sind und nicht auf diese gewartet werden muss.
Eine Überladung, die die ursprünglichen Argumente unverändert sowie zusätzliche variable Argumente des Typs Promise<?> übernimmt. Der Rückgabetyp dieser Überladung ist Promise<Void>, wenn die ursprüngliche Methode void zurückgegeben hat; andernfalls ist es Promise<>, wie in der ursprünglichen Methode deklariert. Zum Beispiel:

Ursprüngliche Methode:
```
void startMyWF(int a, String b);
```
Generierte Methode:
```
Promise<void> startMyWF(int a, String b, Promise<?>...waitFor);
```
Diese Überladung sollte verwendet werden, wenn alle Argumente des Workflows verfügbar sind und nicht auf diese gewartet werden muss, wenn Sie jedoch darauf warten möchten, dass ein anderes Promise betriebsbereit wird. Das variable Argument kann verwendet werden, um Objekte wie Promise<?> weiterzuleiten, die nicht als Argumente deklariert waren, wenn Sie noch mit der Ausführung des Aufrufs warten möchten.
Eine Überladung, die die ursprünglichen Argumente unverändert übernimmt sowie ein zusätzliches Argument des Typs StartWorkflowOptions und ein zusätzliches Argument des Typs Promise<?>. Der Rückgabetyp dieser Überladung ist Promise<Void>, wenn die ursprüngliche Methode void zurückgegeben hat; andernfalls ist es Promise<>, wie in der ursprünglichen Methode deklariert. Zum Beispiel:

Ursprüngliche Methode:
```
void startMyWF(int a, String b);
```
Generierte Methode:
```
Promise<void> startMyWF(
   int a,
   String b,
   StartWorkflowOptions optionOverrides,
   Promise<?>...waitFor);
```
Diese Überladung sollte verwendet werden, wenn alle Argumente des Workflows verfügbar sind und nicht auf diese gewartet werden muss, wenn Sie Standardeinstellungen überschreiben und die Workflow-Ausführung starten möchten oder wenn Sie darauf warten möchten, dass ein anderes Promise betriebsbereit wird. Das variable Argument kann verwendet werden, um Objekte wie Promise<?> weiterzuleiten, die nicht als Argumente deklariert waren, wenn Sie noch mit der Ausführung des Aufrufs warten möchten.
Eine Überladung mit jedem Argument in der ursprünglichen Methode, die durch einen Promise<>-Wrapper ersetzt wurde. Der Rückgabetyp dieser Überladung ist Promise<Void>, wenn die ursprüngliche Methode void zurückgegeben hat; andernfalls ist es Promise<>, wie in der ursprünglichen Methode deklariert. Zum Beispiel:

Ursprüngliche Methode:
```
void startMyWF(int a, String b);
```
Generierte Methode:
```
Promise<Void> startMyWF(
   Promise<Integer> a,
   Promise<String> b);
```
Diese Überladung sollte verwendet werden, wenn die Argumente, die an die Workflow-Ausführung weitergeleitet werden sollen, asynchron evaluiert werden müssen. Ein Aufruf dieser Methodenüberladung wird so lange nicht ausgeführt, bis alle Argumente, die an diese weitergeleitet wurden, betriebsbereit sind.

Wenn einige der Argumente bereits betriebsbereit sind, dann konvertieren Sie diese in ein Promise, das durch die Methode Promise.asPromise(value) bereits im betriebsbereiten Status ist. Zum Beispiel:
```
Promise<Integer> a = getA();
String b = getB();
startMyWF(a, Promise.asPromise(b));
```
Eine Überladung mit jedem Argument in der ursprünglichen Methode wird durch den Wrapper Promise<> ersetzt. Die Überladung hat auch unterschiedliche variable Argumente des Typs Promise<?>. Der Rückgabetyp dieser Überladung ist Promise<Void>, wenn die ursprüngliche Methode void zurückgegeben hat; andernfalls ist es Promise<>, wie in der ursprünglichen Methode deklariert. Zum Beispiel:

Ursprüngliche Methode:
```
void startMyWF(int a, String b);
```
Generierte Methode:
```
Promise<Void> startMyWF(
   Promise<Integer> a,
   Promise<String> b,
   Promise<?>...waitFor);
```
Diese Überladung sollte verwendet werden, wenn die Argumente, die an die Workflow-Ausführung weitergeleitet wurden, asynchron evaluiert werden und wenn Sie darauf warten möchten, dass ein anderes Promise ebenfalls betriebsbereit wird. Ein Aufruf dieser Methodenüberladung wird so lange nicht ausgeführt, bis alle Argumente, die an diese weitergeleitet wurden, betriebsbereit sind.
Eine Überladung mit jedem Argument in der ursprünglichen Methode, die durch einen Promise<?>-Wrapper ersetzt wurde. Die Überladung enthält auch ein zusätzliches Argument des Typs StartWorkflowOptions und variable Argumente des Typs Promise<?>. Der Rückgabetyp dieser Überladung ist Promise<Void>, wenn die ursprüngliche Methode void zurückgegeben hat; andernfalls ist es Promise<>, wie in der ursprünglichen Methode deklariert. Zum Beispiel:

Ursprüngliche Methode:
```
void startMyWF(int a, String b);
```
Generierte Methode:
```
Promise<Void> startMyWF(
   Promise<Integer> a,
   Promise<String> b,
   StartWorkflowOptions optionOverrides,
   Promise<?>...waitFor);
```
Verwenden Sie diese Überladung, wenn die Argumente, die an die Workflow-Ausführung weitergeleitet werden sollen, asynchron evaluiert werden und wenn Sie die Standardeinstellungen überschreiben möchten, die zum Starten der Workflow-Ausführung verwendet werden. Ein Aufruf dieser Methodenüberladung wird so lange nicht ausgeführt, bis alle Argumente, die an diese weitergeleitet wurden, betriebsbereit sind.

Außerdem wird für jedes Signal in der Workflow-Oberfläche eine Methode generiert — zum Beispiel:

Ursprüngliche Methode:


void signal1(int a, int b, String c);

Generierte Methode:


void signal1(int a, int b, String c);

Der asynchrone Client enthält keine Methode, welche der Methode entspricht, die in der ursprünglichen Schnittstelle mit @GetState annotiert wurde. Da das Abrufen des Status einen Webservice-Aufruf erfordert, ist er nicht für die Verwendung innerhalb eines Workflows geeignet. Daher kann er nur über einen externen Client zur Verfügung gestellt werden.

Der Self-Client soll in einem Workflow verwendet werden, um eine neue Ausführung nach Beendigung der aktuellen Ausführung zu starten. Die Methoden auf diesem Client sind den Methoden auf dem asynchronen Client ähnlich, aber die Rückgabe ist void. Der Client enthält keine Methoden, welche den Methode entsprechen, die mit @Signal und @GetState annotiert wurden. Weitere Informationen hierzu finden Sie unter Fortlaufende Workflows.

Die generierten Clients sind von den Basisschnittstellen WorkflowClient und WorkflowClientExternal abgeleitet, die Methoden bereitstellen, die Sie zum Abbrechen oder Beenden der Workflow-Ausführung verwenden können. Weitere Informationen zu diesen Schnittstellen finden Sie in der AWS SDK für Java -Dokumentation.

Die generierten Clients ermöglichen die Interaktion mit den Workflow-Ausführungen in einer stark typisierten Form. Eine Instance eines generierten Client, wird, wenn sie einmal erstellt wurde, mit einer spezifischen Workflow-Ausführung verknüpft und kann nur für diese Ausführung verwendet werden. Außerdem stellt das Framework dynamische Clients bereit, die nicht für einen Workflow-Typ oder eine Ausführung typisch sind. Die generierten Clients basieren verdeckt auf diesem Client. Sie können diese Clients auch direkt verwenden. Sehen Sie sich den Abschnitt zu Dynamische Clients an.

Das Framework generiert auch Fabriken zum Erstellen stark typisierter Clients. Die generierten Client-Fabriken für die Musterschnittstelle MyWorkflow sind:


//Factory for clients to be used from within a workflow
public interface MyWorkflowClientFactory
   extends WorkflowClientFactory<MyWorkflowClient>
{
}

//Factory for clients to be used outside the scope of a workflow
public interface MyWorkflowClientExternalFactory
{
   GenericWorkflowClientExternal getGenericClient();
   void setGenericClient(GenericWorkflowClientExternal genericClient);
   DataConverter getDataConverter();
   void setDataConverter(DataConverter dataConverter);
   StartWorkflowOptions getStartWorkflowOptions();
   void setStartWorkflowOptions(StartWorkflowOptions startWorkflowOptions);
   MyWorkflowClientExternal getClient();
   MyWorkflowClientExternal getClient(String workflowId);
   MyWorkflowClientExternal getClient(WorkflowExecution workflowExecution);
   MyWorkflowClientExternal getClient(
      WorkflowExecution workflowExecution,
      GenericWorkflowClientExternal genericClient,
      DataConverter dataConverter,
      StartWorkflowOptions options);
}

Die Basisschnittstelle für WorkflowClientFactory ist:


public interface WorkflowClientFactory<T> {
    GenericWorkflowClient getGenericClient();
    void setGenericClient(GenericWorkflowClient genericClient);
    DataConverter getDataConverter();
    void setDataConverter(DataConverter dataConverter);
    StartWorkflowOptions getStartWorkflowOptions();
    void setStartWorkflowOptions(StartWorkflowOptions startWorkflowOptions);
    T getClient();
    T getClient(String workflowId);
    T getClient(WorkflowExecution execution);
    T getClient(WorkflowExecution execution,
                StartWorkflowOptions options);
    T getClient(WorkflowExecution execution,
                StartWorkflowOptions options,
                DataConverter dataConverter);
}

Sie sollten diese Fabriken zum Erstellen von Client-Instances verwenden. Mit der Fabrik können Sie den generischen Client (der generische Client sollte für die Bereitstellung der benutzerdefinierten Client-Implementierung verwendet werden) und den DataConverter, der vom Client zum Daten-Marshalling verwendet wird, sowie die Optionen, die verwendet werden, um die Workflow-Ausführung zu starten, konfigurieren. Weitere Informationen finden Sie unter den Abschnitten DataConverters und Untergeordnete Workflow-Ausführungen. Das StartWorkflowOptions enthält Einstellungen, mit denen Sie die bei der Registrierung angegebenen Standardwerte (z. B. Timeouts) außer Kraft setzen können. Weitere Informationen zur Klasse finden Sie in der Dokumentation. StartWorkflowOptions AWS SDK für Java

Einen externen Client, der verwendet werden kann, um Workflow-Ausführungen außerhalb eines Workflows zu starten, während der asynchrone Client verwendet werden kann, um eine Workflow-Ausführung vom Code innerhalb eines Workflows zu starten. Zum Starten einer Ausführung verwenden Sie einfach den generierten Client, um die Methode aufzurufen, welche der Methode entspricht, die @Execute in der Workflow-Schnittstelle annotiert ist.

Das Framework generiert auch Implementierungsklassen für die Client-Schnittstellen. Diese Clients erstellen Anfragen und senden sie an Amazon SWF, um die entsprechende Aktion auszuführen. Die Client-Version der @Execute Methode startet entweder eine neue Workflow-Ausführung oder erstellt eine untergeordnete Workflow-Ausführung mit Amazon SWF APIs. In ähnlicher Weise verwendet die Client-Version der @Signal Methode Amazon SWF APIs , um ein Signal zu senden.

Anmerkung

Der externe Workflow-Client muss mit dem Amazon SWF-Client und der Domain konfiguriert sein. Sie können entweder den Client Factory-Konstruktor verwenden, der diese als Parameter verwendet, oder eine generische Client-Implementierung übergeben, die bereits mit dem Amazon SWF-Client und der Domain konfiguriert ist.

Das Framework durchläuft die Typenhierarchie der Workflow-Schnittstelle und generiert auch Client-Schnittstellen für übergeordnete Workflow-Schnittstellen und leitet sich aus diesen ab.

Aktivitäts-Clients

Ähnlich wie ein Workflow-Client, wird für jede Schnittstelle ein Client generiert, der mit @Activities annotiert ist. Die generierten Artefakte umfassen eine clientseitige Schnittstelle und eine Client-Klasse. Die generierte Schnittstelle für die oben genannte Musterschnittstelle @Activities (MyActivities) lautet wie folgt:


public interface MyActivitiesClient extends ActivitiesClient
{
  Promise<Integer> activity1();
  Promise<Integer> activity1(Promise<?>... waitFor);
  Promise<Integer> activity1(ActivitySchedulingOptions optionsOverride,
                             Promise<?>... waitFor);
  Promise<Void> activity2(int a);
  Promise<Void> activity2(int a,
                          Promise<?>... waitFor);
  Promise<Void> activity2(int a,
                          ActivitySchedulingOptions optionsOverride,
                          Promise<?>... waitFor);
  Promise<Void> activity2(Promise<Integer> a);
  Promise<Void> activity2(Promise<Integer> a,
                          Promise<?>... waitFor);
  Promise<Void> activity2(Promise<Integer> a,
                          ActivitySchedulingOptions optionsOverride,
                          Promise<?>... waitFor);
}

Die Schnittstelle enthält eine Menge von Methodenüberladungen, die jeweils der Aktivitätsmethode in der Schnittstelle @Activities entsprechen. Die Überladungen dienen der Bequemlichkeit und ermöglichen den asynchronen Aufruf von Aktivitäten. Für jede Aktivitätsmethode in der Schnittstelle @Activities werden die folgenden Methodenüberladungen in der Client-Schnittstelle generiert:

Eine Überladung, welche die ursprünglichen Argumente unverändert übernimmt. Der Rückgabetyp dieser Überladung ist Promise<T>, wobei T der Rückgabetyp der ursprünglichen Methode ist. Zum Beispiel:

Ursprüngliche Methode:
```
void activity2(int foo);
```
Generierte Methode:
```
Promise<Void> activity2(int foo);
```
Diese Überladung sollte verwendet werden, wenn alle Argumente des Workflows verfügbar sind und nicht auf diese gewartet werden muss.
Eine Überladung, welche die ursprünglichen Argumente unverändert, ein Argument der Art ActivitySchedulingOptions und ein zusätzliches variables Argument des Typs Promise<?> übernimmt. Der Rückgabetyp dieser Überladung ist Promise<T>, wobei T der Rückgabetyp der ursprünglichen Methode ist. Zum Beispiel:

Ursprüngliche Methode:
```
void activity2(int foo);
```
Generierte Methode:
```
Promise<Void> activity2(
  int foo,
  ActivitySchedulingOptions optionsOverride,
  Promise<?>... waitFor);
```
Diese Überladung sollte verwendet werden, wenn alle Argumente des Workflows verfügbar sind und nicht auf diese gewartet werden muss, wenn Sie Standardeinstellungen überschreiben oder darauf warten, dass ein zusätzliches Promises betriebsbereit ist. Die variablen Argumente können verwendet werden, um zusätzliche Objekte wie Promise<?> weiterzuleiten, die nicht als Argumente deklariert waren, wenn Sie noch mit der Ausführung des Aufrufs warten möchten.
Eine Überladung mit jedem Argument in der ursprünglichen Methode, die durch einen Promise<>-Wrapper ersetzt wurde. Der Rückgabetyp dieser Überladung ist Promise<T>, wobei T der Rückgabetyp der ursprünglichen Methode ist. Zum Beispiel:

Ursprüngliche Methode:
```
void activity2(int foo);
```
Generierte Methode:
```
Promise<Void> activity2(Promise<Integer> foo);
```
Diese Überladung sollte verwendet werden, wenn die Argumente, die an die Aktivität weitergeleitet werden sollen, asynchron evaluiert werden müssen. Ein Aufruf dieser Methodenüberladung wird so lange nicht ausgeführt, bis alle Argumente, die an diese weitergeleitet wurden, betriebsbereit sind.
Eine Überladung mit jedem Argument in der ursprünglichen Methode, die durch einen Promise<>-Wrapper ersetzt wurde. Die Überladung enthält auch ein zusätzliches Argument des Typs ActivitySchedulingOptions und variable Argumente des Typs Promise<?>. Der Rückgabetyp dieser Überladung ist Promise<T>, wobei T der Rückgabetyp der ursprünglichen Methode ist. Zum Beispiel:

Ursprüngliche Methode:
```
void activity2(int foo);
```
Generierte Methode:
```
Promise<Void> activity2(
   Promise<Integer> foo,
   ActivitySchedulingOptions optionsOverride,
   Promise<?>...waitFor);
```
Diese Überladung sollte verwendet werden, wenn die Argumente, die an die Aktivität weitergeleitet werden sollen, asynchron evaluiert werden und wenn Sie Standardeinstellungen, die mit dem Typ registriert sind, überschreiben oder darauf warten möchten, dass zusätzliche Promises betriebsbereit sind. Ein Aufruf dieser Methodenüberladung wird so lange nicht ausgeführt, bis alle Argumente, die an diese weitergeleitet wurden, betriebsbereit sind. Die generierte Client-Klasse implementiert diese Schnittstelle. Die Implementierung jeder Schnittstellenmethode erstellt und sendet eine Anfrage an Amazon SWF, um mithilfe von Amazon SWF eine Aktivitätsaufgabe des entsprechenden Typs zu planen APIs.
Eine Überladung, die die ursprünglichen Argumente unverändert sowie zusätzliche variable Argumente des Typs Promise<?> übernimmt. Der Rückgabetyp dieser Überladung ist Promise<T>, wobei T der Rückgabetyp der ursprünglichen Methode ist. Zum Beispiel:

Ursprüngliche Methode:
```
void activity2(int foo);
```
Generierte Methode:
```
Promise< Void > activity2(int foo,
                             Promise<?>...waitFor);
```
Diese Überladung sollte verwendet werden, wenn alle Argumente der Aktivität verfügbar sind und nicht auf diese gewartet werden muss, wenn Sie jedoch darauf warten möchten, dass andere Promise-Objekte betriebsbereit werden.
Eine Überladung, bei der jedes Argument in der ursprünglichen Methode durch einen Promise-Wrapper ersetzt wird und zusätzliche variable Argumente des Typs Promise<?> Der Rückgabetyp dieser Überladung ist Promise<T>, wobei T der Rückgabetyp der ursprünglichen Methode ist. Zum Beispiel:

Ursprüngliche Methode:
```
void activity2(int foo);
```
Generierte Methode:
```
Promise<Void> activity2(
  Promise<Integer> foo,
  Promise<?>... waitFor);
```
Diese Überladung sollte verwendet werden, wenn auf alle Argumente der Aktivität asynchron gewartet wird und wenn Sie darauf warten möchten, dass andere Promises betriebsbereit werden. Ein Aufruf dieser Methodenüberladung wird asynchron ausgeführt, wenn alle weitergeleiteten Promise-Objekte,betriebsbereit sind.

Der generierte Aktivitäts-Client verfügt auch über eine geschützte Methode, die jeder Aktivitätsmethode entspricht und den Namen {activity method name}Impl(), hat den alle Aktivitäts-Überladungen aufrufen. Sie können diese Methode überschreiben, um eine Demo-Clientimplementierung fertigzustellen. Diese Methode nimmt als Argumente an: alle Argumente der ursprünglichen Methode in Promise<>-Wrappers, ActivitySchedulingOptions und variable Argumente des Typs Promise<?>. Zum Beispiel:

Ursprüngliche Methode:


void activity2(int foo);

Generierte Methode:


Promise<Void> activity2Impl(
   Promise<Integer> foo,
   ActivitySchedulingOptions optionsOverride,
   Promise<?>...waitFor);

Planungsoptionen

Der generierte Aktivitäts-Client ermöglicht Ihnen, ActivitySchedulingOptions als Argument weiterzuleiten. Die ActivitySchedulingOptions Struktur enthält Einstellungen, die die Konfiguration der Aktivitätsaufgabe bestimmen, die das Framework in Amazon SWF plant. Diese Einstellungen überschreiben die Standardeinstellungen, die als Registrierungsoptionen festgelegt sind. Um Planungsoptionen dynamisch festzulegen, legen Sie ein ActivitySchedulingOptions-Objekt nach Ihren Wünschen an und übergeben es an die Aktivitätsmethode. Im folgenden Beispiel haben wir eine Aufgabe festgelegt, die für die Aktivitätsaufgabe verwendet werden soll. Sie überschreibt die registrierte Aufgabenliste für diesen Aktivitätsaufruf.


public class OrderProcessingWorkflowImpl implements OrderProcessingWorkflow {

    OrderProcessingActivitiesClient activitiesClient
            = new OrderProcessingActivitiesClientImpl();

    // Workflow entry point
    @Override
    public void processOrder(Order order) {
        Promise<Void> paymentProcessed = activitiesClient.processPayment(order);
        ActivitySchedulingOptions schedulingOptions
             = new ActivitySchedulingOptions();
        if (order.getLocation() == "Japan") {
            schedulingOptions.setTaskList("TasklistAsia");
        } else {
            schedulingOptions.setTaskList("TasklistNorthAmerica");
        }

        activitiesClient.shipOrder(order,
                                   schedulingOptions,
                                   paymentProcessed);
    }
}

Dynamische Clients

Zusätzlich zu den generierten Clients bietet das Framework auch Allzweck-Clients — DynamicWorkflowClient und DynamicActivityClient —, die Sie verwenden können, um Workflow-Ausführungen dynamisch zu starten, Signale zu senden, Aktivitäten zu planen usw. So möchten Sie z. B. eine Aktivität planen, deren Typ beim Design nicht bekannt war. Sie können DynamicActivityClient zur Planung einer solchen Aktivitätsaufgabe verwenden. Ebenso können Sie eine untergeordnete Workflow-Ausführung dynamisch planen, indem Sie DynamicWorkflowClient verwenden. Im folgenden Beispiel schlägt der Workflow die Aktivität von einer Datenbank aus nach und verwendet zur Planung den Client für dynamische Aktivität:


//Workflow entrypoint
@Override
public void start() {
   MyActivitiesClient client = new MyActivitiesClientImpl();
  Promise<ActivityType> activityType
      = client.lookUpActivityFromDB();
  Promise<String> input = client.getInput(activityType);
  scheduleDynamicActivity(activityType,
                          input);
}
@Asynchronous
void scheduleDynamicActivity(Promise<ActivityType> type,
                             Promise<String> input){
  Promise<?>[] args = new Promise<?>[1];
   args[0] = input;
   DynamicActivitiesClient activityClient
       = new DynamicActivitiesClientImpl();
   activityClient.scheduleActivity(type.get(),
                                   args,
                                   null,
                                   Void.class);
}

Weitere Einzelheiten finden Sie in der AWS SDK für Java Dokumentation.

Signalisieren und Abbrechen von Workflow-Ausführungen

Der generierte Workflow-Client verfügt über Methoden, die jedem Signal entsprechen, das an den Workflow gesendet werden kann. Sie können diese aus einem Workflow heraus verwenden, um Signale an andere Workflow-Ausführungen zu senden. Dadurch wird ein typisierter Mechanismus zum Senden von Signalen bereitgestellt. Manchmal müssen Sie den Signalnamen jedoch möglicherweise dynamisch bestimmen, z. B. wenn der Signalname in einer Nachricht empfangen wird. Sie können den dynamischen Workflow-Client verwenden, um dynamisch Signale an eine beliebige Workflow-Ausführung zu senden. Auf ähnliche Weise können Sie den Client verwenden, um einen Abbruch einer anderen Workflow-Ausführung anzufordern.

Im folgenden Beispiel schlägt der Workflow die Ausführung zum Senden eines Signals von einer Datenbank aus nach und sendet das Signal dynamisch, wobei er den dynamischen Workflow-Client verwendet.


//Workflow entrypoint
public void start()
{
  MyActivitiesClient client = new MyActivitiesClientImpl();
  Promise<WorkflowExecution> execution = client.lookUpExecutionInDB();
  Promise<String> signalName = client.getSignalToSend();
  Promise<String> input = client.getInput(signalName);
  sendDynamicSignal(execution, signalName, input);
}

@Asynchronous
void sendDynamicSignal(
   Promise<WorkflowExecution> execution,
   Promise<String> signalName,
   Promise<String> input)
{
   DynamicWorkflowClient workflowClient
      = new DynamicWorkflowClientImpl(execution.get());
   Object[] args = new Promise<?>[1];
   args[0] = input.get();
   workflowClient.signalWorkflowExecution(signalName.get(), args);
}

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Registrierung von Workflow- und Aktivitätstypen

Workflow-Implementierung