对于这个工作流的学习真的是不断深入的过程，总觉得不能理解的，不可能实现的要求，现在它就出现在你的面前，真心让你哭笑不得！

我们再来说说使用工作流的优势：

1，流程管理业务（切记）

2，能方便的应对业务的变更（业务结点和流程分离）

3，实现流程的复用，结点的复用

4，记录流程追踪过程

5，状态的维护等

    一直在说要用流程来管理业务（控制业务的处理流程），工作流的每个结点并不知道接下来改做什么，也不知道业务要想要做什么，而只管根据流程的顺序执行，至于做什么我无需关心。

理解误区：

    对于WF4.0的工作流来说，每个结点由我们开发人员自己开发，简单来说就是开发业务结点，实现相应的业务功能，再抽象一步就是我们将所有的业务结点进行抽象，使得一个抽象业务结点可以被所有的业务复用。那么这个来说我们很容易理解抽象结点，然后需要使用工作流的话，将结点拖到工作流中，那么这些结点就被工作流管理起来了，我们要做的就是开发结点池，也是实现我们所说的工作流不知道要做什么，而是去控制业务流程的执行。

    那么，再过来说JBPM，做了一个JBPM的实例之后，觉得jbpm没有什么要开发的公共结点，因为我直接拖到流程中的任务，并不需要写什么代码，只需要指派到某个人，或者绑定上某些表单，这些仅仅是一些属性的设置，并不需要开发什么结点呀？所以对于要开发结点池一直很困惑。而且在实现的过程中，我们也在不断思考，工作流到底带给我们了什么？做着做着，实现的方式便成了这样（以下进行说明），大家可以看看存在什么问题！

实现方式：

1，首先，我将所有调用工作流的方法均抽象出来，供所有的业务使用（实现工作流方法复用）

2，对于画好的流程图来说，工作流引擎就会给我们实现，按照流程图的方式自动执行，不需要我们再去实现什么

3，针对每个流程节点配置每个结点的操作人和操作页面

4，每个业务需要工作流操作时，即可调用（互用），具体的业务中掺杂着工作流的方法。

实现功能：

1，针对已经应用工作流的业务来说，应对了流程图（业务）的变更。

例如：

流程图的顺序为：开始---申请修改课程信息--导员审批--教学秘书审批--结束

修改为：开始--申请修改课程信息--导员审批或班长审批---教学秘书审批--结束

对于这个业务的流程变更，我们并不需要重新修改代码，唯一要做的就是部署一个新的流程即可

因为所有的流程处理由工作流来操作和记录（表单和人员指定即可）

2，记录着流程的流转记录

3，针对这个业务来说，无论我怎么变更业务，工作流都可以帮我们处理（对于其他业务也同样对待）

就这样我们就以为大功告成了，确实是吗？当然不是，只能说我们局限了！

那么，还有什么地方不对呢？这些不正是我们需要的吗？问题出在哪里了？应对变化，记录流转。当做到这一步的时候，真的以为已经万事大吉了，一切都OK了，但是这时并不理解老师说的开发结点池，以及工作流并不知道我接下来要做什么的问题。这时我们只看到了能应对当前业务的变更，看似实现了工作流的思想，却没有站在更高的高度去思考。

下篇继续介绍以上问题

工作流技术JBPM开发入门（四）--思想触碰之发现问题（2）