我负责一群即将开始开发轻量级保险索赔系统的开发人员 . 该系统涉及许多手动任务和业务工作流程，我们正在寻找使用Windows Workflow（.NET 4.0） .
业务域的示例如下：保单持有人致电联络中心提出索赔 . 这个“事件”触发两个子任务，这两个子任务是并行手动操作的，可能需要很长时间才能完成;
-
检查客户是否存在欺诈行为 - 操作员致电各信贷公司以检查和评估欺诈客户的潜力的手动流程 . 从这里，子任务可以输入多个子状态（检查进度，参考检查失败，通过参考检查等）
-
将物品发送到维修中心 - 手动过程，保单持有人提出索赔的物品将被送到维修中心进行修理 . 从这里，子任务可以输入许多子状态（等待修复，进行中，修复，发布等） . 只有在每个子任务的状态达到预定义状态（基于业务规则）后，才能继续声明 .
从表面上看，Workflow似乎确实是最好的技术选择;但是我对使用WF 4.0有一些顾虑 .
-
技能集 - 查看平均开发人员技能集我没有看到很多了解或了解Workflow的开发人员 .
-
可维护性 - 社区内对WF 4.0项目的支持似乎很少，而且缺乏技能组合引起了对可维护性的担忧 .
-
进入障碍 - 我感觉Windows Workflow有一个陡峭的学习曲线，而且并不总是那么容易上手 .
-
新产品 - 由于Workflow已经完全重写为.NET 4.0，我将该产品视为第一代产品，可能没有必要的稳定性 .
-
声誉 - 以前版本的工作流程并不受欢迎，被认为难以开发并导致业务不佳 .
所以我的问题是我们应该在这种情况下使用Windows Workflow（WF）4.0还是有替代技术（例如Simple State Machine等）甚至是更好的工作流引擎？
9 回答
我已经完成了几个WF4项目，所以让我们看看是否可以向其他答案添加任何有用的信息 .
从您的业务问题的描述来看，听起来像WF4是一个很好的匹配，所以没有问题 .
关于你的担忧你是对的 . 基本上WF4是一种新产品，缺乏一些重要功能，并且有一些粗糙的边缘 . 有一个学习曲线，你必须做一些不同的事情 . 重点是长时间运行和序列化，这是普通开发人员不习惯的事情，需要一些思考才能正确，因为我经常听到人们在序列化实体框架数据上下文时遇到问题 .
大多数情况下，使用IIS / WAS中托管的工作流服务是执行这些长时间运行类型的工作流时的最佳途径 . 这使得解决版本问题也不难，只需让第一条消息返回工作流版本并将其作为每个后续消息的一部分 . 接下来将WCF路由器置于其间，根据版本将消息路由到正确的 endpoints . 基本是永远不会改变现有的工作流程，总是创建一个新的工作流程 .
那么我对你的建议是什么？不要对未知的事情进行大赌注，对于未经证实的技术而言 . 使用WF4做一个小的，非关键的应用程序 . 这样，如果它工作，你可以扩展它，但如果它失败你可以撕掉它，并用更传统的.NET代码替换它 . 通过这种方式，您可以获得WF4的真实体验，而不必根据二手信息做出决策，并在此过程中学习一种新的强大技术 . 如果可能的话，参加WF4的课程，因为这将节省你很多时间来加快速度（无耻的自我插头here） .
关于简单状态机 . 我没有使用它，但我的印象是短时间运行，内存，状态机 . 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 . 顺便说一句，我们所处理的项目与您描述的项目非常相似，而且它是一个中型项目 . 你可以从我的话中说出我喜欢它并且我确实推荐它虽然它包含了一些风险，因为它是一种新技术，你必须提出一些创新的想法 .
我的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＃devs附加到他们的日常OO和模式集，那么将很难引入 . 如果团队更具创新性，那么采用将变得更加容易，因为潜在的和新的门廊随着每次发现而增加 .
程序员转向这项技术的两个主要概念问题是：a）消息关联和消息交换模式b）工作流和单元测试在C＃中的标准系统中，工作流很少是明确的，因此很少进行单元测试 . 整个工作流程留待接受方案或集成进行测试 . 将明确的WF作为软件工件引入，突然标准开发人员想要尝试对其进行单元测试，这通常不值得做 .
对于那些不熟悉消息交换模式的人来说，它的消息相关性方面有点心态转变 . 大多数开发人员都处理过程和远程调用，Web服务和SOAP，并且通常关注其中的一个或两个 . 要在上面进行抽象并使用基于消息的通用系统，最初可能会让人感到困惑 .
但从积极的方面来看，最终结果是节省了大量时间并创造了大量机会 . 一个主要的问题是，如果视觉上清晰，那么worfklow可以由最终用户，开发人员和分析人员共同完成，消除开发生命周期中不必要的步骤，并将各方聚焦在一个工件上 . 此外，它劝阻岛屿通过鼓励每个业务领域的WF中的一组业务流程，在专用应用程序中具有专用胶层的功能 . 此外，使用AppFabric，可以为您完成持久性，日志记录和唤醒计划活动的管道 . WF4的表现也很出色 .
我的建议是找到最具创新性或探索性的团队成员进行初步侦察，以发现棘手的部分，使核心功能发挥作用，让初始人负责将剩余的工作分开 .
为了完成涉及角色和“子任务”的任何复杂性的保险索赔系统，您确实需要BPM解决方案，而不仅仅是工作流程 . Workflow Foundation 4.0非常流畅，但实际上并不接近BPM产品的功能 .
BPM解决方案，如Metastorm BPM，Global360和K2.NET，提供以人为中心的工作流程，任务，角色和系统集成，可以对您的保险索赔系统等业务流程进行建模和简化 . 使用ASP.NET构建与BPM工作流引擎集成的接口，因为它们的内置设计器通常是有限的，并强制您使用自定义构建的Web控件，这些控件通常不像ASP.NET Web控件那样功能齐全 .
使用您的团队所熟知并熟悉的技术 . Workflow Foundation不是您可以立即使用的产品 - 它可以嵌入您的应用程序中以构建工作流程系统 . 恕我直言，工作流逻辑是最不重要的技术，首先你必须专注于GUI，因为企业主除了GUI之外什么都看不到 . 但是，如果您的系统成功，那么您必须为无休止的变更请求和新要求做好准备，因此您必须实现业务逻辑，以便易于更改并轻松划分为单独的流程以满足不同的用户需求（有时相互矛盾） . BPM有助于完成此任务，因为它允许您拥有适合各种业务需求的单独的多个业务流程版本 . 您不需要完整的BPM引擎，但是对您的业务逻辑进行编码以便对其进行版本控制并将其划分为单独的业务流程非常有用 - 最糟糕的事情是处理“一切”的不可理解和交织的代码块并且没有人能够理解 . 有很多想法 - 状态机，DSL（领域特定语言），脚本等 - 您决定实现应该是什么 . 但是，您应该始终考虑业务流程并相应地组织您的逻辑，以便它反映这些流程 . 并准备好共存许多业务逻辑和数据结构变体 - 这是最困难的设计任务 .
看起来你的团队是以c＃为中心的，所以也许我的想法不适用 . 我经营一家拥有相当多员工的科技公司，我们遇到了同样的需求 . 与许多其他业务不同，我们有大量开发人员可供使用，因此基于代码的工作流解决方案非常理想 .
问题是我们不是我们业务的核心 . Azure / Window工作流程是不可能的 . 我们还尝试了很多大型BPM套件，并遇到了更多问题：它们为您提供了相当紧张的可视化编程体验 . 编程只是无法在可视化环境中完成 . 你可以看到真正让我们感兴趣的list of non-BPM software . 像Decisions.com和IFTTT这样的工具很整洁 . 事实上，Decisions可能非常适合您，因为它根据我的理解与Microsoft产品集成 .
故事的结尾是我们将自己的软件作为创业冒险和内部使用 . 工作流程可以与任何API一起编写和集成，也可以直接与表单一起编写人工流程 . 例如，我们正在整合工作流程，以便为新开发人员提供大量其他软件 . 它非常环保，但在工作流场景中非常强大 . 你可以在这里结账Nebri . 由于基于规则的方法触发事件，因此架构完全不同 . 它减少了您必须编写的代码量，并且具有速度权衡 . 但它可以很容易地处理像complex-event-processing这样的事情，因为Python可以随意使用 .
我的情况是我必须使用4.0，因为.NET 4.5还没有被认可用于我们的prod环境 . 我一般都非常了解如何让长时间运行的工作流程满足我们的业务需求，但最终找到了一个优雅的解决方案 . 这不是任何后来支持的人都可以轻松拿起来的，因为有很多想法，但我确实相信WF是一种管理工作流状态的工具 .
我对WF 4.0的一个重要问题是莫里斯的评论：
如果你只是想要一个新版本，这很好，但是如果您有50,000个持久工作流并且在某些时候意识到工作流中存在错误，该怎么办？您需要能够更新xamlx并仍然可以耦合到现有实例 . 我已经尝试对SQL Server实例表中的各种元数据列进行解压缩，以找到将实例与工作流定义联系起来而没有任何运气的东西 .
我写了一个同步应用程序，用于将数据从旧系统导入我们新的WF 4.0驱动的系统 . 我们基本上将数据加载到系统中，然后运行自动调用工作流程步骤并调用验证方法的过程，主要是模拟用户交互 . 由于我们为访问工作流服务主机而实现的体系结构，这对我们来说真的很有效 . 它是一次性的很好，在运行后你可以通过检查来确保数据迁移过程的一致性，但是一旦系统运行，必须使用这种方法可能成千上万的情况并不是真正的方法这使得整合过程中的信心和负担更加简单 .
我建议您完全避免使用WF 4.0，如果您的环境支持它，请直接使用4.5 . 动态更新和并排版本控制提供了所有开箱即用的错误修复和WF版本控制 . 我还没有准确调查4.5仍然没有被我们的客户认可使用，但急切地等待这个机会 .
我迫切希望的是我们的客户不要求更改策略（以及工作流程调整），并且当前工作流程没有任何错误 . 后者是一个虚荣和空洞的希望，因为总是会出现错误 .
我真的无法理解WF开发团队的负责人发布了一个开箱即用的系统，你无法轻易修复bug . 他们应该开发出一种将实例重新绑定到新xamlx的技术 .