在OpenERP中,工做流是管理一組「所作的事情」(與一些數據模型的記錄關聯)的人爲現象。工做流提供了高級別的方式來組織記錄要上作的事情。html
具體地說,工做流是一個定向的路徑,這裏節點稱爲活動而且弧線稱爲流程進度。數據庫
在一個工做流定義中,一個達到了條件,就會觸發進度的推動,這樣工做流的行爲取決於用戶的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環境中)
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,都完成時,工做流實例認爲是完成了。