Je cherche un peu de clarté en ce qui concerne l'utilisation de Windows Workflow 4 dans une solution intégrée - en particulier en ce qui concerne réhébergement le concepteur et l'exécution des flux de travail créé par eg. un utilisateur professionnel.réhébergement le concepteur WF4 - comment enregistrer et exécuter des flux de travail créés par le concepteur réhébergé
L'intention est que les activités personnalisées requises soient créées et compilées dans une DLL, qui est ensuite déployée avec le concepteur réhébergé, permettant à l'utilisateur métier de créer/configurer des workflows qui utilisent ces activités. enregistrer le workflow en tant que XAML, qui peut être stocké dans un emplacement connu de l'application (base de données, système de fichiers, etc.), puis, lorsque l'application exécute un workflow, il peut utiliser XamlServices.Load pour charger le workflow l'emplacement spécifique et l'exécuter en tant que DynamicActivity?
Comment le flux de travail sauvegardé afin qu'il puisse plus tard être reserialized avec des propriétés et d'autres valeurs de configuration? J'ai essayé de désérialiser un fichier Xaml enregistré hors du concepteur, et aussi en utilisant XamlServices.save().
Y at-il des problèmes potentiels ici à l'utilisation des signets/persistance?
Comme une question connexe, est-il un moyen facile de « Retour » dans un flux de travail, sans définir les branches de retour sur chaque élément organigramme? Je cherche à intégrer un flux de travail avec une interface utilisateur pour permettre à un utilisateur de saisir des réponses, que le WF va traiter, et prendre des décisions en fonction de l'entrée. Grâce à l'interface utilisateur, l'utilisateur devrait être en mesure de «revenir» à une entrée précédente.
Merci Maurice, je l'ai suivi vos messages depuis assez près WF4 Beta 1, et vous fournir beaucoup d'indications utiles et des conseils - en particulier avec la quantité d'orientation « officielle » étant limité à ce stade. À la suite de votre exemple, j'ai actuellement un exemple fonctionnel en cours d'exécution, et je peux éditer dans le concepteur réhosté, et exécuter en utilisant un hôte séparé. Diriez-vous qu'il est recommandé que les flux de travail restent relativement autonomes et communiquent avec d'autres domaines d'applications en utilisant la messagerie/WCF? (c'est-à-dire, n'utilisant pas InvokeMethod directement sur un autre ensemble d'applications)? AppFabric semble l'impliquer. – hitch
Je ne sais pas si c'est toujours la meilleure approche, en fait j'en doute, mais MS semble nous pousser de cette façon. L'utilisation de WorkflowServiceHost nous donne le meilleur rapport qualité-prix, en particulier lorsqu'il s'agit de workflows de longue durée. Et d'après ce que j'ai lu sur AppFabrik WCF est le chemin à parcourir. Maintenant, je pense qu'il y a certainement une place pour d'autres trucs de communication/hébergement là-bas, donc ne rejetez pas WorkflowApplication et les signets d'un coup de main. – Maurice
Dans mon cas mon workflow.xaml réside dans le serveur et ne peut accéder que via le service WCF. Tous les échantillons disponibles qui réhébergent le workflow dans le concepteur de flux de travail en lisant à partir de la base de données ou de la WCF? –