審批流是工作流比較簡單的應用。審批流的特點是一個審批流模板相應一種單據。在審批流中僅處理單據的狀態，如審批通過、審批不通過；審批流中會用到單據數據，如條件中、各種須要引用單據變量的地方。審批流沒有涉及到多個單據之間的處理，因此審批流是相對簡單的。從業界的大多數工作流來看，也不過實現了審批流而已，比方協同辦公、以及ERP中的一些單據的審批。工作流如今應該是處於0基礎階段。
假設須要做真正的多單據的工作流，即業務流。比方從採購申請、採購訂單、收貨單到採購發票，可以定制一個完整的採購流程，更進一步，採購可以跟庫存、生產或者銷售模塊連接起來，就更為完好了。同一時候，假設這些流程可以定制的，比方標准流程是這種，不同企業可以定制符合本企業須要的流程，就更完美了。在這一個過程中，我覺得須要解決兩個較復雜的問題。
1、實體間架構映射問題。
Biztalk中源架構（Source Schema）到目標架構（Target Schema）之間通過XSLT來建立映射。一份源架構的實例（就是一份Xml），能夠參照或者生成一份目標架構的實例（新的Xml）。這是比較好的解決方案，當然，能夠定義一份簡單的映射關系對比表，通過代碼來轉換生成了。這個工作難度應該不大。
2、實體的實例間多對多的關系。
比方收貨單到發票，1張收貨單能夠開n張發票，n張收貨單也可能開1張發票。所以就存在單據實例間的多對多的關系。這樣的關系的處理，對於傳統的功能性流程來說是比較簡單的，通過多次參照就能夠實現。單據實例間的關系是在兩個單據數據之中來維護。可是對於利用工作流來處理這類問題時就變得比較棘手。第一個問題是是否引入流程實例的處理，假設沒有流程實例，這跟傳統的以功能為主的應用有何差別，僅僅是將流程通過圖形化顯示出來，這僅僅是一個殼。假設引入了，就會帶來第二個問題。那就是單據實例之間到底具有什么約束？假設約束，那么僅僅能處理1對1的關系，比方1張收貨單，就必須有1張發票相應，這樣整個流程就能流轉下來。假設沒有約束，錄入發票時，通過什么條件來選擇訂單？從業務角度來看，應該是符合這個流程模板的全部流程實例的上一種訂單。假設選擇了別的流程實例關聯的發票，則那個流程實例就要中止。所以，就會出現流程實例的分之和合並，注意，不是流程模板的活動的分之和合並，而是流程實例。此處的處理，是業務工作流的關鍵所在。
考慮了幾天，沒有徹底想明確，寫下來，供以后參考，希望做過這方面研究的看到了討論一下。