第1節. 關鍵字

馳騁工作流引擎 流程快速開發平臺 workflow ccflow jflow

第1節. 接收人規則設計

接收人員規則是節點屬性的一個重要設定，是確定當前接受人範圍的規則，該規則有多種方式組成。

1.1.1: 概要說明

關鍵字：ccbpm節點訪問規則 接收人規則。

相關功能：訪問規則處理內容。

節點屬性配置:如下圖：

功能入口

解釋說明：就是下一步工作人員的接受人範圍處理規則。A運動到B，如何確定B的處理人範圍。根據不同的業務場景，ccbpm提供瞭如下幾種模式，您可以根據自動不同的業務背景設定自己的業務規則。

說明:

1, 下列設定型別，都設定當前節點作用於下一步節點。

2, 每一種型別，都有路徑自動記憶功能，所說自動記憶功能是當節點第一次向下一個節點投遞時，它把要投遞的人記錄下來。

如果您執行了分配系統就把分配的人員，做為接受人員計算.

可以設定的投遞的型別:

為了更好的說明該規則，cc為我們提供了一個流程測試案例，如下圖：

該案例詳盡的設定了各個模式的方法，請開啟相關的節點屬性，對照節點的名稱，執行該流程。

1.1.2: 屬性欄位儲存

該規則是一個節點欄位屬性，當然要存在節點表裡，WF_Node

1.1.3: 開始節點的接受人規則設計

開始節點是一個特殊的節點，是整個流程的入口，一個流程只有一個開始節點。

開始節點的訪問規則是為了確定那些人可以發起該流程。

開始節點的訪問規則與其他節點也不相同，如下圖。

我們從規則名稱的字面意思不難理解，如何為開始節點繫結可以發起的工作人員。

1.1.4: 中間節點的接受人規則設計

1.1.4.1: 按組織結構結算

本章節詳細的介紹了每種訪問規則在不同場景下的應用，使用者可以根據不同的情況使用不同的訪問規則。

1.1.4.1.1: 按崗位智慧計算

設定方法: 在下一個節點上的節點屬性裡，設定節點崗位。這是預設的投遞規則，他是在下一個節點設定崗位時按照崗位計算. 他的計算方式，首先按照當前操作員的部門範圍計算。如果該操作員部門下沒有這個工作崗位的人員，CCBPM就會把當前操作員的部門級次提高一個級別，在尋找，依次計算。理解了這個演算法，您就不難理解為什麼，本部分的業務，只能讓本部門的經理審批了.

舉例說明:一個省機關下面有n個縣，n個市，n個縣. n個所. 一個所員受理人員的業務，只能讓自己的所長審批，所長的業務只能投遞到本區縣的相關業務部分審批，而非其它區縣業務部分審批。

這就是崗位的許可權與部門許可權的交叉形成的被投遞的人員集合. 這就是ccbpm經常說的。

崗位：表示能做什麼事情。部門: 表示能做那裡的事情。崗位+部門: 表示一個操作員能做那裡的那些事情。

1.1.4.1.2: 按節點繫結的部門計算

設定方法:在當前節點上的節點屬性裡,設定節點崗位.

CCBPM會按照您指定的部門下面的人員，進行投遞, 就是這個n個部門下面都可以接受這個工作. 這個類於傳送郵件的按照郵件組進行傳送。

1.1.4.1.3: 按節點繫結的人員計算:

節點繫結那些人員，該系統就會發送給這些人，如下圖設定。

1.1.4.1.4: 按繫結的崗位與部門交集計算

設定方式:在節點崗位，節點部門都設定。

執行方式：ccbpm會取既具備此崗位集合的又具備此部門集合的人員，做為本節點的接受人員。

1.1.4.1.5: 按繫結的崗位計算並且以繫結的部門集合為緯度

該場景用的較少，不說明了。

1.1.4.1.6: 按指定節點的工作人員或者指定欄位人員的崗位計算

應用場景：為一個單位設定一個裝置維修流程，此單位下分好多部門，有一個IT部門負責計算機裝置維修。每個部門的成員如果有裝置維護的需要，首先填寫一個單子向這個IT部門的受理人員傳送詳細的故障說明。IT受理人員接受到此請求後，根據情況傳送到該發起人的部門領導那裡去。

這是簡單的三個步驟，發起-》IT部門受理-》發起的部門負責人審批。第一步驟基層人員發起，第二步驟是IT受理崗人員受理。第三個步驟中層領導審批。在第三個節點訪問規則就是按按指定節點崗位計算。因為如果按崗位計算在第二步驟就要傳送給IT部門經理審批而非發起人的部門經理審批了。預設的按崗位計算就是按上一個節點的崗位計算，現在的應用場景就是要按指定的節點崗位計算了。

設定方式:在接受物件中設定一個節點編號比如:101。

執行方式：ccbpm在處理接受人時，會按指定節點上的人員身份計算，而非按上一步驟的人員身份計算了。

其它：這種方式是對按崗位計算的補充。

變更記錄: 2015/10/8為了適應能夠按指定的表單欄位作為人員，特支援為，也可以指定一個表單欄位作為處理人。

對於原來設定節點的方式也有效，如果設定一個欄位名稱，ccbpm就從表單欄位取值作為接收人。

1.1.4.1.7: 僅按繫結的崗位計算

按照節點上繫結的崗位來計算接受人，這裡去掉了部門維度的過濾。

1.1.4.2: 按指定節點處理人

