Workflow Workflow ou non ?

Question

Je suis responsable d'une équipe de développeurs qui sont sur le point de commencer le développement d'un poids léger système de réclamations d'assurance. Le système implique beaucoup de tâches manuelles et les flux d'affaires et nous sommes à la recherche à l'aide de Windows Workflow.NET 4.0).

Un exemple de domaine d'activité est la suivante: Le détenteur d'une police d'appels le centre de contact pour faire une réclamation. Cet "événement" les feux de deux sous-tâches qui sont manuellement été traitées en parallèle et peut prendre un long moment pour se terminer;

1. De vérifier la clientèle pour la fraude – Un manuel processus par lequel un opérateur sur diverses sociétés de crédit de vérifier et d'évaluer les possibilités de fraude à la clientèle. De là, la sous-tâche peut saisir un numéro de sous-statuts (à Vérifier en cours, Échec de la Vérification des références, Passé à la Vérification des références, etc)
2. Envoyez l'article à des réparations au centre de processus manuel dans lequel l'élément pour lequel le titulaire de la police a déposé la demande est envoyée au centre de réparations pour être fixé. De là, la sous-tâche peut saisir un numéro de sous-statuts (en Attente de Réparation, Dans le Progrès, la réparation, Posté, etc). La demande ne peut se faire qu'une fois le statut de chaque sous-tâche a atteint un état prédéfini (basé sur les règles de gestion).

Sur la surface, il semble que le Flux de travail est en effet le meilleur choix de la technologie; cependant, j'ai quelques inquiétudes à l'aide de WF 4.0.

1. Compétences – en Regardant le développeur moyen un ensemble de compétences, je ne vois pas beaucoup de développeurs qui comprendre ou de savoir de Flux de travail.
2. Maintenabilité – Il semble y avoir peu de soutien au sein de la communauté WF 4.0 projets et ceci, couplé avec le manque de compétences de soulever des préoccupations autour de la maintenabilité.
3. Barrière à l'entrée – j'ai le sentiment que Windows Workflow a une courbe d'apprentissage abrupte et ce n'est pas toujours facile à ramasser.
4. Nouveau produit – Comme le Flux de travail a été complètement réécrit pour .NET 4.0-je voir le produit en tant que premier produit de génération et peuvent ne pas avoir la stabilité nécessaire.
5. La réputation Précédente des versions de Flux de travail n'ont pas été bien reçus, considérées comme les plus difficiles à développer, avec et a entraîné une faible absorption.

