locked
Accès aux variables d'un workflow ? RRS feed

  • Question

  • Bonjour,

    question idiote, mais je ne trouve la solution nulle part...

    Comment fait-on, à partir de l'application hôte, pour accéder aux variables (propriétés) d'une instance de workflow et éventuellement pour les modifier ?

    La définition de instance.GetWorkflowDefinition().UserData n'est pas très claire et je n'ai pas l'impression que ce soit la solution...

    Faut-il utiliser le service de Tracking ? ou autre chose ?

    Merci d'avance !

    Etienne
    lundi 23 février 2009 10:52

Réponses

  • Si j'ai bien compris ta question, tu as un host qui cherche juste à atteindre des propriétés spécifiques de ton workflow ?

    1) pour commencer, il faut que ton workflow expose effectvement ces propriétés. Exemple:
    namespace WorkflowLibrary1
    {
        public sealed partial class Workflow1 : SequentialWorkflowActivity
        {
            public Workflow1()
            {
                InitializeComponent();
            }

            public string UnePropriete { get; set; }

        }

    }

    Tu trouveras toujours moyen d'exposer ainsi ce que tu veux. Au besoin, ta propriété ne servira que de "façade" pour aller chercher des informations au plus profond des activités de ton workflow ...

    2) Ensuite, il te suffit de récupérer ton instance de workflow depuis ton host:

                    WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof(WorkflowLibrary1.Workflow1));
                    instance.Start();

                    WorkflowLibrary1.Workflow1 wf = (WorkflowLibrary1.Workflow1) instance.GetWorkflowDefinition();
                    wf.UnePropriete = "exemple";


    Evidemment, mon exemple est un peu trivial et l'endroit pas trés approprié pour lire mes propriétés mais le principe est là !







    Xavier
    • Marqué comme réponse Etienne J mardi 16 juin 2009 11:49
    mardi 16 juin 2009 09:58

