最近結束了乙個企業oa系統的專案，客戶是一家海洋航運行業的企業，散運業務全球第一。該系統以工作流系統為基礎平台，對員工工作進行電子化和規範化，由系統來驅動員工自動、快捷、可管地完成日常工作。在開發過程中，在綜合評比多種工作流產品之後，我們選擇了開源工作流產品——osworkflow作為底層工作流引擎支撐，通過擴充套件osworkflow的介面把業務系統和工作流引擎完美無縫地整合在一起。本文就是跟大家一起分享osworkflow擴充套件過程中的經驗心得，希望能對其他朋友有幫助。
在我們開發團隊介入系統開發過程之前，這個專案已經完成了 quickstart 階段，留給我們的階段產品有：系統實現的proposal、乙個能體現使用者page flow的lo-fi，以及在mingle上的 story list和iteration原始計畫。當然，還有專案團隊跟客戶形成的乙個良好的互信基礎和溝通渠道。於是，左 proposal，右 lo-fi，客戶溝通在中間，我們就開始了系統設計的 inception。inception階段的目標根據不同專案會有不同。在這個系統裡面，我們完成的目標有：確定系統實現使用的技術、針對技術進行 spike**可行性、結合master story以及比較粗略的story list實現乙個系統prototype。好，工作開始了！
為什麼選擇osworkflow？
工作流系統其實在理論界已經是研究得非常成熟了，有 wfmc 組織來規範工作流定義語言，而且各種工作流引擎，不僅商業產品，像 jbpm、osworkflow、ofbiz等開源產品也都很多。這些產品都各有特點，應該如何選擇呢？從使用率和文件完整度來看，jbpm 和 osworkflow 佔了上風，我們就從這兩者裡面選了。jbpm基於uml的狀態圖和活**來定義流程，已經加入jboss大家庭，但是相對比較重。osworkflow是個非常輕量級的工作流產品，但是自從2023年就停止活動了。不管如何，選擇的技術都是要為解決未來系統開發會面臨的問題，才算是乙個好的可行的選擇。
通過分析quickstart階段的proposal和lo-fi prototype，然後再反覆跟客戶確認，我們知道了客戶在現階段對系統的要求是：
只需要處理線性的工作流（未來可能需要增加對分支/合併的支援）
不需要功能複雜強大的工作流編輯器
節點流轉主要是手工觸發，不需要基於規則
需要能和遺留系統已有的工作流定義整合，而已有工作流定義用 osworkflow 定義
根據客戶對系統的要求，我們選擇了osworkflow作為最終的候選工作流引擎。因為我們對這幾種工作流產品都不是很熟，對它們是否能滿足系統要求答案不確定。而從另外乙個方面來講，如果系統足夠簡單，我們也可以自己實現乙個狀態機，自己實現對流程節點流轉的維護。
為了做出選擇，我們又分頭對 osworkflow 的配置檔案以及技術架構都進行了細緻的研究。研究過程和結果就不細說了，網上有很多 osworkflow 的介紹文章，大家可以參照。osworkflow 會把乙個簡單的xml配置檔案，轉換成它定義的流程描述類（***descriptor，我們也把它們稱為osworkflow的models），然後在流轉的過程中，將其轉換成工作流例項和工作流節點，並通過相應的持久化介面持久化工作流的狀態。整個過程用乙個簡圖來表示，就會是：
圖1 osworkflow model
考慮到 osworkflow 的實現也是非常輕量級，並且結構非常清晰，而且為了提供以後對分支/合併、以及自定義規則等流轉形式的支援，我們還是選擇了 osworkflow，而不是自己去實現乙個基於狀態機的工作流引擎。但是，我們還不能直接把 osworkflow 放進專案裡面，然後直接引用：一方面我們不想讓開發團隊都糾纏於底層 osworkflow 的技術細節，另外一方面也是因為 osworkflow 並不能完全滿足客戶的系統要求。我們需要擴充套件！
為什麼去擴充套件？
依然是問答模式，osworkflow 有哪些方面不能滿足我們系統的要求？
1. 系統對各個流程的定義都能有版本跟蹤
客戶會對流程定義進行修改，但是流程修改的過程中，流程應該繼續按照原來的定義進行流轉。這樣，對於同乙份流程，系統會同時存在兩個不同的定義，並且都能正常流轉。osworkflow 基於xml檔案的流程配置方式在這種情況下就不能滿足。
2. 系統對流程定義的修改能實現「hot deploy」
客戶對流程定義進行修改後，系統能自動提供給使用者新的流程定義，而不需要重啟伺服器。因為 osworkflow 是在系統啟動的時候，將所有的流程定義都載入記憶體，在系統執行期不會去檢測流程定義的修改。這樣，osworkflow 也不能滿足。
3. 相對於系統的要求，osworkflow 提供的功能還是太複雜了
因為 osworkflow 是提供乙個通用的工作流引擎，所以考慮了很多複雜的情況。這些複雜性對我們系統來講，都是額外的不能對客戶產生價值的特性，而且那些複雜性的存在，也會讓我們開發的時候必須考慮到那些方面，從而影響我們的模型設計和開發。
除了上文提到的幾個原因，我們考慮的因素還有很多方面，最終我們決定是在osworkflow基礎上進行擴充套件，來滿足我們的要求。
如何進行擴充套件？
如何進行擴充套件？我們的原則是什麼？沒有乙個清晰的目標，很可能最終擴充套件的方向和最終實現就會跟我們想要的目標離得比較遠了。
原則一. ddd，mda
我們希望開發團隊在設計開發的過程中只需要考慮系統領域的模型，而不會 involve 到底層的流程流轉細節。
「find core domain models」，我們重新研究了系統的 proposal 和 lo-fi prototype，找出系統裡面的領域物件，它們之間存在這樣的乙個關係：
圖2 系統model
從圖1 osworkflow model 關係圖和圖2 系統 model 關係圖可以看出，它們兩者還是存在著一定的相似點和不同點的。
相同點：
1. 相應 model 完成的功能和職責是非常類似的
2. 不同 model 之見的關係也是非常類似的
不同點：
1. model 的屬性
2. model 的一些行為
原則二. decoupling
我們希望專案實現不依賴於某個工作流產品，而是可以很方便地遷移到其他的工作流產品。第一想法就是——「laying, isolate by inte***ce」。
其實工作流產品除了工作流引擎負責流程節點流轉之外，都另外包括這三部分：流程定義、定**析和狀態持久化。而成熟的工作流產品，不管是jbpm，還是 osworkflow，都會提供介面進行隔離。在osworkflow裡面，介面workflowfactory會負責流程定義的解析和 osworkflow models的初始化，介面workflowstore則負責將workflow和workflowentry的狀態持久化。這樣，我們就可以定製實現介面，將domain models轉換成 osworkflow models，在流程流轉需要持久化流程狀態的時候，則會去持久化domain models。
經過這樣幾個方面的論證和分析，得到的最終方案如下：
1. 使用domain model，而不是工作流model
2. 擴充套件介面將 domain model 轉換成工作流 model
3. 擴充套件介面提供自定義的工作流狀態持久化
4. 不改動 osworkflow 核心
最終實現
圖3 系統實現圖
我們得到了什麼
1. 使用 domain model 進行開發
2. 底層工作流引擎對開發團隊透明
3. 設計、優化工作在應用層次來進行
什麼是傳真文件工作流
企業中的傳真文件是業務流程的載體，文件的流傳不但耗時 效率低，而且缺乏安全性，資訊容易洩露。傳真文件工作流 fax workflow 作為傳真伺服器 系統的乙個應用功能模組，是一套處理傳真文件流傳的應用程式，解決文件在流傳過程中面臨的所有問題，作為業務流程的一部分。在傳真文件工作流 fax work...
工作流建模 工作流概念
工作流建模 工作流概念 1 案例 工作流系統得基本目的是處理案例。每個案例都有乙個唯一標識，而且每個案例的生命週期都是有限的。案例生命週期都處於某個特定狀態，該狀態由三個元素組成 1 案例相關的屬性的值 案例屬性是一系列同案例相關的變數。能夠用來管理案例。正是通過這些變數，才有可能指出在特定條件下某...
工作流 一 什麼是工作流
什麼是工作流 工作流的英文全稱是 workflow，簡單理解則是業務流程的計算機化或自動化。它是是針對工作中具有固定程式的常規活動而提出的乙個概念，通過將工作活動分解定義良好的任務 角色 規則和過程來進行執行和監控，達到提高生產組織水平和工作效率的目的。工作流技術發端於70年代中期辦公自動化領域的研...