Au workflow ou pas au workflow?

Je suis responsable d'une équipe de développeurs qui sont sur le point de commencer le développement d'un système de réclamations d'assurance léger. Le système implique beaucoup de tâches manuelles et de workflows d'entreprise et nous envisageons d'utiliser Windows Workflow (.NET 4.0).

Un exemple du domaine commercial est le suivant: Un preneur d'assurance appelle le centre de contact pour déposer une réclamation. Cet «événement» déclenche deux sous-tâches qui sont exécutées manuellement en parallèle et qui peuvent prendre un certain temps à se terminer;

1. Vérifier le client pour fraude - Processus manuel par lequel un opérateur appelle diverses sociétés de crédit pour vérifier et évaluer le potentiel d'un client frauduleux. À partir de là, la sous-tâche peut entrer un certain nombre de sous-états (vérification en cours, vérification des références échouées, vérification des références réussies, etc.)
2. Envoyer l'article au centre de réparation - Un processus manuel où l'article pour lequel le preneur d'assurance a déposé la réclamation est envoyé au centre de réparation pour être réparé. De là, la sous-tâche peut entrer un certain nombre de sous-états (En attente de réparation, En cours, Réparé, Publié, etc.). La réclamation ne peut continuer que lorsque le statut de chaque sous-tâche a atteint un statut prédéfini (basé sur les règles métier).

À première vue, il semble que Workflow soit en effet le meilleur choix technologique; cependant j'ai quelques soucis en utilisant WF 4.0.

1. Ensemble de compétences - En regardant l'ensemble des compétences moyennes des développeurs, je ne vois pas beaucoup de développeurs qui comprennent ou connaissent Workflow.
2. Maintenabilité - Il semble y avoir peu de soutien au sein de la communauté pour les projets WF 4.0 et cela, couplé au manque de compétences, soulève des préoccupations concernant la maintenabilité.
3. Barrière à l'entrée - J'ai le sentiment que Windows Workflow a une courbe d'apprentissage abrupte et que ce n'est pas toujours aussi facile à comprendre.
4. Nouveau produit - Comme Workflow a été complètement réécrit pour .NET 4.0, je vois le produit comme un produit de première génération et peut ne pas avoir la stabilité nécessaire.
5. Réputation - Les versions précédentes de Workflow n'ont pas été bien accueillies, ont été jugées difficiles à développer et ont entraîné une faible adoption des entreprises.

Ma question est donc de savoir si nous devons utiliser Windows Workflow (WF) 4.0 pour cette situation ou existe-t-il une technologie alternative (par exemple, Simple State Machine , etc.) ou même un meilleur moteur de flux de travail à utiliser?

J'ai fait plusieurs projets WF4 donc voyons si je peux ajouter des informations utiles aux autres réponses.

D'après la description de votre problème commercial, il semble que WF4 est un bon match, donc pas de problème.

En ce qui concerne vos préoccupations, vous avez raison. Fondamentalement, WF4 est un nouveau produit et manque de fonctionnalités importantes et présente des aspérités. Il y a une courbe d'apprentissage, vous devez faire certaines choses différemment. Le point principal est la longue durée de vie et la sérialisation, ce à quoi le développeur moyen n'est pas habitué et nécessite une réflexion pour bien faire car j'entends trop souvent que les gens ont des problèmes pour sérialiser un contexte de données de cadre d'entités.

La plupart du temps, l'utilisation de services de flux de travail hébergés dans IIS / WAS est le meilleur moyen d'effectuer ces types de flux de travail de longue durée. Cela rend la résolution du problème de version pas trop difficile non plus, il suffit que le premier message renvoie la version du flux de travail et en fasse une partie de chaque message suivant. Ensuite, placez le routeur WCF entre les deux qui achemine le message vers le point de terminaison correct en fonction de la version. Le principe de base est de ne jamais changer un flux de travail existant, mais toujours d'en créer un nouveau.

