Contrats de flux de travail et d'activité

Les interfaces Java sont utilisées pour déclarer les signatures des flux de travail et activités. L'interface forme le contrat entre l'implémentation de flux de travail (ou activité) et le client de ce flux de travail (ou activité). Par exemple, un type de flux de travail MyWorkflow est défini à l'aide d'une interface annotée avec @Workflow :

@Workflow
@WorkflowRegistrationOptions(
   defaultExecutionStartToCloseTimeoutSeconds = 60,
   defaultTaskStartToCloseTimeoutSeconds = 10)
public interface MyWorkflow
{
    @Execute(version = "1.0")
    void startMyWF(int a, String b);

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

    @GetState
    MyWorkflowState getState();
}

Le contrat ne possède aucun paramètre propre à l'implémentation. Cette utilisation des contrats à implémentation neutre permet aux clients d'être découplés de l'implémentation et donc fournit la flexibilité pour modifier les détails d'implémentation sans casser le client. À l'inverse, vous pouvez également modifier le client sans modifier le flux de travail ou l'activité en cours d'utilisation. Par exemple, le client peut être modifié pour appeler une activité de manière asynchrone à l'aide d'objets Promises (Promise<T>) sans que l'implémentation d'activité ait besoin d'être modifiée. De même, l'implémentation d'activité peut être modifiée afin d'être terminée de manière asynchrone : par exemple, par une personne qui envoie un e-mailsans que les clients de l'activité ne soient modifiés.

Dans l'exemple ci-dessus, l'interface de flux de travail MyWorkflow contient une méthode, startMyWF, pour lancer une nouvelle exécution. Cette méthode est annotée avec @Execute et doit posséder un type de retour void ou Promise<>. Dans une interface de flux de travail donnée, une méthode maximum peut être annotée avec cette annotation. Cette méthode constitue le point d'entrée de la logique de flux de travail, et l'infrastructure appelle cette méthode pour exécuter la logique de flux de travail lorsqu'une tâche de décision est reçue.

L'interface de flux de travail définit également les signaux qui peuvent être envoyés au flux de travail. La méthode de signal est appelée lorsqu'un signal avec un nom correspondant est reçu par l'exécution de flux de travail. Par exemple, l'interface MyWorkflow déclare une méthode de signal, signal1, annotée avec @Signal.

L'annotation @Signal est requise sur les méthodes de signal. Le type de retour d'une méthode de signal doit être void. Une interface de flux de travail peut comporter zéro ou plusieurs méthodes de signal définies. Vous pouvez déclarer une interface de flux de travail sans une méthode @Execute et certaines méthodes @Signal pour générer des clients qui ne peuvent pas lancer leur exécution mais qui peuvent envoyer des signaux pour lancer des exécutions.

Les méthodes annotées avec @Execute et @Signal peuvent disposer d'un nombre de paramètres de tout type autre que Promise<T> ou ses dérivés. Cela vous permet de transmettre des entrées fortement typées à une exécution de flux de travail au lancement et pendant l'exécution. Le type de retour de la méthode @Execute doit être void ou Promise<>.

De plus, vous pouvez également déclarer une méthode dans l'interface de flux de travail pour signaler le dernier état d'une exécution de flux de travail, par exemple, la méthode getState de l'exemple précédent. Cet état ne représente pas l'état entier de l'application du flux de travail. L'utilisation souhaitée de cette fonction est de vous permettre de stocker jusqu'à 32 Ko de données pour indiquer le dernier état de l'exécution. Par exemple, dans un flux de travail de traitement des commandes, vous pouvez stocker une chaîne qui indique que la commande a été reçue, traitée ou annulée. Cette méthode est appelée par l'infrastructure chaque fois qu'une tâche de décision est terminée pour obtenir le dernier état. L'état est stocké dans Amazon Simple Workflow Service (Amazon SWF) et peut être récupéré à l'aide du client externe généré. Cela vous permet de vérifier le dernier état d'une exécution de flux de travail. Les méthodes annotées avec @GetState ne doivent pas prendre n'importe quel argument et ne doivent pas disposer d'un type de retour void. À partir de cette méthode, vous pouvez renvoyer n'importe quel type correspondant à vos besoins. Dans l'exemple ci-dessus, un objet MyWorkflowState (consultez la définition ci-dessous) est renvoyé par la méthode utilisée pour stocker une chaîne correspondant à l'état et un pourcentage numérique d'exécution. La méthode est censée effectuer un accès en lecture seule de l'objet d'implémentation de flux de travail et est appelée de manière synchrone, ce qui n'autorise pas l'utilisation de toute opération asynchrone comme l'appel de méthodes annotées avec @Asynchronous. Une méthode maximum dans une interface de flux de travail peut être annotée avec @GetState.

public class MyWorkflowState {
   public String status;
   public int percentComplete;
}

De même, un ensemble d'activités est défini à l'aide d'une interface annotée avec @Activities. Chaque méthode de l'interface correspond à une activitépar exemple :

@Activities(version = "1.0")
@ActivityRegistrationOptions(
     defaultTaskScheduleToStartTimeoutSeconds = 300,
     defaultTaskStartToCloseTimeoutSeconds = 3600)
public interface MyActivities {
    // Overrides values from annotation found on the interface
    @ActivityRegistrationOptions(description = "This is a sample activity",
         defaultTaskScheduleToStartTimeoutSeconds = 100,
         defaultTaskStartToCloseTimeoutSeconds = 60)
    int activity1();

    void activity2(int a);
}

L'interface vous permet de regrouper un ensemble d'activités associées. Vous pouvez définir n'importe quel nombre d'activités dans une interface d'activité, et autant d'interfaces d'activité que vous le souhaitez. De même que pour les méthodes @Execute et @Signal, les méthodes d'activité peuvent prendre n'importe quel nombre d'arguments de tout type autre que Promise<T> ou ses dérivés. Le type de retour d'une activité ne doit pas être Promise<T> ou ses dérivés.