4、在src目录入copy build.deploy.xml文件到src目录，并改名为build.deploy.oracle.xml，然后修改文件的create.db    target。内容如下

工作流定义 

  1.1 工作流定义语法检查
  1.2 工作流定义有效性检查 
  1.3 流程可视化建模 
  1.4 组织机构数据的引用 
  1.5 支持离线过程定义 
  1.6 工作流数据定义  
  1.7 图形打印工作流过程定义图形
  1.8 以xml格式保存过程定义文件
  1.9 直接对模板库访问操作 
  1.10 xml过程定义文件打开编辑 

工作流模板库 

  2.1 工作流模板的导入和导出 
  2.2 工作流模板版本控制 
  2.3 工作流模板复制 
  2.4 工作流模板所有者定义
  2.5 工作流模板状态（草稿、发布、过时）
  2.6 工作流模板有效时间

实例初始化 

  3.1 通过Email启动 
  3.2 通过文本文件（Text Files）启动
  3.3 通过XML消息启动  
  3.4 时间事件启动  
  3.5 手工启动 
  3.6 过程调用启动 
 
工作流模式 

  4.1 顺序（Sequence） 
  4.2 并行分支（AND-split） 
  4.3 并行汇聚（AND-join） 
  4.4 条件分支（Conditional routing）、互斥选择（Exclusive Choice、XOR
  4.5 简单汇聚（XOR-join） 
  4.6 多重选择（OR-split、Conditional routing）
  4.7 多重汇聚（？）
  4.8 部分汇聚（Partial join）MI
  4.9 取消活动  
  4.10 取消实例  
  4.11 同步/异步子过程 
 
工作流任务分配 

  5.1 任务分配的两种模式（拉和推）
  5.2 任务队列（拉模式）
  5.3 按工作量分配任务（推模式）
  5.4 分配任务给所有人员（部门、角色、工作组）
  5.5 按人员优先数分配任务（适合基于角色任务分配）
  5.6 先来先做（FCFA），将任务队列中最早创建的任务分配给最先提出执行任务请求的人员
  5.7 分配任务给指定人员
  5.8 推模式下的任务分配异常处理（任务分配异常时，通知模板所有者或工作流管理员）
  5.9 任务重分配（将任务分配给其他用户、指定角色中的用户、角色）
  5.10 任务替代者，由人员指定（交办、代办）

工作流动作 

  5.11 接收任务（状态转换）accept
  5.12 退件（回退到上一节点？）decline
  5.13 执行任务
  5.14 完成任务（状态转换）
  5.15 反向回传/抽单/召回（Process Rollback）
  5.16 分配任务给指定角色
  5.17 分配任务给指定人员
  5.18 使用路由表分配任务 
  5.19 取消任务分配
  5.20 创建子过程（将任务节点用子过程代替？）
  5.21 设置任务优先级（动态修改工作流活动优先级）
  5.22 设置任务说明
  5.23 设置任务期限（设置之时起时间段、指定时间点）
  5.24 取消任务
  5.25 挂起（暂停）任务
  5.26 终止任务
  5.27 启动工作流实例
  5.28 挂起（暂停）工作流实例
  5.29 取消工作流实例
  5.30 终止工作流实例
  5.31 设置工作流实例说明
  5.32 设置工作流实例变量（工作流实例变量赋值），可以作为工作流异常处理的一种方法

工作流活动路由 

  6.1 基于角色路由（任务分配给角色，职务发生变化，流程设计不需变化）
  6.2 基于关系路由（根据相对职务关系路由）
  6.3 设定型（Ad hoc）路由（由办理人员指定下一节点办理人）根据流程处理内容，由办理人从指定人员中选择合适的下一步执行人员

工作流组织机构 

  7.1 支持LDAP目录服务
  7.2 支持组（Group）
  7.3 循环组
  7.4 权重组
  7.5 工作职务组（相同职务的人组成一个组）
  7.6 支持动态定义组（流程执行过程中定义的组）
  7.7 多重角色管理（一人数职）
  7.8 相对职务关系
  7.9 组织图拥有人（组织结构的分级维护）

工作流时间管理 

  8.1 非工作日设定
  8.2 时间事情启动工作流实例（指定时间点、时间间隔、周期时间）
  8.3 任务挂起恢复（指定时间点、时间间隔）
  8.4 过程实例挂起恢复（指定时间点、时间间隔）
  8.5 任务超时通知
  8.6 工作流超时通知
  8.7 系统时钟

工作流系统通知 

  9.1 以邮件方式通知工作超时
  9.2 可自订通知邮件（新任务通知）
  9.3 主动式邮件通知（相对Web-based被动方式）
  9.4 工作流异常通知
  9.4 任务取消通知
  9.5 工作流取消通知

工作流异常处理 

  10.1 异常的分类
  10.2 不同的异常处理方法
  10.3 异常的报告、通知机制
  10.4 异常恢复程序的预定义

工作流接口需求 

  11.1 与Email服务器接口（JMS）
  11.2 与文件系统接口（如NTFS、unix-FS）
  11.3 与ERP、CRM、HR、SCM等系统接口
  11.4 与文档管理系统系统接口
  11.5 与其它工作流系统接口
  11.6 与其它应用系统接口

