当前位置: 首页 > 知识教程 > 详细解析OpenERP的工作流
详细解析OpenERP的工作流
Odoo,OpenERP中文网 / 2013-12-06

一、工作流定义:

  1. <?xml version="1.0"?>
  2.   <terp><data>
  3.     <record model="workflow" id=workflow_id>
  4.     <field name="name">workflow.name</field>
  5.     <field name="osv">resource.model</field>
  6.     <field name="on_create">True | False</field>
  7.   </record>
  8. </data></terp>

model:固定取值"workflow"
id:任意值,唯一标识本工作流
name: 工作流的名称,任意定义
osv: 本工作流关联的对象类型,是OpenERP模块中定义的某对象名,如采购单对象(purchase.order)。是本工作流处理的数据对象。
on_create:每当系统新产生一个osv 中定义的对象的实例时候,是否对应的产生一个和该对象实例关联的工作流实例。默认是True.
工作流和工作流实例:工作流定义了对某一类型的对象,如采购订单(PO)的处理流程。例如,PO单的一般处理流程也许是:1)新建PO,State = draft;2)审批PO,审批的同时,a)系统自动产生收货单,工仓库收货;b)系统自动产生凭据(Invoice),供财务确认付款;c)系统自动产生PDF的采购订单,并自动EMail给该PO单对应的供应商。但对于特定的某个PO对象,需要一个工作流实例,以记录本PO对象处在流程的哪个阶段,如PO1尚在draft状态,PO2已经审批通过。
PO单的审批,以及对应的a)、b)、c)的动作,都可以在OE的工作流中定义解决,而不需要全编码在PO对象上。即工作流实现了流程处理相关的代码和被处理对象的代码相分离,降低了不同处理代码的耦合性,增加了系统功能的柔软性。

二、活动(Activity)定义

  1. <record model="workflow.activity" id="activity_id">
  2.   <field name="wkf_id" ref="workflow_id"/>
  3.   <field name="name">activity.name</field>
  4.   <field name="kind">dummy | function | subflow | stopall</field>
  5.   <field name="subflow_id">subflow_id</field>
  6.   <field name="action">(...)</field>
  7.   <field name="action_id">(...)</field>
  8.   <field name="split_mode">XOR | OR | AND</field>
  9.   <field name="join_mode">XOR | AND</field>
  10.   <field name="signal_send">(...)</field>
  11.   <field name="flow_start">True | False</field>
  12.   <field name="flow_stop">True | False</field>
  13. </record>

model:固定取值workflow.activity
wkf_id:本Activity所属的工作流id
name: 本Activity名称,任意值
kind:本Activity类型,有Dummy, Function, Subflow, Stop All 四种。kind说明,如果流程到达本节点,系统应执行的动作类别。
  Dummy 表示不执行任何动作,即action中定义的代码不会被执行。
  Function 表示执行action中定义的python代码,且,执行action_id中定义的server action。常见情况是,action中定义一个write方法,修改流程关联的对象的状态。对于Function类型的节点,action中定义的代码或者返回False,或者返回一个客户端动作id(A client action should be returned)。
  Subflow类型表示触发“subflow_id”中指定的工作流。仔细的读者或许要问,工作流的执行总是和某个被处理的对象关联,是的,如果定义了action,subflow 关联的对象id 由action中定义的代码返回。如果没有定义action,系统默认subflow关联的对象和本节点所属的工作流处理的对象id一致。stopall类型表示,流程到此节点则结束,但结束前,系统仍会执行action中的代码。

signal_send:执行完本节点的动作(action及action_id定义的动作)后,应向别的工作流发往的signal,格式是:subflow.signal。subflow_id和signal_send必须配合使用,subflow_id表示,触发子工作流subflow_id,在该子工作流中,通常必须定义signal_send,signal_send定义父流程中的某个signal,表示,子流程处理结束后触发父流程中的信号subflow.signal。注意,用于父子流程通信的工作流signal必须是形如subflow.* 。例如,在HR模块的workflow "wkf_expenses"中,需要开发票时候,它触发流程account模块中的工作流“account.wkf”

  1. <field name="subflow_id" ref="account.wkf"/>

