Portée et visibilité de la définition de l'activité
La portée et la visibilité de la définition d'une activité, tout comme la portée et la visibilité d'un objet représentent la capacité d'autres objets d'accéder aux membres de l'activité. La définition de l'activité est assurée par les implémentations suivantes :
Détermination des membres (objets Argument, Variable et ActivityDelegate, et activités enfants) qu'une activité expose aux utilisateurs.
Implémentation de la logique d'exécution de l'activité
L'implémentation peut impliquer des membres qui ne sont pas exposés aux consommateurs de l'activité, mais qui sont des détails de l'implémentation. Semblalble à la définition de type, le modèle d'activité permet à un auteur de qualifier la visibilité d'un membre d'activité concernant la définition de l'activité définie. La visibilité définit les aspects de l'utilisation de membre, notamment la portée des données.
Étendue
Outre la portée des données, la visibilité du modèle d’activité peut limiter l’accès à d’autres aspects de l’activité, tels que la validation, le débogage, le suivi ou le traçage. Les propriétés d'exécution utilisent la visibilité et la portée pour contraindre les caractéristiques d'exécution à une portée spécifique de définition. Les racines secondaires utilisent la visibilité et la portée pour contraindre l'état capturé par un CompensableActivity à la portée de la définition dans laquelle les activités compensables sont utilisées.
Définition et utilisation
Un workflow est écrit en créant de nouvelles activités, en héritant de classes d’activité de base et en utilisant des activités de la Bibliothèque d’activités intégrée. Pour utiliser une activité, l'auteur de l'activité doit configurer la visibilité de chaque composant de sa définition.
Membres d'activité
Le modèle d’activité définit les arguments, les variables, les délégués et les activités enfants que l’activité rend disponible aux consommateurs. Chacun de ces membres peut être déclaré public ou private. Les membres publics sont configurés par le consommateur de l'activité, alors que les membres private utilisent une implémentation corrigée par l'auteur de l'activité. Les règles de visibilité applicables à la portée des données sont les suivantes :
Les membres publics et les membres publics d'activités enfants publiques peuvent référencer des variables publiques.
Les membres privés et les membres publics d'activités enfants publiques peuvent référencer des arguments et des variables privées.
Un membre pouvant être défini par le consommateur d'une activité ne doit jamais être rendu privé.
Création de modèles
Les activités personnalisées sont définies à l'aide de NativeActivity, Activity, CodeActivity ou AsyncCodeActivity. Les activités dérivées de ces classes peuvent exposer des types de membres différents avec différentes visibilités.
NativeActivity
Les activités dérivant de NativeActivity ont un comportement qui est écrit dans le code impératif, et peuvent éventuellement être définies à l'aide d'activités existantes. La dérivation des activités de NativeActivity accorde l’accès à l’ensemble des fonctionnalités exposées par le runtime. Tout membre d'une telle activité peut être défini à l'aide de la visibilité publique ou privée, à l'exception des arguments, qui peuvent uniquement être déclarés public.
Les membres de classes dérivées de NativeActivity sont déclarés au runtime à l'aide du struct NativeActivityMetadata passé à la méthode CacheMetadata.
Activité
Les activités créées à l'aide de Activity ont un comportement qui est conçu strictement via la composition d'autres activités. La classe Activity a une implémentation de l'activité enfant, obtenue par le runtime à l'aide de Implementation. Une activité dérivant de Activity peut définir des arguments publics, des variables publiques, des ActivityDelegates et des activités importés.
Les ActivityDelegates et les activités importés sont déclarés en tant qu'enfants publics de l'activité, mais ne peuvent pas être planifiés directement par l'activité. Ces informations sont utilisées lors de la validation pour éviter d'exécuter des validations de parents dans des emplacements où l'activité ne sera jamais exécutée. Les enfants importés, comme les enfants publics, peuvent être référencés et planifiés par l'implémentation de l'activité. Cela signifie qu'une activité qui importe une activité nommée Activity1 peut contenir un Sequence dans son implémentation qui planifie Activity1.
CodeActivity/AsyncCodeActivity
Cette classe de base est utilisée pour la création de comportement en code impératif. Les activités qui dérivent de cette classe ont uniquement accès aux arguments qu’elles exposent. En d’autres termes, seuls les membres pouvant être exposés par ces activités sont des arguments publics. Aucun autre membre ou visibilité ne s'applique à ces activités.
Résumé des visibilités
Le tableau suivant récapitule les informations de cette rubrique.
| Type de membre | NativeActivity | Activité | CodeActivity/AsyncCodeActivity |
|---|---|---|---|
| Arguments | Public/ Private | Public | Non applicable |
| Variables | Public/ Private | Public | Non applicable |
| Activités enfants | Public/ Private | Public, un enfant privé corrigé défini dans l'implémentation. | Non applicable |
| ActivityDelegates | Public/ Private | Public | Non applicable |
En général, un membre ne pouvant pas être défini par le consomamteur d'une activité ne doit jamais être rendu public.
Propriétés d'exécution
Dans certains scénarios, il s'avère utile de définir la portée d'une propriété d'exécution spécifique aux enfants publics d'une activité. La collection ExecutionProperties offre cette possibilité avec la méthode Add. Cette méthode a un paramètre Boolean indiquant si la portée d'une propriété spécifique est tous les enfants ou uniquement ceux qui sont publics. Si ce paramètre a la valeur true, la propriété sera uniquement visible aux membres publics de leurs enfants publics.
Racines secondaires
Une racine secondaire correspond au mécanisme interne de gestion de l'état des activités de compensation. Lorsque l'exécution d'un CompensableActivity est terminée, son état n'est pas nettoyé immédiatement. L'état est conservé par le runtime dans une racine secondaire jusqu'à ce que l'épisode de compensation soit terminé. Les environnements d'emplacement capturés avec la racine secondaire correspondent à la portée de la définition dans laquelle l'activité Compensable est utilisée.