工作流系统需求 

  12.1 支持多个操作系统，包括windows、AIX、Solaris、HP-Unix、Linux等
  12.2 支持多种数据库，包括MS SQL server、Oracle、DB2、MySQL等
  12.3 支持多种应用服务器，包括weblogic、websphere、Jboss、Apusic、Tomcat等
  12.4 完备的系统日志
  12.5 可处理大量流程
  12.6 从失败（或错误）中恢复系统（自动、手动）、系统（应用）数据备份
  12.7 支持并发处理

工作流系统管理 

  13.1 图形化流程监控
  13.2 流程实例动态修改（修改未执行的过程步骤）
  13.3 工作负荷量显示
  13.4 工作流统计（流程模板、流程实例、任务统计）
  13.5 自定义统计报表
  13.6 统计数据图形化显示
  13.7 临时更改收件人
  13.8 工作重送
  13.9 流程实例挂起/恢复
  13.10 活动实例挂起/恢复
  13.11 代理未来工作
  13.12 可指定代理期限
  13.13 工作流实例超时统计
  13.14 单一步骤超时统计
  13.15 可传回子流程统计数据
  13.16 服务器定时清理

工作流客户端 

  14.1 B/S结构客户端界面
  14.2 浏览器端的数字认证功能
  14.3 单点登录
  14.4 按重要程度排列任务清单
  14.5 用户查看流程执行状态
  14.6 我的任务和共享任务队列（按角色分类）
  14.7 从共享任务队列中选取任务
  14.8 用户指定/取消代理人
  14.9 显示已被代理的工作

工作流数据 

  15.1 基本数据类型（整型、符点型、字符型、日期型、布尔型）
  15.2 复合数据类型（数组）
  15.3 XML数据定义
  15.4 时间数据（三种类型：时间点、时间间隔、周期时间）
  15.5 附件（word、excel等）文件夹的概念（Folder）
  15.6 附件的检入/检出 3
  15.7 变量作用域（全局变量、过程变量）
  15.8 数据的访问控制（读写、读、不可见）
  15.9 数据集合（Data Set）（由多个不同类型数据或数据子集合所构成）
  15.10 数据的表现（表单）
  15.11 子表单（sub-form）

想想看，自己实现的太少了！！！只做到了皮毛而已!需继续努力

工作流系统功能特性描述

编写： jerry 创建日期： 2005-05-18 最后更新： 2005-05-20 版次： 1.0

1.      流程操作

流程在流转过程中需要确定的为下一环节以及该环节的相应的参与者 ( 人或应用程序 ) ，所有的流程操作均是围绕这两方面进行。

1.1.    签收

对事项进行签收表明该流程步骤进行生效阶段，说明当前人员已将事项从待办状态切换为了在办状态。

1.2.    直送 ( 直流 )

直流为流程操作中最为简单的一种操作，直流为当前环节往下仅有一个环节，不存在分支的流转，在直流过程中可确定的是流程下一环节，不可确定的是执行此环节的人员 ( 需要系统根据流程设计时配置的环节参与角色获取具有相关权限的人员，根据配置的是否需要选择人员来决定是否显示选人界面 ) 。

1.3.    分送 ( 分流 )

分流在流程操作中也很常见，分流为当前环节往下具有一个以上的环节可供选择，即存在分支的流转，在此种情况下往往需要提供选择环节的页面以供用户确定需要发往哪个环节。

1.4.    并流

并流为当前环节往下具有一个以上的环节可供选择，即存在分支的流转，但并不需要用户选择往哪个环节的一种流转操作，在并流的情况下系统将自动往所有的分支环节流转，并等待所有分支环节办理完毕后汇总至他们共同的下一环节。

1.5.    条件流转

条件流转为根据流程设计时所编写的脚本由系统计算出结果并决定流程的下一环节或下一环节的参与者。举例来说，当前申请事项金额大于 10 万的时候至经理审批，而大于 50 万的时候则需递交至副总经理审批。

1.6.    退回

审批人员收到申请事项后发现申请条件不符或资料不齐等时需要退回当前申请事项至申请人或上一环节受理人，这种流程操作通常称为退回。

1.7.    取回

当审批人员发现申请事项发送给了一个不合适的办理人员时，如该办理人员尚未签收该事项，则审批人员可将此申请事项取回，避免不必要的麻烦。

1.8.    挂起

由于申请事项的资料不符或其他原因需要将当前申请事项进行暂停办理，挂起当前流程，当需要恢复的时候则恢复该流程继续执行。

1.9.    终止 ( 撤销申请 )

由于申请事项的不合理或申请人员需要撤销该事项的申请时，可对该流程进行终止或撤销申请操作。

1.10.        会签

申请事项需要几个人员按顺序的进行审批，事项将按顺序依次发送给相应的人员进行事项的审批。举例来说，事项需要进行会签，选择人员分别为张三、李四、王五，那么张三首先接收到该事项，张三填写意见后进行发送，系统将自动发送至李四进行处理，李四处理完毕后系统自动发送至王五，王五处理完毕后进入实现的下一处理环节处理。

