第三代AgilePoint 表單開發樣板-AresEFM

AgilePoint 的前端表單

AgilePoint Server 端是採用Web Service 架構, 因此前端表單可採用任何可以呼叫WebService API 的程式語言或工具, 在國外大部份的客戶皆採用InfoPath 作為表單, 不過因為以InfoPath 作表單,一方面需配合MOSS(Mircosoft Office SharePoint Server )及Form Server , 另一方面要作到彈性很高的表單, 較為困難, 所以在國內大部份的客戶皆採用Asp.net 作為前端表單.

以Asp.net 作表單最大的優點是表單的彈性很高, 所有Mircosoft 所提供的表單元件, 甚至是ThirdParty 所開發的元件皆可使用, 再加上Asp.net 是一個標準的程式語言, 因此並無學習上的門坎與障礙, 因此是一個很好的表單前端工具, 但缺點是要作到具有基本功能的表單也需要花一些的功夫, 這也是我們希望剋服的問題.

AgilePoint 與Asp.net 表單發展歷程

第一代表單元件—基本元件

AgilePoint 最原始的表單開發元件有兩種類型, 一種是AgilePoint 預設提供的表單基本元件（如TextBox、DropDownList、Checkbox…）其繼承自Microsoft 所提供的元件, 但加上一個BindingName的屬性, 可自動將元件的內容存入指定的流程變數, 並於顯示時可自動由流程變數取得相關的值,另一種方式是直接採用 Microsoft 或ThirdParty 提供的元件, 此時可呼叫AgilePoint 提供的儲存流程變數的API – setCustomAttr()或以getCustomAttr()取得變數值, 另外要觸發流程事件如發單/同意/退回/加簽/轉派…皆需自行呼叫相關的API , 並處理後續網頁的行為, 此時所作的工作與一般網頁的應用程式開發無異, 但已能享受到AgilePoint流程模型驅動的優點.

第二代表單元件—整合元件

第二代的表單開發元件是我們針對使用者常用的功能, 提功一組較完整的元件, 如發單的按鍵可提供確認是否要執行的訊息, 並自動呼叫啟動流程API, 顯示完成的訊息, 完成後網頁可導向指定的位置.又如簽核意見的輸入, 分別提供輸入欄位、顯示的Grid 等獨立的元件, 此時使用者可以更方便的去組合自己的網頁, 已經可以節省不少的開發時間.

第三代表單元件—表單樣版

AgilePoint 的流程塑模(Modeling)的方式我們一直認為它的功能很強大也很方便, 但是我們也一直在思考如何讓表單開發更為方便, 快速, 但又能保留原有的彈性, 因此我們推出了第三代表單開發樣版.

一張表單大致上可分為幾個部份: 表頭(填單人、日期、部門、單號), 申請的內容, 附件上傳, 簽核意見及各項功能的按鍵(發單/同意/退回/加簽/轉派/暫存/銷單…), 因此我們將這些功能集合為一個樣板, 開發人員只需要複製這個樣板, 修改填寫的區塊, 或加上新的資料區塊, 就可以很快速的完成一張表單的開發, 我們稱這個樣板為AresEFM.

在AresEFM 中我們不僅提供開發的樣板, 亦提供一個可動態指定循序串簽或平行知會的表單與樣板—傳簽申請單,此流程可不經客製直接引用, 並且提供一個通用表單, 此表單已包含表單的基本區塊, 並透過客製化的流程模型, 可達到一張表單可適用多個流程或一個流程可應用不同的表單.

clip_image002

clip_image004

除了單表樣板外我們也開發了一組新的元件及新的使用者介面的設定模式, 除了原有的由介面資訊設定外, 亦可由AgileWork 中定義參與者的角色及功能鍵的權限.

clip_image006

clip_image008

表單樣版的擴充性

AresEFM表單樣版, 因為還是以Asp.net 製作出來的, 且運用的模組化的概念, 共用的部份都包含在BasePage 以及UserControl中,因此使用者亦可修攺這個樣板, 變成自己企業的樣板.

此種作業模式除了保有原來Asp.net 開發表單的彈性, 原有AgilePoint流程整合的觀念並沒有改變,, 同時又有快速開發的優點, 後續我們會積極推廣此種開發模式, 以提高AgilePoint 在企業應用的更高的價值.

留言

張貼留言

這個網誌中的熱門文章

如何使用SQL Profiler 找到語法錯誤