Alors, quel est mon conseil pour vous? Ne prenez pas un gros pari sur une technologie inconnue et pour vous non éprouvée. Faites une petite partie non critique de l'application à l'aide de WF4. De cette façon, si cela fonctionne, vous pouvez l'étendre, mais si cela échoue, vous pouvez le déchirer et le remplacer par un code .NET plus traditionnel. De cette façon, vous obtenez une expérience réelle avec WF4 au lieu d'avoir à fonder une décision sur des informations de seconde main et vous apprenez une nouvelle technologie puissante dans le processus. Si possible, suivez un cours sur WF4 car cela vous fera gagner beaucoup de temps pour vous mettre à niveau (auto-plug éhonté ici ).

À propos de la machine à états simple. Je ne l'ai pas utilisé mais j'avais l'impression que c'était pour des machines à états de courte durée, en mémoire. L'un des principaux avantages de WF4 est la durée de fonctionnement.

Je suis arrivé à ce dilemme à plusieurs reprises et j'avais choisi de ne pas utiliser le fond de teint Work Flow. Certaines considérations (similaires aux vôtres) étaient

1. Les flux de travail impliqués étaient beaucoup plus simples (une combinaison de machine à états et d'actions séquentielles) et le faire dans WF semble exagérer pour les efforts impliqués.
2. La courbe d'apprentissage permettant aux développeurs de comprendre et d'utiliser efficacement WF a été jugée élevée. Le tableau de transition d'état décrivant les transitions valides et les actions à entreprendre est utilisé pour une flexibilité supplémentaire et les développeurs étaient à l'aise avec lui, en comprenant facilement le concept et l'objectif.
3. Les chances de changements de processus métier étaient minces et des changements rudimentaires étaient facilement possibles avec l'aide de la table de transition. Un changement dans la transition signifierait un script de base de données tandis que le changement des actions entraînerait une nouvelle version / patch. Cependant, la probabilité d'une telle occurrence a été jugée faible.

En regardant en arrière après 13-14 mois, je pense toujours que la décision de ne pas utiliser WF était correcte. OMI, WF est logique là où il y a une forte probabilité que le flux de travail puisse changer et / ou les règles commerciales peuvent changer. WF permet d'isoler le flux de travail dans un fichier séparé et de le rendre configurable par les utilisateurs sera plus simple.

Nous utilisons WF 4.0 ces derniers mois. Je dois dire qu'il est difficile de penser à la manière du workflow. Cependant, je peux vous dire que cela en vaut la peine. Nous en savions très peu lorsque nous avons commencé. Nous avons acheté un livre pour débutants et professionnels pour WF 4.0 qui a aidé. J'ai moi-même regardé de nombreuses vidéos en ligne et suivi PDC 2009 pour leurs dernières nouvelles sur WF 4.0 et en quoi il est différent des versions précédentes quelque peu nulles. Une chose majeure pour laquelle nous devions proposer une solution est la façon dont nous pouvons traiter les arguments In / Our dans un flux de travail sans limiter nos activités personnalisées à certains types de données et comment passer des paramètres entre les activités. J'ai trouvé une bonne solution pour cela, et l'expérience de flux de travail que nous avons jusqu'à présent n'est pas du tout mauvaise. Réellement, nous avons une application gourmande en flux de travail qui devient de plus en plus grande et je ne peux vraiment pas m'imaginer la résoudre dans un environnement différent. J'adore l'effet visuel qu'il a: il m'éloigne des détails de la construction if / else etc. et rend les règles métier apparentes d'une manière qui ne vous oblige pas à plonger dans des lignes de code pour savoir ce qui se passe ou comment corriger un bug. Au fait, le projet sur lequel nous avons travaillé est très similaire à ce que vous avez décrit et c'est un projet de taille moyenne. Vous pouvez dire à partir de mes mots que je l'aime et je le recommande bien qu'il comporte certains risques car il s'agit d'une nouvelle technologie et que vous devez trouver des idées innovantes. cela m'éloigne des détails des constructions if / else, etc. et rend les règles métier apparentes d'une manière qui ne vous oblige pas à vous plonger dans des lignes de code pour savoir ce qui se passe ou comment corriger un bogue. Au fait, le projet sur lequel nous avons travaillé est très similaire à ce que vous avez décrit et c'est un projet de taille moyenne. Vous pouvez dire à partir de mes mots que je l'aime et je le recommande bien qu'il comporte certains risques car il s'agit d'une nouvelle technologie et que vous devez trouver des idées innovantes. cela m'éloigne des détails des constructions if / else, etc. et rend les règles métier apparentes d'une manière qui ne vous oblige pas à vous plonger dans des lignes de code pour savoir ce qui se passe ou comment corriger un bogue. Au fait, le projet sur lequel nous avons travaillé est très similaire à ce que vous avez décrit et c'est un projet de taille moyenne. Vous pouvez dire à partir de mes mots que je l'aime et je le recommande bien qu'il comporte certains risques car il s'agit d'une nouvelle technologie et que vous devez trouver des idées innovantes.

mes 2 cents ...

J'ai fait trois projets en WF 3.5 et je dois dire que ce n'est pas facile. Cela vous oblige à penser d'une toute nouvelle manière, surtout lorsque la persistance est utilisée. La mise à jour de l'application qui contient des centaines de flux de travail persistants incomplets est difficile. Un seul changement de rupture dans la sérialisation les bloque tous. L'introduction de plusieurs versions de la même bibliothèque pour prendre en charge les nouveaux et anciens flux de travail en cours d'exécution est courante. C'était difficile.

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

Quoi qu'il en soit, la meilleure approche que vous pouvez adopter est de faire une preuve de concept. Prenez un seul WF de vos exigences et essayez de l'implémenter dans WF 4.0. Vous passerez du temps avec elle mais vous prouverez si vous êtes capable 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 en tant que service WCF hébergé dans Windows AppFabric. AppFabric fournit des fonctionnalités prêtes à l'emploi pour l'hébergement de WF.

Je pense que cela n'a pas vraiment de sens aujourd'hui de parler de Workflow dans WF4 comme un choix technologique pour ce genre de problème. Ce qui est vraiment approprié, comme mentionné par Ladislav Mrnka ci-dessus, ce sont les services WCF WF hébergés dans AppFabric.

Mon expérience avec cela est que cela rapporte de grands dividendes et est très agréable, mais des problèmes surviennent au début car il n'est pas bien compris que pour de nombreux programmeurs, il s'agit d'un changement de méthodologie plus qu'un changement de technologie. D'autre part, les généralistes et ceux qui ont un état d'esprit de résolution de problèmes ont vu WCF WF AppFabric comme un ensemble d'opportunités passionnantes. Donc, si le mélange de personnes sur le projet sont des développeurs C # assez conservateurs attachés à leur ensemble quotidien d'OO et de modèles, ce sera difficile à introduire. Si l'équipe est plus innovante, alors l'adoption sera beaucoup plus facile car le potentiel et les nouvelles portes se multiplient à chaque découverte.

Les deux principaux problèmes conceptuels rencontrés par les programmeurs lors du passage à cette technologie étaient: a) Corrélation des messages et modèles d'échange de messages b) Flux de travail et tests unitaires Dans les systèmes standard en C # par exemple, un flux de travail est rarement explicite et donc rarement testé unitaire. Le flux de travail global est laissé pour les tests par des scénarios d'acceptation ou d'intégration. Introduisez un WF explicite comme un artefact logiciel et les développeurs standard veulent soudainement essayer de le tester unitaire, ce qui ne vaut généralement pas la peine.