1.11.        催办

事项审批过程中的审批人员如觉得该事项在某一个审批人员处停留时间太长的话可对其进行催促，以提醒其迅速办理该事项，在流程操作上称为催办。

1.12.        竞争办理

竞争办理的概念为当两个用户都收到某事项时，谁先签收了该事项则为谁对该事项进行办理，同时该事项也将从另一用户的待办列表中移除。

1.13.        联审

联审为流程操作中较复杂的一种，事项发送后将发送至当前环节的下面所有环节，这时的环节通常由一个子流程构成，在各自的子流程执行完毕后统一回至主流程的下一环节中，此种流转过程称为联审。

审批人员在进行事项审批时，觉得该事项不需要经过流程图上所示意的其下的环节而可直接跳转到下面的其他任意一个环节进行流转。

如审批人员觉得不需要提交至科长审批以及处长审批，则可直接通过跳转操作将事项直接送至办公室环节进行办理。

1.15.        传阅

审批人员在进行事项审批时，觉得需要将该事项传送给相关人员进行查看，此流转过程称为传阅，相关人员在接收到此事项后只可查看不可进行审批。

1.16.        传阅办理

传阅办理与传阅的不同之处在于接收到此事项的人员可选择对此事项进行办理或不办理，而事项的流转并不等待此传阅办理过程的结束。

1.17.        意见补签

事项的审批人员在事项已经发送至后续环节办理的过程中均可进行意见的补签，此操作称为意见补签。

2.      流程管理

2.1.    调度

在流程执行的过程中根据流程的执行状态等等可对该流程事项进行调度，将事项调度至相应的环节中。

2.2.    监控

对流程事项进行监控，包括查看流程的执行过程 ( 最好是可视化的图形表示 ) 、流程执行过程中的相关信息 ( 如签收人、签收时间、办理时间等 ) 。

2.3.    查询

根据流程事项的关键字对流程事项进行简单或综合的查询。

2.4.    统计分析

对查询所得的流程事项进行统计分析，主要为分析某类事项的办结率、效率、在办件、已办结件、已归档件等等。

3.      流程列表

3.1.    待办列表

在待办列表中列出发送至当前用户的所有事项，包括事项的一些基本信息 ( 标题，时间等等 ) ，用户通过此处进行事项的签收工作。

3.2.    已办列表

在已办列表中列出经过当前用户办理但目前尚未办结归档的所有事项，用户可通过此对这些事项的办理状况进行监控，同时也可对事项进行催办操作。

3.3.    已办结列表

在已办结列表中列出经过当前用户办理并已办结归档的所有事项，用户可通过此查看事项的整个办理过程以及办理结果。

4.      与应用的接口

4.1.    组织机构的接口

在事项流转过程中需要确定下一环节的参与者，此时如配置了此环节需进行选人操作，此时需要调用应用的组织机构接口以提供选人界面供用户选择下一环节的参与者，接口中需提供按角色获取人员以及根据人员组装出其相应的组织机构树。

4.2.    角色的接口

在流程设计时需配置相应环节的参与角色，此时需调用应用提供的角色接口，接口中需提供获取该流程事项类型的角色、创建该流程事项类型的角色的功能，或者也可以采用在设计阶段不调用应用接口，当流程部署至应用时同时创建所需的角色。

4.3.    表单的接口

表单使得流程系统有了实际的应用意义，表单作为流转过程中的载体，与流程系统的接口至关重要，涉及到表单的存储方式，表单数据的获取方式，流程环节中表单的挂接，流程信息与表单信息构成的相关数据表。

<workflow>
   <initial-actions>
      <action id="0" name="开始">
        <pre-functions>
           <functions type="class">
            <arg name="class.name">com.opensymphony.workflow.util.Caller</arg>
           </functions>
        </pre-functions>
         <results>
          <unconditional-result old-status="Finished" status="Queued" step="1" owner="${caller}" />
         </results>
      </action>
     
   </initial-actions>
   <steps>
     <step id="1" name="送假单">
        <actions>
          <action id="1" name="送出">
              <restrict-to>
                   <conditions>
                     <condition type="class">
                              <arg name="class.name">
                                com.opensymphony.workflow.util.AllowOwnerOnlyCondition
                              </arg>
                           </condition>
                  </conditions>
              </restrict-to>
           <pre-functions>
            <function type="class">
          <arg name="class.name">com.opensymphony.workflow.util.Caller</arg>
         </function>
           </pre-functions>
           <results>
            <unconditional-result old-status="Finished" status="Queued" step="2" owner="${caller}"/>
           </results>
          
          </action>
        </actions>
     </step> 
     <step id="2" name="送假单">
      <actions>
       <action id="2" name="批准">
        <pre-functions>
         <function type="class">
          <arg name="class.name">com.opensymphony.workflow.util.Caller</arg>
         </function>
        </pre-functions>
        <results>
         <unconditional-result old-status="finished" status="Queued" step="3" owner="${caller}"/>
        </results>
       </action>
       <action id="3" name="驳回">
        <pre-functions>
         <function type="class">
          <arg name="class.name">com.opensymphony.workflow.util.Caller</arg>
         </function>
        </pre-functions>
        <results>
         <unconditional-result old-status="finished" status="Queued" step="1" owner="${caller}"/>
        </results>
       </action>
      </actions>
     </step>
     <step id="3" name="停止"  />
   </steps>
