J'ai besoin de construire une application de flux de travail dynamique dans .net qui permettra essentiellement de créer, surveiller, mettre en pause, redémarrer, persister et mettre à jour dynamiquement un flux de travail. Chaque nœud du workflow est une tâche informatique exigeante qui peut prendre plusieurs heures et les workflows se composent d'au moins 20 nœuds. Pour l'instant, il semble que la meilleure solution est d'utiliser WF4 mais en regardant autour de moi j'ai trouvé une programmation basée sur des agents en F #, Orléans ou Akka.NET très attrayante pour implémenter une solution de workflow et contrairement à WF4 n'est pas tellement plomberie à apprendre. Est-ce une bonne idée de démarrer une solution avec une programmation basée sur un agent ou devrais-je rester avec WF4?meilleure façon de construire une application de workflow dans .net
Répondre
<edit>
Pour répondre à votre question sur la construction d'un modèle à base d'agents, qui est la meilleure approche à mon avis. Cela facilite le débogage et la maintenance, tout en séparant le "pilote" de l'ensemble de l'opération (c'est-à-dire que vous pouvez remplacer WF et le remplacer par un autre appareil).
</edit>
WF4 peut être utilisé pour la conduite de votre logique d'affaires de longue durée. La meilleure approche que j'ai utilisée est un flux de travail qui lance simplement des "processus d'agent", et pendant que l'agent fonctionne, l'instance WF hiberne attendant d'être éveillée par un agent.
En un mot, quelque chose comme cette approche:
- ont un processus « d'orchestration » qui est en charge de démarrer de nouveaux processus et des flux de travail hydratantes persisté.
- Et d'avoir un "agent" processus (ou processus) qui exécutent réellement vos tâches de longue durée.
Le processus Orchestration
Ce processus est en charge de démarrage d'une nouvelle instance de workflow. Votre flux de travail démarrerait simplement un processus d'agent pour effectuer le travail réel. L'instance de workflow est alors mise en veille prolongée.
Ce processus attendrait également les demandes de reprise des instances de flux de travail mises en veille prolongée. En substance, une instance de workflow ne serait "en cours d'exécution" que pour quelques instants, et déléguerait le travail réel à d'autres threads/processus.
Une façon de mettre en œuvre le processus d'orchestration est un service Web. Cela facilite le rappel d'un processus d'agent pour réveiller une instance de workflow endormie lorsque l'agent est terminé.
Le processus Agent
Ce processus aura le savoir-faire réel l'exécution des travaux. Lorsqu'il est appelé par le processus d'orchestration, certaines informations lui sont données pour connaître le contexte (c'est-à-dire les objets métier) sur lequel il doit s'exécuter. Quand il se termine, l'agent informe le processus d'orchestration qu'il a terminé.
Retour au processus de Orchestration
Lorsqu'un agent termine sa tâche, il fait un rappel au processus d'orchestration que le contexte est prêt à passer à l'élément suivant dans le flux. Le processus d'orchestration permettrait alors d'hydrater le flux de travail de ce contexte et de le reprendre. Le flux de travail peut décider qu'une autre tâche de longue durée est en cours et, par conséquent, lance un autre processus d'agent pour déléguer la tâche, puis hiberner de nouveau l'instance de flux de travail. Et ce cycle continue jusqu'à ce que l'instance de flux de travail atteigne la fin.
La « dynamique » Flux de travail Partie
Je pense que votre référence à la mise à jour d'un flux de travail « déjà en cours », correct? Si oui, WF4.5 a la capacité de le permettre. Je ne l'ai jamais implémenté (encore) mais c'est faisable d'après ce que j'ai lu.
Le concept consiste à ajouter des métadonnées sur la version de votre flux de travail en cours d'exécution. WF prendrait soin de lancer une mise à jour dynamique des activités, que vous avez le contrôle de la coordination.
Merci, je pense que je comprends votre point de vue. Dans mon cas, les noeuds du flux de travail seront pour la plupart des scripts R que je devrai enrouler afin de fournir quelques options. Ensuite, je devrai fournir l'orchestration du workflow. Mon point est que même si WF fournit de très jolies fonctionnalités (persistance et mises à jour dynamiques), il ne semble pas que le développeur soit amical. Alors, est-il préférable d'utiliser WF uniquement pour la partie orchastration ou devrais-je utiliser autre chose comme Akka.Net? – Mario
Il y a une courbe d'apprentissage pour ramasser WF, mais ce n'est pas incroyablement difficile. Le bon côté des choses, c'est que cela fournit beaucoup de choses, ce qui est un énorme avantage. La mise en garde est un peu de recherche de documentation qui est nécessaire pour certains si la fonctionnalité. Il y a beaucoup de blogs à propos de différentes choses à ce sujet, donc c'est un avantage de nos jours. Je dis que si vous pouvez trouver de la documentation sur les fonctionnalités que vous utiliseriez probablement, alors allez-y. – ajawad987
Cette idée d '"orchestration" de @ ajawad987 est l'approche du tueur, elle utilise WF pour sa force: long processus/transaction. Avec lui, vous pouvez éviter la plupart des parties douloureuses (écrire des activités personnalisées, etc). Lorsque la majeure partie de la logique est en dehors du WF (dans les "agents"), vous n'aurez pas besoin de rafraîchir trop souvent le WF, ce n'est que l'épine dorsale du processus de longue durée. La partie semaine est l'évolutivité et le stockage: J'ai créé un projet github pour porter WF à Orléans, où Orléans fournit le stockage, le planificateur et donne de l'évolutivité et de la portabilité. https://github.com/OrleansContrib/Orleans.Activities – lmagyar
ce sont des choses vraiment différentes, je ne suis pas très familier avec WF4 ummm ... Personnellement, je commencerais avec WF4 et "cela pourrait prendre plusieurs heures" ressemble au genre de choses qui vivent dans un monde de workflow, avec tous les cloches et les sifflets de type "long running transatction" – user2088029
Il semble que WF4 ait une opinion divisée: https://stackoverflow.com/questions/104099/when-to-use-windows-workflow-foundation (regardez la deuxième réponse) et https://stackoverflow.com/questions/513657/why-use-windows-workflow – Mario