流程處理始終是我這邊專案的中乙個重點，之前寫過乙個部落格關於工作流的。不過最近處理了同事碰到的問題，感覺有必要再記錄一下。
一、回顧工作流
首先，用大白話回顧一下，什麼是工作流以及為何有工作流產品。工作流就是先設計乙個工作處理的規範，有幾個崗位，從哪個崗位發到哪個崗位，這個設計好一般使用中不動了。可以看成是一種複雜的字典項，可以記錄在檔案中，資料庫xml方式存放，或者直接表存放，使用時一般快取在系統中。
為何有工作流產品？產品一般是通用性，實際工作中，不同的崗位人員處理方式完全不同，錄入的內容也不同，但也有相同的地方，就是一些流向，任務分配。所以按照把公共部分抽象出來的原則，才有了工作流產品。乙個事項在流動過程中，工作流中有工作流例項，自己的系統中有業務例項；工作流中有業務分配，自己的系統中有業務資料。等於是共性與個性分開了，當然他們之間有欄位關聯著。
二、問題
好了，開始說說問題。這個專案是另一同事參與，我指導他技術。主要是處理乙個流程中的and分支與合併，流程圖上畫了3個部門，實際中使用者要求可以選擇3個，可以選擇其中兩個，當然1個也行。這個情況，是非常常見的情況，我做過業務比這複雜多的流程，都用自己寫的流程分配處理的，有幾個就分配幾個併發任務唄，每乙個併發任務完成後，檢測是不是大家都完成了，都完成了可以進入下乙個崗位了。
難點是啥？工作流用的內部產品，原始碼無。外面包裝了流程介面卡，可支援jbpm等其它。再外面是一套之前乙個人寫的業務層，包含了一批w開頭的業務表。業務表與表單系統又套在一起。這個業務表外又包裝了一層另乙個人寫的inf開頭的業務表。頁面上用的待辦任務都是用inf表，頁面寫的還蠻複雜的。流程工具畫的流程圖裝入系統後，產生與w系列表對應的環節與操作表，又產生了一批與inf對應的崗位與活動操作表。所以具體的乙個業務過程，被分成了三部分，內部是工作流例項、中間的一層業務，外面又是一層業務。
同事把主要時間放在改表單，就是修改and部門選擇實際處理人的功能上了。我看過了資料庫設計並分析了資料，說這個and任務已經產生了，在這裡改沒有任何作用，必須在and產生前控制and的個數。作為乙個不確認的任務，最快速的打通其中的難點是最主要的，千萬不要浪費時間有細節上。比如專案應該是先搭建好資料模型與基本結構，而不是裝飾房間。最近乙個專案中有幾個字典項，已有公共頁面處理，但最終客戶要有處理頁面，但我說這個很簡單，先填寫好資料，推進更重要的工作。
三、處理過程
1.首先我認為and分支，可以選擇分支是乙個很通用的功能，也許配置一下就ok了，經過了解沒了此功能。反編譯看到and合併的條件是與流程配置中個數為準。
2.我最初的建議是分配and任務的時候，使用者勾選部門並標識下來，如果標識是不參與的，就預設讓此任務自動完成。在待辦任務與已辦任務中根據標識過濾掉。這樣應該最簡單，而且業務層次最外面，改動最小。（簡單測試在提交and任務後，讓其中乙個部分的任務立即完成，但copy來的提交中涉及表單，涉及一些設計模式，報錯就先放下了。畢竟我不是主導的，只是建議）
3.另一方面，之前參與過的另一團隊技術負責向技術總監求援，遠端指導中說試試xor，以及測試流程連線上的請求條件可以過濾，還說and xor都已經被改過了，都沒啥區別了，關鍵是流程連線上的條件。只要表單裡有條件，就會起作用。看來已經被不同的人改的太亂了。大家都吃不準，只有試。xor是排他流程。
4.當然是審核崗位，只有同意才可以分配and任務，不同意直接轉結束，所以還是審核的兩個分支中，其中乙個先加了and節點。主要測試and後的連線上的條件是不是可以用來協調真正分配的任務。同事準備寫條件，並改寫提交表單以加入條件。我說先用表單中已有的項來驗證是不是可行，只要寫個條件就行，省的改了半天又不可行。時間花在重要的驗證可行性上。and上的分支果然有作用了，只產生了3個中的2個任務。
5.下一步是合併操作，之前已經說過and合併是與配置的個數有關，怎麼辦？他們暫時也沒辦法。我建議修改原碼，才知道沒有原碼，另一團隊技術負責說可以複製出來這個類來改，改好會優化載入的。哦，是了，這個我怎麼沒想到呢。他說他們這邊一直這麼幹的，看來我之前專案圈中交流太少，技術交流非常的重要。如果我是負責多個專案的管理人員，肯定會組織各個專案技術人員講解自己的專案，最近的問題與收穫。但我們這邊沒這個機制。最後我只寫和幾行**，終於用實際產生的任務數作為and 合併的條件，測試通過了。
6. 既然技術中的難點都攻克了，那就交給同事繼續開發了。
四、反思
回想我提出的第乙個思路，開始認為最簡單的繞過問題的，就是自動提交不選的分支任務。僅作標識。為何沒成功呢？分配完and任務，立即呼叫提交任務啊，應該也是只要改10行左右的核心**啊。因為我不具體負責也沒多測多想。等問題都解決後才想到最根本的問題是，把兩個提交串起來，必須是兩個不同的請示，不同的事務。其實模擬使用者操作做個提交應該是非常簡單的事情。
一次處理專案中工作流問題的過程記錄
流程處理始終是我這邊專案的中乙個重點，之前寫過乙個部落格關於工作流的。不過最近處理了同事碰到的問題，感覺有必要再記錄一下。一 回顧工作流 首先，用大白話回顧一下，什麼是工作流以及為何有工作流產品。工作流就是先設計乙個工作處理的規範，有幾個崗位，從哪個崗位發到哪個崗位，這個設計好一般使用中不動了。可以...
記專案中的一次記憶體洩漏問題
最近在使用qt開發乙個大型專案，記憶體占用可能有點多，其中在vector.push back 的時候報了乙個segment fault錯誤，感到很奇怪。因為平時遇到段錯誤，大多數情況下都是陣列越界 使用訪問元素 而vector的push back 函式，在新增元素時，如果空間不足，會先向記憶體申請原...
一次完整的HTTP請求處理過程
osi七層模型我們都知道，那當我們從瀏覽器輸入到有頁面顯示的過程中發生了什麼呢？下面我們就通過抓包來分析 網路傳輸 工具 任意瀏覽器 wireshark抓包工具 應用層 瀏覽器接收使用者輸入的網域名稱由瀏覽器 客戶向伺服器傳送請求get，而應用層的get請求被封裝在http協議中，抓包分析get資訊...