L'aspect corrélation des messages est un peu un changement d'état d'esprit pour ceux qui ne sont pas familiers avec les modèles d'échange de messages. La plupart des développeurs ont traité des appels en cours et à distance, du service Web et de SOAP, et se sont généralement concentrés sur un ou deux d'entre eux. Abstraire avant tout et travailler avec un système général basé sur les messages peut être déroutant au début.

Du côté positif cependant, le résultat final est quelque chose qui fait gagner beaucoup de temps et crée de nombreuses opportunités. Une chose principale est que le worfklow, s'il est visuellement clair, est quelque chose sur lequel l'utilisateur final, le développeur et l'analyste peuvent travailler ensemble, éliminant les étapes inutiles du cycle de vie du développement et concentrant les parties sur un artefact. En outre, il décourage les îlots de fonctionnalités dans les applications dédiées, avec des couches de colle dédiées, en encourageant une suite de processus métier dans WF par domaine métier. De plus, avec AppFabric, la plomberie pour la persistance, la journalisation et le réveil des activités planifiées est faite pour vous. Les performances du WF4 sont également exceptionnelles.

Ma recommandation serait de trouver le membre de l'équipe le plus innovant ou explorateur qui effectue le dépistage initial pour découvrir les parties délicates, faire fonctionner les fonctions de base et confier à cette personne initiale la responsabilité de compartimenter le travail restant.

