WF当前工作流设计存在的缺陷

        长久以来，由于看到太多的类似X3的这种工作流平台，所以心里一直觉得这种一个工作流环节对应一个岗位操作的流程设计方式就应该是业务工作流平台。的确，这种方式对用户来说很直观，很容易理解。但是，就像任何其他系统一样，越简单的东西越不灵活，越灵活的东西则越不简单。这种简单直观的工作流平台最致命的问题就是不灵活。特别是面对用户各种各样不可理喻的特殊要求，虽然我没有很亲身体会过，但我猜这些做工作流平台的开发商都很痛苦。

举个例子，我在网上看到有这种工作流需求：

l  终审制：是常规审核流程的一种扩展。即每个环节都有最终审核权。只要该环节认为没有必要让上级（领导）进行审核，则可以进行此操作。

l  跨审：存在这样的情况，流程中的某一环节因为某种原因（可能相关人员请假了）而导致流程无法运行下去。有两种解决方法：一种是通过延时活动在等待一定时间后，自动将活动跳转到下一个处理环节中去，这种方式的缺点是必需等待；另一种操作方式是，下一个要处理环节的相关人员可以直接审核上一个环节所涉及的稿件内容，这种审核方式即跨审是一种更为及时的操作方式。

每一个环节的审核又可能有下面的表决方式：

l  权重值性要求：环节中参与的每一个用户都有一个权重值。当同意权重值之和达到一定期望值后，则该环节通过。或者反对权重值之和达到一定的期望值则认为是未通过审核。

l  角色性要求。如：某一环节要求五个编辑中的三个如果同意则进入下一个环节，如果有两个表示反对则打回。另一个例子：只要有两个副台或一个正台同意则通过，只要有一个副台或一个正台否决则打回。

        其实这些流程还算比较正常。我在原来单位做公文流转的时候还有一种“自由流”，可以在任意环节由岗位人员在全公司范围内任意选择一个或多人作为下一个审批环节，并且不能明确具体由多少人需要审核，最后还要在自由流结束后还需要再会到正常的流程轨迹上来，并且需要根据判断跳过以前审核过的人员。

        事实上，比以上这些复杂的多，古怪得多的流程非常常见（得益于国内公司普遍不规范的管理流程）。那么，在这种情况下，靠环节和连接线组成的流程图已经完全不能对这些现实问题进行合适的建模了。这个时候，大量奇怪的环节属性，规则，表达式脚本纷纷拥上。很容易形成这样的流程设计：流程图非常简单，可能只有几个环节，和几条简单的连接线。但是实际上，大量的复杂性都被隐藏在各种属性的设置，规则的组合和大量脚本代码之中。这时，所谓的流程设计图还有多大意义？和写代码又有多大区别呢？用户还能自己设计流程吗？

        而WF的设计理念，则是采用了一种更加底层的建模方式，完全面向程序员。在WF的哲学中，设计工作流这种事情在绝大多数情况下是用户不能做的。只有在很少数非常简单的情况下，可以由用户来自主构建非常简单的工作流。WF的这种思想在SharePoint的工作流中体现得非常好，在SharePoint中，用户可以用非常容易的方式通过SharePoint Designer来构建完成基本功能的工作流。而复杂一点的工作流，则交给开发人员，通过完全面向底层建模的工作流技术，来最大程度的降低复杂工作流的开发难度。这种方式，要比大部分国内的工作流厂商妄图使用同一种工作流平台，既能满足用户简单的设计工作流，又能支持开发人员设计复杂的工作流的概念要先进很多。因为这种通用工作流模型的技术，最后往往会形成一个让用户觉得用起来太复杂，而开发人员又感觉功能不够强大开发起来蹩足的畸形产物。

        由于一直受到这种传统工作流的影响，以前我觉得WF和现实的流程模型差异太大，很难做出一个满足应用的工作流平台实在是有点错怪WF了。其实换个思路，比如以前我一直觉得WF的顺序工作流怎么连回退都不支持啊？如果用户在签批到某一个节点，要求打回去重审这种功能都无法实现，怎么做审批流程？难道老外都从来不回退工作流的？而状态机工作流，怎么不支持分支多状态啊？要是用户要求要同时把文件发给多个人审批怎么办？其实这种思维就是将这种传统思维上往WF上硬套了。其实应该是这样，比如说回退吧，可以把原先的那条流程废掉，动态的从回退的那个节点根据定义生成一条新的工作流定义，然后再根据新的定义重新生成新的工作流实例，然后再把文件交给这个新的工作流实例进行流转。这不就回退了吗？以前怎么那么死脑筋呢？

        在新的思维方式下，应该重新审视一下WF了。