工作流学习总结
最近做华为产品线的一个网站，由于网站中涉及到流程的业务，比如认证流程，注册流程。接口人让我找一个适合项目的轻量级的工作流框架，
并要求开源协议是权限最广的，允许用于商业开发的工作流框架，由于以前从没接触过工作流，对工作流技术基本不了解，我只好先在网上搜
一下资料，发现工作流的框架真的很多，最后我根据开源协议和轻量级这两个要求锁定了OsWorkFlow，总算迈出了应用工作流的第一步。
接下来就是了解OsWorkFlow的核心思想，为以后的项目整合做准备。
下面就简要的总结一下工作流的核心思想：
OsWorkFlow的核心是工作流描述文件，一个工作流描述文件描述了针对一个特定workflow的所有的steps,states,transitions,functions.
一个工作流由多个步骤(step)来表示流程(flow)。
Step
大致相当于流程所在的位置。譬如企业年检，年检报告书在企业端算一个step，在工商局算第二个step，在复核窗口算第三个step。每个step
可以有多种状态（status）和多个动作（action），用Workflow.getCurrentSteps()可以获得所有当前的step。
Status
流程在某个step中的状态。很容易理解，譬如“待认领”、“审核不通过”之类的。OSWorkflow中的状态完全是由开发者自定义的，状态判别纯
粹是字符串比对，灵活性相当强，而且可以把定义文件做得很好看。
Action
导致流程状态变迁的动作。一个action典型地由两部分组成：可以执行此动作的条件（conditions），以及执行此动作的结果（results）。
条件可以用BeanShell脚本来判断，因此具有很大的灵活性，几乎任何与流程相关的东西都可以用来做判断。
Result
执行动作后的结果。这是个比较重要的概念。result分为两种，conditional-result和unconditional-result。执行一个动作之后，首先
判断所有conditional-result的条件是否满足，满足则使用该结果；如果没有任何contidional-result满足条件，则使用unconditional-result。
unconditional-result需要指定两部分信息：old-status，表示“当前step的状态变成什么”；后续状态，可能是用step+status指定一个新状态，
conditional-result非常有用。还是以年检为例，同样是提交年检报告书，“未提交”和“被退回”是不同的状态，在这两个状态基础上执行“提交”
动作，结果分别是“初次提交”和“退回之后再次提交”。这时可以考虑在“提交”动作上用conditional-result。也可能进入split或者join。
Split/Join
流程的切分和融合。很简单的概念，split提供多个result；join则判断多个current step的状态，提供一个result。
了解了OsWorkFlow的原理，接下来就开始做整合了，整合的过程中还是出现了不少的问题，比如源码中的数据库查询语句与Oracle不兼容，大部分
通过改工作流的源码解决掉了。最主要的是数据源的整合问题，项目当前使用的数据源是用spring配置的，那么怎样将当前的数据源与工作流共享呢？
开始感觉这个问题不好解决，因为不知道OsWorkFlow是怎样获取数据源的。只好去研究源码，那要怎么研究呢？总不能一行一行去读吧，我觉得最好
的办法还是Debug，顺藤摸瓜我很快找到了源头，原来OSworkflow 会把一个简单的xml配置文件，转换成它定义的流程描述类（XXXDescriptor），然
后在流转的过程中，将其转换成工作流实例和工作流节点，并通过相应的持久化接口持久化工作流的状态。而数据源就是在这些流程描述类中获取的，
这些类中都有一个init方法用于获取数据源，于是我写了一个类继承XXXDescriptor类并重写了init方法，用spring中的上下文类：ApplicationContext
的getBean方法获取本地的数据源，然后将OsWorkFlow配置文件中的描述类改为我本地的类，这样总算实现了数据源的整合。整合工作完成。
最后就是在项目开发中，根据项目需求不断优化工作流的配置，体会比较深的就是在做自主认证流程时，接口人提到，方案有可能被打回重新编辑，并且
要打给方案制定人，而不是拥有方案制定角色的一个群体，后来我用到了OsWorkFlow中的全局变量来解决这个问题。通过这些改动我体会到，OsWorkFlow
已经将需求中可能出现的情况都考虑到了，并且构造了比较简单的组件来解决这些问题，目前我们项目涉及的流程还都比较简单，用到的OsWorkFlow的功能和
组件都是一些比较基础的，它的高级功能很多还没有用到。
写了这么多，也不能算是一篇技术类文章，只能算是我从项目中使用工作流的一个总结。
并要求开源协议是权限最广的，允许用于商业开发的工作流框架，由于以前从没接触过工作流，对工作流技术基本不了解，我只好先在网上搜
一下资料，发现工作流的框架真的很多，最后我根据开源协议和轻量级这两个要求锁定了OsWorkFlow，总算迈出了应用工作流的第一步。
接下来就是了解OsWorkFlow的核心思想，为以后的项目整合做准备。
下面就简要的总结一下工作流的核心思想：
OsWorkFlow的核心是工作流描述文件，一个工作流描述文件描述了针对一个特定workflow的所有的steps,states,transitions,functions.
一个工作流由多个步骤(step)来表示流程(flow)。
Step
大致相当于流程所在的位置。譬如企业年检，年检报告书在企业端算一个step，在工商局算第二个step，在复核窗口算第三个step。每个step
可以有多种状态（status）和多个动作（action），用Workflow.getCurrentSteps()可以获得所有当前的step。
Status
流程在某个step中的状态。很容易理解，譬如“待认领”、“审核不通过”之类的。OSWorkflow中的状态完全是由开发者自定义的，状态判别纯
粹是字符串比对，灵活性相当强，而且可以把定义文件做得很好看。
Action
导致流程状态变迁的动作。一个action典型地由两部分组成：可以执行此动作的条件（conditions），以及执行此动作的结果（results）。
条件可以用BeanShell脚本来判断，因此具有很大的灵活性，几乎任何与流程相关的东西都可以用来做判断。
Result
执行动作后的结果。这是个比较重要的概念。result分为两种，conditional-result和unconditional-result。执行一个动作之后，首先
判断所有conditional-result的条件是否满足，满足则使用该结果；如果没有任何contidional-result满足条件，则使用unconditional-result。
unconditional-result需要指定两部分信息：old-status，表示“当前step的状态变成什么”；后续状态，可能是用step+status指定一个新状态，
conditional-result非常有用。还是以年检为例，同样是提交年检报告书，“未提交”和“被退回”是不同的状态，在这两个状态基础上执行“提交”
动作，结果分别是“初次提交”和“退回之后再次提交”。这时可以考虑在“提交”动作上用conditional-result。也可能进入split或者join。
Split/Join
流程的切分和融合。很简单的概念，split提供多个result；join则判断多个current step的状态，提供一个result。
了解了OsWorkFlow的原理，接下来就开始做整合了，整合的过程中还是出现了不少的问题，比如源码中的数据库查询语句与Oracle不兼容，大部分
通过改工作流的源码解决掉了。最主要的是数据源的整合问题，项目当前使用的数据源是用spring配置的，那么怎样将当前的数据源与工作流共享呢？
开始感觉这个问题不好解决，因为不知道OsWorkFlow是怎样获取数据源的。只好去研究源码，那要怎么研究呢？总不能一行一行去读吧，我觉得最好
的办法还是Debug，顺藤摸瓜我很快找到了源头，原来OSworkflow 会把一个简单的xml配置文件，转换成它定义的流程描述类（XXXDescriptor），然
后在流转的过程中，将其转换成工作流实例和工作流节点，并通过相应的持久化接口持久化工作流的状态。而数据源就是在这些流程描述类中获取的，
这些类中都有一个init方法用于获取数据源，于是我写了一个类继承XXXDescriptor类并重写了init方法，用spring中的上下文类：ApplicationContext
的getBean方法获取本地的数据源，然后将OsWorkFlow配置文件中的描述类改为我本地的类，这样总算实现了数据源的整合。整合工作完成。
最后就是在项目开发中，根据项目需求不断优化工作流的配置，体会比较深的就是在做自主认证流程时，接口人提到，方案有可能被打回重新编辑，并且
要打给方案制定人，而不是拥有方案制定角色的一个群体，后来我用到了OsWorkFlow中的全局变量来解决这个问题。通过这些改动我体会到，OsWorkFlow
已经将需求中可能出现的情况都考虑到了，并且构造了比较简单的组件来解决这些问题，目前我们项目涉及的流程还都比较简单，用到的OsWorkFlow的功能和
组件都是一些比较基础的，它的高级功能很多还没有用到。
写了这么多，也不能算是一篇技术类文章，只能算是我从项目中使用工作流的一个总结。
