工作流程和審批流

      審批流是工作流程比較簡單的應用。審批流的特點是一個審批流模板對應一種單據。在審批流中僅處理單據的狀態，如審批通過、審批不通過；審批流中會用到單據資料，如條件中、各種需要引用單據變數的地方。審批流沒有涉及到多個單據之間的處理，因此審批流是相對簡單的。從業界的大多數工作流程來看，也僅僅是實現了審批流而已，比如協同辦公、以及ERP中的一些單據的審批。工作流程現在應該是處於初級階段。

      如果需要做真正的多單據的工作流程，即業務流。比如從採購申請、採購訂單、收貨單到採購發票，能夠定製一個完整的採購流程，更進一步，採購能夠跟庫存、生產或者銷售模組串連起來，就更為完善了。同時，如果這些流程能夠定製的，比如標準流程是這樣的，不同企業可以定製符合本企業需要的流程，就更完美了。在這一個過程中，我認為需要解決兩個較複雜的問題。

    1、實體間架構映射問題。
          Biztalk中源架構（Source Schema）到目標架構（Target Schema）之間通過XSLT來建立映射。一份源架構的執行個體（就是一份Xml），可以參照或者產生一份目標架構的執行個體（新的Xml）。這是比較好的解決方式，當然，可以定義一份簡單的映射關係對照表，通過代碼來轉換產生了。這個工作難度應該不大。
        
    2、實體的執行個體間多對多的關係。
          比如收貨單到發票，1張收貨單可以開n張發票，n張收貨單也可能開1張發票。所以就存在單據執行個體間的多對多的關係。這種關係的處理，對於傳統的功能性流程來說是比較簡單的，通過多次參照就可以實現。單據執行個體間的關係是在兩個單據資料之中來維護。但是對於利用工作流程來處理這類問題時就變得比較棘手。第一個問題是是否引入流程執行個體的處理，如果沒有流程執行個體，這跟傳統的以功能為主的應用有何區別，僅僅是將流程通過圖形化顯示出來，這隻是一個殼。如果引入了，就會帶來第二個問題。那就是單據執行個體之間究竟具有什麼約束？如果約束，那麼只能處理1對1的關係，比如1張收貨單，就必須有1張發票對應，這樣整個流程就能流轉下來。如果沒有約束，錄入發票時，通過什麼條件來選擇訂單？從業務角度來看，應該是符合這個流程模板的所有流程執行個體的上一種訂單。如果選擇了別的流程執行個體關聯的發票，則那個流程執行個體就要中止。所以，就會出現流程執行個體的分之和合并，注意，不是流程模板的活動的分之和合并，而是流程執行個體。此處的處理，是業務工作流程的關鍵所在。

       考慮了幾天，沒有徹底想明白，寫下來，供以後參考，希望做過這方面研究的看到了討論一下。