AgilePoint 進階篇

找出系統效能問題的第一步—資料庫的效能

AgilePoint 的系統架構是IIS 上的一個Application, 因此通常其效能問題的發生的原因通常與一般網頁的應用程式相同, 因此在追查系統效能上, 最常發生的問題是發生在資料庫存取的問題上.

通常資料庫的效能問題, 常出現的問題在於SQL 的執行計劃(Execution Plan), 目前不論Oracle 或SQL Server 都是採用Cost-Base , 也就是依照資料的筆數與分佈的情形計算各種執行計劃的cost, 來決定用那一鍵值或那一種方式讀取效率最高.

因此在處理資料庫效能問題上, 通常程序如下:

1. 以SQL Profiler 找出使用IO量最大的SQL:

2. 先點選檔案新增追蹤

3. 無特殊目的可採用預設的選項, 並設定存放的目錄檔案名稱

4. 點選執行後系統會開始搜集系統的效能數據,

可特別注意兩個欄位CPU 與Reads, CPU 表示執行這段SQL 所耗費的時間, Reads 表示讀取冊數, 如果Reads 的次數很高, 通常需要分析這段SQL 是否有問題.

進一步的分析, 一個簡單的方法是將這段SQL 拿到SQL Server Management Studio ,

可將此SQL 開啟一個新的執行視窗, 貼上SQL 後, 可點選顯示估計執行計劃, 則SQL 下方會顯示其評估的結果.

 

可將執行計劃儲存為檔案交由資料庫的專家分析.

或可點選執行計劃之單一節點, 觀察其採用的執行計畫, 特別注意其估計的資料列數目與認知中應有的實際數是否有極大差異, 我們曾遇過設定正確, 可是統計確是錯誤的狀況, 原因不明,因此即使設定正確, 亦要根據執行計劃的估計比數判斷是否有問題.

若有較大的差異可能是資料庫經過大量資料異動後, 資料庫的統計值不正確所導致, 可檢查自動更新統計資料是否設定為True. 並且注意這個自動統計參數的設定可分為資料庫層級, 資料表層級

 

亦可點選單一Table 的統計資料, 檢查其上次更新時間,若上次更新後有大量刪除或轉檔則可能是造成統計值的錯誤.

若要快速更新統計值, 可執行

USE 指定資料庫

EXEC sp_updatestats

如何動態決定下一個步驟的逾期時間?

在流程中有時需要動態決定下一個步驟的時間, 常見情境如案件可分一般件, 急件,特殊件…每種案件逾期的時間都不一樣, 又如工作交辦, 需於特定日期前完成, 超過則為逾期,目前預設的時間限制, 可設定時間長度及單位, 同時長度部份可以是一個變數, 對於第一種情境可以在表單上依案件類別找出對應的時間長度, 將其指定至流程變數, 下一個步直接指定時間長度的變數.但對於第二種的情境則無法以這個方法解決.

且這種作法並無法達到較好的元件化的概念

因此對於動態流程逾期的時間最好的作法是在AgileWork 中直接依設定逾期的時間, 配合AgileWork 參數化的設計概念, 在我們提供的AFAgileWork 中, 我們提供多種逾期時間限制的選項, 設定時可點選AdvancedTimeSpan(進階逾時控制), 預設為無作用.

 

1. 依案件別, 直接指定各種案件逾期的時間長度與單位.

選擇ByCondition(依條件決定逾期時間), 並依需要決定是否勾選Business hours, 以決定是否依工作曆計算.

下方列表的部份則設定各種逾期的條件, 如所列出的條件皆不符合時則採用預設的工時限制.

2.直接指定逾期時間

若逾期的時間是由前面步驟的人直接指定, 則可將其存入指定的流程變數,

於進階時間限制(Advanced TimeSpan)中直接指定存放逾期時間了流程變數.

設定限制型態為指定時間（Specify DateTime）

指定逾期時間變數,格式為dateTime 並可設定 之後或之前多久為逾期時間.

若指定的時間格式無效, 則會以預設的工時限制為逾期時間.

AgilePoint 流程管理常用SQL

1. 如何清除測試機的所有資料

delete WF_EVENTS

delete WF_AUTO_WORKITEMS

delete WF_MANUAL_WORKITEMS

delete WF_ACTIVITY_INSTS

delete WF_CUSTOM_ATTRS

delete WF_PROC_TRACKINGS

delete WF_LARGE_TEXTS where TEXT_ID in ( select PROC_INST_ID from WF_PROC_INSTS )

delete WF_PROC_INSTS

delete WF_MAIL_DELIVERABLES

2.取得指定流程資訊

select WK.WORK_ITEM_ID,WAI.NAME,WK.SESSION_, WK.STATUS,
       WK.ORIGINAL_USER_ID,O_WRU.FULL_NAME,
       WK.USER_ID,WRU.FULL_NAME,
       WK.ASSIGNED_DATE,WK.COMPLETED_DATE,WK.RESTRICTION_TYPE,WK.CLIENT_DATA