</workflow>
这是请假单的第二个演变，添加了:
  <restrict-to>
                   <conditions>
                     <condition type="class">
                              <arg name="class.name">
                                com.opensymphony.workflow.util.AllowOwnerOnlyCondition
                              </arg>
                           </condition>
                  </conditions>
              </restrict-to>
这个配置。这段配置就是用来限定下一步的执行人必须是这一步的发起人。

osworkflow限制的用法有：
事實上OSWorkflow 2.7版提供了以下四種限制條件。

• OSUserGroupCondition：限制由隸屬某指定Group的人執行。
  
• StatusCondition：限制step的status為某個值時才能執行。
  
• AllowOwnerOnlyCondition：只允許Owner執行。
  
• DenyOwnerCondition：只有Owner不能執行。
  

 <property key="history.table" value="OS_HISTORYSTEP"/>
 <property key="current.table" value="OS_CURRENTSTEP"/>
 <property key="historyPrev.table" value="OS_HISTORYSTEP_PREV"/>
 <property key="currentPrev.table" value="OS_CURRENTSTEP_PREV"/>
 <property key="step.id" value="ID"/>
 <property key="step.entryId" value="ENTRY_ID"/>
 <property key="step.stepId" value="STEP_ID"/>
 <property key="step.actionId" value="ACTION_ID"/>
 <property key="step.owner" value="OWNER"/>
 <property key="step.caller" value="CALLER"/>
 <property key="step.startDate" value="START_DATE"/>
 <property key="step.finishDate" value="FINISH_DATE"/>
 <property key="step.dueDate" value="DUE_DATE"/>
 <property key="step.status" value="STATUS"/>
 <property key="step.previousId" value="PREVIOUS_ID"/>

    
 </persistence>
 
 <factory class="com.opensymphony.workflow.loader.XMLWorkflowFactory">
  <property key="resource" value="workflows.xml"/>
 </factory>
</osworkflow>
propertyset.xml文件格式如下：
<?xml version="1.0" encoding="UTF-8"?>
<propertysets>
    <propertyset name="jdbc"
      class="com.opensymphony.module.propertyset.database.JDBCPropertySet">
        <arg name="datasource" value="java:comp/env/jdbc/DefaultDS"/>
        <arg name="table.name" value="OS_PROPERTYENTRY"/>
        <arg name="col.globalKey" value="GLOBAL_KEY"/>
        <arg name="col.itemKey" value="ITEM_KEY"/>
        <arg name="col.itemType" value="ITEM_TYPE"/>
        <arg name="col.string" value="STRING_VALUE"/>
        <arg name="col.date" value="DATE_VALUE"/>
        <arg name="col.data" value="DATA_VALUE"/>
        <arg name="col.float" value="FLOAT_VALUE"/>
        <arg name="col.number" value="NUMBER_VALUE"/>
    </propertyset>
</propertysets>
workflows.xml文件格式如下：

<workflows>
  <workflow name="leave" type="resource" location="leave.xml"/>
</workflows>

osuser.xml文件格式如下：
<?xml version="1.0" encoding="UTF-8"?>
<opensymphony-user>
         <provider class="com.opensymphony.user.provider.jdbc.JDBCAccessProvider">
         <property name="user.table">os_user</property>
         <property name="group.table">os_group</property>
         <property name="membership.table">os_membership</property>
         <property name="user.name" >username</property>
         <property name="user.password">passwordhash</property>
         <property name="group.name">groupname</property>
         <property name="membership.userName" >username</property>
         <property name="membership.groupName">groupname</property>
         <property name="datasource">java:comp/env/jdbc/DefaultDS</property>
       </provider>
       <provider class="com.opensymphony.user.provider.jdbc.JDBCCredentialsProvider">
         <property name="user.table">os_user</property>
         <property name="group.table">os_group</property>
         <property name="membership.table">os_membership</property>
         <property name="user.name" >username</property>
         <property name="user.password">passwordhash</property>
         <property name="group.name">groupname</property>
         <property name="membership.userName" >username</property>
         <property name="membership.groupName">groupname</property>
         <property name="datasource">java:comp/env/jdbc/DefaultDS</property>
       </provider>
       <provider class="com.opensymphony.user.provider.jdbc.JDBCProfileProvider">
         <property name="user.table">os_user</property>
         <property name="group.table">os_group</property>
         <property name="membership.table">os_membership</property>
         <property name="user.name" >username</property>
         <property name="user.password">passwordhash</property>
         <property name="group.name">groupname</property>
         <property name="membership.userName" >username</property>
         <property name="membership.groupName">groupname</property>
         <property name="datasource">java:comp/env/jdbc/DefaultDS</property>
       </provider>
       <authenticator class="com.opensymphony.user.authenticator.SmartAuthenticator" />
     </opensymphony-user>

