驗測「Workflow 產品」系統整合彈性度的 POC
上個星期，應我們某一上市鋼鐵公司客戶資訊部門協理的邀請，期能協同參與 Workflow 產品 的 Survey，主要是希望能應用在明年 ERP(利用 .NET 系統開發，但需要逐漸從 AS400 移轉)系統的電子簽核功能。
該位協理已經檢視過國內多套 Workflow 產品，但均不是太滿意，例如，光是要求 A牌以 Java-based 所開發的 Workflow 產品能提供個 Web Service 介面供呼叫，就不太能提的出來；或者，雖然與其 ERP 系統同是 .NET Famework 的 Workflow 產品，但卻與 Web UI(ASP or ASP.NET)以及資料庫系統綁得太緊，從 Workflow 廠商的角度，所提供的系統整合的解決方案，就是由 ERP 系統的資料庫，可能是透過 EAI(Enterprise Application Integration) 將資料給整合至 Workflow 系統的資料庫內，甚至，乾脆簡單一點，就是只要能 “匯入(Import)” 至 Workflow 的資料庫就好了。
所以，從 Workflow 廠商角度所提供的系統整合解決方案，均是以 Workflow 的角度來看待系統整合，然後以 Workflow 為核心，來整合其它的系統，包括 ERP、財會系統 …等。這也算合理，因為，最好就是用了該廠商的產品，然後就是一直 “依賴” 它，不要換掉，一同與之成長。 🙂
嗯，不過呢，協理的要求很清楚：要能實現電子簽核的功能，以及．．．未來要能換的掉 Workflow 產品，但卻不致影響到 ERP 系統的主架構。
從客戶的角度來看，還是不太希望能把公司最核心的命脈：ERP 系統，給緊緊的與某一廠商 Workflow 產品綁在一起，況且，頭大的還不止 Workflow 呢，還有要如何能從 AS400 逐漸的將業務邏輯給移轉至新開發的 ERP.NET 系統，又要不影響到 AS400 既有用戶的權益。當然，這就是明年初我們顧問團隊準備輔導該專案在架構設計的最重要議題，因而，更不可能在專案一開始的階段，就被某一個產品給牽著鼻子走。
如何檢視 Workflow 產品的 “好壞” 呢？ 我個人是很肯定國內外一流 Workflow 產品所提供的表單設計、Process Definition 視覺化設計、電子簽核功能的成熟度等。所以，關於功能與圖形操作介面的檢視，由客戶單位覺得 “對眼”，以及價位上可以接受就可以了；至於個人比較重視的，當然就是在系統整合的彈性度上，也就是說：在架構設計上，系統與系統的整合，絕對不是透過資料庫、而是透過 Middleware 層所提供的程式呼叫介面來達成。
我提了一個算是蠻簡單、來驗測 Workflow 產品在系統整合彈性度的 POC(Proof of Concept)。從三個構面，來檢視 Workflow 系統的整合度。
- 表達並行簽核(會簽)功能的業務流程圖(利用 UML 活動圖表達)。
- 表達資訊系統功能觀點的使用案例圖。
- 表達物件(每一支的 .cs 程式碼)在系統動態期間訊息傳遞的循序圖。
圖1 表達的是一個簡單的業務流程圖，我是利用活動圖來表達的，一般 Workflow 廠商即使不懂 UML 也都還知道流程圖的表達。很簡單，就是先目視一下，Workflow 系統要能提供並行(parallel)簽核，或稱之為會簽的功能，以及，當然，要能對業務流程的簽核邏輯，如 “決策(decision)” 的條件判斷做流程的狀態轉移(transition)。同時，該業務流程圖也隱含了，至少有兩個資訊系統的支援：人力資源(HR,Human Resource)系統與Workflow 系統，以及有哪些角色(role)，或稱之為參與者(actor)，來使用資訊系統。 (從圖一，可以看得出有 “請假當事人”、”直屬主管”、”專案主管”、”人事部門” 等參與者)
（點擊圖片鏈接看原圖）圖1、一個簡單的請假業務流程圖
圖2 則是表達了以 HR 系統為開發範圍的使用案例圖(Use Case Diagram)。個人經常是用此來表達資訊系統的架構設計，簡單清晰又明瞭。從圖2 可以看得出 “誰” 來使用 HR 系統，包括了 “請假當事人”、”簽核主管”、”人事審核人員” 等主要參與者(Primary Actor)。這裡我用了 “一般化(generalization)” 的語法來表達 部門主管與專案主管都是簽核主管，另外，我用了 “公司員工” 這個參與者，卻沒有利用 “一般化” 語法來表達，而是利用註解(note)來說明，主要是為了簡潔圖形的表達。然後，Workflow 系統在該架構設計下，就屬於是 HR 系統的支援性參與者(supporting actor)，這也隱含了未來在系統的實做中，HR 系統是透過 “介面(interface)” 的呼叫來與 Workflow 系統整合。
（點擊圖片鏈接看原圖）圖2、一個請假系統的使用案例圖
圖3~圖5 則是實現(realize) 圖2 各個使用案例的循序圖(sequence diagram)。除了一個簡單的表單(form)畫面(請記得，是強調簡單，只要實做幾個欄位就可以了)外，在 Middleware 層，只設計了一個 “控制物件(control object)”，最起碼就已經隔閡掉表單與 Workflow 系統的直接溝通。另外，在圖4 “填寫請假資訊” 的案例實現上，就可以明顯看得出，實做的程式要能達成同時寫入兩個資料庫：HR 與 Workflow。若是同質(同是 .NET Framework)的系統，則可以以緊密的整合方式(tight-coupling)來達成同時寫入兩個資料庫的 “2-phase commit”；而若是異質(一為 .NET，另一為 J2EE)的系統，則可能採取的是透過 “web-service” 的寬鬆連結(loose-coupling)的整合方式，此時，就不太可能達成同時寫入兩個資料庫系統、而是必須採取如 “沖銷” 這樣的手段了。
（點擊圖片鏈接看原圖）圖3、實現請假系統—列出待辦事項的循序圖
（點擊圖片鏈接看原圖）圖4、實現請假系統—填寫請假資訊的循序圖
（點擊圖片鏈接看原圖）圖5、實現請假系統—簽核請假資訊的循序圖
驗證架構 POC 的程式誰來寫？ 這不會是 Workflow 廠商來寫的，可不要期待，一般廠商對於為什麼還要多透過一顆 控制物件 來傳遞表單資訊，還不一定能接受，更何況，等到更嚴謹一點，要透過好幾個物件的傳遞(例如，我一定會再設計一個 “workflow_adapter” 這樣的 boundary 物件)，才能連結到 Workflow 系統，更是無法認同的。
請記得，架構的 POC 是要由提出架構設計的那一方來主導實做的，其實說起來在這個案例上，就是需要由我們顧問團隊來實現的。不過，由於我們一向會輔導客戶單位資訊部門的 IT 人員來實做程式碼，這樣讓客戶單位能有直接參與的感覺，也比較實在。至於 Workflow 廠商的技術代表，可能是 pre-sell or 技術人員，只要在場提供諮詢，當要連結 workflow 系統時，該呼叫哪一個 APIs(Application Programming Interfaces)、以及所帶的參數與回傳值等資訊即可。
當然，一定是要依照循序圖內的規範給實做(implement)出來。過程需要多久才能實做完成呢？ 一般是半天就可以完成實做的，最晚應該不會超過 3 天。若是超過 3 天，就要檢討了，到底是負責實做的 IT 人員的實做能力、平台整合技術等問題，還是… workflow 無法提供出具體的呼叫介面… 簡單的回饋與結論就可以出來了。
※延伸參考：
o 「漫談系統整合—誰是老大？」
o 「淺論架構的 POC (Proof of Concepts)」
※P.S.
若想參考 UML Model(EA 6 格式)檔，可下載：WorkflowPOC.rar
另，若沒有 EA UML 工具，可以下載免費的 EA-Lite Viewer 觀看。
Kenming Wang
Hi 效能狂:
請我們團隊另一位成員 partner 回答的,, 我對這倒是考究沒那麼慎重的。 !^^
>
基本上，Property應該是Method的一種特殊型態(在Java中，就是getter及setter)，因此，在UML中，通常會使用Method的一個stereotype來表達。
至於產生程式碼時，則可以視Support的工具來自行定義Property對應的程式碼。
效能狂
續上篇，
而會有四層 (類別名稱、欄位、屬性、方法)。
如下圖所示：
http://j2se.myweb.hinet.net/job/class01.jpg
效能狂
請問各位大大，在 UML 中的 Class Diagram，
.NET 特有的類別成員 – Property (屬性) 要怎麼表示 (Java沒有)？
也就是說，Java 和 UML Class Diagram 中，
Class 中的「屬性(attribute)」、「方法;操作(method)」，此二者
Java 可和 UML 的 Class Diagram 直接對應。
但 attribute 在 .NET 中是叫「欄位(field)」，
.NET 另有一種 Java 和 UML 所沒有的機制，叫「屬性(Property)」，也就是 Get、Set，
該 Property 機制，在 Java 和 UML 中是沒有的(是指要程式員手動撰寫)，
在 Java 中是要自己寫函數(方法)，去做 Class 中 Private attribute 的 Get 和 Set 動作，
而不像 .NET 已有內建，專門用來 Get、Set 的「屬性(Property)」機制。
也就是 Java → Class, attribute, method
而相對 .NET → Class, field, method, property
想請問大大們，若要用 UML 的 Class Diagram 來設計.NET 中的 Class，
該如何繪製，.NET 多出的一個「屬性(Property)」機制？
微軟 VS 2005 開發工具，有內建一種「類別圖表檢視」，
該「類別圖表檢視」裡面，
除了 UML 和 Java 的「attribute」、「method」外，
還多列了一種 .NET 特有的「屬性(Property)」，
也就是像 UML Class Diagram 中，各個類別裡，不是有三層(類別名稱、attribute、操作)，
而會有四層 (類別名稱、欄位、屬性、方法)。
在程式語言中，有只有 .NET 有這種特有的「屬性(Property)」，亦即 Get、Set。
若是 Java，這種取得 Private attribute(field) 的 Get、Set，
就要自己手動寫 function(method) 去做 Get、Set 的動作。
請問各位大大，在 UML 中的 Class Diagram，
.NET 特有的類別成員 – Property (屬性) 要怎麼表示 (Java沒有)？
謝謝。
~效能狂
contempt@pchome.com.tw
http://blog.xuite.net/j2ee/coder
Kenming Wang
Hello Gecko:
有意思。 🙂
我想，客戶資訊單位與產品廠商之間，總是會有各自的觀點與想法的。
個人會提出這一個簡單的 POC 驗測，也就是希望 “單純” 一點，若雙方能同意進行此一 POC，那麼，在其實現的過程中，雙方比較能有機會取得 “謀和” 點，也比較能瞭解雙方的需求與可能的為難之處。
Gecko
我想這裡應該可以接受更多聲音，讓我澄清一下
實情是A廠商帶了 web services 的 solution 去裝，也當場實作demo WS 呼叫 workflow，客戶接著要求許多的WS界面，但A廠商不願意在成交前，配合客戶在現有的 web services 增加更多新的呼叫界面。
Kenming Wang
Hello Air:
1. 這是 “責任分派” 的問題考量。正確地來說，”列出待辦事項” 可能是 Portal 系統的責任，不一定是屬於 HR 系統的責任。在此簡化的 POC 是放在 HR，其實也算還好，因為，它也僅是 “delegate” 的角色，實際仍是由 Workflow 取得待辦事項的資訊的。
2. 不算是，從圖3 可以看出，一般化的參與者是 公司員工，任何人都可能會用到此案例。
3. 這裡其實沒有探究到系統(HR)的結構設計問題，在 POC 實做中，先 “聚焦” 在整合 workflow APIs 的議題上，其它的設計物件，如文中所述，已先忽略。
4. yes, 業務邏輯上若需要，就把它加上去。不過，仍請注意，在架構 poc 時，由於在圖 4 已呈現了 2-phase commit 的議題，在此再重覆，意義比較不大。(架構整合的 PO 並不著重在業務邏輯的精確度)
Air
從圖1看起來，這個待辦事項清單是被掛在HR系統裡? 不知道是否有隱含
所有的待辦事項都是屬於HR的應用?
從圖3看起來像是一個查詢待辦事項與請假明細的sequence diagram。
所以actor是審核主管囉?
從圖4和圖5看起來是透過一個controller去處理workflow system與
HR system的更新動作。圖4是start一個process，圖5是complete一個
assignment。用controller的好處是可以比較容易抽換workflow system
的實作。我們的經驗中，有使用過Session Bean和Spring POJO來實作
controller。
另外在圖5中，簽核後可能也還是需要更新HR DB。
Kenming Wang
Hello Jade:
本篇文章僅是一篇在我個人輔導的過程中一個記錄，比武擂臺？ 沒那麼慎重。
但，貴單位的 workflow framework 產品可以進行 POC 驗證，個人是可以建議客戶單位評估的。
是否可以即刻聯絡 HSDc 呢？(TEL: 02-27227179)
今天(星期三)我們即可以安排貴單位過來技術簡報的。
(P.S. 您的 Email 地址似乎不正確？ 無法寄送與您聯絡…)
Jade Yu
請問一下這是公開比武擂台嗎?? ｈａ ｈａ
換句話說就是我們的Workflow framework可以參加POC驗證嗎?
如果可以的話，我們可以進行技術簡報