一次处理项目中工作流问题的过程记录

    流程处理始终是我这边项目的中一个重点，之前写过一个博客关于工作流的。不过最近处理了同事碰到的问题，感觉有必要再记录一下。

一、回顾工作流

    首先，用大白话回顾一下，什么是工作流以及为何有工作流产品。工作流就是先设计一个工作处理的规范，有几个岗位，从哪个岗位发到哪个岗位，这个设计好一般使用中不动了。可以看成是一种复杂的字典项，可以记录在文件中，数据库XML方式存放，或者直接表存放，使用时一般缓存在系统中。

    为何有工作流产品？产品一般是通用性，实际工作中，不同的岗位人员处理方式完全不同，录入的内容也不同，但也有相同的地方，就是一些流向，任务分配。所以按照把公共部分抽象出来的原则，才有了工作流产品。一个事项在流动过程中，工作流中有工作流实例，自己的系统中有业务实例；工作流中有业务分配，自己的系统中有业务数据。等于是共性与个性分开了，当然他们之间有字段关联着。

二、问题

    好了，开始说说问题。这个项目是另一同事参与，我指导他技术。主要是处理一个流程中的and分支与合并，流程图上画了3个部门，实际中用户要求可以选择3个，可以选择其中两个，当然1个也行。这个情况，是非常常见的情况，我做过业务比这复杂多的流程，都用自己写的流程分配处理的，有几个就分配几个并发任务呗，每一个并发任务完成后，检测是不是大家都完成了，都完成了可以进入下一个岗位了。

    难点是啥？工作流用的内部产品，源码无。外面包装了流程适配器，可支持jbpm等其它。再外面是一套之前一个人写的业务层，包含了一批W开头的业务表。业务表与表单系统又套在一起。这个业务表外又包装了一层另一个人写的INF开头的业务表。页面上用的待办任务都是用INF表，页面写的还蛮复杂的。流程工具画的流程图装入系统后，产生与W系列表对应的环节与操作表，又产生了一批与INF对应的岗位与活动操作表。所以具体的一个业务过程，被分成了三部分，内部是工作流实例、中间的一层业务，外面又是一层业务。

   同事把主要时间放在改表单，就是修改and部门选择实际处理人的功能上了。我看过了数据库设计并分析了数据，说这个and任务已经产生了，在这里改没有任何作用，必须在and产生前控制and的个数。作为一个不确认的任务，最快速的打通其中的难点是最主要的，千万不要浪费时间有细节上。比如项目应该是先搭建好数据模型与基本结构，而不是装饰房间。最近一个项目中有几个字典项，已有公共页面处理，但最终客户要有处理页面，但我说这个很简单，先填写好数据，推进更重要的工作。

 

三、处理过程

    1.首先我认为and分支，可以选择分支是一个很通用的功能，也许配置一下就OK了，经过了解没了此功能。反编译看到and合并的条件是与流程配置中个数为准。

    2.我最初的建议是分配and任务的时候，用户勾选部门并标识下来，如果标识是不参与的，就默认让此任务自动完成。在待办任务与已办任务中根据标识过滤掉。这样应该最简单，而且业务层次最外面，改动最小。（简单测试在提交and任务后，让其中一个部分的任务立即完成，但COPY来的提交中涉及表单，涉及一些设计模式，报错就先放下了。毕竟我不是主导的，只是建议）

   3.另一方面，之前参与过的另一团队技术负责向技术总监求援，远程指导中说试试xor，以及测试流程连线上的请求条件可以过滤，还说and xor都已经被改过了，都没啥区别了，关键是流程连线上的条件。只要表单里有条件，就会起作用。看来已经被不同的人改的太乱了。大家都吃不准，只有试。XOR是排他流程。

    

  4.当然是审核岗位，只有同意才可以分配and任务，不同意直接转结束，所以还是审核的两个分支中，其中一个先加了and节点。主要测试and后的连线上的条件是不是可以用来协调真正分配的任务。同事准备写条件，并改写提交表单以加入条件。我说先用表单中已有的项来验证是不是可行，只要写个条件就行，省的改了半天又不可行。时间花在重要的验证可行性上。and上的分支果然有作用了，只产生了3个中的2个任务。

  5.下一步是合并操作，之前已经说过and合并是与配置的个数有关，怎么办？他们暂时也没办法。我建议修改原码，才知道没有原码，另一团队技术负责说可以复制出来这个类来改，改好会优化加载的。哦，是了，这个我怎么没想到呢。他说他们这边一直这么干的，看来我之前项目圈中交流太少，技术交流非常的重要。如果我是负责多个项目的管理人员，肯定会组织各个项目技术人员讲解自己的项目，最近的问题与收获。但我们这边没这个机制。最后我只写和几行代码，终于用实际产生的任务数作为and 合并的条件，测试通过了。

6. 既然技术中的难点都攻克了，那就交给同事继续开发了。

四、反思

    回想我提出的第一个思路，开始认为最简单的绕过问题的，就是自动提交不选的分支任务。仅作标识。为何没成功呢？分配完and任务，立即调用提交任务啊，应该也是只要改10行左右的核心代码啊。因为我不具体负责也没多测多想。等问题都解决后才想到最根本的问题是，把两个提交串起来，必须是两个不同的请示，不同的事务。其实模拟用户操作做个提交应该是非常简单的事情。

     

    大家都喜欢产品，群里一个同事要做OA产品，但越是接近最终用户，变化就越多，最初的产品条件变了，再打补丁，再改。层层包装。人员在变，越改越复杂，越不稳定。我始终认为一个透彻清楚的原型系统，或者完整的设计思路更有帮助。你可以自由定制，自由修改。如果真那么好做产品，我们这样的项目公司早被牛B的公司吃掉了。