请假列子的配置如下：

package com.pdw.wfbo;

import java.util.HashMap;
import java.util.Map;

import com.opensymphony.workflow.*;
import com.opensymphony.workflow.basic.BasicWorkflow;
import com.opensymphony.workflow.config.DefaultConfiguration;

public class LeaveWFBO {
 
   /**
    * 送出假单
    * @param employee
    * @return
    */
 public long send(String employee) {
  Workflow workflow=new BasicWorkflow("peidw");
  DefaultConfiguration config=new DefaultConfiguration();
  workflow.setConfiguration(config);
  long workflowId=-1;
  try {
   workflowId=workflow.initialize("leave",0,null);//leave是workflows.xml里配置的工作流名称
   workflow.doAction(workflowId,1,null);
  }catch(Exception e) {
   e.printStackTrace();
  }
  return workflowId;
 }
 
    /**
     * 批假
     * @param workflowId 工作流编号
     * @param actionId  工作编号，2 准许，3 驳回
     */
 public void allow(long workflowId,int actionId) {
  Workflow workflow=new BasicWorkflow("peidw");
  DefaultConfiguration config=new DefaultConfiguration();
  workflow.setConfiguration(config);
  try {
   System.out.println("actionId->"+actionId);
   System.out.println("workflowId->"+workflowId);
   workflow.doAction(workflowId,actionId,null);
  }catch(Exception e) {
   e.printStackTrace();
  }
 }

}

这是上面的这个例子的一个说明

(史帝芬, 2005/6/6, hi.steven@gmail.com)

看完第一支程式，相信讀者會有許多疑問，這些先就流程的設定做初步的介紹。首先，讀者應該注意到了，第一支程式的用到三個xml設定檔，沒錯，這三個是設定流程的設定檔。 osworkflow.xml：這個檔案是設定流程是否存在資料庫或存在記憶體，前面的內容是存在MS SQL Server的寫法。 leave.xml：請假流程寫在這個檔案，這也是osworkflow的重點之一。 workflows.xml：指定系統啟動時要載入那些流程。 這裡針對leave.xml做些說明… initial-actions：每個流程都至少需定義一個initial-actions，這是流程的起點。 action：導致流程變動的動作，每個action都有個編號，且不能重複。 step：雖然它的名稱是步驟，似乎它會有動作? 其實將它視為流程位置可能比較恰當，osworkflow真正的動作在action發生。 result：執行動作後的結果，result有兩種conditional-result和unconditional-result，每個result一定有unconditional-result，當conditional-result的條件都不滿足時，就執行unconditional-result。 status：流程在某個action時的狀態。 old-status：流程執行某個action後的狀態。 caller：這是OSWorkflow的保留字，可取得呼叫此工作流的user，即Workflow workflow = new BasicWorkflow(caller); 在資料庫中會記錄於Table OS_HISTORYSTEP如下: 記得在pre-functions加上如下設定… <pre-functions> <function type="class"> <arg name="class.name">com.opensymphony.workflow.util.Caller</arg> </function> </pre-functions>

       主要定义了用户对工作流的操作方法和用户获得工作流信息的方法。如doAction(long id, int actionId, Map inputs)方法可以执行工作流的Action并产生transaction；用户调用getAvailableActions(long id, Map inputs)可以获得知道工作流实例中符合条件的可以执行的Action。

2.com.opensymphony.workflow.WorkflowContext 工作流的Context接口。

      只有两个方法，其中getCaller()获得调用者，setRollbackOnly()可以回滚Action造成的transaction。

      setRollbackOnly()方法非常重要，可以在此方法中实现工作流数据与业务数据的事务处理。由于工作流引擎将流程数据与业务数据分离开管理，所以工作流数据与业务数据之间的事务处理往往比较困难，甚至有很多商业的工作流引擎都没有解决这个问题，造成软件上的漏洞。可惜在BasicWorkflowContext中并没有实现回滚时的事务处理，但实现起来应该不会很困难，在以后会单独考虑。

3.com.opensymphony.workflow.spi.WorkflowEntry 工作流实例的接口。

     定义了获得工作流实例信息的方法。

4.com.opensymphony.workflow.config.Configuration 工作流配置接口。

      获得osworkflw的配置信息和流程的定义信息， osworkflow中的例子就是使用此接口的默认实现。如果想让osworkflw与自己的系统更好的整合，这个接口需要自己实现。

5.com.opensymphony.workflow.loader.AbstractWorkflowFactory 流程定义的解析器。

      osworkflow中提供了此抽象类的3种实现，最常用的是XMLWorkflowFactory，可以对编写的工作流定义xml文件进行解析。

6.com.opensymphony.workflow.spi.WorkflowStore 工作流存储接口。

      实现此接口可以实现用多种途径保存工作流信息，jdbc,hibernate,ejb,memory.........

AbstractWorkflow类是workflow接口的最基本的实现。

1.public int[] getAvailableActions(long id, Map inputs)方法：

返回当前可以执行的Ation。

