【轉】Odoo開發之：工做流 workflow

在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，都完成時，工做流實例認爲是完成了。

 

 

對於OpenERP知道工做流實例完成了是很重要的。一個工做流能夠有一個activity，其是另外一個工做流（稱爲子流）。當子流完成了，這個活動也就完成了。

 

Subflow（子流）

一個活動能夠嵌入一個完整的工做流，稱爲子流（嵌入的工做流叫作父工做流）。實例化的工做流經過屬性subflow_id指定。

 

注意

在GUI中，那個屬性不能被設置除非activity的種類是Subflow

 

當其子流完成時這個activity被認爲是完成了（它的輸出transitions準備評估）

 

 

從子流中發送一個信號

 

當一個工做流嵌入了一個工做流的activity（做爲子流），子流能夠從其本身的activities發送一個信號到其父工做流，經過給的信號名（屬性signal_send）。OpenERP經過發送以subflow爲前綴 signal_sen的值給父工做流處理那些activities.

 

換句話說，可能相互交互而且在父工做流中獲取transition，做爲子流中執行的activities。

 

Server actions（服務器action）

一個action能夠運行一個Server Action 經過在屬性action_id中指定其ID。

 

Python action

一個acitivity能夠執行一些Python代碼，由屬性action給出。評估環境與Condition部分解釋的同樣。

 

Split mode（分叉模式）

 

一個activity處理後，就評估其輸出transitions。通常地，若是一個transition能被獲取，OpenERP經過它而且繼續通向transition導向的下一個activity。

 

 

實際上，當多個transition離開一個activity，OpenERP可能繼續或者不，這取決於其餘的transitions。即，transitions上的conditions能聯合在一塊兒，聯合的結果通知OpenERP穿過0,1，或者全部的transitions。這種聯合的方式由屬性split_mode控制。

 

有三種分叉模式：XOR，OR 和ＡＮＤ

 

 

XOR

當遷移與一個XOR分叉模式聯合時，只要第一個知足遷移條件的遷移跳轉，只有 一個跳轉。

 

OR

使用OR模式，只要知足遷移條件即沿着該遷移跳轉。有零個或者多個跳轉。剩餘的遷移條件將再也不評估。

 

AND

使用AND模式，OpenERP只有全部遷移都知足遷移條件才跳轉，並且是沿全部遷移跳轉。有零個或所有跳轉

 

Join mode（合併模式）

 

就像輸出遷移條件能夠合併起來決定它們可否經過同樣，輸入遷移能合併來決定一個activity（活動）是否將處理或者何時處理。屬性join_mode控制那個行爲。

 

有兩種可能的合併模式：XOR和AND

 

XOR

 

使用XOR模式，以本節點爲終點的入遷移，只要有一個跳至本節點，即執行本節點的Action。

 

AND

 

使用AND模式，在處理activity前，OpenERP將等待直到全部的輸入遷移已經經過。（以本節點爲終點的入遷移，只有全部遷移都已經跳至本節點，才執行本節點的Action）

 

種類

 

Activities能是不一樣的種類：dummy，function，subflow，或者stopall。種類定義了一個activity能作的工做類型。

 

Dummy

 

activity的Dummy種類什麼都不作，或者對應activites僅調用一個服務action。什麼都不作的activities用於做爲hubs來獲取/分發translations

 

 

Funcation（函數）

 

對應activity（活動）的Funcation（函數）種類僅須要運行一些Python代碼，而且多是一個Server action。

 

Stop all

activity的 stopall種類徹底中止工做流實例而且標記其已經完成。另外其也能夠運行一些Python代碼。

 

Subflow

當activity的種類是Subflow時，activity插入到另外一個工做流實例。當子流完成時，activity也認爲完成。

 

默認地，the subflow is instanciated for the same record as the parent workflow。經過提供Python代碼（返回一個記錄ID(做爲子流的一樣的數據模型)）可能改變行爲。嵌入的子消息流實例是一個所給的記錄。

 

 

詳細內容請參考官方資料：https://www.odoo.com/documentation/master/reference/workflows.html