osworkflow入门实例.docx
《osworkflow入门实例.docx》由会员分享，可在线阅读，更多相关《osworkflow入门实例.docx（18页珍藏版）》请在冰豆网上搜索。
osworkflow入门实例
所有相关的osworkflow的文档大家可以到
下面就开始正文：
在此文以及我的后继关于osworkflow的文档中，不会对工作流相关的基本概念进行解释，这些必备的知识还是需要个人自己充电的。
Osworkflow与目前绝大多书的工作流系统是不同的，而最大的不同点体现在它的韧性上和灵活程度上，在商业界和开源世界都存在它的影子。
最开始大家可能比较难于理解，举个例子：
osworkflow并不强制要求您用图形工具来开发工作流，推荐的首选办法是手写xml文件（即手写过程定义的xml文档，而图形工具操作的实质也是操作此xml，图形工具只是给非专业人士如业务分析人员，过程定义人员使用的）。
它充分胜任这种整合，就想现存代码和数据库之间整合一样。
虽然这样似乎看起来并不太适合进行快速所谓的“即插即用”工作流解决方案，但是osworkflow所提供的解决方案能够提供足够的灵活度来满足一个大型各种应用的所有需求。
Osworkflow的韧性：
可以把osworkflow看做一个低层次的工作流实现。
在其他工作流系统中像loops和conditions这样的情况可以以图形图标形式展现出来，在osworkflow中必须进行编码。
就是说最起码的脚本语言必须来如此设定。
所以并不希望非技术人员来修改工作流。
尽管一些系统提供了GUI操作来完成简单的工作流编辑，但是这种做法并不是十全十美的，如当这样改变流程后，此工作流周边的应用往往被破坏。
所以osworkflow始终认为最好的变更控制办法就是以开发人员（前提：
熟知每个变化）来做这些操作。
Osworkflow在2.5.0版本就开始支持图形操作（designer），2.6.0和2.7.0做了许多改进。
打算在3.0中正式推出。
所以现在在使用GUI操作时候还是需要进行一些适当的预防手段的。
Osworkflow内部使用的是有限状态机的概念（对于这部分理解不好的，可以参看UML中的状态图部分，就可以有个初步理解）。
每个状态都是通过一个stepID和一个状态来共同描述的。
一个变迁（从一个状态到另外一个状态）只有在一个action发生的前提下才会被触发。
在一个工作流的生命周期中始终会有一个或多个活动的状态。
简单的讲就是以工作流引擎和简单xml为基础来完成商务工作流过程处理。
先决知识准备部分：
Osworkflow包括：
Oscore2.0.1+
Propertryset1.2+
Jakartacommons-logging
Beanshell（可选）
BSF（可选）
EJB接口（并不是一定要在EJBcontainer中）
Xml解析（在jdk1.4中并不是必须的）
Osworkflow的api部分将会支持jdk1.3+。
GUIdesigner部分需要1.4的JVM。
关于soap和工作调度：
GLUE部分（我还没接触过，不敢乱讲，大家看原英文解释部分吧。
）大致意思是说如果需要soap或者远程作业调度支持的，就需要下载GLUE专业库。
另外还有就是Quartz来支持。
如果在应用服务器上runQuartz，那么就经过适当配置就不再需要GLUE了，但是必须把作业调度的local参数设置为true。
运行例子：
简单的部署没有什么特别说。
仅仅把osworkflow所带的例子拷贝到tomcat（举例）的webapps下就可以了。
所带的这个例子不需要配置什么DB，当然也就做不了持久性处理（即所有的所有都没存储到实际数据库中。
）当然这并不是实际应用当中所想见到的，这个例子的意义就在于简单的理解osworkflow。
对于进行持久数据存储的例子在英文原件中有，我就不复制粘贴过来了。
大家自己去看就可以了。
具体都是如何修改配置文件，如果tomcat的server.xml文件，以及必要的jar拷贝工作。
这些实际应用的例子会在后继文档中也许会有阐述，如果特别简单就不多写这方面东西了。
感觉上不会复杂。
呵呵^_^
持久存储：
Osworkflow共提供了五种存储机制：
memorystore（默认）自带的例子就是如此，SerializableStore,JDBCStore,ofbizstore,和EJBStore.如果上述这些都没满足您的要求，那就得自己来实现osworkflow的接口com.opensymphony.workflow.spi.workflows了。
具体看api吧。
本文只是入门篇，大致知道有这么一回事的。
不同的存储实现需要不同的配置设置工作。
推荐大家看api（此部分）来完成配置。
原文中给出了JDBC的配置例子：
请参看原文。
工作流定义部分：
Osworkflow尽最大可能使用配置来保证灵活度。
仅一个文件osworkflow.xml需要在classpath中。
这个文件设置了持久存储的方法（jdbc,ejb,ofbiz），工作流工厂类被用来加载工作流定义内容。
默认的工厂是：
com.opensymphony.workflow.loader.xmlworkflowfactory。
从classpath中加载文件。
在测试的时候，更改工作流定义文件然后重新加载它，你可以通过一个reload参数来指定是否完成自动重载。
如果想指定自己的工作流定义，需要继承com.opensymphony.workflow.loader.Abstractworkflowfactory。
然后剩下的就是你自己的任务了。
com.opensymphony.workflow.loader.JDBCWorkflowFactory是一个选择工厂，他允许你存储工作流定义为数据库内容而不是在xml文件中。
一般配置如下：
osworkflow.xml:
...
workflows.xml:
本文结束，谢谢！
！
周日，莫映我们javaparty的伙伴讲了讲osworkflow，估计很多人还是一头雾水。
目前国内似乎关注osworkflow的人越来越多，但是却没有多少人去关注其真正值得参考和学习的地方，这是不应该的。
OSWorkflow的确非常灵活，但是我们不光需要知道“用的灵活”，还要知道“深层次的东东”。
于是才有了这个系列介绍的打算：
在阅读此系列之前，请队FSM又算了解，也请先阅读一下这篇文档：
我们现在就先从osworkflow的一个实例如何初始化入手：
首先OS的Workflow，和我们通常所理解的Engine并不是很一样。
在OSWorkflow中没有“Service”的概念，所以每次访问的时候，都可以重新创建一个Workflow对象。
我们可以把这个Workflow理解成一个ExecuteEngine或者ExecuteRunner。
在一个访问请求中，一个Workfow对象负责维护一个流程实例的管理和操作。
Workflowworkflow=newBasicWorkflow（"testuser"）;
DefaultConfigurationconfig=newDefaultConfiguration（）;
workflow.setConfiguration（config）;
longworkflowId=workflow.initialize（"mytest",1,null）;
workflow.doAction（workflowId,1,null）;
我们先来说说initialize方法，可以边看文档，边阅读osworkflow的AbstractWorkflow类：
在你的一个工作流定义文件中，至少是需要定义一个initialaction。
这些initialaction其实就是流程实例的可能运行起点。
就如同我们通常说说的startnode或者startactivity等等。
xmlversion="1.0"encoding="UTF-8"?
>
...
...
在initialize方法中，主要是存在四个功能：
（1） 创建流程实例对象，在osworkflow中，流程实例对象用WorkflowEntry接口的子类实现
（2） 构造临时变量的集合，即transientVars；用于在一个转移过程中临时保持数据状态
（3） 获取指定的Action对象
（4） 执行这个Action，并造成转移，即transitionWorkflow方法
这几个功能中，重中之重，也是OSWorkflow的最为核心的算法，就是最后的转移。
在这转移过程中，会执行下面的一系列操作：
（这张列表最初是由莫映整理，我补充和修改了一些）
（01）Getcurrentstep（获取当前的Step）
（02）ValidatetransientVars（验证临时变量）
（03）Validateinputs（验证输入的数据）
如果step不为null（执行初始化action的时候，currentstep还不存在）
（04）Executepost-functions（step-level）（执行step的postfunction）
（05）Executepre-functions（action-level）（执行action的prefunction）
（06）Checkeachconditionalresults（检查每一个条件的执行结果）
（07）Executepre-functions（result-level）（运行result的prefunction）
（08）Movecurrentstepintohistory
（09）Createnewcurrentstep
（10）Executepre-functions（step-level）
（11）Executepost-functions（result-level）
（12）Executepost-functions（action-level）
如果是初始化动作
（13）MarktheentrystateasActivated
如果是结束动作
（14）SettheentrystateCompleted
获取globalActions中可以自动执行的，并执行
（15）performavailableandautoglobalactions
OSWorkflow深层讲解系列
（二）流程实例的结束之一收藏
下面来说说OSWorkflow流程实例的结束。
在workflowpattern中有一种模式：
ImplicitTermination（隐性终止）。
这种模式描述了这样一种情形：
活动集中没有任何可以执行（或有可能执行）的活动，此时流程实例已经不能进行任何操作和运转。
这个和我们通常所说的死锁，不是一回事情：
流程的死锁是表示流程实例依然存在可以运行（或必需运行的）的活动实例，但是由于缺少资源而不能执行某项操作而造成流程实例没有正常运行。
这种情况最为典型的就是，某一个出差了，但是没有设置代理，造成任务没有执行。
在OSWorkflow支持了ImplicitTermination。
当然OSWorkflow也支持我们最为常用的设置结束点。
先说说OSWorkflow对设置结束点的支持，这个是非常容易的，只需要将Step中的某一个Action的属性finish的值设置为“true”即可。
既然这么简单，我为什么还要说呢？
既然一个简单东东还拿来说，那就说明这个东东其实不简单。
让我们来思考一个问题，OSWorkflow为什么会将finish这个属性放在了Action而不是放在了Step上呢？
依据我们通常说理解的：
在众多活动节点中，有一个结束节点，这个结束节点表示了流程实例结束的语义。
实际上很多工作流引擎都是这么做的，shark,jbpm,yawl等等。
这是因为在OSWorkflow的视角中，并没有一个Step这个概念。
OSWorkflow真正只有两个视角：
State和Action。
而step和status只是联合扮演了state的角色。
所以在OSWorkflow的执行引擎类中，只有doAction等等操作方法，而没有doStep之类的方法。
对于执行引擎来说，其只知道，任何一种状态，都必然意味着是由某种action所引起的变化结果。
Action上设置Finish，表示这个Action只要发生，其产生的结果状态就是“Finish”。
——这是FSM（有限状态机）的基本原则——一个Finish状态的产生，就表示整个流程实例的结束。
所以想把OSWorkflow的精华理解透彻，就必须在脑海中先暂时放弃“活动”、“结束点”、“起始点”之类的概念。
——所以在这里顺便说一句额外的话，OSWorkflow其实并不是非常适合刚刚接触工作流的初学者。
刚刚接触工作流的人，个人建议还是先钻研钻研WFMC的一些东东，虽然我们都说XPDL这不好，那不好，其实xpdl之中有很多值得参考的思想。
再说说OSWorkflow对ImplicitTermination的支持。
Osworkflow对隐性终止是很容易的，虽然现实中，我们不会去故意去创造“隐性终止”这种情况，也更不希望这种情况的发生。
在OSWorkflow任意一次的action的执行后，如果这个action没有造成流程实例的终结，那么就会去检测是否存在隐性终止的情况存在。
publicvoiddoAction（longid,intactionId,Mapinputs）{
······
if（!
transitionWorkflow（entry,currentSteps,store,wf,action,transientVars,inputs,ps））{
checkImplicitFinish（id）;//这个id是流程实例id
}}
transitionWorkflow方法我们在第
（一）篇中已经有所介绍了，再次就不再叙述。
transitionWorkflow返回的结果是这个流程实例是否已经结束。
在checkImplicitFinish方法中，主要是遍历当前所有的currentstep节点（这些currentstep节点就表示当前处于运行中的活动节点）。
如果这些currentstep都没有被定义action，那么整个流程实例就存在隐性的结束。
说道这里就结束了吗？
当然不了，因为上面这百来字的短文太简单了，即使我不说，大家一看代码就会一清二楚。
要说就说点让人值得思考的：
在OSWorkflow中，几乎所有的status都是外界定义的，就是说你可以定义自己的status，然后再workflow.xml中指明某个action的结果造成另一个step的某种status。
只有一处地方状态是osworkflow自己所约束的，就是action中的finish状态。
osworkflow本身并不知道这些status本身所代表的具体含义。
虽然osworkflow提供了几个status的定义参考，比如finish,queue等等。
但是这些对osworkflow引擎来说，并没有实际的意义。
所以在OSWorkflow的隐性终止判断中，就存在一个值得回味的地方。
这个时候，我们在回过头来看看OSWorkflow的checkImplicitFinish方法：
其回遍历所有的currentstep，并且依据每一个step的定义来判断（注意采用的是定义，而非step实例）。
依据每一个currentstep是否存在action来判断。
乍一看，可能很多人会认为这种判断是存在漏洞的：
如某个step还在运行怎么办（这个step没有定义action）。
——这就是值得回味的地方。
在osworkflow中，你即使在同一个step中，想从一个status到另一种status，也必须定义action。
如果这个step不存在action，那说明什么呢？
就说明这个step的状态根本就不允许更改，既然不允许更改，那么这个step的实例也就没有任何运行的意义。
——OSWorkflow的隐性终止的判断原则也就这么出来了。
我一直都说OSWorkflow是遵循FSM的，那么是在什么地方遵循呢？
就是在这些判断规则和原则上一点一滴的遵循。
对于OSWorkflow来说那些，function,conditon只是一个外设。
OSWorkflow讲解系列（三）Function与workitem收藏
接下来说说，如何利用OSWorkflow的function进行任务的分配：
OSWorkflow是只是一个workflowengine的内核体。
我们都说osworkflow非常的易扩展，但是这也同样说明了，用osworkflow去实现一个能够运行的工作流系统是非常繁琐的事情。
繁琐并不是难，因为你要想实现一个流程，不得不自己去实现大量的condition和function。
既然说到工作流，那么肯定会涉及到“任务交给谁做”的问题。
但是OSWorkflow压根就没有管这种需求，对于其来说，其提供了c和f，如果再有什么额外的需求和功能，那么就扩展condition或function。
于是，你不得不扩展一些function类去处理“角色”“任务分配”“提交任务”等等诸如此类的操作。
在我的标题中提到了workitem，这个概念几乎在其他工作流引擎都有所体现，但是对osworkflow来说，这是一个空白区域。
至于workitem的含义，请参考wfmc的《Terminology&Glossary》。
OSWorkflow引擎只负责了“流程的运转”，当然这个运转会根据你所定义的Action和condtion来判断。
Funtion对osworkflow来说，只是step、action、result执行过程需要调用的功能，至于这个功能作什么，OSWorkflow并不关心，引擎只是负责提供几个参数接口。
publicinterfaceFunctionProvider{
publicvoidexecute（MaptransientVars,Mapargs,PropertySetps）throwsWorkflowException;
}
所有的Function实现类都必须实现这个FunctionProvider接口中execute方法，而且能够处理的信息，也全部来自这个方法中的三个参数：
transientVars
这个是最为核心的参数，记录非常重要的一些对象，比如WorkflowContext，WorkflowEntry，输入参数等等。
args
这个是function配置中的arg参数，具体请参考osworkflowdtd
ps
是PropertySet对象，记录了流程实例所需要保存的数据，可以理解成osworkflow所描述的流程相关数据。
具体transienVars中包含哪些对象，请参考FunctionProviderapidoc。
下面就说说如何利用Function进行任务的分配。
个人建议你在Step的pre-function中做处理，配置如下：
nucleus.assign.AssignmentFunction
A
role
22
······
看了这个配置形式，我想大家应该明白如何去处理。
你可以在function中获取自己所定义的角色、根据角色获取人员、根据人员产生workitem······。
你在function所作的这一切操作对osworkflowengine来说都是透明的——你所产生的worklist所代表的含义只有你自己知道。
其中我为什么会附加了一个arg属性：
actionID？
这是因为我需要告诉每一个workitem在其应该处理哪一个动作。
因为外部程序都是通过Workflow.doAction（long,int,java.util.Map）这个接口来激活流程的运转或改变实例的状态。
总体来说，利用osworkflow去实现一个完整的工作流例子，还是比较麻烦的。
主要是要扩展和自己实现的太多。
/*
*Author:
MeansonWang
*Date:
2005-01-15
*Email:
meansonw@
*/
OSWORKFLOW-如何设置Osworkflow的日志及将级别设为[DEBUG]
工作流OSWORKFLOW使用的是Commons-logging组件来进行日志管理。
但默认的日志级别是【DEBUG】，虽然HANI的手册中提到【注意，是提到】了设置日志的方法，却并不怎么灵光。
看他的MAILLIST，也是爱理不理，到也是，不喜欢写手册是每个程序员的通病，更别提手把手教你如何配置他的软件啦，“一点技术成分都没有”。
呵呵。
其实很简单，了解了Commons-logging就一了百了。
Commons-logging最强的地方就是，它可以使用多个日志组件来记录日志，自动搜索你的【CLAS
升级会员 