Donc ma question est doit-on utiliser Windows Workflow (WF) 4.0 pour cette situation ou est-il une alternative à la technologie (I. E., Simple Machine d'État, etc) ou même d'un meilleur moteur de flux de travail à utiliser?

Answer 1

J'ai fait plusieurs WF4 des projets afin de les permet de voir si je peux ajouter toutes les infos utiles pour les autres réponses.

À partir de la description de votre problème d'entreprise, il sonne comme WF4 est un bon match, donc pas de problèmes là-bas.

Quant à vos préoccupations, vous avez raison. Fondamentalement WF4 est un nouveau produit et manquant de certains éléments importants et a des bords rugueux. Il y a une courbe d'apprentissage, vous avez à faire certaines choses différemment. Le point principal est long et la sérialisation, qui est quelque chose que le développeur moyen n'est pas utilisé et nécessite une certaine réflexion pour obtenir le droit comme je l'entends trop souvent que les gens ont des problèmes de sérialiser une des entités cadre de contexte de données.

La plupart du temps à l'aide de flux de travail des services hébergés dans IIS/A est le meilleur itinéraire pour faire des longue course type de flux de travail. Qui rend la résolution du problème de contrôle de version pas trop dur non plus, juste le premier message de retour le flux de travail de la version et de faire une partie de chaque message. Ensuite, placer la WCF routeur entre qui achemine le message vers le bon point de terminaison basé sur la version. La base est de ne jamais modifier un flux de travail existant, toujours en créer un nouveau.

Quel est donc mon conseil pour vous? Ne pas prendre un gros pari sur l'inconnu, et pour vous, non prouvée, pièce de technologie. Faire un petit, non critique, de la partie de l'application à l'aide de WF4. De cette façon, si cela fonctionne, vous pouvez étendre sur elle, mais si elle échoue, vous pouvez le déchirer et de le remplacer avec de plus traditionnel .NET code. De cette façon, vous obtenez de l'expérience réelle, avec WF4 au lieu de fonder une décision sur la deuxième main de l'information et de l'apprentissage d'un nouveau et puissant de la technologie dans le processus. Si possible, prendre un cours de WF4 que, qui permettra d'économiser que vous beaucoup de temps à se lever à la vitesse (sans vergogne auto fiche ici).

Au sujet de la Simple Machine d'État. Je n'ai pas utilisé, mais j'étais sous l'impression qu'il a été de courte durée, dans la mémoire, de l'état des machines. L'un des principaux avantages de WF4 est longue course aspects.

Answer 2

Je suis venu à ce dilemme couple de fois et j'avais choisi de ne pas utiliser le Flux de Travail de la fondation. Certaines considérations (similaire à la vôtre) ont été

1. Impliqués flux de travail ont été beaucoup plus simple (une combinaison de l'état de la machine et des actions séquentielles) et de le faire dans WF semble exagéré pour les efforts impliqués.
2. La courbe d'apprentissage pour les développeurs à comprendre et à utiliser WF était effectivement considéré comme élevé. Changement de statut d'un tableau décrivant valide les transitions et les actions à entreprendre sont utilisés pour plus de flexibilité et les développeurs sont à l'aise avec elle, facilement comprendre le concept et le but.
3. Les Chances de changements aux processus opérationnels étaient minces et rudimentaire des modifications ont été facilement possible avec l'aide de la table de transition. Un changement dans la transition signifierait un script de base de tout changement dans les actions de résultat dans les nouvelles de presse/patch. Cependant, la probabilité d'un tel événement a été jugée faible.

En regardant en arrière après 13-14 mois, je continue de penser que la décision de ne pas utiliser WF était correcte. OMI, WF sens où il est fort probable que le capot que le flux de travail peut modifier et/ou de l'entreprise, des règles peuvent changer. WF permet d'isoler les flux de travail dans un fichier distinct, et ainsi de rendre configurable par les utilisateurs sera plus simple.

Answer 3

Nous avons été à l'aide de WF 4.0 le couple des derniers mois. Je dois dire que c'est difficile de penser que le Flux de travail. Cependant, je peux vous dire que ça en vaut la peine. Nous en savions très peu lorsque nous avons commencé. Nous avons acheté un débutant et professionnel livre pour WF 4.0 qui m'ont aidé. J'ai, moi-même, regardé beaucoup de vidéos en ligne et suivi PDC 2009 pour leur les dernières nouvelles à propos de WF 4.0 et comment elle est différente de la précédente un peu sucky versions. Un grand chose que nous avions à proposer une solution pour la façon dont nous pouvons traiter Dans/Nos Arguments dans un flux de travail sans cadre de nos activités personnalisées à certains types de données et comment passer des paramètres entre les activités. J'ai trouver une bonne solution pour que, et le flux de travail de l'expérience que nous avons jusqu'à présent n'est pas mal du tout. En fait, nous avons un flux de travail intensif de l'application qui devient de plus en plus et je ne peux vraiment pas m'imaginer de le résoudre dans un environnement différent. J'aime l'effet visuel qu'il a: il me tient à l'écart de l'détails de if/else, etc constructions et rend les règles métier apparente d'une manière qui ne vous fera pas forcé de plonger dans les lignes de code pour savoir ce qui se passe ou comment corriger certains bug. Par ailleurs, le projet que nous avons travaillé sur la est très similaire à ce que vous avez décrite, et c'est un projet de moyenne envergure. Vous pouvez dire à partir de mes mots, que je l'aime et je ne le recommande bien que l'on incorpore certains risques comme c'est une nouvelle technologie et vous avez à venir avec des idées novatrices.

my 2 cents...

Answer 4

J'ai trois projets en WF 3.5 et je dois dire que c'est pas facile. Il vous force à penser dans la toute nouvelle manière, surtout quand persistance est utilisé. La mise à jour de l'application qui contient des centaines de incomplète persistant du flux de travail est difficile. Seule modification de rupture dans la sérialisation se bloque tous. L'introduction de plusieurs versions de la même bibliothèque à l'appui des nouveaux et vieux exécution des flux de travail est commun. Il a été difficile.

Je n'ai pas essayé WF 4.0 encore, mais basée sur l'expérience de BizTalk et WF 3.5 je pense qu'il sera similaire.

De toute façon la meilleure approche que vous pouvez prendre est de faire Preuve de Concept. Prendre seul WF de vos exigences et essayer de implment dans WF 4.0. Vous passerez un peu de temps avec elle, mais vous le prouver si vous êtes en mesure de le faire dans WF 4.0 et s'il y a des avantages visibles.

Si vous décidez d'utiliser WF 4.0, j'insiste pour que vous vérifiez la possibilité d'exécuter WF service WCF hébergé dans Windows AppFabric. AppFabric fournit certains de la fonctionnalité de boîte pour l'hébergement de WFs.

Answer 5

Je pense qu'il n'a pas vraiment de sens aujourd'hui pour vous parler de Flux de travail dans WF4 comme une technologie de choix pour ce genre de problème. Ce qui est vraiment approprié, tel que mentionné par Ladislav Mrnka ci-dessus, WCF, WF Services hébergés dans AppFabric.

Mon expérience est qu'il accorde une grande dividendes et est très agréable, mais des problèmes surviennent au début car il n'est pas apprécié à sa juste valeur que pour de nombreux programmeurs c'est une méthode de décalage de plus d'une révolution technologique. D'autre part, les généralistes et les personnes avec un problème de résolution de mentalité vu WCF, WF AppFabric comme un ensemble de possibilités intéressantes. Donc, si le mélange de gens sur le projet sont assez conservateurs C# devs attachés à leur du jour de OO et les modes, ça va être dur à mettre en place. Si l'équipe est de plus en plus innovantes, alors que l'adoption sera beaucoup plus facile parce que le potentiel et de nouvelles portes à multiplier à chaque découverte.

Deux principaux problèmes conceptuels programmeurs avaient à passer à cette technologie a été: un Message de la corrélation et de la messaged l'échange des modèles b) les flux de travail et de tests unitaires Dans les systèmes standard en C# par exemple un flux de travail est rarement explicite et donc rarement l'objet de tests unitaires. L'ensemble du flux de travail est laissé à l'essai par l'acceptation de scénarios ou de l'intégration. Introduire explicitement WF logiciel artefact et soudain standard devs veulent essayer et de test de l'unité, ce qui est généralement pas la peine de le faire.

Le message de corrélation aspect de c'est un peu de changement de mentalité pour ceux qui ne connaissent pas l'échange de messages de modèles. La plupart des développeurs ont traitée dans le processus et à distance des appels, des services web et du SAVON, et habituellement centré sur un ou deux de ceux-ci. À l'abstrait au-dessus de tout et de travailler avec un message général en fonction du système peut être déroutant au premier abord.

Sur le côté positif cependant, le résultat final est quelque chose qui permet d'économiser beaucoup de temps et crée beaucoup d'opportunités. Une chose principale est que l'worfklow, si visuellement clair, c'est quelque chose qui peut être travaillé par l'utilisateur final, développeur et analyste ensemble, d'éliminer les étapes inutiles dans le cycle de développement, en insistant sur les parties sur un artefact. En outre, il dissuade les îles de la fonctionnalité des applications dédiées, avec des couches de colle, en encourageant une suite de processus d'affaires dans WF par domaine d'affaires. De plus, avec AppFabric, la plomberie, de la persistance, de l'exploitation forestière, et de se réveiller à des activités programmées est fait pour vous. WF4 performance est remarquable aussi.

Ma recommandation serait de trouver le plus innovant ou exploratoire membre de l'équipe de faire les premiers scoutisme pour découvrir les parties difficiles, obtenir les fonctions de base de travail, et que ce premier personne responsable pour ensuite compartimenter le reste des travaux.