1.1.4.2.1: 按上一節點表單指定的欄位值作為本步驟的接受人

設定方式: 在當前節點屬性訪問規則處理內容中指定此方式，在上一個節點的表單上新增一個SysSendEmps的文字框。

執行方式: 在使用者填寫上一個步驟的節點表單時，這個指定的欄位可以用逗號分號分開，可以輸入多個接受人員的編號。下一步的接受人員就按使用者輸入的內容結束。
說明：這種方式就類似於傳送郵件。

1.1.4.2.2: 與上一節點處理人員相同

節點A是甲處理，傳送到節點B,也是需要甲處理。

1.1.4.2.3: 與開始節點處理人相同

當前節點的處理人與開始節點一致，發起人是zhangsan,現在節點的處理人也是他。

1.1.4.2.4: 與指定節點處理人相同

應用場景1：A B C 三個節點, B向C傳送時C的接受人員要求與A的工作人員一致。

設定方式: 在[訪問規則處理內容]中設定一個節點ID比如:101。

應用場景2：如下圖，當一個節點可以多個節點可以到達時，在【訪問規則處理內容】需要配置多個節點的ID值，如下圖：

節點3，可能是從節點1，或者節點2轉到節點3，如果在節點3上配置此規則就要配置節點2節點1的兩個節點ID，用逗號分開，例如: 507,509。這種情況下ccbpm就會自動判斷節點3究竟是從那個節點上過來了，從而把處理人投遞給節點3。

對父子流程的支援：

2015年1月28日為珠海高凌變更：如果是父子流程，在子流程上的一個節點要指定與父流程的一個節點的人員相同，配置方式不變化。

比如：父親流程甲，呼叫子流程乙，在乙的一個節點上的工作處理人員與甲的一個節點處理人員相同，那就在該引數裡設定甲的節點編號，可以是多個變化，如果甲是一個子執行緒也同樣支援。

1.1.4.3: 按自定義SQL計算

1.1.4.3.1: 按設定的SQL獲取接受人計算

按SQL計算通俗好理解，就是ccbpm在執行一個查詢sql時，返回一個數據源，在資料來源里約定該節點的接收人資訊。

設定方法: 在當前節點屬性裡 [接受人SQL]設定一個sql 語句. 這個select 查詢語句有一個列. No 分別表示，操作

編號, 操作員名稱. 這個sql可以有引數.

比如: 1, SELECT No,Name FROM PORT_EMP WHERE [email protected]_Dept

查詢出來當前操作員中的部門下的所有人員.

2, SELECT xxx as No, yyy as Name FROM dbo.xxxx.YourTable WHERE 欄位名稱[email protected]表單欄位名稱.

從您的業務系統中，查詢一組人員，變數可以是當前節點欄位的編號，格式為 @+欄位英文名稱.

關於合流點的接受人按sql獲取接受的表示式的問題

注意子執行緒向合流點發送時，接受人規則的表示式的變數是臨近合流點的子執行緒節點變數。

比如: 流程編號為ABC三個節點.

A 是分流點，B是合流點 C是子執行緒。

如果C的接受人員規則是按sql計算:

配置的表示式如下表達式是錯誤的:

select UserNo as No, xx as Name from ND2701 WHERE [email protected]

如下表達式才是正確的:

select UserNo as No from ND2701 WHERE [email protected]

這是因為子執行緒在傳送時獲取的變數OID 是子執行緒的ID而非，幹流上的WorkID.

關於子執行緒接受人的特殊約定：

如果遇到分組的維度,就約定返回4個列來解決問題，流程demo:\\流程樹\\同表單分合流\\一人多子執行緒模式(批次維度任務模式)流程.

在第2個子執行緒節點配置瞭如下SQL。

該資料來源返回了三個列，分別是：No,Name, GroupMark

No=操作員編號，Name=操作員名稱, GroupMark就是分組的維度.

比如配置的SQL: SELECTNo,Name,FK_DeptFROMPort_EmpWHEREFK_Deptin('2','5')

應用場景: 有一批物品需要化驗，一個人員可能需要承擔多個化驗專案，這就需要這個人在這個子執行緒裡有n件工作。再比如：一件工作需要下發兩個部門處理，如果一個部門的一個人處理了，另外該部門的人員的工作就要自動去掉，屬於搶辦任務，也就是說，子執行緒也需要搶辦任務。

對動態表單樹的支援:

什麼是動態表單樹？請參節點屬性、表單、表單型別章節。簡單的說，該節點的表單是有上一步傳送人員動態指定的。該節點大部分是子執行緒節點，也可以是多人處理的普通節點。

應用場景：a節點發向b節點，張三需要分配給，甲乙丙丁四個人去工作，但是這四個人工作內容不同。雖然甲乙丙丁四個人都可以接受到該節點的工作，但是填寫的內容是由張三動態的分配的。

我們就要在這裡約定資料來源來表達接收人的資訊，第一種情況沒有批次號：返回的列需要有如下要求，No,Name,FrmIDs 第3列是表單ID，多個表單ID用逗號分開。

第二中情況具有批次號：需要返回的列是， No,Name,BatchNo,FrmIDs.

Ccbpm為該種應用場景做了一個demo,請參考：

在節點2屬性裡我們做了如下設定

實現步驟：在開始節點裡ccbpm的節點表單裡設計了一個明細表。

1.1.4.3.2: 按SQL確定子執行緒接受人與資料來源

此方法與分合流相關，只有當前節點是子執行緒才有意義。