目前用户自定义工作流引擎设计面临的问题

  如果说现在我们已经实现了用户自定义工作流，可能这种说法并不准确，但是如果说我们现在还没有开发出用户自定义工作流，这种说法也不正确，严格地讲，如果开发出一个比较完善的用户自定义工作流的得到的分数是90分，那么我们现在的技术水平可能有30-35分，还没有及格。。。因为从我们几年摸索的情况来看，现在开发出一个完全用户自定义工作流还存在一些问题

  1：用户设计出一个流程图，提交到运行数据库，变成运行实例并交由流程引擎中的自动运行控制器管理，该流程可以按照预先设定的路径自动运行下去直到结束，中间不需要人为的干预，这个目前是没有问题的，但是流程在自动运行过程中是否能够满足下面的目标01，特别是在流程图的节点数量大于20个，且流程图的拓扑结构比较混乱，分支与汇聚结构不对称的情况下，我心里面是没有数的。。。没有做过严格的测试，所以我只敢给自己的ARC(自动运行控制器)结构打30分。。。

     * 目标01(流程在运行过程中,无人工参与和控制的情况下)：
     *
     * 所有节点都要访问到  
     * 所有节点都要按照预先设定的次序访问到 
     * 对节点访问的次数要正确
     * 对节点的访问时间要符合系统要求


  2：如果流程是由表单(嵌入公式或者其它计算模块)的数据来驱动的情况下，表单中的数据每经过一个节点，无论是被人工还是被脚本语言处理，都要发生变化，而这种变化又要被带入下一个节点的处理过程中，很常见的情况是，前一个节点的表单数据发生变化之后，要让系统根据这个表单数据的变化情况来决定下一个流转的节点是哪个步骤，简单的讲就是，我们流程的运行方向要根据流程前一个节点的数据处理结果来确定，在流程走完前一个节点之前，我们的系统对无法获得一个确定的参数来判断下一步该走哪个节点。。。2年前就遇到这样的需求，但是并没有找到解决的办法，如果ARC结构能够处理这样的情况，估计可以得45-50分

  解决这个问题的思路倒是有，但是在代码上没有一个很好的实现，如果流程在运行过程中还要面临多步回退(反馈)的情况，ARC的设计就更加复杂，不知道我是否能够获得及格的分数。。。。而要设计出一个可以获得80分以上的用户自定义工作流引擎，就不是我个人所能够做到的了。。。。