利用osworkflow实现业务流程
图二 在业务逻辑中集成工作流 接下来要并行地执行风险分析和财务历史核查,这里是放置分支的最理想地点。 在部门经理最终确认以前,并发的工作流环节必须得到合并。我们可以通过应用一个合并(join)来实现它,合并通过一个条件告诉工作流引擎,是否可以合并并进行到下一环节。在本例中,我们假设这个条件为:前面两个环节都已具有“Finished”的结束状态。即当风险分析或财务审核任何一个未完成前,不能进行到下一步:
Osworkflow体系结构
我们将在本节分析控制osworkflow的体系结构,我们需要理解它是怎样适用到我们的程序中来的。如我们所猜想的,Osworkflow最主要的接口是Workflow,这个接口也是整个工作流引擎的入口点。是整个系统的门面(facade)。
接口的实现主要关注具体的业务操作能力,这个接口定义了工作流查询,获取当前的可执行动作,执行动作,显示历史环节等。
工作流被持久化在工作流存储体(Workflow Store)中,osworkflow提供了几种持久化的方法,包括Hibernate持久化集成,JDBC持久化集成等。一个存储体包含了环节信息,变量,工作流自身的描述信息等等。
用户可能遇到的最常见的应用模式如下所示:
1) 通过给定的状态在工作流存储体中查询工作流信息,通常还根据某一个工作流程中具有需执行动作的用户来进行查询。这种查询时通过WorkflowQuery对象中的Workflow.query()方法实现的。
2) 通过getAvailableActions()方法列出所有在满足条件查询结果中可执行的操作。
3) 通过doAction()方法执行用户选择的动作。在执行动作的时候一些执行参数可以以java.util.Map的形式传递,以实现在工作流定义的运行期进行信息的传递。
4) 用户可以有选择地通过调用initialize()实例化一个工作流。
在理想情况下,由业务逻辑层负责调用osworkflow中的方法,如图二所示:

在osworkflow中,业务逻辑描述在一个XML文件中,称为工作流描述符(workflow descriptor.)。我们将在实现小节中建立一个简单的描述符。在工作流描述符中的功能(functions)和条件(conditions)中,用户可以定义自己的业务逻辑。笔者将在把工作流集成到应用程序中一节中进行论述。
实现
本小节介绍如何把一个业务逻辑抽象成一个工作流。首先我们要在业务流程图中识别出工作流的环节。如图一所示,显然,我们共有四个环节,同时包含一个分支及一个合并。在下面的bank.xml文件中,读者将看到它们在描述符中是如何被表示的。
建立好环节以后,必须在每个环节中添加一些动作以便于工作流运转。每个动作有唯一的无条件结果,条件结果由读者有选择地来实现。
<step id="1" name="Form Filling">
<actions>
<action id="2" name="Fill Form">
<results>
<unconditional-result old-status="Finished" split="1"/>
</results>
</action>
</actions>
</step>
<splits>
<split id="1">
<unconditional-result old-status="Finished"
status="Underway" owner="Risk Analyst" step="2"/>
<unconditional-result old-status="Finished"
status="Underway" owner="Financial Officer" step="3"/>
</split>
</splits>
<joins>
<join id="1">
<conditions type="AND">
<condition type="beanshell">
<arg name="script"><![CDATA[
"Finished".equals(jn.getStep(2).getStatus()) &&
"Finished".equals(jn.getStep(3).getStatus())
]]></arg>
</condition>
</conditions>
<unconditional-result old-status="Finished"
status="Underway" owner="Manager" step="4"/>
</join>
</joins>