Toutes les réponses

  • J'imagine que ta question porte surtout sur comment y accéder lorsque le workflow est dans un état Hidden ? Je m'étais posé les mêmes questions et la réponse est effectivement dans le service de Tracking et les User Trackpoint. Evidemment lorsque l'instance est active, le host n'a aucune difficulté pour accéder aux propriétés exposées pas le workflow mais une fois persisté, c'est une autre paire de manches ...
    Tu peux regarder cet article MSDN sur le sujet. Je te conseille aussi les samples du SDK car il y a un outil interactif qui permet des paramétrer le tracking et il est trés intéressant !

    Xavier
    vendredi 22 mai 2009 14:10
  • OK, merci de ta réponse, j'irai jeter un oeil par là... Même si je ne travaille plus (pour le moment) sur ce projet !
    Etienne
    vendredi 22 mai 2009 17:27
  • Salut !

    Je suis allé jeter un œil sur le lien que tu m'as donné. En fait, sans même parler de persistance (pour l'instant tout du moins), je souhaiterais juste accéder aux variables liées à un workflow donné (par son instanceId). les seules variables qui m'intéressent sont les variables utilisateur (celles déclarées dans le projet de workflow en lui-même).
    Pour résumer, je veux lire / affecter le contenu des variables utilisateur d'un workflow à partir de l'host. Très concrétement, un workflow dans mon cas correspond à un processus de validation d'un document : On trouve donc des variables comme l'utilisateur qui a créé le document, celui qui l'a validé le cas échéant, le statut courant d'un document...
    Toutes ces variables n'apparaissent hélas pas par l'intermédiaire du service de tracking, qui ne présente que les variables "système".

    Merci de m'éclairer !

    Etienne
    Etienne
    mardi 16 juin 2009 08:51
  • Si j'ai bien compris ta question, tu as un host qui cherche juste à atteindre des propriétés spécifiques de ton workflow ?

    1) pour commencer, il faut que ton workflow expose effectvement ces propriétés. Exemple:
    namespace WorkflowLibrary1
    {
        public sealed partial class Workflow1 : SequentialWorkflowActivity
        {
            public Workflow1()
            {
                InitializeComponent();
            }

            public string UnePropriete { get; set; }

        }

    }

    Tu trouveras toujours moyen d'exposer ainsi ce que tu veux. Au besoin, ta propriété ne servira que de "façade" pour aller chercher des informations au plus profond des activités de ton workflow ...

    2) Ensuite, il te suffit de récupérer ton instance de workflow depuis ton host:

                    WorkflowInstance instance = workflowRuntime.CreateWorkflow(typeof(WorkflowLibrary1.Workflow1));
                    instance.Start();

                    WorkflowLibrary1.Workflow1 wf = (WorkflowLibrary1.Workflow1) instance.GetWorkflowDefinition();
                    wf.UnePropriete = "exemple";


    Evidemment, mon exemple est un peu trivial et l'endroit pas trés approprié pour lire mes propriétés mais le principe est là !







    Xavier
    • Marqué comme réponse Etienne J mardi 16 juin 2009 11:49
    mardi 16 juin 2009 09:58
  • Parfait, c'est exactement ce que j'attendais !

    Merci beaucoup !

    Bonne journée,
    Etienne
    mardi 16 juin 2009 11:21
  • Autre problème :

    Dans ma logique applicative, chaque instance de workflow est associée à un document et à une entreprise (IDs).
    Je souhaiterais être en mesure, pour chaque couple document/entreprise, de récupérer l'ID du workflow qui est associé, de façon à pouvoir le relancer au besoin.

    La persistance sous Workflow Foundation est mise en place (exécution des deux scripts qui vont bien), et le déchargement fonctionne apparemment (table InstanceState remplie).
    J'ai également lancé les scripts concernant le tracking.

    Mon problème est le suivant :
    Où sont enregistrées les instances de workflows sérialisées dans ces tables ? Comment désérialiser tout ça et faire le lien entre un ID d'instance de workflow et les deux clés citées plus haut (qui sont donc des variables utilisateur du workflow) ??

    Merci beaucoup.
    Etienne
    mardi 16 juin 2009 15:09
  • C'est là où ma 1ère réponse s'applique :)

    La solution "qui ne réinvente pas la roue":
    1) c'est d'exposer les valeurs document/entreprise en tant que propriété du workflow.
    2) c'est d'enregistrer ces propriétés avec le service de tracking. Evidemment, il faut aussi un service de persistance.
    3) Une fois l'instance de workflow persistée, l'idée c'est d'interroger la base de tracking pour retrouver par le biais des valeurs document/entreprise l'instance de workflow qu'il est nécessaire de redémarrer.

    L'étape 1) est facile. La 2) est un peu plus compliquée car l'idéal est d'utiliser un TrackingProfile et ce n'est pas trivial ! Heureusement, il y a dans le Windows SDK une application incroyablement utile qui permet de créer de manière interactive un tel TrackingProfile : on se demande presque pourquoi ça ne fait pas partie des outils de base de VS ?! La fin est plus simple et tu as aussi dans le SDK un exemple ...

    La bonne nouvelle, c'est qu'en fouillant un peu, j'ai trouvé cet article qui résume à peu prés tout ...
     


    Xavier
    mercredi 17 juin 2009 15:45
  • Merci pour cette aide précieuse !

    Je vais regarder tout ça demain et je te tiens au courant de l'avancement !

    Bonne soirée.


    Etienne
    mercredi 17 juin 2009 18:01
  • Alors :

    Pour le 1) :
    Pas de souci, les deux IDs sont bien présents dans les propriétés du workflow. De ce côté là, pas de souci.

    2)
    Je ne comprend pas grand chose à toutes ces tables...Autant la gestion de la persistance est relativement simple avec les outils de base, autant pour le tracking c'est vraiment pas limpide. Il y a beaucoup de choses que je ne comprend pas. Très concrètement :
    - J'ai tendance à m'embrouiller avec leurs innombrables tables, dont je ne saisis pas l'utilité des 3/4. J'ai le sentiment d'avoir sous la main une usine à gaz et je me mélange les pinceaux avec tous leurs concepts (j'ai jeté un oeil à ton article mais ça reste obcure pour moi)... ActivityTrackingRecord, TrackingProfile, UserTrackPoint etc... J'ai regardé aussi ici : http://blogs.coforcert.com/dlarticles/WF-TrackingService.pdf, mais je ne capte pas les concepts fondamentaux, la façon dont les briques s'assemblent, donc le code ne me parle pas... Si tu as d'autres articles encore plus simples (difficile...), je suis preneur.
    - Quelles sont les tables VRAIMENT utiles pour le tracking et pour ce que je veux faire ?
    - Comment contrôler les données qui sont "trackables", et comment gérer leur enregistrement en base ?

    J'ai testé le sample du SDK (TrackingProfileDesigner), mais le workflow ne s'affiche déjà pas correctement, à partir de sa DLL (seule la structure est bien là, les boucles...).

    3) Je suis en train de regarder tout ça...

    Ce qu'il faudrait que je fasse en priorité, c'est d'afficher dans une datagrid tous les workflows, qu'ils soient persistés ou en mémoire, avec ID, état, état de validation, ID du test, ID de l'entreprise, créateur, bref à peu près toutes les propriétés.

    Tout cela se fait par des datasets mais ça n'est pas un problème. Reste à remplir les lignes...

    Merci de ton aide.
    Etienne
    jeudi 18 juin 2009 13:25
  • Personne n'aurait un sample, simplifié à l'extrême et bien commenté, pour récupérer les propriétés d'un workflow persisté, par l'intermédiaire d'un Tracking Profile ?
    Tout ça est bien compliqué...

    Par exemple, j'ai un workflow persisté. Les services de persistance / tracking sont en place. J'ai certaines variables du workflow que je veux récupérer (TestId, CompanyId...) :

    - Comment créer de façon simple un TrackingProfile pour répondre à cette problématique (les samples trouvés sur le Net en font beaucoup trop, j'ai l'impression... Je ne veux que récupérer des valeurs de propriétés persistées)
    - Faut-il utiliser, dans le workflow, la fonction TrackData() pour indiquer quelles propriétés sont récupérables par l'hôte ?
    - Comment, une fois tous les mécanismes mis en place, récupère-t-on les propriétés du WF ?

    Merci.
    Etienne
    lundi 29 juin 2009 14:52