• 得到工作流流程实例。
• 得到工作流实例的定义。
• 得到工作流实例的PropertySet。
• 得到工作流的当前Step。
• 产生TransientVars。
• 得到Global Actions。
• 判断可以执行的Global Action增加到可执行Action列表中。
• 获得当前Steps中的可执行Action并添加到可执行Action列表中。
• 返回可执行Actions。

2. public void setConfiguration(Configuration configuration)方法：

设置工作流配置方法。

3.public Configuration getConfiguration()方法：

返回工作流配置方法，如果没有获得配置信息，初始化配置信息。

4.public List getCurrentSteps(long id)：

获得工作流当前所在步骤。

5.public int getEntryState(long id):

获得工作流的状态。

6.public List getHistorySteps(long id)

获得工作流的历史步骤。

7. public Properties getPersistenceProperties()

获得设置的持久化参数。

8.public PropertySet getPropertySet(long id)

得到工作流的PropertySet，调用store中的方法。

9.public List getSecurityPermissions(long id)

得到工作流当前Step的permissions。

10.public WorkflowDescriptor getWorkflowDescriptor(String workflowName)

得到工作流的定义。

11.public String getWorkflowName(long id)

根据工作流实例返回工作流定义名。

12. public String[] getWorkflowNames()

返回系统中配置的所有工作流的名字。

13.public boolean canInitialize(String workflowName, int initialAction)，public boolean canInitialize(String workflowName, int initialAction, Map inputs)，private boolean canInitialize(String workflowName, int initialAction, Map transientVars, PropertySet ps) throws WorkflowException

判断指定的工作流初始化Action是不是可以执行。

14.public boolean canModifyEntryState(long id, int newState)

判断工作流是不是可以转换到指定状态。

• 不可以转换到CREATED状态。
• CREATED，SUSPENDED可以转换到ACTIVATED状态。
• ACTIVATED可以转换到SUSPENDED状态。
• CREATED，ACTIVATED，SUSPENDED 可以转换到KILLED状态。

15.public void changeEntryState(long id, int newState) throws WorkflowException

转换工作流状态。

16.public void doAction(long id, int actionId, Map inputs) throws WorkflowException

执行Action。

• 获得工作流store，和流程实例entry。
• 判断是不是活动的工作流，不是就返回。
• 获得工作流的定义。
• 获得工作流当前所再Steps。
• 获得工作流PropertySet。
• 生成transientVars。
• 从GlobalActions中和当前Steps的普通Actions中判断执行的Action是否试可执行的。
• 完成Action的Transition。

17.public void executeTriggerFunction(long id, int triggerId) throws WorkflowException

调用工作流的Trigger Function

18.public long initialize(String workflowName, int initialAction, Map inputs) throws InvalidRoleException, InvalidInputException, WorkflowException

初始化一个新的流程实例。返回流程实例id。

19.public List query(WorkflowQuery query)，public List query(WorkflowExpressionQuery query)

查询流程实例。

20.public boolean removeWorkflowDescriptor(String workflowName) throws FactoryException

删除已经配置的工作流定义。

21.public boolean saveWorkflowDescriptor(String workflowName, WorkflowDescriptor descriptor, boolean replace) throws FactoryException

保存工作流定义。

22.protected List getAvailableActionsForStep(WorkflowDescriptor wf, Step step, Map transientVars, PropertySet ps) throws WorkflowException

获得指定步骤的可用Actions。

23.protected int[] getAvailableAutoActions(long id, Map inputs)

返回可执行的AutoActions。

24.protected List getAvailableAutoActionsForStep(WorkflowDescriptor wf, Step step, Map transientVars, PropertySet ps) throws WorkflowException

返回指定Step中可执行的AutoActions。

25.protected WorkflowStore getPersistence() throws StoreException

返回配置的store。

26.protected void checkImplicitFinish(long id) throws WorkflowException

判断工作流是不是还有可执行的Action，如果没有，完成此工作流实例。

27.protected void completeEntry(long id, Collection currentSteps) throws StoreException

结束工作流实例，就是把改变流程实例的状态并把当前的Steps都放入到历史表中。 

28.protected boolean passesCondition(ConditionDescriptor conditionDesc, Map transientVars, PropertySet ps, int currentStepId) throws WorkflowException

29.protected boolean passesCondition(ConditionDescriptor conditionDesc, Map transientVars, PropertySet ps, int currentStepId) throws WorkflowException，protected boolean passesConditions(String conditionType, List conditions, Map transientVars, PropertySet ps, int currentStepId) throws WorkflowException

判断条件是不是符合。

30.protected void populateTransientMap(WorkflowEntry entry, Map transientVars, List registers, Integer actionId, Collection currentSteps) throws WorkflowException

产生临时变量transientVars，包含context，entry，store，descriptor，actionId，currentSteps，以及定义的register和用户的输入变量。

31.protected void verifyInputs(WorkflowEntry entry, List validators, Map transientVars, PropertySet ps) throws WorkflowException

验证用户的输入。

32.private boolean isActionAvailable(ActionDescriptor action, Map transientVars, PropertySet ps, int stepId) throws WorkflowException

