基于数据库的workflow思路

 首先，一个任务是由多个节点组成，节点之间是有条件地流动的。每个节点中都定义使用者范围、附件和相关的子任务。其实任务就是一个节点集，从事务的导航上来说，任务其实是没有必要的，只是为了对事务进行考评，才人为地把一系列节点划归一个任务。节点间不是一个线性的关系，而是一个网格状的关系。  
   
  具体的实现是，在数据库中，建立一个任务模板库，在这个库里，将任务按类型进行定义，定义其相对应的属性，然后定义一个节点流转关系库，将节点的流转顺序和相对应的条件写入。每一个节点，都有一个对应的操作角色，可以是一个人也可以是一群人，这里的“一群人”其实是指“一群人中的任何一人”，是“或”的关系。对于一个节点来说，在建立下一个节点时，定义的下一节点操作角色如是“群组”则该角色中的人都是“与”的关系，因为，如果是“且”关系，就自动产生多个节点了。而对于一个被产生的节点来说，只要定义其“如果其有未完成前驱，则等待”，这样可以保证所有的条件都满足时才会被产生。  
   
  还要再定义一个节点库，在这个库里记录每个节点角色中的操作和附件条件，比如“至少有一个文档”或者“最多建立3个子任务”等等。  
   
  上面的结构只一个任务的模板，而具体的业务内容，则在另外的数据表中体现。所以在任务模板库中，有关分支条件，只是一个条件分类，而不是具体的内容，因为对于不同的业务过程，具体的条件变量是千差万别的。  
   
  在实际应用时，传入用户名、任务号和条件，就可以自动导航到正确的节点。然后读出这个节点的操作要求和对应的表单进行数据的操作。当不传入条件时，就用默认的条件导航。  
   
  这样，只要做一个可视化的界面，将流程的定义转化为数据模板格式保存到数据库中，就可以让上面的库起到一个导航和提醒的功能。而将任务的流转控制和具体的业务数据分离开来，这样的话有一个好处，就是可以把现有的业务系统，集成到这个引擎上来。  
   
  事实上，这个数据库就成了一个大的实例库，实例运行的状态都保存在数据库中。这种方法在实现中应该是比较简单和有效的，但是其效率可能有点问题，但对于一般企业ERP应用是绝对不成问题的。