我們走的設計路線和國外的產品不太一樣，不一樣在**呢？ 國外的流程的設計思路是通過事先定義一整套規則(類似xpdl)來約束和控制流程圖的複雜度(我對國外的產品了解不夠多，僅僅是在有限的了解程度上面提出這樣的看法)，從而避免在流程引擎中處理這些複雜的圖的問題，而我們卻沒有通過事先定義這樣的複雜的規則來約束和降低使用者自定義流程圖的靈活性，這樣一來，在引擎和流程流轉控制這乙個層面就會遇到很多相對比較複雜的問題，我的博文中提到的幾種演算法就是專門處理這些複雜情況的，這樣雖然可以把流程圖的使用者自定義的優點可以發揮到最大，但是也使流程引擎的設計難度大大增加，這是乙個矛盾，開發者可以通過定義一套複雜的xml規則來使流程圖的使用者自定義受到約束和控制，避免使用者畫出具有很複雜拓撲結構的流程圖，但是這種限制對終端使用者來講不是很令他們感到滿意的。。在實際應用中，乙個組織和企業對流程的需求是不會因為流程系統的限制而降低的，我們既然要給使用者自定義流程圖的設計器，那麼我們就不應該在xml定義中給這種設計的過程太多的限制。。我們的設計目標是盡量的讓引擎能夠處理使用者花出來的複雜的流程圖，當然這種複雜是有一定限度的。。。另外定義規則的xml也使流程引擎的設計可以更好的結構化和模組化，更符合oo的思想，這是定義規則的另外乙個好處，不過既然都讓使用者自己可以設計流程圖了，我覺得還是我們搞設計和開發的人多費點神，盡量把引擎的做的強大一些，盡量讓使用者方便些，我們人畢竟不是ms，也不是什麼bpm聯盟，只是一群依靠獲得使用者的滿意來吃飯的軟體工程師。。。
說了那麼多廢話。。。。。還是要說幾句正兒八經話
我們的引擎如果遇到乙個複雜的流程圖，裡面分支和匯聚的拓撲結構都不規則，也不對稱，要設計演算法比較困難的時候，該怎麼辦呢？
第一種辦法：讓使用者在設計過程中把特殊的節點設定特殊標誌，我們在引擎中針對這些特殊標誌做特殊處理
第二種辦法:把複雜流程圖分割槽(類似於petri網的四種基本模式的劃分)，對不同的區域做不同的處理,我們可以把複雜的圖劃分為不同的區域，對不同的區域分別採取不同的處理方式。。。
在實際設計開發過程中，我們還會遇到很多困難，不用怕。。。克服困難，繼續前進，我們搞技術就是不斷在克服困難中取得進步的。。。
2頂
0踩
jeesite工作流表結構
最近在利用jeesite開發乙個小系統，趁著這個機會整理了activiti中的相關表，跟蹤流程，然後檢視這幾個表中資料的變化，可以更好地理解流程的開發。現在整理出來，希望可以幫助更多的人！一.工作流部署 repositoryservice 1.流程定義資料表 act re procdef 2.流程設...
工作流任務的訊息處理
最近自己在開發工作流系統，簡單寫一下工作流任務的訊息處理的業務流程，記錄一下。在工作流引擎產生乙個任務需要某個人進行人工處理的時候，工作流先插入一條任務到 wf t task 表中，這條任務記錄應該包括 任務id，任務的狀態 未處理 處理任務的角色 如部門經理 處理任務的人 如張三，屬於 部門經理 ...
工作流子系統邏輯結構
工作流子系統從邏輯結構上，可以分為三層 任務層 具有一定規則和格式的正向或反向任務流，負責前後兩個工作節點的連線。工作流引擎 根據指定的流程規則，結合當前應用環境，確定任務流方向或產生新任務流的核心模組。流程邏輯層 由流程配置 應用配置和環境兩部分組成。流程配置主要為工作流配置，步驟配置和進入條件配...