圖片
  SQL Profiler 我們在執行SQL 語法時, 常發生SQL Server 端的錯誤, 但無法直接由Client 端的訊息看出來,此時我們可透過SQL Profiler 來找到Server 執行的錯誤, 只是Server 端的事件那麼多該如何找到錯誤呢? 一個很重要的觀念, SQL Server 不論執行的結果如何, 正確或錯誤都會產生Complete的事件, 如 StoreProcedure 的 SP:Completed/StmtCompleted   一般SQL 的SQL:StmtCompleted / BatchCompleted. 奇怪了, 都錯了怎麼還有BatchCompleted 呢? 別緊張在Error 欄也有寫執行結果(1-Error) ,因此我們可以針對執行結果為1-Error 的部份, 來看它的錯誤原因,只要設定Exception 及User Error Message , 並針對所需的指令類別(StoreProcedure或一般SQL)所需的Completed 事件, 就可以找到錯誤的指令.   實際應用的案例 以下是一個我們在Client 端程式所發生的錯誤, 可是單由Client端的訊息看不出來錯在那裡, 執行資料庫Schema 更新失敗(Schema Ver.18 update failed) 接下來要找到失敗的原因. 1. 開啟 SQL Profiler. 開始-->程式集—>Mircosoft SQL Server 2005->效能工具->SQL Server Profiler. 2.新增追蹤 3.連結資料庫 4.設定所需的事件 預設項目除了 RPC:Completed , SP:StmtCompleted, SQL BatchCompleted 其餘均可取消.   5.勾選 顯示所有事件及顯示所有資料行. 6.選擇必要的事件    對於找出一般SQL 指令的錯誤而言, 只需要設定三個值, 其餘可取消.    設定Errors and Warnings 之 Exception 與User Error M...
閱讀完整內容

如何將SQL Server 的查詢輸出寫入文字檔

圖片
  SQL Server 預設會將執行結果顯示於畫面上，可設定將其輸出寫入外部檔案，此項設定只針對新開啟的視窗有效. 以下範例是針對SQL Server 2005 . a. 開啟SQL Server Management Studio b. 點選工具à選項 c. 設定查詢結果，選擇將結果存檔 d. 開啟新的執行視窗，並執行指令. e. 選擇輸出檔案名稱. 雖然預設副檔名為 .rpt , 但其內容為文字檔，因此可用文字編輯開啟.
閱讀完整內容

AgilePoint逐級簽核與指定簽核層級範圍

圖片
  循序簽核 企業流程中, 大部份的行政流程都採用申請者逐級簽核的方式進行, 由申請者開始依組織的層級逐級向上簽核,當導入BPM或Workflow時也會面臨同樣的問題, 一般常見的作法是逐一繪出組織層級與流程. 上述的流程雖然很清楚的呈現簽核者的層級與流程, 可是問題也不少,因為一般流程的訪談都是以最基層的員工為主, 因此很容易發生以自己為出發點去設計流程,試問 1.如果經理自己申請是否要自己核准, 如果協理申請是否要給經理簽 ? 2. 如果有一個部門沒有協理怎麼辦 ?一個流程如果要適用於生產部門的工廠與行政支援部門, 通常其組織結構是不同的, 傳統的作法是把每個組織了流程劃出來, 整個流程密密麻麻. 逐級簽核 新的流程設計通常改用逐級簽核的方式, 以類似迴圈的方式判斷是否達到核決的權限, 如未達到則在找上一階主管, 已達到則離開迴圈, 不論申請者是何層級或組織階層為何皆可執行.   AgilePoint 提供很有彈性的逐級簽核的判斷,可在單一條件的流程元件(Single Condition) 是否達核決權限中判斷指定的流程變數(圖中IsPrivileged)為True或False, 因此只要在流程中依組織的核決規則去設定流程變數值即可. 判斷是否達核決權限的判斷有許多種方法, 第一種是在人工簽核作業元件中設定判斷的基准,該元件會依設定的內容指定流程變數的值. 內件元件可以依人員或部門甚至流程變數的值作判斷, 判斷的方法有特定的值(等於某個層級), 特定欄位值是否符核該層級的區間(經理可准假幾天, 協理可以核准採購金額多少),上簽幾階等不同的方式. 如果內建的內容無法滿足時,亦可在表單上運算然後將結果(True/False)直接設定給流程變數, 不過我們通常不建議將判斷寫於表單上, 比較建議的方法是寫成一個流程元件(AgilePart), 其優點除了簡化表單的設計外, 另一個好處是可以重覆利用這個元件, 達到組合流程的目的. 資產處分流程中, 依資產使用年限與殘值決定核決層級, 以AgilePart 製作核決權限判斷元件. 設計一個可參數化的流程元件直接設定所需的核決層級. 透過上述幾個案例, 可以發現逐級簽核有兩個重點, 一個是需要一個樹狀...
閱讀完整內容