在OpenERP中,工作流是管理一组“所做的事情”(与一些数据模型的记录关联)的人为现象。工作流提供了高级别的方式来组织记录要上做的事情。
具体地说,工作流是一个定向的路径,这里节点称为活动并且弧线称为流程进度。
- 活动定义了OpenERP应该处理的工作,比如改变某些记录的状态,或者发送邮件。
- Transitions 控制了活动之间工作流的处理进度
在一个工作流定义中,一个达到了条件,就会触发进度的推进,这样工作流的行为取决于用户的actions(比如点击一个按钮),变更记录,或者任意的Python代码。
Basic(基本)
使用数据文件定义一个工作流是很直截了当的:针对activities和transitions的记录工作流是与记录一起给出。例如,这里是定义在XML中简单的一系列的两个activities。
<record id="test_workflow" model="workflow">
<field name="name">test.workflow</field>
<field name="osv">test.workflow.model</field>
<field name="on_create">True</field>
</record>
<record id="activity_a" model="workflow.activity">
<field name="wkf_id" ref="test_workflow"/>
<field name="flow_start">True</field>
<field name="name">a</field>
<field name="kind">function</field>
<field name="action">print_a()</field>
</record>
<record id="activity_b" model="workflow.activity">
<field name="wkf_id" ref="test_workflow"/>
<field name="flow_stop">True</field>
<field name="name">b</field>
<field name="kind">function</field>
<field name="action">print_b()</field>
</record>
<record id="trans_a_b" model="workflow.transition">
<field name="act_from" ref="activity_a"/>
<field name="act_to" ref="activity_b"/>
</record>
定义的工作流关联到一个特定的模型(这个模式由模型workflow的osv属性给出)。activities或者transations内指定的方法将在这个模型上调用。
在上路的例子代码中,创建了一个调用test_workflow的工作流。其由两个activities,“a”和“b”,一个transation,从a到b,组成。
第一个activity有属性flow_start,并设置为true,这样OpenERP知道在工作流实例化后从哪里开启工作流便利。因为工作流记录的on_create设置为true,为每个新创建的记录实例化工作流(否则,要通过其他的方式实例化工作流,比如一些模块的Python代码)。
当实例化工作流时,从activity a开始。那个activity是一种函数,意味着模型test.workflow上的方法action pring_a调用(通常传递cr,uid,ids,context参数给它)。
a和b之间的transation不指定任何条件。意味着处理a后工作流实例立即从a走向b,并稍后处理activity b。
Transation(迁移)
Transation提供了一个控制结构安排工作流。当一个activity完成时,工作流引擎就试着从一个完成的activity(活动)流向下一个activity(活动)。在它们最简单的表单中(如同上面的例子),它就继续连接activities(活动):即之前的activities(活动)处理完成就处理后面的activities(活动)。
作为一下子运行所有的activities(活动)的替换,其也可能在transitions(迁移)上等待,仅当匹配了某些条件才能通过。标准是条件,信号或者触发。它们将在下面详细讨论。
Conditions(条件)
当完成一个activity时,检查它的输出Transation决定工作流实例处理它们并到达下一个activity。当只定义了一个条件时(没有信号,没有触发),OpenERP评估这个条件,如果评估为true,工作流实例处理通过transation。如果条件不匹配,在每次关联的记录修改时都会再评估一次,或者通过一个显示的方法调用做这件事。
默认地,属性condition(即评估表达式) 是true。注意条件可能有几行长,在那种情况下,最后的一个值决定了是否采取通过。
在条件评估环境中,定义了几个方便的符号(除了在OpenERP的safe_eval环境中)
- 所有的模型列名,and
- 所有浏览器记录属性
Singals(信号)
除了条件外,一个transation可以指定一个信号名。当使用一个信号名时,transation不会直接通过,即使condition评估为true。阻塞transation,等待被唤醒。
为了唤醒一个由信号名定义的transation,信号必须发送给工作流实例。发送信号的通用方式是在用户界面使用一个按钮,使用元素<button/>并且信号名作为按钮的属性name。一旦点击了按钮,信号发送给当前记录的工作流实例。
注意
当信号发送给工作流实例时,仍要评估条件。
Triggers(触发)
条件评估为fasle,transation不会通过(并且它引导的activity不立即处理)。工作流实例仍然可以通过提供所谓的触发器处理transation。这是发生在条件不满足,触发器记录在数据库中的情况下。之后,可能唤醒工作流实例,其安装了那些触发器,提供它们重新评估transation条件。这种机制使得唤醒工作流实例很便宜,只是针对几个(安装了触发器的工作流)而不是全部
触发器以记录IDs记录在数据库中(与模型名字一起)并适用于等待那些记录的工作流实例。transation定义提供了一个模型名(属性trigger_model)和一个Python表达式(属性trigger_expression),在给定的模型中评估成一列记录IDs。那些记录的任何一个可以唤醒它们关联的工作流实例。
注意
无论什么时候transation重试,触发器不重装。
Splitting and joining transitions(拆分和联合过渡)
当多个transitions离开同一个activity,或者流向同一个activity,OpenERP提供了获取哪个transition的控制,或者如何处理到达的activity。activity的split_mode和join_mode 属性用于这样的控制。那些属性的可能值解释如下。
Activities
transition可以通过工作流的控制结构看见,activities是事件发生的地方,从改变记录状态到发送邮件。
存在不同的activities:Dummy,Function,Subflow和Stop all,当activity处理时每个做不同的事情。除了这些类型,activity还有其他属性,详情看下面。
Flow start and flow stop(流开始和流结束)
flow_start属性是一个布尔值,指定了当工作流实例化时,activity是否在处理。多个activities能将其属性flow_start设置为true。当为一个记录实例化一个工作流时,OpenERP简单地处理所有,并之后评估输出的transitions。
属性flow_stop是一个布尔值,指定activity是否停止工作流实例。当所有的activity,其flow_stop属性设置为true,都完成时,工作流实例认为是完成了。