from dbo.WF_PROC_INSTS PIS,
     dbo.WF_ACTIVITY_INSTS WAI,
     dbo.WF_MANUAL_WORKITEMS WK  LEFT JOIN WF_REG_USERS WRU
                                     on(WK.USER_ID=WRU.USER_NAME)
                                 LEFT JOIN WF_REG_USERS O_WRU
                                     on(WK.USER_ID=O_WRU.USER_NAME)
where PIS.PROC_INST_NAME='通用表單-2009/12/1 10:51:30(791)'
  and PIS.PROC_INST_ID=WK.PROC_INST_ID
  and WK.ACTIVITY_INST_ID=WAI.ID
order by WK.ASSIGNED_DATE,WAI.NAME,WK.SESSION_

3.取得指定流程資訊（含組織)

以下SQL 可取得每一個WorkItem 及其相關組織的資訊, 但若人員有兼職情形, 因兼職資訊存在於ClientData中, 無法直接以SQL Join查詢, 因此會有一個WorkItem 多筆資料的情形,需自行刪除未使用到的部門

select WK.WORK_ITEM_ID,WAI.NAME,WK.SESSION_, WK.STATUS,

             WK.ORIGINAL_USER_ID,O_WRU.FULL_NAME,

            O_AUI.RANK as User_RANK,O_ADU.DEP_ID,O_ADI.DEP_NAME,

            O_ADI.DEP_MANAGER_NAME,O_ADI.MANAGER_LEVEL,O_ADI.UPPER_DEP_ID,

            WK.USER_ID,WRU.FULL_NAME,

            AUI.RANK as User_RANK,ADU.DEP_ID,ADI.DEP_NAME,

           ADI.DEP_MANAGER_NAME, ADI.MANAGER_LEVEL,ADI.UPPER_DEP_ID,

          WK.ASSIGNED_DATE,WK.COMPLETED_DATE,

         WK.RESTRICTION_TYPE,WK.CLIENT_DATA

from  dbo.WF_PROC_INSTS PIS,  dbo.WF_ACTIVITY_INSTS WAI,

           dbo.WF_MANUAL_WORKITEMS WK

                       LEFT JOIN WF_REG_USERS WRU

                                                on(WK.USER_ID=WRU.USER_NAME)

                       LEFT JOIN AF_USER_INFO AUI

                                              on(WK.USER_ID=AUI.USER_NAME)

                      LEFT JOIN AF_DEP_USER ADU

                                           on( WK.USER_ID=ADU.USER_NAME)

                     LEFT JOIN AF_DEP_INFO ADI

                                           on(ADU.DEP_ID=ADI.DEP_ID)

                     LEFT JOIN WF_REG_USERS O_WRU

                                           on(WK.USER_ID=O_WRU.USER_NAME)

                     LEFT JOIN AF_USER_INFO O_AUI

                                          on(WK.USER_ID=O_AUI.USER_NAME)

                     LEFT JOIN AF_DEP_USER O_ADU

                                          on( WK.USER_ID=O_ADU.USER_NAME)

                    LEFT JOIN AF_DEP_INFO O_ADI

                                          on(O_ADU.DEP_ID=O_ADI.DEP_ID)

where PIS.PROC_INST_NAME='通用表單-2009/12/1 10:51:30(791)'

and PIS.PROC_INST_ID=WK.PROC_INST_ID

and WK.ACTIVITY_INST_ID=WAI.ID

order by WK.ASSIGNED_DATE,WAI.NAME,WK.SESSION_

如何作到一個步驟有多個參與者與批次簽核?

在AgilePoint 中要作到批次簽核的功能是一件很容易, 因為AgilePoint 是採用webService的架構, 因此要完成一個步驟只要有工作代號(WorkItemID), 逐筆呼叫api.CompletedWorkItem(WorkItemId) 就可以了.

但是要作一個通用的批次簽核要考慮的問題就比較多了, 原因是AgilePoint 沒有絕對的核準或退回, 其核准或退回只是一個流程變數等於True或False, 而變數麼名稱是可以自定的.

因此若要作到批次簽核, 首先變數名稱一定要先統一, 另外AgilePoint 支援同一個步驟可以有多個參與者, 此時核准或退回就不能單純改變流程變數,

(如上圖流程變數 IsApprove, 如果每個參與者點選同意或退回都去改變他的值, 則其最後的值會由最後一個人決定).因此我們在點選同意或退回的後,

表單中可呼叫SetClientDataVerifyResult(VERIFY_RESULT VerifyResult)

其參數有 VERIFY_RESULT.Approve: 同意

VERIFY_RESULT.Reject: 不同意

VERIFY_RESULT.NoComment: 沒意見(不常用)

這些資料將會寫入每一個WorkItem 的私有的參數欄(Clientdata)

同時在流程元件設定投票的優先順序VotingPriority.

此元件設定為Approve_First 或Reject_First 會讀取 相關的WorkItem 的Clientdata 所存放的核決結果, 判斷出一個惟一的值, 並將其寫入指定的變數.

可設定的判斷有兩種:

Voting Priority: 設定符合條件

             Approve_First - 當符合條件時將ApproveRejectResult的變數設為True。

             Reject_First -當符合條件時將ApproveRejectResult的變數設為False。

             None - 不作Voting判斷。

