《深入理解OpenERP的工作流(Workflow)》由会员分享，可在线阅读，更多相关《深入理解OpenERP的工作流(Workflow)（5页珍藏版）》请在金锄头文库上搜索。
1、深入理解 OpenERP的工作流(Workflow) 一、工作流定义：workflow.nameresource.modelTrue | Falsemodel：固定取值workflowid：任意值，唯一标识本工作流name: 工作流的名称，任意定义osv： 本工作流关联的对象类型，是 OpenERP模块中定义的某对象名，如采购单对象（purchase.order）。是本工作流处理的数据对象。on_create：每当系统新产生一个 osv 中定义的对象的实例时候，是否对应的产生一个和该对象实例关联的工作流实例。默认是 True.工 作流和工作流实例：工作流定义了对某一类型的对象，如采购订单（PO
2、）的处理流程。例如，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对象上。即工作流实现了流程处理相关的代码和被处理对象的代
3、码相分离，降低了不同处理代码的耦合性，增加了系统功能的柔软性。二、活动（Activity）定义activity.name dummy | function | subflow | stopallsubflow_id(.)(.)XOR | OR | ANDXOR | AND(.)True | FalseTrue | Falsemodel：固定取值 workflow.activitywkf_id：本 Activity所属的工作流 idname: 本 Activity名称，任意值kind：本 Activity类型，有 Dummy, Function, Subflow, Stop All 四种。kin
4、d说明，如果流程到达本节点，系统应执行的动作类别。Dummy 表示不执行任何动作，即 action中定义的代码不会被执行。Function 表示执行 action中定义的 python代码，且，执行 action_id中定义的 server action。常见情况是，action 中定义一个 write方法，修改流程关联的对象的状态。对于 Function类型的节点，action 中定义的代 码或者返回 False，或者返回一个客户端动作 id（A client action should be returned）。Subflow类型表示触发“subflow_id”中指定的工作流。仔细的读者或
5、许要问，工作流的执行总是和某个被处理的对象关联，是的，如果定义了 action，subflow 关联的对象 id 由 action中定义的代码返回。如果没有定义action，系统默认 subflow关联的对象和本节点所属的工作流处理的对象 id一致。stopall 类型表示，流程到此节点则结束，但结束前，系统仍会执行action中的代码。signal_send：执行完本节点的动作 （action 及 action_id定义的动作）后，应向别的工作流发往的 signal，格式是：subflow.signal。subflow_id 和 signal_send必须配合使用，subflow_id 表示
6、，触发子工作流 subflow_id，在该子工作流中，通常必须定义 signal_send，signal_send 定义父流程中的某个 signal，表示，子流程处理结束后触发父流程中的信号 subflow.signal。注意，用于父子流程通信的工作流 signal必须是形如 subflow.* 。例如，在HR模块的 workflow wkf_expenses中，需要开发票时候，它触发流程account模块中的工作流“account.wkf”（）。account.wkf 处理完成后，发出信号 subflow.paid 通知 wkf_expenses流程（subflow.paid）。wkf_ex
7、penses 中定义了信号 subflow.paid（subflow.paid）。split_mode： 有三个选项，XOR，OR，AND，默认是 XOR。XOR 表示，由本节点始发的出迁移中，沿着第一个满足迁移条件的迁移跳转。OR 表示由本节点始发的出迁移中，只要满足迁移条件即沿该迁移跳转。AND 表示由本节点始发的出迁移中，只有所有迁移皆满足迁移条件才跳转，而且是同时沿所有迁移跳转。XOR 只有一个跳转，OR 有零或多个跳转，AND 有零或全部跳转。join_mode：有两个选项，XOR，AND，默认是 XOR。XOR 表示，以本节点为终点的入迁移中，只要有一个跳至本节点，即执行本节点的
8、action。AND 表示，以本节点为终点的入迁移中，只有所有迁移都已经跳至本节点，才执行本节点的action。flow_start：表示流程的开始节点。flow_stop：表示流程的结束节点。三、迁移（Transition）的定义迁移的完整 XML 定义格式如下。(.)(.)(.)(.)act_from：本迁移的起始节点，引用之前定义的 Activity。act_to：本迁移的结束节点，引用之前定义的 Activity。signal： 触发本迁移的信号，表示，如果系统收到 signal定义的信号，则触发本迁移。触发信号有三种方式，1）最常见的是用户点击视图中的“name = 本处定义的 si
9、gnal”的 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代
10、码，通常是一个函数调用。当系统收到 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关联的工作流实例。然后，可以调用 workflo
11、w_service的方法 trg_trigger(self, uid, res_type, res_id, cr)实际执行该工作流。实际使用例子请参考 Sale模块的工作流定义 wkf_sale：procurement.orderprocurement_lines_get() 最后编辑时间 : 六月 27, 2011, 03:31:46 下午 作者 NewZN 迁移（Transition）的定义漏了权限组 group_id，修正如下。表示只有该权限组可以触发本迁移。迁移的完整 XML 定义格式如下。(.)(.)(.)(.)上文关于 Trigger model和 Trigger expr_id的
12、解释不够清楚，更清楚的解释参看链接：http:/ explain here what these two fields do: trigger_model and trigger_expr_id, for people looking for help :- These fields let you ask for an evaluation of the condition when a specific object changed.For example, suppose you want to set a Sale Order into the state Done once it h
13、as been shipped. The first the time the condition will be evaluated, it will be False. But later (some days after), we will confirm the shipping order. But our workflow condition is not checked again. Unless you define trigger_model and trigger_expr_id.- Trigger model: The object type which will tri
14、gger an evaluation of your condition.- Trigger expr_id: A list of model ids which will trigger the condition.For example, to take the example of our Sale Order, we dont want to check the condition each time a shipping order is confirmed, but only when the shipping order associated to our sale order
15、is confirmed !Note: You can put a call to a function into trigger_expr_id, like get_shipping_ids(), or you can directly put a python value (like in my example in the previous post).WARNING: Currently (OpenERP 6.0) you can only use trigger_model and trigger_expr_id a few objects: account.move.line, procurement.order and stock.move !
