Question

J'évalue WF pour une utilisation dans les applications métiers en ligne sur le Web et j'aimerais entendre des comptes rendus récents de cette technologie.

Mon principal intérêt est d'améliorer la maintenabilité des projets et peut-être d'accroître la productivité des développeurs lorsque vous travaillez sur des processus complexes qui changent fréquemment.

J'aime beaucoup l’idée de WF, mais elle semble relativement inconnue et de nombreux commentaires plus anciens que j’ai entendu mentionner mentionnent que c’est extrêmement complexe une fois que l’on aborde la question.

S'il est surdimensionné au point d'être inutilisable (ou d'un mauvais compromis) pour un projet de taille petite à moyenne, c'est quelque chose que je dois savoir.

Bien sûr, il est sorti depuis la fin de 2006, alors peut-être a-t-il mûri. Si tel est le cas, c’est un autre élément d’information qui serait très utile!

Merci d'avance!

Était-ce utile?

La solution

Windows Workflow Foundation est un produit très performant, mais toujours dans sa 1ère version: - (

Les principales raisons d'utilisation incluent:

  1. Modélisation visuelle des besoins de l'entreprise.
  2. Séparez votre logique métier des règles commerciales et d'externaliser les règles sous forme de fichiers XML.
  3. Séparez votre flux métier de votre application en externalisant vos flux de travail sous forme de fichiers XML.
  4. Création de processus de longue durée avec la capacité automatique de réagir si rien ne s'est passé pendant une période prolongée. Par exemple, une facture non payée.
  5. Persistance automatique des flux de travail longs pour limiter l'utilisation des ressources et permettre à un processus et / ou à une machine de redémarrer.
  6. Suivi automatique des flux de travail en fonction des besoins de l'entreprise.

WF est fourni en tant que bibliothèque / infrastructure, vous devez donc généralement écrire sur l'hôte qui instancie le moteur d'exécution WF. Cela dit, utiliser WCF hébergé dans IIS est une solution viable et vous épargne beaucoup de travail. Cependant, le couplage WCF / WF n’est pas parfait et nécessite un travail sérieux. Voir ici http : //msmvps.com/blogs/theproblemsolver/archive/2008/08/06/using-a-transactionscopeactivity-with-a-wcf-receiveactivity.aspx pour plus de détails. Attendez-vous à quelques modifications / améliorations dans la prochaine version.

WF (et WCF) jouent un rôle central dans bon nombre des nouveautés issues de Microsoft. Vous pouvez vous attendre à des annonces intéressantes pendant le PDC.

BTW, le maintien de plusieurs versions d’un flux de travail en cours nécessite un peu de travail, mais c’est surtout du standard .NET Je viens de faire une série de billets de blog sur le sujet commençant ici: http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx

À propos de la modélisation visuelle des besoins de l'entreprise. En théorie, cela fonctionne assez bien avec une séparation d'intention et de mise en œuvre. Cependant, dans la pratique, vous allez laisser tomber quelques activités supplémentaires sur un flux de travail uniquement pour des raisons techniques, ce qui va à l’encontre du but recherché: vous devez dire à un analyste métier d’ignorer la moitié des formes et des lignes.

Autres conseils

Question associée: Quand utiliser Windows Workflow Foundation? Ma réponse à cette question :

  

Vous n’avez besoin de WF que si l’un des   ce qui suit est vrai:

     
      
  1. Votre processus est long.
  2.   
  3. Votre processus change fréquemment.
  4.   
  5. Vous voulez un modèle visuel du processus.
  6.   
     

Pour plus de détails, voir Paul Andrew's   post: Pourquoi utiliser Windows Workflow Foundation pour ?

     

S'il vous plaît ne confondez pas ou ne racontez pas WF   avec programmation visuelle de tout genre.   C'est faux et peut conduire à très mauvais   décisions d’architecture / de conception.

Donc, si vous avez de telles exigences, alors WF est un bon candidat. Bien sûr, il est relativement complexe, mais il faut mentionner que les problèmes que l’on essaie de résoudre sont également complexes (et parfois très complexes). À mon humble avis, il est par exemple très complexe de déshydrater / réhydrater des objets auxquels sont associés des gestionnaires d'événements (avec des événements pouvant être déclenchés lorsque l'objet n'est pas en mémoire).

Je ne peux pas juger de ce que vous entendez par "projet de petite à moyenne taille", mais en général, je dirais que si votre projet répond à au moins deux exigences de la liste ci-dessus, vous pouvez considérer WF comme une solution.

Nous avons utilisé WF dans une application SharePoint de grande taille et je peux dire que tout va bien. Il a beaucoup de puissance et de flexibilité. et, comme le mentionne Kevin, une fois que vous maîtrisez les concepts sous-jacents des workflows, vous pouvez faire à peu près tout ce que vous voulez.

D’un autre côté, certains problèmes très graves, tels que le manque de versions, peuvent nuire à votre application à l’avenir. Nous avons été obligés de déployer jusqu'à 3 versions parallèles du même flux de travail, à savoir xxx-v1, xxx-v2 et xxx-v3, pour que les anciennes instances continuent de fonctionner et que les nouvelles instances utilisent les versions mises à jour. Une vraie douleur dans le cul. Oh, et il y a aussi des concepts vraiment non intuitifs (jetons de corrélation, wtf ??)

Nous avions un projet au travail auquel je participais dans l'utilisation de Workflows. L’idée (de la direction) était que nous, programmeurs, écrivions les activités de workflow avec le "moteur". et cadre. Ensuite, les non-programmeurs s’occuperaient de tout le reste en compilant leurs propres flux de travail dans des dll que le moteur chargerait automatiquement.

La gestion a été vendue à cette idée de non-programmeurs utilisant Workflow pour aider à développer des logiciels, et c'était à peu près une perte de temps totale. Le problème que nous essayions de résoudre avec ce projet était relativement complexe et nous savions dès le départ que le logiciel devrait être modifié presque constamment (ses calculs dépendaient d’autres entreprises et des gouvernements).

Le résultat final a été que nous n’avons pas été en mesure de rendre les modules de flux de travail suffisamment génériques pour que quiconque puisse les utiliser. Ce sont donc les programmeurs qui ont été forcés de travailler avec les workflows, et tout ce que les workflows ont fait était de nous en empêcher.

J'utilise Workflow 4.0 depuis quelques mois et, bien que très impressionné, j'ai eu beaucoup de mal à apprendre.

Pour la version la plus récente (fournie avec .NET 4.0 RC), il n’existe pratiquement aucune documentation sur le Web, aucun livre ni aucun cours de formation. Je n'ai trouvé que des articles relatifs à la version 3.0 maintenant disparue. Même la documentation MSDN est légère sur le terrain.

Le concepteur de flux de travail n’est pas aussi intuitif qu’il devrait être, l’apprentissage est donc très difficile. J'ai dû compter sur les réponses d'une seule personne sur StackOverflow (merci, Maurice!) Et je serais bourré sans son aide.

En résumé, je pense que cela a du potentiel, mais vous seriez fou de l’apprendre encore - attendez plus de formation, de documentation et de livres sinon vous y rentrerez aveuglément!

L'année dernière, nous avons mis au point une application opérationnelle avec WF, qui sert désormais de colonne vertébrale à un système incroyablement énorme, utilisé par une très grande banque pour sa procédure de prêt hypothécaire. Le processus pe comporte de nombreuses étapes allant de la demande du client à l’approbation du crédit.

Bien que ce fût un succès, il y avait tellement de problèmes et de crises tout au long du processus. Et cela ne vaut pas la peine pour tout projet de petite taille.

Je considère MS WF comme une bibliothèque de flux de travail de bas niveau plutôt que comme un produit de flux de travail d'entreprise à part entière tel que K2. Il vous permettra de créer une application compatible avec le flux de travail, mais ce n’est pas en soi une application de flux de travail. Mon expérience dans ce domaine a été positive, même si nous avons dû construire beaucoup de notre propre infrastructure autour de celle-ci (un cadre pub / sous, un gestionnaire de la vie dans le monde, etc.). Une grande partie de la documentation est assez simpliste et ne couvre pas la création d’une application de flux de travail d’entreprise basée sur MS WF.

Difficile à apprendre. Assez flexible. Ne pas confondre avec un outil visuel pour les utilisateurs finaux, uniquement pour les programmeurs. Je ne sais pas si j'aime l'approche de la propriété de dépendance.

Cela dépend vraiment de ce que vous voulez en faire. Je ne l'ai que peu utilisé, mais comparé à des produits plus matures comme MetaStorm (techniquement, il s'agit d'un MPM, mais il existe toujours un composant de flux de travail), de flux de travail Process Choriographer et IBM MQ, il n'y a pas de comparaison possible. C'est juste pas assez mature. D'autre part, c'est gratuit là où les autres ne le sont pas et peuvent probablement faire le travail. Je ne sais pas si je placerais une opération de plusieurs millions de dollars dessus, mais avec les plus petites, je lui donnerais un autre coup. Le véritable obstacle auquel vous allez faire face est le changement de processus de pensée qu’il nécessite. Si vous n'avez pas de développeurs qui ont déjà travaillé avec des systèmes d'état, cela peut être un véritable obstacle.

Brian, je ne peux pas répondre à votre commentaire, mais de toute façon, par version, je veux dire apporter des modifications au code sous-jacent du flux de travail sans interrompre les instances déjà en cours d'exécution, ni appliquer sans problème les mises à jour des flux de travail existants. Je ne suis pas sûr de la WF «standard», mais au moins, dans l'environnement SharePoint, il n'existe aucun concept de version de flux de travail. Les nouvelles versions doivent donc être déployées sous forme de flux de travail complètement différents, ce qui devient un cauchemar pour la maintenance. Cela n'a rien à voir avec la "réhydratation", la réhydratation est le processus par lequel vous ramenez un flux de travail "en sommeil" après une situation ou un changement d'état. Cela est géré de manière transparente par le runtime de workflow.

WF est intégré à SharePoint (WSS 3.0) et j'ai créé pas mal de flux de travail pour divers sites Web SharePoint. Je peux donc parler de mon expérience de WF dans SharePoint. Comparé à d'autres cadres de workflow, WF se distingue bien. C’est stable (je n’ai connu aucune erreur mystérieuse), les flux de travail sont assez faciles à concevoir (grâce au concepteur de flux de travail de Visual Studio) et vous pouvez utiliser des flux de travail non seulement séquentiels, mais aussi des machines à état.

Ce n'est pas parfait, bien sûr, et un développeur aura certainement besoin d'un peu de temps pour comprendre le concept (à savoir, le modèle d'activité); mais il est définitivement utilisable, même pour de "petites tâches".

Je n'ai jamais essayé WFF, mais je me souviens d'avoir lu cet article sur WFF de Leon Bambrick . où il dit fondamentalement que tout le genre des outils de développement logiciel est un non-sens. Peut-être vous aider à décider d'une manière ou d'une autre.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top