Afin de faire un système de réclamation d'assurance de toute complexité qui implique des rôles et des «sous-tâches», vous avez vraiment besoin d'une solution BPM, pas seulement d'un flux de travail. Workflow Foundation 4.0 est astucieux, mais il ne se rapproche vraiment pas des fonctionnalités d'un produit BPM.

Les solutions BPM, telles que Metastorm BPM, Global360 et K2.NET, fournissent un flux de travail, des tâches, des rôles et une intégration système centrés sur l'humain qui peuvent modéliser et rationaliser les processus métier tels que votre système de réclamation d'assurance. Utilisez ASP.NET pour créer l'interface qui s'intègre au moteur de flux de travail BPM, car leurs concepteurs intégrés sont généralement limités et vous obligent à utiliser leur contrôle Web personnalisé qui n'est généralement pas aussi complet que les contrôles Web ASP.NET.

Optez pour la technologie que votre équipe connaît et avec laquelle elle se sent à l'aise. Workflow Foundation n'est pas un produit que vous pouvez utiliser tout de suite - c'est plutôt un ensemble de pièces que vous pouvez intégrer dans votre application afin de créer un système de flux de travail. À mon humble avis, la logique du flux de travail est l'élément technologique le moins important, tout d'abord vous devez vous concentrer sur l'interface graphique car les propriétaires d'entreprise ne verront rien d'autre que l'interface graphique. Mais si votre système réussit, vous devez être préparé à des demandes de changement sans fin et à de nouvelles exigences.Vous devez donc implémenter votre logique métier afin qu'elle soit facile à modifier et à diviser en processus distincts pour répondre aux différents besoins des utilisateurs (parfois contradictoires). . Le BPM vous aide dans cette tâche car il vous permet de disposer de plusieurs versions distinctes de processus métier répondant à divers besoins métier. Vous ne t besoin d'un moteur BPM à part entière pour cela, mais il est utile de coder votre logique métier afin qu'elle puisse être versionnée et divisée en processus métier individuels - la pire chose à avoir est une goutte de code impossible à comprendre et entrelacée qui gère `` tout '' et que non on peut comprendre. Il existe de nombreuses idées pour cela - machines à états, DSL (langages spécifiques au domaine), scripts, etc. - vous décidez de la mise en œuvre. Mais vous devez toujours penser en termes de processus métier et organiser votre logique en conséquence afin qu'elle reflète ces processus. Et soyez prêt à la coexistence de nombreuses variantes de logique métier et de structures de données - c'est la tâche de conception la plus difficile à mon avis. est utile pour coder votre logique métier afin qu'elle puisse être versionnée et divisée en processus métier individuels - la pire chose à avoir est un blob de code impossible à maîtriser et enchevêtré qui gère `` tout '' et que personne ne peut comprendre. Il existe de nombreuses idées pour cela - machines à états, DSL (langages spécifiques au domaine), scripts, etc. - vous décidez de la mise en œuvre. Mais vous devez toujours penser en termes de processus métier et organiser votre logique en conséquence afin qu'elle reflète ces processus. Et soyez prêt à la coexistence de nombreuses variantes de logique métier et de structures de données - c'est la tâche de conception la plus difficile à mon avis. est utile pour coder votre logique métier afin qu'elle puisse être versionnée et divisée en processus métier individuels - la pire chose à avoir est un blob de code impossible à maîtriser et enchevêtré qui gère `` tout '' et que personne ne peut comprendre. Il existe de nombreuses idées pour cela - machines à états, DSL (langages spécifiques au domaine), scripts, etc. - vous décidez de la mise en œuvre. Mais vous devez toujours penser en termes de processus métier et organiser votre logique en conséquence afin qu'elle reflète ces processus. Et soyez prêt à la coexistence de nombreuses variantes de logique métier et de structures de données - c'est la tâche de conception la plus difficile à mon avis. DSL (langages spécifiques au domaine), scripts, etc. - vous décidez de la mise en œuvre. Mais vous devez toujours penser en termes de processus métier et organiser votre logique en conséquence afin qu'elle reflète ces processus. Et soyez prêt à la coexistence de nombreuses variantes de logique métier et de structures de données - c'est la tâche de conception la plus difficile à mon avis. DSL (langages spécifiques au domaine), scripts, etc. - vous décidez de la mise en œuvre. Mais vous devez toujours penser en termes de processus métier et organiser votre logique en conséquence afin qu'elle reflète ces processus. Et soyez prêt à la coexistence de nombreuses variantes de logique métier et de structures de données - c'est la tâche de conception la plus difficile à mon avis.