判断Action是否可用。

33.private Step getCurrentStep(WorkflowDescriptor wfDesc, int actionId, List currentSteps, Map transientVars, PropertySet ps) throws WorkflowException

获得Action所在Step。

34.private boolean canInitialize(String workflowName, int initialAction, Map transientVars, PropertySet ps) throws WorkflowException

判断工作流是不是可以实例化。

35.private Step createNewCurrentStep(ResultDescriptor theResult, WorkflowEntry entry, WorkflowStore store, int actionId, Step currentStep, long[] previousIds, Map transientVars, PropertySet ps) throws WorkflowException

产生新的当前Step。

• 从resulte中获得nextStep，如果为-1，nextStep为当前Step。
• 获得定义中的owner，oldStatus，status。
• 完成当前Step，并且将当前Step保存到历史库中。
• 生成新的Step。

36.private void executeFunction(FunctionDescriptor function, Map transientVars, PropertySet ps) throws WorkflowException

执行Function。

37.private boolean transitionWorkflow(WorkflowEntry entry, List currentSteps, WorkflowStore store, WorkflowDescriptor wf, ActionDescriptor action, Map transientVars, Map inputs, PropertySet ps) throws WorkflowException

完成工作流的transation。

• 得到配置文件流，并解析。
• 获得持久化信息，包括持久化类的路径和持久化类初始化参数。
• 获得工作流信息解析类路径，并初始化。

4. public WorkflowStore getWorkflowStore() throws StoreException

获得工作流初始化类。

2. Status：某个Step的状态，每个Step可以有多个Status。比如上例中阅读，等待提意见，等待签字，等待交秘书处理，都是Step的状态。Step＋Status共同组成了工作流的状态，也就实现了FSM中的Status。Step的Status在OSWorkflow中就是一段文本，状态的判断其实就是自定义的一段文本的比较，非常灵活。

3. Action：造成工作流状态转换的动作，比如”阅读文件“动作，造成了工作流状态从”领导审批＋等待阅读"转换成“领导审批＋等待提出意见”。由于工作流的状态是Step＋Status，所以Action可以造成Stats的变化，也可以造成Step的变化。

4. Result：工作流状态的转换，也就是Action造成的结果。也就是FSM中的Transition。每个Action中至少包含一个unconditional result和包含0或多个conditional result，Result的优先级顺序是 第一个符合条件的conditional result > 其他符合条件的conditional result  > unconditional result。

5.Split/Join:字面意思就可以解释。Split可以产生多个unconditional result；而Join可以判断多个Step的状态，如果都满足条件的时候，Join产生一个unconditional result。可以用来实现其他工作流产品定义中的同步区的作用，比如一个投标文件的评标过程，分别要在技术方面和商务方面对标书进行评分，这样就可以使用Split将工作流分开进入商务评标组和技术评标组分别进行评标，当两个评标过程都完成后使用Join将两个流程合并，并对两个评标做的评分进行汇总。

6.External Functions：执行的功能和动作。任何的工作流引擎都要与实际的业务操作相结合，External Functions就是OSWorkflow中执行业务操作的部分，比如审批流程中，领导填写意见后将领导的意见更新到业务数据库中的过程。Functions有两种类型，pre step function和post step function，分别发生转移前和发生转移后执行。Functions可以被定义到Step中和Action中。

7.Trigger Functions，一种不是定义在Action中的Function，依靠计划自动执行。

8.Validators：用来检验用户输入是否符合条件，只有符合条件，Action对应的转移才能执行，如果不符合条件，返回InvalidInputException异常。

转于:ch(耐心)

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE workflow PUBLIC "-//OpenSymphony Group//DTD OSWorkflow 2.7//EN" 
"http://www.opensymphony.com/osworkflow/workflow_2_7.dtd">
<workflow>
  <initial-actions>
   <action id="0" name="開始">
      <results>
        <unconditional-result old-status="Finished" status="Queued" step="1" />
      </results>
    </action>
  </initial-actions>

  <steps>
    <step id="1" name="填假單">
      <actions>
        <action id="1" name="送出">
	  <pre-functions>
	    <function type="class">
	      <arg name="class.name">com.opensymphony.workflow.util.Caller</arg>
	    </function>
	  </pre-functions>
          <results>
            <unconditional-result old-status="Finished" status="Queued" 
step="2"  owner="User100" />
          </results>
        </action>
      </actions>
    </step>

    <step id="2" name="批假單">
      <actions>
        <action id="2" name="准許">
	  <pre-functions>
	    <function type="class">
	      <arg name="class.name">com.opensymphony.workflow.util.Caller</arg>
	    </function>
	  </pre-functions>
          <results>
            <unconditional-result old-status="Finished" status="Queued" 
step="3"  owner="${caller}"/>
          </results>
        </action>

        <action id="3" name="駁回">
	  <pre-functions>
	    <function type="class">
	      <arg name="class.name">com.opensymphony.workflow.util.Caller</arg>
	    </function>
	  </pre-functions>
          <results>
            <unconditional-result old-status="Finished" status="Queued" 