Session WorkItem :指定評估對像為該批參與者的作業型態。

             Orginal WorkItem - 原始指定的作業(任務)，不含動態會簽。

             All WorkItem - 所有作業, 包括加簽的人亦考慮在內。

Approve Reject Result 設定符合條件後輸出True/False所存放的變數

ApproveReject Rating 評估輸出Approve或Reject 的比率

            1% 只要有一個WorkItem 符合輸出條件即可

           50% 一半的WorkItem符合輸出條件

         100% 全部的WorkItem皆需符合輸出條件

          其它- 自行輸入(需輸入%)

Wait All Task Completed 指定評估時機

         True - 所有作業完成才評估

         False - 每一個作業完成即評估, 只要達到指定的比率, 則其它尚未簽核的工作會被取消,

並直接輸出判斷的結果.

採用Voting 預設輸出的流程變數為ApproveRejectResult.

因此當一個步驟可能多個參與者時, 除了設定VotePriority 外, 並需將同意或退回的判斷設定為VotingPriority 所指定的變數.

如果一個步驟只會有一個參者可選擇直接由按鍵設定流程變數(IsApprove)或設定VotingPriority 其結果是相同的, 差別在於VotingPriority 會多作一次判斷.

上面我們談完了, 如何由表單上或流程元件控制核決結果, 接下來要談到批次簽核.

AgilePoint 的批次簽核事實上就是模擬表單上的動作, 但因為我們無法控制該步驟是採用直接設定流程變數(如IsApprove)或由流程元件判斷Clientdata再設定流程變數(ApproveRejectResult), 因此在批次簽核的頁面上會同時將 SetClientDataVerifyResult(VERIFY_RESULT VerifyResult)寫入ClientData 並將IsApprove 設為True 或False.

通常要使用批次簽核的步驟, 表單上除簽核意見外不應輸入其它欄位, 因此只有特定的步驟才可使用批次簽核, 因此要可以批次簽核的步驟可以在流程元件Manual Activity 中，設定[參與者]之[非必要](Optional) == false及[等待工作完成]WaitWorkPerformed == false，此作業於簽核後會將簽核結果寫入WorkItem 之client Data 並設定流程變數IsApprove=True.

當設定完成, 流程執行至改步驟時, 若該步驟之社設定符合上述設定時會自動出現批次簽核的選項

點選批次簽核的Button, 並勾選欲牽核的表單.

輸入簽核意見與內容, 並點選核准、拒決或取消, 系統自動將簽核結果寫入ClientData 與流程變數

註: AresPortal 中所含的BatchSignPage 是一個未編譯客制網頁, 目前在簽核時只會寫入流程變數IsApprove等於True 或False,換言之目前批次簽核只支援, 一個步驟, 同時只有一個人簽核, 新的版本, 會同時寫入 SetClientDataVerifyResult(VERIFY_RESULT VerifyResult), 請更新為新的版本或直接加入以下程式碼.

如何達成作業Pool, 一份工作同時指派多人, 但只要部份的人簽核 ？

在AgilePoint 中一個步驟可以同時指派給多人, 但真正需要執行的人數, 可由流程元件Manual Activity控制之屬性[最大參與者數](Max Participants)設定,

指派的人數小於[最大參與者數] 則表示所有被指派者都需簽核, 如設定為 1則表示被指派者只有一個人需簽核.

指派多個參與者的方法常用的有下列幾種:

1. 單一流程變數- 指定多人

如$O2U_AssignedUser_USER (使用者存放於流程變數AssignedUser中,人員間以分號區隔, 若需指定部門, 可以UserName 後加逗號.)

2. 單一流程變數-指定多部門

如$O2D_AssignedDept_USER (使用者存放於流程變數AssignedDept中,部門間以分號區隔.)

3. 指定多個流程變數, 流程變數間以分號區隔.

4. 使用組織變數 如$O2_DeptID_ALL( 註:DeptID為特定部門代號)

5. 其它任何可一此設定多人的方法皆可使用.

除了原有的流程變數外, 我們在新一個版本另外增加一個功能是指定部門主管層級範圍與人數

(此視窗為新版AFAgileWork 之ParticipantsUser 的設定部門視窗)

例如在一個組織中

L6-組長 L5-科長 L4-經理 L3-協理 L2-副總 L1-總經理, L0-董事長

若申請者送出表單後, 可由 L6 至 L3 任一人核可, 之後再由上一階主管逐一簽核至 L1的總經理.

則可以設定為MANAGERGROUP , 並指定最多幾個Manager , 且範圍為L6 至 L3 ,

則 L6 至 L3 的主管每人都會收到一個New 的Task , 其中一人簽核後, 可在配合逐級簽核至指定層級.

上述設定UserRank 由L6 至 L3 , 會依使用者所在部門, 尋找上階部門只要部門主管層級是在L6至L3 之簽則會加入指派名單, 若L4 之經理發單, 則上階部門只會取得L3(協理).

必要時利用這種設定方式可加快企業流程之進行.

 

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

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

表單樣版的擴充性

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

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