- 1 -
一种基于OSWorkflow工作流引擎的工作流监控技术
仇璐
北京邮电大学计算机科学与技术学院，北京 (100876)
摘 要：目前工作流监控技术存在的问题是：流程监控得到的流程图与实际业务流程有一定
差距，针对存在的这个问题，本文提出了一种基于 OSWorkflow解析布局文件的工作流监控
技术，首先将 xml格式的 OSWorkflow工作流引擎配置文件导入流程设计器自动生成 XML
格式流程布局文件，然后在运行时刻利用 JGraph 解析布局文件还原业务流程图，实现流程
监控。该技术解决了目前工作流监控技术存在的问题，已经在国内某大型运营商的运行调度
流程监控中得到了应用，并取得了较好的效果。
关键词：工作流管理系统，流程监控，OSWorkflow JGraph
中图分类号：
1. 引言
工作流的概念起源于生产组织和办公自动化领域, 它解决的主要问题是：为实现某个业
务目标，在多个参与者之间，利用计算机，按某种预定规则自动传递文档，信息或者任务[1] 。
目前对于工作流技术的研究主要集中在：工作流过程定义工具的设计和实现，可视化流程设
计器的开发，工作流过程定义语言模型的设计，工作流结构正确性验证方法研究，工作流仿
真技术，柔性工作流的研究，以及流程互操作上[2-6]，针对工作流监控的研究和实际应用相
对较少且存在一些问题。
但是在工作流管理联盟( workflow managementcoalition , WfMC) 提出的标准中[7] ,工作
流管理(administration) 和监控(monitoring & cont rolling) 是工作流参考模型的重要组件之一,
它与工作流执行服务通过接口 5 进行交互,目前对于流程监控和管理研究较多的是基于更改
的实例迁移或演化策略[8-10] ，但是在实际工程应用中用户迫切希望了解流程实例的具体运
行情况，关于这一点的研究一直被忽略。
目前实际工程系统中关于上述流程监控的实现主要有两种方式：一是直接以文字的方式
列出流程实例运行所经过的所有状态及相关信息，这种方式的缺点是显而易见的，很不直观，
目前采用这种方式的比较少；二是根据流程运行历史数据采用某种画图技术（JAVA 2D，
VML，SVG）将流程走过的历史以图形化方式呈现[11] ，这种方式解决了第一种方式信息
不直观的问题，但是依然不能满足用户的需求，因为这样还原的流程图和实际的业务流程图
存在一定差距而且只能反映历史，不能明确告知用户当前状态在整个业务流程中所处的位
置，并且存在响应速度慢的问题。
2. 流程监控实现
解决问题的思路
通过引言部分的分析，我们发现现在流程监控存在的普遍问题是：流程监控得到的流程
图与实际业务流程有一定差距；根据历史数据还原的只是流程图的一部分；响应速度慢。针
对这三个问题，我们在分析现有流程监控实现技术的基础上，提出了一种基于解析流程配置
文件得到布局文件再结合实例运行时刻信息实现图形化流程监控的技术。
- 2 -
图1 流程监控实现机制
如上图所示，为了解决第一个问题，在流程配置文件和业务流程图中增加一个流程布局
文件，流程布局文件记录了用户可理解的业务流程图图元和工作流引擎可识别的流程配置文
件之间的对应关系。增加这样一个中间布局文件的原因是，虽然业务流程图和流程配置文件
之间存在紧密的映射关系，理论上通过解析流程配置文件可以直接还原出业务流程图，但是
实际业务流程很复杂，通过现有的图形拓扑布局算法直接解析得到的流程图，图元和连线混
乱，用户很难理解。因此通过流程设计器解析流程配置文件得到业务流程图后，由开发人员
进行手工调整，使流程图贴近实际业务流程图，然后将调整后的布局信息保存到布局文件，
这样就解决了解析得到流程图和实际业务流程有出入的问题。
对于第二个问题，我们解决问题的思路是首先根据布局文件还原出用户可理解的整体业
务流程图，然后根据流程实例运行时信息在业务流程图上将当前状态和走过的历史步骤标示
出来。
最后关于响应速度，因为不同流程实例基于的业务流程图是一定的，因此在第一次监控
时我们把解析布局文件得到的业务流程图片存放到内存中，以后对基于同一个业务流程的流
程实例进行健康是只需要从内存中取出业务流程图片按照运行信息对流程图进行标示就可
以了。这样除了在第一次监控时速度比较慢，后面的流程实例监控速度都比较快。
由于目前几乎所有的工作流引擎配置文件都基于 XML 描述的，因此这一监控技术具有
一定的推广价值。下面的部分就详细介绍基于 OSWorkflow 工作流引擎的具体实现。
OSWorkflow 工作流引擎
OSWorkflow 是三大主流开源工作流引擎之一，它基于 FSM（有限状态自动机，Finite
State Machine）理论。每一个 state 都是由 step 和 status 联合体现出来的，一个 state 到另一
个 state 的状态跃迁 transition 依赖于 action 的执行，在 action 执行前需要判断动作的执行条
件是否满足，在动作执行改变状态前后都可以调用 function 来执行一些其它操作，动作执行
完成后通过判定条件来确定执行结果 result。每一个流程都至少有一个或者多个活动的 state，
流程中至少有一个起始状态，一个或者多个终止状态。
下图描述了 OSWorkflow 的基本元素及其相互关系。
- 3 -
图2 OSWorkflow 基本元素关系图
流程设计器的实现
流程设计器主要用来完成 OSWorkflow 流程配置文件和布局文件的转换。在解决问题思
路部分提到过流程配置文件存放了有关业务流程的所有信息，但是实际业务往往很复杂，包
括很多不确定分支，因此直接解析流程配置文件得到一个用户可理解的流程图是不可行的。
于是我们转换思路，通过对 OSWorkflow 自带的工作流设计器进行改造，容许用户对设计器
解析生成的流程图进行布局调整并且可以将调整后的布局信息保存到一个新的布局文件中。
这个新生成的布局文件保存有流程图元的位置信息以及流程图元和业务流程的对应信息，解
析它可以快速画出流程图并且不需要任何复杂的拓扑算法。
主要算法
图3 流程设计器输入及输出示意图
如上图示，流程设计器的输入是一个流程配置文件，输入为一个或多个布局文件。这是
因为在实际应用中，一个流程配置文件通常包含多个业务流程，出现这种情况有两种原因：
- 4 -
一是为了减少开发人员的工作量和流程配置文件数量，将相关的多个业务流程在同一个流程
文件中配置；二是业务流程本身包含子流程，子流程和父流程配置在同一个流程文件中。
因此需要解决的第一个问题就是如何将一个复杂的流程文件分割成独立的简单流程集
合。因为不同的子流程的入口初始动作是不一样的，因此分割主要依赖于如何通过入口动作
完成对对应子流程所有元素的遍历，遍历算法描述如下：
输入：初始动作 id
输出：对应初始动作的子流程模型
方法描述：
（1） 根据初始动作 id 得到对应的描述符 InitActionDescriptor；
（2） 通过遍历初始动作所有的条件结果和非条件结果，分析得到通过初始动作可以
达到的所有状态，并将这些状态对应的描述符加入一个临时 Map：traveled 中，
这个临时 map 以 stepId+status 为 key，记录了以初始动作为起点可以到达的所
有状态；
（3） 遍历所有的 step 的所有 action，分析每个动作可以到达的状态，将这些状态以
同样的方式放入另一个临时 map：statusMap 中，这个 map 记录了所有的可达
状态；
（4） 在第三步遍历所有 action 的过程中，需要对每一个 action 进行分析，判断 action
的执行结果是否大于 1，如果大于 1 则说明需要分支，往模型中加入相应的动
作分支模型；
（5） 遍历 traveled 中的状态图元，状态图元（状态 1）的 outgoingActions 加入动作
集合中，并且遍历 statusMap，如果其中的某一状态图元（状态 2）的
incomingActions 和状态 1 的 outcomingActions 有重合，则说明状态 2 可以通过
状态 1 可达，将状态 2 加入到 traveled 中；遍历完成后，traveled 中存放的就是
通过初始动作所有可达状态集合；将可达状态集合加入模型中；至此所有的可
达状态图元，初始动作图元以及动作分支图元已经加入模型中；
（6） 遍历连接线集合，若某一连接线的起点和终点图元在可达图元集合中则往模型
中插入的该连接线，遍历完成后所有可达连接线也加入模型中。
通过解析流程配置文件，对每一个初始动作进行遍历，可以得到一个 map，map 的 key
值是工作流名，value 还是一个 map，这个子 map 的 value 是初始动作 id，value 是对应于这
个初始动作的子流程。
描述一个流程时，需要描述它的布局信息和业务流程信息。布局信息用 Layout 类存储，
包括每个显示图元的位置信息以及业务信息。业务流程信息，用 WorkflowDescriptor 类储存
相应信息，包括所有流程元素，初始动作，步骤，状态，动作等的各种相关属性以及显示信
息。
对应于 osworkflow 工作流引擎的各种元素，我们设计了相应的类来描述这些元素。流
程图元素可以分为两大类，一类是图元，包括状态图元，初始动作图元，动作分支图元，每
个图元元素主要由三个类表示，一个继承 WorkflowCell 的类，用来记录图元的业务属性，
一个继承 VertixView 的类，记录显示信息，一个继承 CellPosition 的类，记录布局信息。如
图 4 所示就是类之间的关系。
- 5 -
图 4 流程图节点图元类及其关系
另一大类流程图元素，就是各种连接线元素，可以分为两类，一是由状态图元或者初始
动作图元作为起点的，叫做 ResultEdge；一类是以动作分支图元为起点的连接线，叫做
ActionSplitEdge。如图 5 所示就是就是边图元类的相互关系。
图 5 流程图边图元类及其关系
另外用 ResultHolder 来记录图元和边元素之间的对应关系，即边连接的是哪两个图元。
输出布局文件介绍
从上面的介绍可以知道，流程图一共有两大类五种元素，状态图元，初始动作图元，动
作分支图元，结果边，动作分支边。我们希望只通过解析布局文件就可以还原调整后的流程
图，因此在布局文件中既需要记录每个图元的位置信息，也需要记录业务信息也就是某个图
- 6 -
元对应的是业务中的哪一个步骤。
状态图元：记录状态对应的步骤，状态，是否子流程，是否结束状态，显示字段，位置
信息；
初始动作图元：只需要记录显示字段和位置信息
动作分支图元：记录位置信息和显示信息
连接线图元：纪录位置信息，显示信息，起点类型，起点信息，终点类型，终点信息，
关联动作 Id。其中起点和终点类型对应流程图元包括三种，状态，动作分支，初始动作；
对应不同的起点和终点类型，记录的起点和终点信息也不一样。对应状态型起点或终点，需
要记录状态名和步骤名；对应于动作分支和初始动作型起点或终点，则需要记录动作名。
这些信息对于后面介绍的渲染算法很重要，这是有了这些位置信息加业务信息，才能准
确快捷的将当前状态和历史路线标示出来。
渲染算法
为了解决第二和第三个问题，我们会将前面设计器输出的布局文件解析成业务流程图片
并存放在内存中，在以后的监控中只需用根据运行时刻信息对内存中的业务流程图片进行渲
染标示出历史步骤和当前状态，渲染算法就是用来完成这个工作。
下面是对渲染算法的简单描述：
输入：wfId（工作流实例的唯一标示）
输出：标有运行信息的流程图片
方法：
（1） 根据 wfId 查找 os_currentstep，os_historystep（由工作流引擎自维护的记录流程
实 例 运 行 信 息 的 表 ） ， 得 到 流 程 实 例 当 前 状 态
currentState=currentStep+currentstatus ， 以 及 所 有 的 历 史 动 作 id 集 合
historyActionIds；
（2） 然后到指定的存放所有流程跟踪结果图片的目录下寻找文件名为
WfId+currentState+ 的文件是否存在，如果存在则直接
返回图片信息；如果不存在则跳到第 3 步；
（3） 删除该目录下关于这个流程实例的流程跟踪图片，也就是以同一个 wfId 作为文
件名开始的图片，继续第 4 步；
（4） 根据 wfId 得到该流程实例对应的流程配置文件名 wfName，首先判断内存中是
否已经存在该配置文件对应的流程图集合，如果有直接返回该图片集合；如果
没有则查找该配置文件对应的所有布局文件，即以wfName开头的所有 lyt文件，
并解析这些 lyt 文件利用 Jgraph 还原出对应的流程图集合，以 map 的形式存放
到内存中，key 是初始动作 id，value 是对应的流程图片；
（5） 接下来根据 os_currentstep 和 os_historystep 进一步判断流程实例使用的是哪一
个流程图。具体判断逻辑如下：如果 os_historystep 没有记录 ,则读取
os_currentstep 得到 currentstep，currentstatus，然后遍历该流程文件对应的所有
边 集 合 ， 找 到 一 条 fromType=“init” ， toType=“status” ，
to=“currentstep+currentstatus”的边，这条边对应的 actionId 就是流程实例对应的
初始动作 id，也就是对应流程图片的 key 值；如果 os_historystep 有记录，则取
第一个 actionId ，遍历边集合找到 actionId 对应的边，如果 edge 的
- 7 -
fromType=“init”，toType=“status”，则可以确定流程实例的初始化动作就该
actionId。
（6） 找到对应的原始流程图后，下一步就是根据 os_currentstep 和 os_historystep 在
原始流程图上标示运行信息，并将图片保存在指定的目录下。我们一共需要在
原始流程图上标示两类信息：首先是流程实例的当前状态，这个通过 currentstep
和 currentstatus 可以很容易确定；然后是标示出实例运行历史情况，这个也可
以通过匹配 historyActionIds 和流程图的边集合来实现，但是需要注意的是对于
splitAction还需要通过判断下一个 action的起点来确定标注 split的哪一条分支。
需要注意的是这一修改过程必须是同步的，也就是同一时刻只容许一个用户对
内存中存放的原始流程图进行修改，并且修改完后需要将所做的变化还原。
3. 工程应用效果
该技术已应用到某省联通电子运维系统中，用来对工单调度进行跟踪。下面用一个运行
实例来说明工程应用效果。某一时刻 A 用户申请了一张故障工单并且派发给 B 用户和 C 用
户进行处理。B 收到任务后立刻进行处理，而 C 收到任务后没有进行任何处理。这个时候
用户登录系统点击流程跟踪，看到如图 6 左边所示的流程图，绿色标示出的状态（子流程）
表明目前 B，C 正在处理且没有完成处理，红色路线标明的是历史步骤。如果用户想进一步
了解 B，C 的处理情况，可以点击子流程，这时弹出 B，C 具体的流程处理情况，同样红色
表明历史步骤，绿色表示当前处理状态，图 6 右半部分就是 B 的处理情况，此时 B 用户还
没有对工单进行受理。
图 6 流程跟踪工程应用效果图
- 8 -
系统现已上线半年，从用户的反馈看，基于这种技术的流程跟踪响应速度比以前有较大
提高，而且直观易于理解，可以很清晰的标示出当前状态和历史步骤，用户对流程整体情况
和以后可能的动作也可以整体把握，并且具有一定的交互性，得到用户好评。
4. 结论
基于 JGraph 解析中间布局文件实现流程跟踪的技术经由工程实践证明能够大幅度提高
页面响应速度，提供尽可能多且清晰的流程运行信息，进而提高用户满意度。此技术一定程
度上弥补了当前对流程监控跟踪的研究空白，原理简单，通用性强，并且可以在不影响原有
系统架构的基础上快速开发部署，具有较好的现实意义和参考价值。
同时在实际应用中，发现此技术只能较好的解决对同一系统内工作流实例运行状态的监
控，不能提供对有交互的异构系统中不同工作流实例进行监控。但是在实际应用中，用户对
此有较多需求，因此下一步将把研究重点放在如何监控两个有交互的不同工作流实例
参考文献
[1] 王淼．工作流技术在办公自动化系统中的应用[J]．北京工业职业技术学院，2007 ，Vol 6 No3：58-61
[2] 曹宝香．PDM 中工作流的过程定义工具的设计和实现[J]．计算机科学，2006 ， No 11：102-105
[3] 雷超．基于 JGraph 可视化工作流模型设计器的开发[J]．软件开发与应用，2006， No 11：94-96
[4] 徐庆．基于 xml 的工作流过程定义语言模型 XMWPDL [J]．小型微型计算机系统，2003 Vol 24 No 5：
849-852
[5] 刘磊．基于 WF-net 网的工作流仿真技术研究[J]．计算机工程与应用，2006，2006 年 35 期：44-46
[6] 王东勃．基于多自主元的柔性工作流研究[J]．计算机集成制造系统，2007，2007 年 05 期：956-960
[7] 邬可可．工作流参考模型研究与基于 J2EE 的实现[J]．计算机与现代化，2007，2007 年第 4 期：115-120
[8] F Casati , S Ceri , B Pernici , et al1 Workflow evolution [J ]1 Data and Knowledge Engineering , 1998 , 24
(3) : 211 – 238
[9] M Reichert , P Dadam1．ADEPTflex —Suppporting dynamic changes of workflow without losing control
[J ]．1 Journal of Intelligent Information Systems , 1998 , 10 (2) : 93 – 129
[10] W M P vander Aalst1 How to handle dynamic change and capture management information [C]1 In : Proc of
the 4th IFCISInt’l Conf on Cooperative Information Systems(Coop IS99) 1 LosAlamitos , CA : IEEE
Computer Society Press , 1999
[11] 徐海军．SVG 在工作流图形监控中的应用[J]．信息技术，2006，2006 年第 2 期：28-30
A Process Supervisory Technology based on OSWorkflow
Workflow Engine
Qiu Lu
School of Computer Science and Technology，Beijing University of Posts and
Telecommunications，Beijing（100876）
Abstract
Now one of the existing problem of process supervisory is that: there are certain gaps between the
supervisory result, usually a flowchart, and the actual business process .To address this issue, a process
supervisory technology based on OSWorkflow workflow engine is proposed in this paper .This
supervisory method has several steps : Firstly, we converse an engine configuration file to a workflow
layout file using the workflow designer; Secondly, during the running time we using this layout file to
re-generate the actual business process chart ,then we implement process supervisory. This method has
been applied in a large domestic telecom-operator scheduling process system , and has achieved good
results.
Keywords：workflow management system，process supervisory，OSWorkflow，JGraph