account.wkf处理完成后,发出信号subflow.paid 通知wkf_expenses流程

  1. <field name="signal_send">subflow.paid</field>

wkf_expenses中定义了信号subflow.paid

  1. <field name="signal">subflow.paid</field>

split_mode:有三个选项,XOR,OR,AND,默认是XOR。XOR 表示,由本节点始发的出迁移中,沿着第一个满足迁移条件的迁移跳转。OR 表示由本节点始发的出迁移中,只要满足迁移条件即沿该迁移跳转。AND 表示由本节点始发的出迁移中,只有所有迁移皆满足迁移条件才跳转,而且是同时沿所有迁移跳转。XOR 只有一个跳转,OR 有零或多个跳转,AND 有零或全部跳转。
join_mode:有两个选项,XOR,AND,默认是XOR。XOR 表示,以本节点为终点的入迁移中,只要有一个跳至本节点,即执行本节点的action。AND 表示,以本节点为终点的入迁移中,只有所有迁移都已经跳至本节点,才执行本节点的action。
flow_start:表示流程的开始节点。
flow_stop:表示流程的结束节点。

三、迁移(Transition)的定义
迁移的完整 XML 定义格式如下。

  1. <record model="workflow.transition" id="transition_id">
  2.   <field name="act_from" ref="activity_id_1"/>
  3.   <field name="act_to" ref="activity_id_2"/>
  4.   <field name="signal">(...)</field>
  5.   <field name="condition">(...)</field>
  6.   <field name="trigger_model">(...)</field>
  7.   <field name="trigger_expr_id">(...)</field>
  8. </record>

act_from:本迁移的起始节点,引用之前定义的Activity。
act_to:本迁移的结束节点,引用之前定义的Activity。
signal:触发本迁移的信号,表示,如果系统收到signal定义的信号,则触发本迁移。触发信号有三种方式,1)最常见的是用户点击视图中的“name = 本处定义的signal”的button,此时相当于向系统发送迁移信号量。系统会根据视图中的对象id,找到对象关联的workflow,再找到与button name相同的signal,触发之。2)调用workflow_service的方法:trg_validate(self, uid, res_type, res_id, signal, cr),此方法表示,触发对象类型res_type关联的workflow的signal信号,工作流实例关联的对象实例是 res_id。3)子流程的signal_send 发出的信号,此种情况前文已说过。
condition:迁移的条件,是一段Python代码,通常是一个函数调用。当系统收到signal中定义的信号时候,检查此处的条件,条件为真则实际触发迁移。
trigger_model和trigger_expr_id:此二字段表示启动一个新工作流实例。trigger_model定义对象类型,trigger_expr_id 定义一段Python代码,返回trigger_model类型的对象id。此二字段表示,如果act_from 中的action 执行完毕,且condition 条件OK,则系统中插入一个trigger_model类型,trigger_expr_id返回的对象id关联的工作流实例。然后,可以调用workflow_service的方法trg_trigger(self, uid, res_type, res_id, cr)实际执行该工作流。实际使用例子请参考Sale模块的工作流定义 wkf_sale:

  1. <field name="trigger_model">procurement.order</field>
  2.             <field name="trigger_expr_id">procurement_lines_get()</field>

 

迁移(Transition)的定义漏了权限组group_id,修正如下。表示只有该权限组可以触发本迁移。
迁移的完整 XML 定义格式如下。

  1. <record model="workflow.transition" id="transition_id">
  2.   <field name="act_from" ref="activity_id_1"/>
  3.   <field name="act_to" ref="activity_id_2"/>
  4.   <field name="group_id" ref="groupid"/>
  5.   <field name="signal">(...)</field>
  6.   <field name="condition">(...)</field>
  7.   <field name="trigger_model">(...)</field>
  8.   <field name="trigger_expr_id">(...)</field>
  9. </record>