工作流系统在OA系统中应用

流程有初始化流程实例的api,执行流转的api。在表单提交的时候，将表单中用于流程的数据作为参数传递到流程的api中，这些都可以做成通用的过程。不知道您的思路是怎样的呢？

是这样的，在工作流运行过程中，流程的流转是需要系统自动控制的，也就是说流程在运行过程中是不需要人为来干预的，在这种自动运行状态下，流程的流转于流程数据之间的交互会因为流程的后驱节点的不确定性而产生流程数据的不确定性，而流程数据如果无法确定，那么流程的自动运行控制器就无法获得足够的运算数据，将无法使流程前往正确的下一个节点。。。问题就在这里。。。。不知道你们遇到这样的情况 没有？

流程的流转需要系统自动控制，不需要人为的干预。
比如条件跳转吧：if (表达式) A节点    表达式返回true，就到达A节点。表达式中用到的数据，在流程上下文中都能提供，则流程引擎能自动判断，即自动控制；
如果表达式中用到的数据，流程上下文不能提供，则需要人工干预（或从表单中传入数据）。

流程的流转控制，是从前面节点到后驱节点流转的，到达那个后续的节点，不会确定不了。

"表达式中用到的数据，在流程上下文中都能提供"

表达式中用到的一个数据值，是通过流程走到这一个节点的时候才能够计算出来的，从流程上下文数据列表中无法提前获得。。这点是重要，数据值是实时读取的，不是事先存储在数据库中的。。。。所以问题就在这里。。啊

楼上，我觉得您有个误区
在上一节点的表达式中，不能设计成取下一个节点的处理日期吧，下一节点还未执行呢，永远也取不到处理日期啊。

设计的时候，要避免这样的设计，不能设计成自相矛盾的吧

的确是遇到这样的问题了，也许是我的引擎设计和你们的设计有所不同吧。。。。

不是引擎设计的问题，是在给业务流程建模的时候，表达式中不能取下一步还未发生的情况，如果下一步设计了任务参与人，那取下一步的任务参与人是可以的，总之不要设计成取不到的值，就可以了

从我eworkflow的描述看，他系统的原理非常简单，虽然引擎不能动，也没有数据计算能力，但节点流转时引擎发现有条件，可以向表单抛出一个请求（.net 领域称其为委托），提取相应字段数据，或干脆把表达式送给表单计算，进行计算后，根据回传结果进行流转。这样就可做到表单与引擎分离，同时又不影响运行。这里面技术上没有问题，很多系统都是这么做的。
但引擎与表单和在一起也并不一定不可行，而且还可以提供更多的有意思的能力，比如LZ提到的流转，在工作流领域考虑的最弱的是节点操作人，合并起来后这个问题就很好处理了。
我的博客《探索流程的奥秘之三-如何梳理业务流程》对业务模型建了个模，可以看到表单其实对应着提交物，不同操作下，提交物会从一个状态进入另一个状态，正如LZ所说，在一个业务中，提交物的数量是不同的，因此将业务流程仅绑定一个提交物（表单）的思路是有问题的，但目前绝大部分工作流产品都是这么做的。

 

这里面貌似存在了一个悖论，既然引擎不知道表单，当然也就不知道表达式的值能不能取到，为了不让这个值取不到，就必须用操作（节点）去发出“初始化”命令。而有时，这种初始化也是有条件的，就形成了老牛拉磨的循环了。

高人啊，高人。。。。