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

在OpenERP中,工做流是管理一組「所作的事情」(與一些數據模型的記錄關聯)的人爲現象。工做流提供了高級別的方式來組織記錄要上作的事情。html

 

具體地說,工做流是一個定向的路徑,這裏節點稱爲活動而且弧線稱爲流程進度。數據庫

  • 活動定義了OpenERP應該處理的工做,好比改變某些記錄的狀態,或者發送郵件。
  • Transitions 控制了活動之間工做流的處理進度

在一個工做流定義中,一個達到了條件,就會觸發進度的推動,這樣工做流的行爲取決於用戶的actions(好比點擊一個按鈕),變動記錄,或者任意的Python代碼。express

 

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,組成。ui

 

第一個activity有屬性flow_start,並設置爲true,這樣OpenERP知道在工做流實例化後從哪裏開啓工做流便利。由於工做流記錄的on_create設置爲true,爲每一個新建立的記錄實例化工做流(不然,要經過其餘的方式實例化工做流,好比一些模塊的Python代碼)。spa

 

當實例化工做流時,從activity a開始。那個activity是一種函數,意味着模型test.workflow上的方法action pring_a調用(一般傳遞cr,uid,ids,context參數給它)。.net

 

a和b之間的transation不指定任何條件。意味着處理a後工做流實例當即從a走向b,並稍後處理activity b。code

 

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 和AND
 
 
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
相關文章
相關標籤/搜索