Vers un workflow ou pas vers un 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éclamation d'assurance poids léger. Le système implique de nombreuses tâches manuelles et des flux de travail d'entreprise et nous envisageons d'utiliser Windows Workflow (.NET 4.0).
Un exemple du domaine d'activité 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 peuvent prendre un certain temps;
- Vérifier le client pour la fraude - Un 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 de référence échouée, vérification de référence réussie, etc.)
- 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é. À partir de là, la sous-tâche peut entrer un certain nombre de sous-statuts (en attente de réparation, en cours, réparé, publié, etc.). La réclamation ne peut se poursuivre qu'une fois que le statut de chaque sous-tâche a atteint un statut prédéfini (en fonction des règles métier).
En surface, il semble que Workflow soit en effet le meilleur choix technologique; cependant j'ai quelques soucis en utilisant WF 4.0.
- Ensemble de compétences - En regardant l'ensemble de compétences des développeurs, je ne vois pas beaucoup de développeurs qui comprennent ou connaissent Workflow.
- Maintenabilité - Il semble y avoir peu de soutien au sein de la communauté pour les projets WF 4.0 et cela, associé au manque de compétences, soulèvent des préoccupations concernant la maintenabilité.
- Barrière à l'entrée - J'ai le sentiment que Windows Workflow a une courbe d'apprentissage abrupte et ce n'est pas toujours aussi facile à comprendre.
- 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.
- Réputation - Les versions précédentes de Workflow n'ont pas été bien reçues, considérées comme difficiles à développer et ont entraîné une mauvaise adoption des activités.
Ma question est donc de savoir si nous devrions 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 workflow à utiliser?
J'ai fait plusieurs projets WF4 alors 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 soit un bon match, donc pas de problème.
En ce qui concerne vos préoccupations, vous avez raison. Fondamentalement, WF4 est un nouveau produit qui 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 exécution 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 beaucoup trop souvent que les gens ont des problèmes pour sérialiser un contexte de données de structure d'entités.
La plupart du temps, l'utilisation des services de flux de travail hébergés dans IIS/WAS est la meilleure voie lorsque vous effectuez ce type de flux de travail de longue durée. Cela rend la résolution du problème de versionnage 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. L'essentiel est de ne jamais modifier un workflow existant, mais toujours d'en créer un nouveau.
Alors, quel est mon conseil pour vous? Ne prenez pas un gros pari sur un morceau de technologie inconnu et pour vous non prouvé. Faites une petite partie non critique de l'application en utilisant WF4. De cette façon, si cela fonctionne, vous pouvez l'étendre, mais s'il échoue, vous pouvez l'extraire et le remplacer par du code .NET plus traditionnel. De cette façon, vous obtenez une expérience réelle avec WF4 au lieu d'avoir à baser 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 à jour (self plug sans vergogne ici ).
À propos de la machine d'état simple. Je ne l'ai pas utilisé mais j'avais l'impression que c'était pour un fonctionnement court, en mémoire, des machines à états. L'un des principaux avantages de WF4 est les aspects à long terme.
Je suis arrivé à ce dilemme à quelques reprises et j'avais choisi de ne pas utiliser la fondation Work Flow. Certaines considérations (similaires aux vôtres) ont été
- Les flux de travail impliqués étaient beaucoup plus simples (une combinaison de machine d'état et d'actions séquentielles) et le faire en WF semble surpasser pour les efforts impliqués.
- Courbe d'apprentissage permettant aux développeurs de comprendre et d'utiliser WF était effectivement considéré comme élevé. 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 cela, comprenant facilement le concept et but.
- Les chances de changement de processus métier étaient minces et des changements rudimentaires étaient facilement possibles à l'aide de la table de transition. Un changement de transition signifierait un script de base de données tandis qu'un changement dans les actions entraînerait une nouvelle version/un nouveau 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. IMO, WF est logique là où il y a une forte hotte probable qui le flux de travail peut changer et/ou les règles métier peuvent changer. WF permet d'isoler le flux de travail dans un fichier séparé et ainsi le rendre configurable par les utilisateurs sera plus simple.
Nous utilisons WF 4.0 ces deux derniers mois. Je dois dire que c'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ébutant et professionnel 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). à propos de WF 4.0 et en quoi il diffère des versions précédentes quelque peu nulles. Une chose importante pour laquelle nous avons dû proposer une solution est la façon dont nous pouvons traiter In/Nos arguments dans un flux de travail sans limitation 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 mauvaise du tout. En fait, nous avons une application intensive de flux de travail ça devient de plus en plus gros et je ne peux vraiment pas m'imaginer le résoudre dans un environnement différent. J'aime l'effet visuel qu'il a: ça me garde loin des détails de if/else etc construit 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 bogue. Soit dit en passant, 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 de mes mots que je l'aime et je le recommande bien qu'il comporte certains risques car c'est une nouvelle technologie et 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 de manière complètement nouvelle, surtout lorsque la persistance est utilisée. Mise à jour de l'application qui contient des centaines de fichiers incomplets le flux de travail persistant est difficile. Un changement unique de sérialisation les bloque tous. L'introduction de plusieurs versions de la même bibliothèque pour prendre en charge les flux de travail nouveaux et anciens est courante. C'était difficile.
Je n'ai pas encore essayé WF 4.0 mais sur la base de 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 y passerez du temps mais vous prouverez si vous êtes capable de le faire) que 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érifiiez 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 des 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 type de problème. Ce qui est vraiment approprié, comme mentionné ci-dessus par Ladislav Mrnka, est WCF WF Services hébergés dans AppFabric.
D'après mon expérience, cela rapporte beaucoup et est très agréable, mais des problèmes se posent au début car il n'est pas correctement apprécié que pour de nombreux programmeurs, il s'agit d'un changement de méthodologie plus que d'un changement de technologie. D'un autre côté, les généralistes et ceux qui ont un 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 est des développeurs C # assez conservateurs attachés à leur ensemble quotidien de OO et modèles, il sera difficile à présenter. Si l'équipe est plus innovante, l'adoption sera beaucoup plus facile car le potentiel et les nouvelles portes se multiplient à chaque découverte.
Deux principaux problèmes conceptuels rencontrés par les programmeurs pour passer à cette technologie étaient: a) la corrélation des messages et les modèles d'échange de messages b) les flux de travail et les tests unitaires Dans les systèmes standard en C # par exemple, un flux de travail est rarement explicite et donc rarement testé unitaire. Le workflow global est laissé à des tests par des scénarios d'acceptation ou d'intégration. Introduisez un WF explicite comme artefact logiciel et tout à coup les développeurs standard veulent essayer de le tester à l'unité, ce qui ne vaut généralement pas la peine de le faire.
L'aspect de corrélation des messages est un peu un changement de mentalité pour ceux qui ne sont pas familiers avec les modèles d'échange de messages. La plupart des développeurs ont traité les appels de processus et à distance, les services Web et SOAP, et se sont généralement concentrés sur un ou deux d'entre eux. Abstraire par-dessus 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 beaucoup d'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. De plus, 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 programmées est fait pour vous. Les performances du WF4 sont également exceptionnelles.
Ma recommandation serait de trouver le membre de l'équipe le plus innovant ou le plus explorateur pour effectuer le dépistage initial afin de découvrir les parties délicates, de faire fonctionner les fonctions de base et de confier à cette personne initiale la responsabilité de compartimenter ensuite 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 simple 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 comme 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.
Choisissez 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 immédiatement - 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 workflow. À mon humble avis, la logique du flux de travail est l'élément technologique le moins important, vous devez d'abord 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 est un succès, vous devez être prêt à répondre aux demandes de changement sans fin et aux nouvelles exigences.Vous devez donc implémenter votre logique métier de manière à ce qu'elle soit facile à modifier et à diviser en processus distincts pour répondre aux différents besoins des utilisateurs (parfois contradictoires). . 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 n'avez pas 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 un blob de code imparable et entremêlé qui gère `` tout '' et que personne ne peut comprendre. Il existe de nombreuses idées pour cela - machines d'état, DSL (langages spécifiques au domaine), scripts, etc. - vous décidez de ce que devrait être l'implémentation. 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 préparez-vous à la coexistence de nombreuses variantes de la logique métier et des structures de données - c'est la tâche de conception la plus difficile à mon humble avis.
Il semble que votre équipe soit centrée sur c #, alors peut-être que mes pensées ne s'appliquent pas. Je dirige une entreprise technologique avec pas mal d'employés et nous avons rencontré le même besoin. Contrairement à de nombreuses autres entreprises, nous avions beaucoup de développeurs à notre disposition, donc une solution de workflow basée sur le code était idéale.
Le problème est que nous n'avons pas beaucoup de ressources pour la configuration/maintenance du système et les coûts de licence, à moins que ce ne soit assez essentiel à notre activité. Azure/Window Workflow était tout simplement hors de question. Nous avons également essayé quelques-unes des grandes suites de BPM qui existent, et avons rencontré plus de problèmes: elles vous offrent une expérience de programmation visuelle assez nerf-ed. La programmation ne peut tout simplement pas être entièrement effectuée dans un environnement visuel. Vous pouvez voir la liste des logiciels non BPM qui nous a réellement intéressé. Des outils comme Decisions.com et IFTTT sont soignés. En fait, les décisions pourraient vous convenir, car elles s'intègrent aux produits Microsoft, si je comprends bien.
La fin de l'histoire est que nous avons lancé notre propre logiciel comme une aventure entrepreneuriale et pour un usage interne. Les workflows peuvent être écrits et intégrés à n'importe quelle API, ainsi que les processus humains directement avec les formulaires. Par exemple, nous intégrons des flux de travail pour intégrer de nouveaux développeurs qui extraient/mettent à jour de nombreux autres logiciels. Il est assez vert mais extrêmement puissant dans les scénarios de workflow. Vous pouvez commander Nebri ici. Étant donné que l'approche basée sur des règles tire sur les événements, l'architecture est assez différente. Il réduit la quantité de code que vous devez écrire et offre un compromis de vitesse. Mais il peut gérer des choses comme traitement d'événements complexes facilement car Python est à votre disposition.
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'ai eu beaucoup de mal à comprendre généralement comment obtenir des flux de travail de longue durée pour répondre à nos besoins commerciaux, mais j'ai finalement trouvé une solution élégante. Ce n'est pas quelque chose que n'importe qui qui viendra plus tard pour prendre en charge peut simplement ramasser facilement parce qu'il y a tellement de choses à penser, mais je crois en WF comme un outil pour gérer les états du flux de travail.
Une grande chose que je conteste avec WF 4.0 est le commentaire de Maurice:
L'essentiel est de ne jamais modifier un workflow existant, toujours 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 workflows persistants et réalisez à un moment donné qu'il y a un bug dans le workflow? Vous devez pouvoir mettre à jour le xamlx tout en étant couplé aux instances existantes. J'ai essayé de décompresser les différentes colonnes de métadonnées dans la table des instances SQL Server pour trouver quelque chose qui lie l'instance à la définition de workflow sans aucune chance.
J'ai écrit une application de synchronisation pour importer des données d'un ancien système dans notre nouveau WF 4.0 piloté). Nous chargeons essentiellement les données dans le système, puis exécutons le processus qui consiste à appeler automatiquement le étapes de workflow et méthodes de validation des appels, essentiellement moqueuses de l'interaction des utilisateurs. Cela ne fonctionnait vraiment bien avec nous qu'en raison de l'architecture que nous avons mise en œuvre pour accéder au service de workflow Host. pour assurer la cohérence du processus de migration des données, mais avoir à utiliser cette approche pour potentiellement des centaines de milliers de cas une fois qu'un système est en ligne n'est pas vraiment une approche qui inspire confiance et surcharge le processus d'intégration de simples corrections de bugs.
Ma recommandation est que vous évitiez WF 4.0 tout à fait et allez directement à 4.5 si votre environnement le prend en charge. Les mises à jour dynamiques et la version côte à côte qu'il fournit permettent de corriger les bogues et WF versioning out of the box. Je n'ai pas encore étudié exactement comment 4.5 n'est toujours pas accrédité pour une utilisation par notre client, mais attend 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 se maintiennent sans bugs. Ce dernier étant un espoir vain et vide car des bugs surgissent toujours.
Je ne peux vraiment pas comprendre ce qui se passait à travers la tête de l'équipe de développement WF pour sortir un système où hors de la boîte, vous ne pouvez pas corriger facilement les bugs. Ils auraient dû développer une technique pour lier une instance à new xamlx.