工做流和審批流

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

      假設需要作真正的多單據的工做流，即業務流。比方從採購申請、採購訂單、收貨單到採購發票，能夠定製一個完整的採購流程，更進一步，採購能夠跟庫存、生產或者銷售模塊鏈接起來，就更爲無缺了。同一時候，假設這些流程能夠定製的，比方標準流程是這種，不一樣企業能夠定製符合本企業需要的流程，就更完美了。在這一個過程當中，我以爲需要解決兩個較複雜的問題。

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

       考慮了幾天，沒有完全想明確，寫下來，供之後參考，但願作過這方面研究的看到了討論一下。