Je suis dans une situation où je dois utiliser 4.0 car .NET 4.5 n'est pas encore accrédité pour une utilisation dans notre environnement de production. J'avais beaucoup de mal à comprendre en général comment obtenir des flux de travail de longue durée pour répondre aux besoins de notre entreprise, mais j'ai finalement trouvé une solution élégante. Ce n'est pas quelque chose que n'importe qui venant plus tard pour prendre en charge peut simplement prendre en charge car il y a tellement de choses à penser, mais je crois en WF en tant qu'outil de gestion des états de flux de travail.

Un gros problème avec WF 4.0 est le commentaire de Maurice:

La base est de ne jamais changer un flux de travail existant, toujours d'en créer un nouveau

C'est génial si vous voulez juste une nouvelle version, mais que se passe-t-il si vous avez 50 000 flux de travail persistants et que vous vous rendez compte à un moment donné qu'il y a un bogue dans le flux de travail? Vous devez être en mesure de mettre à jour le xamlx tout en restant couplé aux instances existantes. J'ai essayé de décompresser les différentes colonnes de métadonnées dans le tableau des instances de SQL Server pour trouver quelque chose qui lie l'instance à la définition du flux de travail sans aucune chance.

J'ai écrit une application de synchronisation pour importer des données d'un ancien système dans notre nouveau système piloté par WF 4.0. Nous chargeons essentiellement les données dans le système, puis exécutons le processus qui appelle automatiquement les étapes du flux de travail et appelle les méthodes de validation, se moquant essentiellement de l'interaction de l'utilisateur. Cela n'a vraiment bien fonctionné avec nous qu'en raison de l'architecture que nous avons mise en œuvre pour accéder à l'hôte du service de flux de travail. C'est génial comme une seule fois, où après l'exécution, vous pouvez effectuer des vérifications pour assurer la cohérence du processus de migration des données, mais devoir utiliser cette approche pour potentiellement des centaines de milliers de cas une fois qu'un système est en service n'est pas vraiment une approche. qui instille la confiance et surcharge le processus d'intégration de simples corrections de bogues.

Ma recommandation est d'éviter complètement WF 4.0 et de passer directement à 4.5 si votre environnement le prend en charge. Les mises à jour dynamiques et la gestion des versions côte à côte qu'il fournit permettent de corriger les bogues et de gérer les versions WF dès la sortie de la boîte. Je n'ai pas encore étudié exactement comment la 4.5 n'est toujours pas accréditée pour une utilisation par notre client, mais j'attends avec impatience cette opportunité.

Ce que j'espère désespérément, c'est que notre client ne demande pas de modifications de politique (et donc d'ajustements de flux de travail) et que les flux de travail actuels tiennent sans aucun bogue. Ce dernier étant un espoir vain et vide car les bugs surgissent toujours.

Je ne peux vraiment pas comprendre ce qui se passait dans les têtes de l'équipe de développement de WF pour sortir un système dans lequel vous ne pouvez pas résoudre les bogues facilement. Ils devraient avoir développé une technique pour relier une instance à un nouveau xamlx.