step="1"  owner="${caller}"/>
          </results>
        </action>
      </actions>      
    </step>

    <step id="3" name="停止" />
  </steps>
</workflow>

• 创建的：0
• 活动的：1
• 挂起的：2
• 中止的：3
• 完成的：4
• 未知的：－1

OSWorkflow概况

在商用和开源世界里，OSWorkflow 都不同于这些已有的工作流系统。最大不同在于 OSWorkflow 有着非常优秀的灵活性。

OSWorkflow的优势

OSWorkflow 基于有限状态机概念。每个 state 由 step ID 和 status 联合表现（可简单理解为 step 及其 status 表示有限状态机的 state）。一个 state 到另一 state 的 transition 依赖于 action 的发生，在工作流生命期内有至少一个或多个活动的 state。这些简单概念展现了 OSWorkflow 引擎的核心思想，并允许一个简单 XML 文件解释工作流业务流程。

OSWorkFlow核心概念

概念定义

状态（Status） 工作流 Status 是用来描述工作流程中具体Step（步骤）状态的字符串。OSWorkflow 的有 Underway（进行中）、Queued（等候处理中）、Finished（完成）三种 Status。一个实际State（状态）真正是由两部分组成：State = (Step + Status) 。

流转（Transtion） 一个State到另一个State的转移。

动作（Action） Action 触发了发生在 Step 内或 Step 间的流转，或者说是基于 State 的流转。一个 step 里面可以有多个Action。Action 和Step 之间的关系是，Step 说明“在哪里”，Action 说明“去哪里”。 一个 Action 典型地由两部分组成：可以执行此Action（动作）的 Condition（条件），以及执行此动作后的 Result（结果）。

条件（Condition）类似于逻辑判断，可包含“AND”和“OR”逻辑。比如一个请假流程中的“本部门审批阶段”，该阶段利用“AND”逻辑，判断流程状态是否为等候处理中，以及审批者是否为本部门主管。

结果（Result） Result 代表执行Action（动作）后的结果，指向新的 Step 及其 Step Status，也可能进入 Split 或者 Join。Result 分为两种， Contidional-Result （有条件结果），只有条件为真时才使用该结果，和 Unconditional-Result（无条件结果），当条件不满足或没有条件时使用该结果。

分离/连接（Split/Join）流程的切分和融合。很简单的概念，Split 可以提供多个 Result（结果）；Join 则判断多个 Current Step 的态提供一个 Result（结果）。

步骤、状态和动作(Step, Status, and Action)

对于一个执行的工作流来讲，步骤的切换是不可避免的。一个工作流在某一时刻会有一个或多个当前步骤，每个当前步骤都有一个状态值，当前步骤的状态值组成了工作流实例的状态值。一旦完成了一个步骤，那么这个步骤将不再是当前步骤（而是切换到一个新的步骤），通常一个新的当前步骤将随之建立起来，以保证工作流继续执行。完成了的步骤的最终状态值是用Old-Status属性指定的，这个状态值的设定将发生在切换到其他步骤之前。Old-Status的值可以是任意的，但在一般情况下，我们设置为Finished。

切换本身是一个动作（Action）的执行结果。每个步骤可以含有多个动作，究竟要载入哪个动作是由最终用户、外部事件或者Tiggerd的自动调用决定的。随着动作的完成，一个特定的步骤切换也将发生。动作可以被限制在用户、用户组或当前状态。每一个动作都必须包含一个Unconditional Result和0个或多个Conditional Results。

所以，总体来说，一个工作流由多个步骤组成。每个步骤有一个当前状态（例如：Queued, Underway or Finished），一个步骤包含多个动作。每个步骤含有多个可以执行的动作。每个动作都有执行的条件，也有要执行的函数。动作包含有可以改变状态和当前工作流步骤的results。

结果、分支和连接(Results, Joins, and Splits)

有条件结果(Conditional Result) Conditional Result是Unconditional Result的一个扩展。它需要一个或多个Condition子标签。第一个为true的Conditional（使用AND或OR类型），会指明发生切换的步骤，这个切换步骤的发生是由于某个用户执行了某个动作的结果导致的。

三种不同的Results(conditional or unconditional) 一个新的、单一的步骤和状态的组合。一个分裂成两个或多个步骤和状态的组合。将这个和其他的切换组合成一个新的单一的步骤和状态的组合。每种不同的result对应了不同的xml描述，你可以阅读http://www.opensymphony.com/osworkflow/workflow_2_7.dtd，获取更多的信息。注意：通常，一个split或一个join不会再导致一个split 或 join的发生。

自动步骤(Auto actions)

整合抽象实例(Integrating with Abstract Entities)

工作流实例状态(Workflow Instance State)

然而，当工作流处于ACTIVATED状态的时候，调用者可以终止或挂起这个工作流（设置工作流的状态为KILLED 或 SUSPENDED）。一个终止了的工作流将不能再执行任何动作，而且将永远保持着终止状态。一个被挂起了的工作流会被冻结，他也不能执行任何的动作，除非它的状态再变成ACTIVATED。