我负责一群即将开始开发轻量级保险索赔系统的开发人员.该系统涉及许多手动任务和业务工作流程,我们正在寻找使用Windows Workflow(.NET 4.0).
业务域的示例如下:保单持有人致电联络中心提出索赔.这个"事件"触发两个子任务,这两个子任务是并行手动操作的,可能需要很长时间才能完成;
检查客户是否存在欺诈行为 - 操作员致电各信用公司以检查和评估欺诈客户的潜力的手动流程.从这里,子任务可以输入多个子状态(检查进度,参考检查失败,传递参考检查等)
将物品发送到维修中心 - 手动过程中,保单持有人提出索赔的物品将被送到维修中心进行修理.从这里,子任务可以输入许多子状态(等待修复,进行中,修复,发布等).只有在每个子任务的状态达到预定义状态(基于业务规则)后,才能继续声明.
从表面上看,Workflow似乎确实是最好的技术选择; 但是我对使用WF 4.0有一些顾虑.
技能组合 - 查看普通开发人员技能组合,我看不到很多了解或了解Workflow的开发人员.
可维护性 - 社区内对WF 4.0项目的支持似乎很少,而且缺乏技能组合引起了对可维护性的担忧.
进入障碍 - 我有一种感觉,Windows Workflow有一个陡峭的学习曲线,并不总是那么容易上手.
新产品 - 由于Workflow已经完全重写为.NET 4.0,我将该产品视为第一代产品,可能没有必要的稳定性.
声誉 - 以前版本的工作流程并不受欢迎,被认为难以开发并导致业务不佳.
所以我的问题是我们应该在这种情况下使用Windows Workflow(WF)4.0还是有替代技术(例如,简单状态机等)甚至是更好的工作流引擎？
我已经完成了几个WF4项目,所以让我们看看是否可以向其他答案添加任何有用的信息.
从您的业务问题的描述来看,听起来像WF4是一个很好的匹配,所以没有问题.
关于你的担忧,你是对的.基本上WF4是一个新产品,缺乏一些重要的功能,并有一些粗糙的边缘.有一个学习曲线,你必须以不同的方式做一些事情.重点是长时间运行和序列化,这是普通开发人员不习惯的事情,需要一些思考才能正确,因为我经常听到人们在序列化实体框架数据上下文时遇到问题.
大多数情况下,使用IIS/WAS中托管的工作流服务是执行这些长时间运行类型的工作流时的最佳途径.这使得解决版本问题也不难,只需让第一条消息返回工作流版本并将其作为每个后续消息的一部分.接下来将WCF路由器置于其间,根据版本将消息路由到正确的端点.基本是永远不会改变现有的工作流程,总是创建一个新的工作流程.
那么我对你的建议是什么？不要对未知的事情进行重大赌博,对于未经证实的技术而言.使用WF4做一个小的,非关键的应用程序.这样,如果它工作,你可以扩展它,但如果它失败你可以撕掉它,并用更传统的.NET代码替换它.通过这种方式,您可以获得WF4的真实体验,而无需根据二手信息做出决策,并在此过程中学习一种新的强大技术.如果可能的话,参加WF4的课程,因为这将节省你很多时间来加快速度(这里无耻的自我插件).
关于简单状态机.我没有使用它,但我的印象是短暂运行,内存,状态机.WF4的主要优点之一是长期运行.
我几次遇到这种困境,我选择不使用工作流程基础.一些考虑因素(类似于你的)是
所涉及的工作流程更加简单(状态机和顺序操作的组合),并且在WF中执行它似乎过度了解所涉及的工作.
开发人员有效理解和使用WF的学习曲线被认为很高.描述有效转换和要采取的操作的状态转换表用于提供额外的灵活性,开发人员对此感到满意,易于理解概念和目的.
业务流程变化的机会很小,在过渡表的帮助下很容易实现基本的变化.转换中的更改将意味着数据库脚本,而操作中的更改将导致新的发布/修补程序.然而,这种发生的可能性被认为是低的.
回顾13-14个月之后,我仍然认为不使用WF的决定是正确的.IMO,WF在工作流程可能发生变化和/或业务规则可能发生变化的可能性很大的情况下是有意义的.WF允许在单独的文件中隔离工作流,因此使用户可以配置它将更简单.
过去几个月我们一直在使用WF 4.0.我不得不说,考虑工作流方式很有挑战性.但是,我可以告诉你这是值得的.当我们开始时,我们知之甚少.我们已经为WF 4.0购买了一本初学者和专业书籍.我,我自己,在线观看了许多视频,并关注PDC 2009,了解他们关于WF 4.0的重大新闻,以及它与以前有些糟糕的版本有什么不同.我们必须提出解决方案的一个主要问题是我们可以在工作流中处理In/Our Arguments,而不会将自定义活动限制为某些数据类型以及如何在活动之间传递参数.我已经为此提出了一个很好的解决方案,到目前为止我们所拥有的工作流程体验并不差.其实,我们有一个工作流密集型应用程序越来越大,我真的无法想象自己在不同的环境中解决它.我喜欢它具有的视觉效果:它让我远离if/else等构造的细节,并使业务规则显而易见,不会让你被迫潜入代码行以了解正在发生的事情或者如何修复一些bug.顺便说一句,我们所处理的项目与您描述的项目非常相似,而且它是一个中型项目.你可以从我的话中说出我喜欢它并且我确实推荐它虽然它包含了一些风险,因为它是一种新技术,你必须提出一些创新的想法.它使我远离if/else等构造的细节,并使业务规则显而易见,这种方式不会让你不得不深入了解代码行以了解正在发生的事情或如何修复某些bug.顺便说一句,我们所处理的项目与您描述的项目非常相似,而且它是一个中型项目.你可以从我的话中说出我喜欢它并且我确实推荐它虽然它包含了一些风险,因为它是一种新技术,你必须提出一些创新的想法.它使我远离if/else等构造的细节,并使业务规则显而易见,这种方式不会让你不得不深入了解代码行以了解正在发生的事情或如何修复某些bug.顺便说一句,我们所处理的项目与您描述的项目非常相似,而且它是一个中型项目.你可以从我的话中说出我喜欢它并且我确实推荐它虽然它包含了一些风险,因为它是一种新技术,你必须提出一些创新的想法.
我的2美分......
我在WF 3.5中完成了三个项目,我不得不说这并不容易.它迫使你以全新的方式思考,特别是在使用持久性时.更新包含数百个不完整的持久工作流的应用程序具有挑战性.序列化中的单次更改会使它们全部崩溃.引入同一个库的多个版本以支持新旧运行的工作流程很常见.这很有挑战性.
我还没有尝试过WF 4.0,但根据BizTalk和WF 3.5的经验,我认为它会类似.
无论如何,你可以采取的最佳方法是做概念验证.从您的要求中获取单个WF并尝试在WF 4.0中实施.您将花费一些时间,但您将证明您是否能够在WF 4.0中做到这一点并且是否有任何明显的好处.
如果您决定使用WF 4.0,我坚持要求您检查将WF作为Windows AppFabric中托管的WCF服务运行的可能性.AppFabric为托管WF提供了一些开箱即用的功能.
我认为今天谈论WF4中的Workflow作为这类问题的技术选择并没有多大意义.如上面Ladislav Mrnka所述,真正合适的是在AppFabric中托管的WCF WF服务.
我的经验是,它带来了巨大的收益并且非常愉快,但是问题在一开始就出现了,因为对于许多程序员而言,这是一种方法转变而不是技术转变,这一点并不适当.另一方面,通才和那些有解决问题心态的人将WCF WF AppFabric视为一系列令人兴奋的机会.因此,如果项目中人员的混合是相当保守的C#开发人员附加到他们的日常OO和模式集,那将很难介绍.如果团队更具创新性,那么采用将变得更加容易,因为潜在的和新的门廊随着每次发现而增加.
程序员转向这项技术的两个主要概念问题是:a)消息关联和消息交换模式b)工作流和单元测试在C#中的标准系统中,工作流很少是明确的,因此很少进行单元测试.整个工作流程留待接受方案或集成进行测试.引入一个明确的WF作为软件工件,突然标准开发人员想要尝试对其进行单元测试,这通常不值得做.
对于那些不熟悉消息交换模式的人来说,它的消息相关性方面有点心态转变.大多数开发人员都处理过程和远程调用,Web服务和SOAP,并且通常关注其中的一个或两个.要在所有内容之上进行抽象并使用基于消息的通用系统,最初可能会令人困惑.
从积极的方面来说,最终的结果是节省了大量时间并创造了大量机会.一个主要的问题是,如果视觉上清晰,那么worfklow可以由最终用户,开发人员和分析人员共同完成,消除开发生命周期中不必要的步骤,并将各方聚焦在一个工件上.此外,它通过鼓励每个业务领域的WF中的一系列业务流程,阻止专用应用程序中的功能孤岛,具有专用胶层.此外,使用AppFabric,可以为您完成持久性,记录和唤醒计划活动的管道.WF4的表现也很出色.
我的建议是找到最具创新性或探索性的团队成员进行初步侦察,以发现棘手的部分,使核心功能发挥作用,并让最初的人负责将剩余的工作分开.
为了完成涉及角色和"子任务"的任何复杂性的保险索赔系统,您确实需要BPM解决方案,而不仅仅是工作流程.Workflow Foundation 4.0非常流畅,但实际上并不接近BPM产品的功能.
BPM解决方案,如暴风BPM,Global360和K2.NET,提供人力中心的工作流程,任务,角色和系统集成,可以建模并简化业务流程,喜欢你的保险理赔系统.使用ASP.NET构建与BPM工作流引擎作为其内置的设计人员通常是有限的集成接口,并迫使你使用他们通常不作为全功能的ASP.NET Web控件定制的Web控件.
京公网安备 11010802040832号 | 京ICP备19059560号-6 