问题描述
自己设计了一个简单的工作流,基本上可以用,但现在又这样一个问题:1.提交的数据如何与工作流绑定?如果是操作了一张表,比如发起一个请假单,然后各个部门流转审批,是可以绑定在流程实例中的,但是现在因为每个部门可能是操作各自的表的,并且是多张的,联合关系怎么在流程中指明?2.现在想了2种方法,不知道对不对:1).在数据库中建立视图,工作流在任务实例中保存视图名,相关联的字段等,2)流程任务实例中只保存相关联的字段和值,具体的业务,包括操作哪些表,那些表的关系,都在业务代码中实现,流程只提供需要的相应的字段和值.不知道有没有相关做过的朋友来帮助一下,给个思路,谢谢各位了!分不多,谢谢了!
解决方案
解决方案二：
1.业务数据与工作流数据应当是分开的数据。也就是说业务数据保存在一张表中，而工作流信息保存在另外的数据表中，工作流运转的时候，只需要附带着业务数据表的ID值，就可以定位到相应的业务数据了。2.工作流运转的模型无非就是申请——查找申请人的经理或指定的角色对应的人员，当某个步骤审批完毕后，计算出下一级审批人，然后再发送待办，从而循环推动即可3.简单工作流也可以去网上下载一些简单的工作流引擎系统来进行处理，没必要太过于纠结。大部分都是倒金字塔型的审批关系，且为单线流转，很少出现并签、会签的情况
解决方案三：
解决方案四：
楼上的已经分析得很全了
解决方案五：
引用1楼jjkk168的回复:
1.业务数据与工作流数据应当是分开的数据。也就是说业务数据保存在一张表中，而工作流信息保存在另外的数据表中，工作流运转的时候，只需要附带着业务数据表的ID值，就可以定位到相应的业务数据了。2.工作流运转的模型无非就是申请——查找申请人的经理或指定的角色对应的人员，当某个步骤审批完毕后，计算出下一级审批人，然后再发送待办，从而循环推动即可3.简单工作流也可以去网上下载一些简单的工作流引擎系统来进行处理，没必要太过于纠结。大部分都是倒金字塔型的审批关系，且为单线流转，很少出现并签、会签的情况
感谢你的回答。你说的那些，基本都实现了。就是在绑定业务数据上的问题。举个例子。比如说，业务员工提交了一份客户的资料，这份客户资料包含了很多信息，不在一张表中的。所以，我在绑定到流程表中的时候，是以“表名+ID”用逗号分割多张表呢，还是在数据库中把所有客户资料的表建立视图，然后流程中只存放视图名称和id就可以了，方便解析角色在某个节点所能操作的数据。然而，我们小组有人提出的是，在业务表中加一个字段，绑定到流程，即这条数据是在流程的那一步提出的。这样一来，我有n张表，不是这些表都要这些写。。我感觉这样的关系绑定，没有把流程和业务分离，所以才有上述的提问。你觉得呢？
解决方案六：
这个其实，你只需要想象一下序列化就明白了姑且不关心什么流转，姑且认为他就是硬编码int状态a{get;set;}dosomething(){if(a>0){}else{}}那么你考虑一下把这个对象序列化以后是什么样的，然后你在考虑一下把这个东西从保存的地方反序列回来，在执行dosomething这个方法会是什么效果在《WF本质论》中微软大大们叫这种方式为“书签”，看到那里的就放个“书签”，下次直从书签那地方开始看ps：至于你考虑的什么数据库表如何设计，其实我本身根本就不关心，你直接序列化到一个字段可以，你把他拆成n个小项，用所谓的关系数据库表示也可以，这个不是核心问题。在另外说一下，刚刚执行过程是硬编码，实际上很多引擎本身不是硬编码，而是“脚本解析”，如果是动态语言脚本解析顺理成章，如果是静态语言，多数则是先语法树，然后根据语法树动态解析另外你担心的什么提交的资料其实也不是工作流的核心问题，他只是附带的“项目资源”，同理上面怎么设计其实也不是什么太纠结的地方，你喜欢怎么弄就怎么弄
解决方案七：
引用4楼pangboy的回复:
Quote: 引用1楼jjkk168的回复:
1.业务数据与工作流数据应当是分开的数据。也就是说业务数据保存在一张表中，而工作流信息保存在另外的数据表中，工作流运转的时候，只需要附带着业务数据表的ID值，就可以定位到相应的业务数据了。2.工作流运转的模型无非就是申请——查找申请人的经理或指定的角色对应的人员，当某个步骤审批完毕后，计算出下一级审批人，然后再发送待办，从而循环推动即可3.简单工作流也可以去网上下载一些简单的工作流引擎系统来进行处理，没必要太过于纠结。大部分都是倒金字塔型的审批关系，且为单线流转，很少出现并签、会签的情况感谢你的回答。你说的那些，基本都实现了。就是在绑定业务数据上的问题。举个例子。比如说，业务员工提交了一份客户的资料，这份客户资料包含了很多信息，不在一张表中的。所以，我在绑定到流程表中的时候，是以“表名+ID”用逗号分割多张表呢，还是在数据库中把所有客户资料的表建立视图，然后流程中只存放视图名称和id就可以了，方便解析角色在某个节点所能操作的数据。然而，我们小组有人提出的是，在业务表中加一个字段，绑定到流程，即这条数据是在流程的那一步提出的。这样一来，我有n张表，不是这些表都要这些写。。我感觉这样的关系绑定，没有把流程和业务分离，所以才有上述的提问。你觉得呢？
像我们平时在设计这种模型的时候，通常会有多张业务表，比如说请假申请的主表是一张表，采购申请的主表是另外一张表，但仍需要有一张流程的定义表，比如说序号为1的是采购申请，序号为2的是请假申请。那么将这个流程的ID也需要存入到各个业务的主表中，这样就可以通过业务表指定到对应的流程定义了。另外，由于这些业务表通常具有一些公用的字段，比如说流程ID、业务表主键ID、创建时间、申请时间、编号、状态等，建议建立一张专门的通用业务数据表，当修改各个业务表的时候，也需要对这张通用的表进行修改，而不是使用视图。根据我们平时的经验，如果需要使用视图，就不得不使用多张表的联合操作（UNION），当业务数据量一大，则在效率上将会有很大的影响（UNION的视图是无法创建视图索引的）当你传递参数的时候，你根据传入的流程ID和业务表主键ID，就可以直接定位到流程通用主表数据，然后根据流程ID，就可以定位到需要设置的数据表，以及相应的流程定义。另外顺带说明一下，流程ID不是一成不变的，当管理模型发生变更后，流程也会发生变化，你有可能会启用新的流程，而停用旧的流程，这里在切换的时候存在有一个问题，就是当你需要切换的时候，仍存在有还没有审批完的流程你会怎么处理？通常的结果就是旧流程按旧规则走，新流程按新规则走。那么这个时候你就需要启用一支新的流程定义，而不是在原有的流程定义的基础上进行更改。
解决方案八：
引用6楼jjkk168的回复:
另外顺带说明一下，流程ID不是一成不变的，当管理模型发生变更后，流程也会发生变化，你有可能会启用新的流程，而停用旧的流程，这里在切换的时候存在有一个问题，就是当你需要切换的时候，仍存在有还没有审批完的流程你会怎么处理？通常的结果就是旧流程按旧规则走，新流程按新规则走。那么这个时候你就需要启用一支新的流程定义，而不是在原有的流程定义的基础上进行更改。
这应该按照实际用户的要求来设计，不要只用技术的角度去看。在实际应用中，大部分都是按照新的流程继续运行，而不是按照旧的流程。并且用户在制定新的流程时，会考虑到按照旧的流程已经走到一半的那些业务能不能在新的流程中继续走下去的问题。如果只用技术的角度去看，就会非常地僵化。
解决方案九：
解决方案十：
实际上，“流程ID”这个概念如果被僵化了，可能就本末倒置了，就会脱离了实际。当一个员工它在处理一个工作时，例如它负责填写“xxxx分公司xx月设备报损情况”，然后他点了一下按钮就把任务工作簿mail出去了。这时候，系统去找这个业务数据的流转定义规则，而不是去找什么“流程ID”。你可以想象一下，一个大的企业集团，如果领导在8月5日指派了新的岗位人员甚至新的部门负责手机全集团的设备情况（例如原来是计划统计部，现在是改到了新成立的设备资源部），而下属公司在8月3日填写的报表快递给集团的哪个部门的哪个人接收？肯定不能瞎写工作流程序，否则这样的软件能卖出去、能用起来，背后一定是靠给企业个别人送礼、送回扣而存在，而不是靠产品了。
解决方案十一：
而下属公司在8月3日填写的报表快递给-->而下属公司在8月3日填写但是又被计划统计部“打回”要求修改的报表快递给
解决方案十二：
引用7楼sp1234的回复:
Quote: 引用6楼jjkk168的回复:
另外顺带说明一下，流程ID不是一成不变的，当管理模型发生变更后，流程也会发生变化，你有可能会启用新的流程，而停用旧的流程，这里在切换的时候存在有一个问题，就是当你需要切换的时候，仍存在有还没有审批完的流程你会怎么处理？通常的结果就是旧流程按旧规则走，新流程按新规则走。那么这个时候你就需要启用一支新的流程定义，而不是在原有的流程定义的基础上进行更改。这应该按照实际用户的要求来设计，不要只用技术的角度去看。在实际应用中，大部分都是按照新的流程继续运行，而不是按照旧的流程。并且用户在制定新的流程时，会考虑到按照旧的流程已经走到一半的那些业务能不能在新的流程中继续走下去的问题。如果只用技术的角度去看，就会非常地僵化。
并不是说一定需要启用新的流程定义。如果需要在原基础上更改，那就直接更改原来的流程定义即可。如果需要启用新的，那就需要形成一个新的流程ID才可以。总之，每一行业务数据，均需要绑定到一支流程的定义中，不管是旧的还是新的了。
解决方案十三：
流程和业务表单绑定，为业务表单存在多个视图时分别与流程实例节点绑定。仅供参考