EEP2010WorkFlowContents

Contents

目 錄

第一章 Workflow基本觀念

第二章 基本Workflow設計
第三章 Workflow基礎設計實作

第四章 Workflow Web設計實作

第五章 Workflow進階設計

第六章 EF Workflow的處理

附錄：

A、WorkFlow元件屬性說明

B、WorkFlow活動屬性說明

C、WorkFlow系統資料表結構說明

D、WorkFlow系統檔案說明

E、WorkFlow Expresssion格式


Workflow基本觀念

本章說明內容之大綱摘要：

v 1-1 工作流程簡介

v 1-2 關於Workflow Foundation

v 1-3 EEP2010 Workflow Foundation

v 1-4 Workflow活動元件簡介

v 1-5 企業組織與角色

v 1-6 待辦/經辦/逾時事項


1-1 工作流程簡介

q 何謂工作流程管理系統

幾年前，工作流程可稱為電子簽核，定義也很多，多家廠商可以自我表述。隨著WFMC(Workflow Management Coalition)的成立，絕大多數的工作流程系統大都已經依照WFMC的標準來制定規格，以下我們就WFMC標準簡單定義一下工作流程管理。

工作流程：Work Flow，就是自動化處理程序的簡稱，指企業參與者對文件或訊息按照規範的制度來作業，並使其在企業參與者間傳遞，也就是一系列相互銜接，自動進行的業務活動或任務。狹義一點，你就當作它是企業單據的電子簽核。

工作流程管理：Workflow Management就是人與電腦共同工作的自動化協調控制和通訊，在電腦化的業務過程上，通過在網路上的軟體系統，使所有文件流程與命令的執行都處於受控制的狀態。在工作流程管理下，工作量可以被監督與分派，使每个用戶的工作量可以達成平衡。

工作流管理系统：Workflow Management System是可透過軟體的定義，來建立工作流程並管理其執行。它必須執行在一個或多個工作流程引擎上，這些引擎必須能了解這些過程的定義，與工作流程間的參與者（可以是人或另一個軟體）相互作用，並根據需求配合其他的工具或程式相互應用。

總體來說，實際在企業中運作的工作流程管理系統，它必須是一個「人機結合」的系統。它的基本功能將呈現在下列幾個方面：

1. 定義工作流程，包括具體的流程活動(Activity)(平常我們稱程序)與規則等，這些定義是同時被人及電腦所共同瞭解的，就是人為的定義讓電腦系統能確實瞭解。

2. 遵循定義去建立實例(Instant)與執行實際的工作流程。

3. 監察、控制、管理執行中的業務與工作流程(可以解釋為企業單據)，例如可對任務(單據)、工作量與進度的檢查與平衡工作等等。


1-2 關於Workflow Foundation

q 關於微軟的WF

2007年初，老大哥微軟終於推出了第一個可以在.NET上執行的Work Flow架構，Windows Workflow Foundation(簡稱WF)，它提供了一個可以整合在VS2010之下的程式開發環境與相關的工具，讓程式開發人員可以利用WF來建構工作流程管理系統，程式人員可以自由開發屬於自己的「流程活動元件」 (Activity)，並整合其他現成可用的Web Service與其他外部的程式，可應用到各種不同的企業領域中。它有幾個特色，說明如下：

1. WF是有狀態的、持久化的、不間斷執行的應用程式：WF是個有狀態的服務(能記住上一次執行到哪)的架構，並且是一個非同步執行的工作流程應用程序(可以不用讓Client去等待)，最重要的是WF的工作流程引擎可以確保所有工作流程實例長期執行，並能抵抗機器的當機重開(這是因為這些Instant可以被序列化保存著)。

2. 親和與視覺化的工作流程模型：WF為開發人員提供了一個親和與視覺化的工作流程模型，來描述應用系統所需要的處理過程。透過使用此開發界面能讓工作流程模型所提供的流程元件、狀態管理等，讓開發人員可以分離應用程式的邏輯和商業邏輯，構造一個高層次的抽象化流程物件，達到容易理解與維護的目的。

3. 元件化可重用：WF為開發者提供了一系列的流程活動，這是一種基本工作單元，可被元件化設計。這種架構封裝了開發者可能經常性使用到的一些程式，可節省開發時間，也可讓這些自定義的活動元件提供了方法(Method)，通過將工作流程引擎載入，來讓這個活動元件可受到外界的指揮來執行相對的方法。

4. 可整合其他服務端的服務：執行時，可以透過Web Service或其他遠端服務程

序來整合流程中各活動元件與需配合的商業邏輯與資料庫服務，包含資料的分裝與派送，讓系統更加靈活，在SOA(Service Oriented Architecture)服務導向架構風行的今日，更顯得與其他服務整合的重要性。

q WF的架構

瞭解了WF的功能與特色後，接著透過這張圖，來了解WF的架構，現將下圖各名詞解釋如下：

(註：之前微軟官方稱Windows Workflow Foundation為WWF，現簡稱為WF)

Activity：流程活動，為工作流程中的最基本單元，此活動單位，可以很簡單到複雜皆可。

Workflow：工作流程，為一組多個流程活動所組成的部分或全部的商業處理程序，當流程在引擎中被建立時，會製造一個流程實例(Instant)。

WF designers：流程的圖形設計工具，可用於新增與修改的工作流程中的各個流程活動。

WF base activity library：流程活動的基本元件組，這是微軟為我們開發好現成的流程活動元件，開發者可以直接使用，也可以自行來設計這類的活動元件。

WF runtime engine：用來執行工作流程的程式庫，也就是WF的工作引擎，並提供與外部整合與溝通的機制與服務，來加強本引擎的彈性能力。

Host Process：流程主機程序，這是一個WF主機的處理程序，當WF的runtime engine執行時，此主機程序將提供穩定的執行服務，如支援工作流程的狀態(利用序列化保留上次的狀態)，處理流程的交易和其他功能等。

WF提供了開發者自由發揮的空間，架構上提供了以下兩種流程：

1. Sequential Workflow：一個循序往下進行流動的工作流程，每個流程活動都依流程的邏輯往下被執行，是一個只能前進不能後退的流程，此流程也可以讓參與者互動，決定何時往下執行，最常運用在企業之複雜型商業邏輯的抽象化，可以簡化耦合度與讓商業邏輯透明化。

2. State Workflow：一個依照各個流程活動的狀態，來決定往下執行那個流程活動，此為企業流程最常用的應用，可以讓企業單據與服務在工作流中與參與者互動並整合企業的商業邏輯。


1-3 EEP2010 Workflow Foundation

q EEP2010 WF簡介

EEP2010 Workflow Foundation，採用Microsoft .NET 4.0 Workflow Foundation為核心技術，整合快速的電子表單工具，可以輕易與企業的ERP等資訊系統整合，讓企業流程與單據在可靠且穩定的Workflow 環境下落實BPM管理制度，改善企業流程，讓企業大幅提高作業效率與監督控管能力，以e化提升企業經營競爭力。現將EEP2010 WF產品要項說明如下：

1. 100% 採用WF Designer，除了可以在VS2010中設計工作流程外，我們有另外設計一個WF Designer來讓企業流程架構師與管理師來獨立執行，方便更改流程時可以不必進入VS2010來設計。

2. WF Designer的流程圖可以透過Windows與Web來讓User直接作為導覽圖或預覽公司抽象化的流程制度。

3. 使用強大的WF Runtime Engine作為核心的系統，讓你的Workflow能更穩定的執行與其他系統進行整合。

4. 開發近10個高階的流程活動元件(Activity)，可以直接與EEP2010的原有的Windows表單與Web表單無縫結合(只要多貼一個WF元件即可)。我們所開發的Activity目前都是Sequential(依序)類型的活動元件，但為了能在企業簽核中可以退回與簡化作業，我們在WF Runtime Engine中往上架了一層FLRuntime來解決此問題。

5. 提供配合原EEP2010的Login系統，可擴充整合WF所要的組織與角色其授權標準的設定，並提供全新完整兼具彈性的代理人制度。

6. Login系統同樣可配合AD/Group的帳號與Email資料整合，每個流程活動可

以控制是否整合發送Email通知或以Email簽回。

7. 另提供流程入口主頁(Portal)，Web與Win都可以通用，並提供統一的待辦事項(此User所有流程單據的代辦中心)，經辦事項(此User經辦過且未結案的流程單據)，異常預警中心(屬下或自己的待辦逾時或發生異常)等等功能。

8. 在EEPNetServer上的執行引擎有提供Workflow的API接口，以方便提供同樣在.net上其他網頁與Windows Client系統的整合與橋接，在Server端方面，我們也提供Web Service方式來與其他類似SOA架構的服務相互整合。

q EEP2010 WF的架構

如圖為EEP2010 WF系統的架構圖，各部分功能簡單說明如下：

EEPNetServer：整個EEP2010WF系統事架構在EEPNetServer上，為了能搭配現有Server端被包裝過的商業邏輯(業務流程)，因此如要在A/P Server中執行Workflow系統，只要將FLRunTime.dll註冊上即可運作。

EEP WF Designer：改寫或繼承自WF Designer的功能，可以獨立於VS2010之外，讓設計者可以不必透過VS2010，設計完成的工作流程將存成XOML檔案，須存放在EEPNetServer的指定目錄上，在Designer中所使用的活動元件，都是來自FLTools的活動元件。

EEP WF Activity：為EEP所提供常用的工作流程活動元件，可以很快速與EEP表單結合，達到簽核的目的，開發者也可以自行繼承或新增自已的流程活動元件，此模組中有部分使屬於U/I的元件，使用在Web或Windows的Client中為了配合流程簽核的操作所使用，並不是所有的元件都是屬於Acitivity。(此DLL為FLTools.DLL)。

EEP WF Core：為EEP的基本類型與基本相互溝通的核心程式庫，用來溝通FLTools的元件與FLRunTime以及FLDesigner所共同的元件類型與程式接口。(DLL名稱為FLCore.DLL)。

EEP WF RunTime：用來實際執行每個工作流程實例，與控制整個執行時期的狀態，他會交給微軟的WF Engine來執行，以增加流程的可靠度與穩定度，另外，此RunTime引擎中有特別去支援Sequential依序的活動可以被逆流退回。(DLL名稱為FLRunTime.DLL)。

FLDesignerCore：用來讓支援讓Web或Win的Client端程式，可以將設計好的流程圖可以顯示出來，除了讓User更了解公司的流程規範外，更重要的是讓User以此流程圖來操作表單與簽核。

EEP Win/Web Client：與之前的EEPNetClient.EXE與EEPWebClient類似，都可以自行Login到EEPNetServer上之外，還可以利用這兩個新的主頁面程式，顯示出Workflow的流程圖，並顯示待辦與經辦的資料，還有異常預警的警示資料等等。
註：因為整體的架構使用到微軟的Workflow Foundation，所以在Runtime的主機與開發的環境中都需要安裝 .NET 4.0或以上，在開發環境上還要安裝Windows Workflow Foundation的擴充包才能執行與開發。

q EEP2010 WF基本組成

EEP2010包含了下列幾個部分：

1. 流程開發器：提供管理師用來設計企業流程所使用的開發介面，如圖，開發者的背景是流程規劃師，可以ISO的制度或企業流程，來設計流程介面，圖中間區域為流程設計區，設計者在此設計流程，右上方為活動元件(Activity)區，可以將活動元件貼入設計區中，下方為屬性區域，可以用來定義所有元件的各別屬性。

EEP2010 WF有十餘個活動元件，有些元件須配合EEP2010的Windows表單與Web表單來呈送與審核，另外，本WF是一個與資料庫高度整合的系統，因此任何一個工作流程都須配合一個主資料表來進行流程運作；流程開發器所設計的結果會存成XOML檔案格式。

2. 流程引擎：EEP2010的流程引擎是以.NET 4.0的Workflow Foundation為核心所開發的架構，整個核心為3個dll構成，這3個dll都是建置在EEPNetServer上(EEPNetServer就是EEP2010的Application Server，除了當作應用系統的伺服器外，也可以做為工作流程伺服器)，其中FLRunTime.dll為執行中心，控制所有線上流動的單據與活動；另兩個dll分別為FLCore.dll與FLTools.dll，分別代表WF的公用程式接口及活動元件庫。FLRunTime與FLTools是個開放原始碼的程式，可以讓企業自行增加活動元件與改善流程引擎功能。

3. 使用者介面：使用者介面上主要有三個元件負責，FLWizard元件負責取得流程待辦 (該User的承辦單據)與經辦(該User送出或經辦過的未結案單據)；FLNavigator則負責將單據呈送或進行審核退回等工作，會與Server端的FLCore自動進行溝通；FLDesigner元件則負責讓流程開發器所設計的流程圖可以顯示出來，讓User可以透過流程圖點選與操作單據。

待辦與經辦事項文後有說明，請自行參閱。


1-4 Workflow活動元件簡介

在EEP2010 WF中，整個流程設計都是以活動元件所構成，以下我們將EEP2010 WF的幾個重要活動元件(Activity)說明如下：

1. FLStandard Stardard ：標準活動元件，這是最基礎的活動元件，用來設定使用一個Windows與WEB表單來進行簽核，並設定呈送的對象與角色。

2. FLApprove approve ：審核活動元件，這是一個專門用來審核的活動元件，與FLStandard同樣設定一個Windows與WEB表單來簽核，本活動的對象一定是呈送者的主管，最特別的是本活動可以依不同的職級來設定不同的核決權限條件，不必去組合多個IfElseActivity活動變得龐大複雜。

3. FLNotify notify ：通知活動元件，這個活動主要用來通知一個特定的對象，讓該對象能即時收到通知，並且無論該對象處理為何，都會往下繼續流動，也就是不會受到這個活動的影響而停滯。

4. ParallelActivity [image] ：平行處理活動元件，可同時處理多個活動的會簽(條件AND)與平行簽核(OR)，會簽會等所有平行活動審核完畢才會往下流動，平行簽核則是只要有任一活動審核就會往下流動，目的是可以提升簽核效率。

5. IfElseActivity [image] ：邏輯判斷元件，可以定義一個或多個邏輯判斷式，來處理企業的商業邏輯，用來分支處理往下走哪一條活動路線。

6. FLProcedure Procedure ：處理程序活動元件，該活動是對應到Application Server上的一個伺服程式(Server Method)，就是流程經過本活動時，會執行該Server Method，並且會告之流程方向(有往後呈送與往前退回)。

7. FLSunFlow Prepare ：子流程活動元件，用來串接另一個子流程所使用，可以讓

Flow當中有一個子流程，當該子流程結束時，會回到原流程繼續執行，唯一要注意的是，主流程與子流程須同為一個流程表單，否則無法串接與持續。

8. FLValidate Validate ：稽核活動元件，這是一個資料或制度稽核的檢查，可以預先設定條件，如條件不符合，系統會自動退回處理，符合才能往下流動。

9. FLHyperLink NextFlow ：連結活動元件，此專門用來讓User操作的活動元件，在Server上的WF引擎將不做任何處理，當User按了這個連結活動時，會打開指定的另一個流程圖。

10. FLQuery Query ：查詢活動元件，此專門用來查詢簽核中或已結案的單據，結合在流程活動中以方便User查詢資料，當然本活動元件在Server上的WF引擎是不會有任何作用的(By Pass)。

11. FLReject [image] ：中止活動元件，此專門用來中止流程的進行，也就是強制作廢本張單據，除了作廢外，會指定執行一段ServerMethod進行中止或錯誤的處理，並可設定中止通知的對象。

12. FLDetails ：明細活動元件，此專門用來Master/Detail這種有多筆明細表的資料來進行流程的簽核，在本活動中，可以根據此Details的各筆內容來進行流程簽核，每一筆都可以設定要簽核的角色及是否為平行處理或串列處理，此活動可以用來動態自定流程的簽核與自動流程步驟等等強大功能。

以上的活動元件，都可以設定一個對應的Windows或Web表單，可以兩者都設或任選一個，目的是為了在流程當中，User可以透過Web或Windows來簽核都可，以整合企業內外的管理者與用戶，當然Web系統會自行對應到Web的表單，Windows的系統就對應到Windows表單。


1-5 企業組織與角色

Workflow是一個與其他系統非常緊密的系統，在設計一個Workflow之前，除了應該將簽核表單設計好之外，也要配合其他的設定，如公司的組織部門的結構，到人員的編制與部門機能，各部門主管的職級與核決權限等等，以下說明與Workflow相關的基本設定。

q 群組與角色設定

系統的設定除了User外，還有群組的設定，群組就是代表多個Users，一般代表部門或特殊群組，但在Workflow系統中，群組可以用來作為角色來使用，只要在群組當中設定「角色」為「Y」即可，如下圖，角色一定是群組，但群組不一定是角色(設為Y的才是角色)，有時角色只能有一個User(如部門主管)，但有時可以多個，這個設定與前版的EEPFlow有很大的不同，主要是關係變簡單了，設定也變簡單了。

q 組織設定

企業組織在Workflow中是必要的設定，否則將無法正常運作，因為Workflow是用來規範企業的簽核制度，由屬下填寫單據往下呈送，過程中必須定義那個User在企業是扮演什麼職務(角色)，在什麼組織與部門之下，主管是誰，其後面有沒有另外的主管等，都是透過組織來設定完成的。

組織定義是以一個樹狀的結構來定義，由上往下定義，每個組織或部門都要定義其主管為那一個角色負責(一定要以角色來定義)，其部門之下有那些角色成員（有那些角色編制），注意這些組織的成員中，大都是複數角色(一個角色代表多個User，如業務，工程師)，但如果是主管或特定的角色(如出納或倉管)，一般都是單獨角色(一個角色一個User扮演)，否則簽核到該角色時，如果有多人則會有權責的問題。

q 職級設定

企業在制訂流程時，一般主管簽核的活動元件(FLApprove)並不是單層簽核即可，都會依據單據情況來自動決定簽核的層級，如最常見的請購單，可以制訂各級主管的請購金額上限，如一般主管為一萬元，經理為三萬元，副總為十萬，超過十萬則要總經理簽核等。如此在FLApprove中就必須制訂各部門主管的職級，好讓系統遇到主管簽核時能自動依據主管權責條件來決定簽送到那個層級主管。如圖即為職級設定的畫面。

q 組織代號設定

前面的組織設定中，是可以有多套組織一起運作，如公司會有一個行政組織，可能還會有一個公會組織(福委會)或特殊的專案組織等等，因為組織的不同，部門主管與成員也不同，因此在Workflow中必須定義對應到那一個組織以方便系統自動運作，但為了方便，在Workflow建立時，系統預設都視為公司行政組織。

q 代理人設定

由於企業的User並不是一直都在公司或能上網的地方，因此只要有人請假或出差就會有代理人的問題，因為Workflow電子簽核，一定要有人上線簽核才會往下流動單據，因此企業主管出差請假前就必須讓系統知道由誰代理原來的角色，代理的設定將有時間性與功能性，如下圖定義此角色將由那個User代理並指定期間，並且可以指定哪些流程由哪些人代理之，讓系統的代理可以更彈性。

上圖中，注意有一個「平行代理」欄位，正常代理情況下都是「N」，如果為「Y」代表被代理者與代理者間的關係是平行的關係，也就是此代理關係是屬於常態性的代理，並非一段短期間的代理，在待辦事項中兩者都會看到相同的單據，兩者也都可以對此些單據進行簽核，不同的是：如果是原角色簽核時將不會發出「通

知」給平行代理者，反之，如果是平行代理者簽核時，流程將會繼續往下流動，同時系統將會自動發送「通知」給原職務角色，其目的是為了解決原職務角色經常外出，公司內部的職務將有一位常態的代理人，以免因主管外出影響公司運作。


1-6 待辦/經辦/通知/逾時事項

q 待辦事項

這個部份就是要顯示登入者的待辦事項，所謂待辦事項就是根據企業的流程制度，其屬下或其他部門的使用者必須經過登入者批示或確認才能生效的單據，在此待辦事項可以直接打開此單據的表單或報表進行審核或確認，因為每個人都有他自己的待辦，所以會依登入者在企業所扮演的不同角色來顯示出待辦事項，一個使用者可以扮演多個角色，並會在同一個待辦窗中看到所有負責的事項，就好像E-Mail一樣，每個人都有自己的E-Mail。另外，簽核者擊點 [image] 將此單據打開並簽核或直接點擊 [image] 審核，點擊 [image] 退回。

q 經辦事項

這個部份是指登入者所經辦過且未結案的事項與單據，只要經過此登入者所經手的任何單據，都會自動列在此追蹤事項中，當然，與待辦事項一樣每個登入者有他自己的追蹤事項。也可點擊 [image] 來打開原來的單據，但不能去更改資料，因為已經在流程當中；這按鈕 [image] 就是要將呈送過去的單據取回，此是為了在主管未簽核單據前，呈送者都可以後悔取回，但如果主管已經簽核或已經在呈送到下面流程時，即無法有權利取回，只能找目前的經辦人員將其單據退回。經辦追蹤如圖所示，與待辦是非常相似的。

q 通知事項

指登入者所有通過的單據，或他人所提供的通知類型的單據會顯示於通知事項中，與待辦最大的不同是，待辦必須由登入者即時處理，才能往下運作，但通知則較無關緊要，登入者不處理也不影響他人的運作，自行參考或慢慢處理即可。

q 逾時事項

企業的管理已經從危機處理進化到防範於未然，與其有很強的應變能力，還不如防範事件的發生，逾時事項就是要扮演逾時單據通知的功能，以防止屬下積壓重要單據來減少企業的損失。透過逾時事項可以來了解登入者屬下的單據產生逾時情況，並會透過逾時事項來通知其後面的高階主管，而且可以指定要查看的屬下階層，如設定為2級，代表往下查看2級的屬下是否有超過指定時間尚未處理的單據。逾時事項的畫面如圖所示，可以透過屬下層級來設定查看層級。


基本Workflow設計

本章說明內容之大綱摘要：

v 2-1 Workflow的安裝

v 2-2 流程設計的準備工作

v 2-3 設計一個簡單的流程

v 2-4 執行流程的結果


2-1 Workflow的安裝

安裝EEP2010 WF与其之前的EEP2006 WF和EEP2008 WF版本的安装不同。目前EEP2010有Flow的Setup版本。具体的安装步骤请参考文件(0)EEP2010-Setup.CHM。


2-2 流程設計的準備工作

在流程設計前，我們必須針對這些必要的系統資料表，做好準備，為了能讓讀者能依照本文件進行學習，請盡量按照我們規劃的資料去的設定，等到正式使用時再轉入自己的資料。所有的基本資料都可以透過EEPManager來設計，打開「Security Manager」頁面，依下列次序設定之：

Step1＞切換到了「Users & Groups」頁籤中，我們先來設定幾個Users的資本資料，做為往下範例的依據，如下圖，我們建立的多個Users的帳號。

在此我們設定了11個User，其中「001,002,003,004,005,006,007,009」是下文中一定會用到的，其餘的User可以不建立，另User的姓名請自行參考，Email帳號請先不必輸入，等下文中用到Email時再回來設定。

Step2＞設定Groups，之前的Groups是代表使用者群組，但在Workflow中卻也可以代表角色，一個角色可以有多個User扮演，也可是一個User，在此我們將角色設定為「Y」就代表示流程所使用的角色，因此之前的群組不一定是角色，但角色也可以是一個群組，如下圖，可以透過後面的ListBox來設定該角色為哪一個User或哪些User：

設定時，我們設定了R01到R10等公司的職務，分別代表不同的職務，在ListBox中設定完畢後，必須按一下「Save」的Button才會真正存檔。請依下表建立角色的名稱與用戶：

角色代號 | 角色名稱 | 使用者 | 備註
R00 | 總經理 | 001 |
R01 | 業務 | 003,006 |
R02 | 業務經理 | 005 |
R03 | 行政經理 | 002 |
R04 | 工程師 | 004,011 |
R05 | 客服經理 | 007 |
R06 | 業務助理 | 008 | 可以不設
R07 | 專案經理 | 010 | 可以不設
R08 | 專案工程師 | 004,011 | 可以不設
R09 | 財務會計 | 009 | 可以不設
R10 | 倉管 | 009 |

Step3＞設定「OrgLevel」，代表設定公司主管的層級，代碼設定時須注意必須職級小的設定到職級大的，如最小的主管是「1」，最大的主管是「9」等等。

職級的用途是在組織設定時，用來定義該組織主管的層級，因為在流程中的主管審核大都會依照不同的層級有不同的授權，就以此來做授權標準。

Step4＞設定「OrgKind」，代表設定公司組織代號，依照公司的組織情形建立資料，系統預設’0’為公司的基本組織。

因為同一個角色可能在不同組織上扮演不同的功能，因此會根據組織的不同，會有不同的主管與流程。

Step5＞設定「Organization」公司組織，因為Workflow的流程制定，很多地方會用到使用者的主管設定，因此必須要有樹狀組織的設定才能定義出User的主管與組織位階，如下圖為組織設定的畫面：

請依照上圖的組織設定之，輸入時，請參考一下說明：

部門編號：可以自行編立，如果同層部門的編號將為其排序的依據，如上面的業務部為’2’，專案部為’3’，因此業務部在上方，以此類推。

上層部門：本部門市隸屬哪一個部門之下，可以用來定義其樹狀的結構，為空白代表組織最上層。

主管：此設定是必填的，否則無法存檔，每個組織都必須設定一個主管，而主管的角色最好也只能定義一個User，因為該主管的角色如果有兩個User，則會發生權責不清的現象。

職級名稱：就是上述的OrgLevel主管層級，每個部門主管在該組織中的主管層級，主管審核Activity元件的授權標準就是會以此主管層級來處理的。

部門中角色：每個部門內，都可以設定有哪些角色，注意在此都是角色為主，無法以User來設定，因此都必須透過角色來定義User，操作時，必須要按下『Update』的Button才能進行部門的角色定義。如下，可以按照下表來設定組織的資料。

部門編號 | 部門名稱 | 上層部門 | 主管 | 職級 | 部門角色
1 | 總公司 |  | R00 | 總經理 |
2 | 業務部 | 1 | R02 | 經理 | R01,R06
3 | 專案部 | 1 | R07 | 經理 | R08
4 | 客服部 | 1 | R05 | 經理 | R04
5 | 總管理部 | 1 | R03 | 經理 | R09,R10


2-3設計一個簡單的流程

接著我們要開始設計一個最簡單的流程，我們就用一個單檔的【客戶申請流程】做為我們的流程申請範例，可以按以下的設計步驟來進行設計：

Step1＞在EEP2010 WF中，對於所有要參與Flow流程的簽核，都必須對應到一個實體的資料表，這是因為本WF系統必須利用此Table來對應一個Window Form或Web Form的表單，作為簽核的單據。因此，我們在客戶申請流程中，就以Customers這個Table作為客戶申請的資料表，如下我們在Customers增加了兩個欄位：一個為flowflag (char 1)，此為EEP2010 WF系統中，規定必須在你的流程資料表中一定要增加的一個系統欄位，流程引擎將會用flowflag來做為該單據在流程中的簽核狀態，如’N’代表新增申請，’P’代表簽核中，’Z’代表已通過審核等等；一個為CreditAmount (Momey)，代表此客戶的信用額度，此欄位用來做為本例的審核條件欄位。

Step2＞接著我們透過EEP Wizard的【Server Package Wizard】，來產生一個Server端的Package，我們將其命名為 SCustomers，TableName選Customers，欄位選全部，請最好事先在資料字典中先去新增剛剛flowflag與CreditAmount欄位的中文欄位抬頭，勾選CustomerID為Key，最後將產生一個SCustomers.DLL。

最後在EEPNetServer的【Package Manager】中，將SCustomer.dll註冊到Solution1這個方案當中，如圖。

Step3＞接在我們同樣使用EEP Wizard的【Windows Form Package Wizard】，來產生一個Windows的表單Package，選擇Package Name為CCustomers，FormName也是CCustomers，Provider選擇剛剛SCustomers.dll的Customers這個Table，View的欄位選CustomerID與CompanyName即可，MasterFields則選擇所有欄位，如圖，最後產生一個CCustomers.DLL的Windows Form Package。生成目錄在【C:\Program Files\Infolight\EEP2010\EEPNetFLClient\Solution1】，在Wizard模板下修改路径，如下图所示。

Step4＞為了方便利用此Windows Form來輸入客戶申請資料，並避免User在打開申請單後使用左方的GridView來點選到其他資料，因此，我們可以將左方的GridView資料隱藏起來，可以點選上面的GridView，按二次”ESC”鍵，使其焦點停在其上層的SplitterContainer元件上，並將SplitterContainer的Panel1Collapsed設為True即可縮掉左方的GridView了。

Step5＞為了讓此表單擁有工作流程的功能，因此我們將上面的InfoNavigator的元件，在CCustomers.designer.cs中改用FLNavigator元件，因為FLNavigator是繼承自InfoNavigator，因此可以透過Designer.cs中來直接更改Class名稱即可。步驟如下：

首先，在工具箱中找到【FLTools / navigatorConvert】這個元件，將這個元件拖入這個表單中，這樣navigatorConvert 元件是用來設計模式中要將InfoNavigator轉換成FLNavigator所使用。

Step6＞接著，請打開 CCustomers.designer.cs這個程式，去尋找”Srvtools.InfoNavigator”，應該有2個地方需要更改，如下找到new的地方：

將上面 Srvtools.InfoNavigator()改成

this.infoNavigator1 = new FLTools.FLNavigator();

再往下找，應該會找到private的物件處，如下：

請將這列程式改成

private FLTools.FLNavigator infoNavigator1;

最後，我們將CCustomers.designer.cs存檔起來，並將CCustomers.cs的Form關閉，重新開啟此Form，目的是為了能重新打開更換成新的FLNavigator元件，可以點選這個InfoNavigator1這個元件(元件名稱不變)，看看其ClassName是否已經更換為FLNavigator了。

Step7＞使用navigatorConverter元件來完成FLNavigator的轉換工作，剛剛我們更改ClassName只是在Create此Navigator使用FLNavigator為ClassName，但之前有一些Workflow的操作Icon按鈕並沒有相對產生(除非你一開始就貼FLNavigator，否則事後更改的都不會有Icon)，接著再navigatorConvert1的FlowNavigator的屬性中設定到InfoNavigator1，再利用navigatorConverter的右鍵或右上角快捷的【Set Default】功能來預設FLNavigator內的流程功能按鈕，如圖，將會產生多個功能按鈕。

接著設定「FLNavigator.FlowBindingSource」屬性，我們將其設定為ibsCustomers即可，再來可以將此InfoNavigator1中刪除不要用的按鈕，如可以將Print與Export刪除等，到此為止，我們已經設計好一個流程的表單，與一般的EEP2010表單類似。如果是之前用EEP2010所設計好的表單，如果要增加WorkFlow的功能時，也可以用以上的步驟來實現，如果你是新開發的表單就要具有Workflow的功能，則可以在AddIns\Templates\CSingle的目錄中，將原來的Template表單事先貼好FLNavigator取代InfoNavigator元件，將會讓你的設計更為快速與簡便。

Step8＞為了在這個表單打開時，預設不要啟動InfoDataSet的資料，我們將idCustomers的AlwaysClose設定為True，代表打開這個表單時，idCustomers不會被起動，表單上也不會有資料顯示；另外，為了保護顯示的欄位不會被USER隨意去更動，我們將ibsCustomers的AutoDisibleControl設定為True，代表一定要按下「編輯」或「新增」的按鈕才能編輯資料，然後重新Rebuild一下CCustomer.csproj專案檔。

Step9＞接著我們在EEP2010的FLDesigner目錄下找到FLDesigner.exe，為了方便，可以桌面建立捷徑以方便使用。雙擊後，會出現Login的介面，這裡是用於確認在整個Flow流程設計時所要登錄的DB是哪個。進入FLDesigner.exe，如圖，按下File/New之後將會自動產生一個空的流程。

其中，中間的部分為【流程設計區】，右上角的區域【流程活動元件區】，可以將右上角的活動元件(Activity)拖入流程當中，右下角區域為【屬性區】，用來設定各流程活動的屬性內容，最下方的頁籤，目前只用到第一頁的檢視設計頁面，第二個以後分別為取消處理/錯誤處理/補償處理/事件處理等頁面，第二頁以後目前都沒有用到，可以不必設定與相對處理。

Step10＞新建一個流程，首先要設定此流程的基本設定，可以點選到上圖中流程設計區中空白的部分，可以針對此流程屬性按以下的設定：

OrgKind：代表本流程所要使用的公司組織代號，系統允許公司有多個組織，依不同的組織來找到不同的角色與不同的作業流程，一般可以在此設定預設的組織，或是可以在User上呈前再來決定公司的組織。我們選一個預設的公司組織0。

TableName：本流程一定要有一個主要的table來對應，因此必須在此填入相對的TableName，可以用下拉的方式來選TableName，在客戶申請流程中，我們選 Customers 作為流程的主Table。

Keys：指TableName中的Key Fields，代表該Table的主鑑欄位，可以定義多個，中間以’;’隔開即可，定義此Key Fields的目的是為了在流程中，我們需收集此單據的鍵值欄位與其內容，列入代辦事項與經辦事項中，好讓使用者可以用此欄位來識別資料內容。在此我們設定CustomerID。

(Name)：本流程的名稱，此不必設定，系統會以此文件(XOML)為流程名稱。

Base類別：固定都繼承自 FLTools.FLSequentialWorkflow這個類別。

Description ：流程的說明，一般對User來說，此才是真正User所認知的流程名稱，在此我們可以使用中文名稱來定義，如我們設定為客戶申請 。

Enable: 請固定設為True。

FormName：請選擇一個Windows的表單名稱，可以按下右方的選取按鈕，選擇回來的格式為 DllName.FormName，在此我們選擇 CCustomers.CCustomers。因為這裡是Windows的表單，所以我們定義FormName屬性，如果是Web表單，則須定義WebFormName這個屬性。在此設定了FormName這樣我們將默認整個流程都訪問CCustomers.CCustomers這個Form。

Step11＞從【流程活動元件區】中拖入兩個FLStand(標準流程)活動元件，如下圖：拖入FLStand活動時，需在Start與End間的區域上放開Mouse左鍵即可。如下圖，先定義第一個流程活動：

(Name)：活動名稱，為了讓User可以貼切了解，我們直接輸入中文客戶申請。

FormName：請選擇一個Windows的表單名稱，可以按下右方的選取按鈕，選擇回來的格式為 DllName.FormName，在此我們選擇 CCustomers.CCustomers。因為這裡是Windows的表單，所以我們定義FormName屬性，如果是Web表單，則須定義WebFormName這個屬性。如果在前面的整個流程的設定中，已經設定了FormName那麽就可省略此步設定。

NavigatorMode：設定打開此表單後，要控制其Navigator的進入的狀態，因為流程表單被打開後，就無法像之前的表單打開一樣，可以讓User任意新增/更改/刪除/查詢資料等等，在流程中操作表單，必須控制Navigator只能操作某些動作，不是任意可以讓User操作，在此設定為Insert，代表只能讓User可以新增資料，無法操作其他功能。

FLNavigatorMode：此與NavigatorMode很類似，但此用來控制流程按鈕的狀態，因為表單我們改貼了FLNavigator後，多了幾個流程按鈕，因此透過此流程活動的屬性，來控制此FLNavigator哪些流程按鈕可以執行，哪些則要隱藏等等。在此設定為Submit，代表只能讓User可以操作上呈與暫停的操作，(暫停是指呈送者先暫時存在自己的待辦事項中)。

SendToKind：用來設定此活動的對象種類，對象種類有Role/RefRole/Manager/Applicate等等，Role代表對象為一個角色，RefRole代表為參考角色，就是根據某個欄位內容做為動態的角色，Manager則代表對象為上呈者的主管(根據組織的設定)，Applicate則代表最原始的申請者等等。在此因為是流程的第一個活動，所以應該被設定為Applicate。

接著設定第二個FLStand活動元件，如下圖：

(Name)：活動名稱，直接輸入中文主管審核。

FormName：請選擇一個Windows的表單名稱，同樣選擇選擇 CCustomers.CCustomers 這個表單，當然，目前是因為申請與審核的表單是同一個，如果不同是可以設定不同的表單，但必須另外設計表單。

NavigatorMode：設定打開此表單後，要控制其Navigator的進入狀態，此活動為審核的狀態，因此我們將其設定為Normal，代表不能對資料進行更改的動作(不能新增/更改/刪除/查詢資料等等)。

FLNavigatorMode：在此設定為Approve，代表將顯示「審核」與「退回」的按鈕，而不是Summit的「上呈」按鈕。

SendToKind：活動的對象種類，我們設定為 Manager，代表要往下將上呈給目前活動者的直屬主管（由組織設定中，來找到該呈送者的主管）。

Step12＞在此Work Flow Designer中，選擇File/Save Workflow AS 功能，此時請選擇一個目錄，請注意，目錄必須在Infolignt\EEP2010\EEPNetServer\Workflow之下，可以建立一個子目錄來存放，例如我們在此建一個FL目錄來存放此WorkFlow的XOML檔案(XOML為.net3.0新的XML檔案)，檔案命名為 Infolignt\EEP2010\EEPNetServer\Workflow\FL\Customers.Xoml，如圖：

Step13＞流程設定好了之後，我們將利用EEPManager來設定此Xoml流程檔案的權限，進入Security Manager後，在Menu Utility中，新增一個”客戶申請”的項目，如圖：

其中須注意，要將Module Type設定為「Flow」，代表此Module為Workflow的表單，此時在Package右方的小按鈕中選擇Infolight\EEP2010\EEPNetServer\Workflow\FL之下的Customers.Xoml檔案後，Package則為”FL”，Form Name則會呈現”Customers”代表為FL\Customers.Xoml，最後別忘了設定「Access Groups」，設定為”EveryOne”代表所有人都可以使用。


2-4執行流程的結果

接著我們要來執行上一節所設計的流程，並依上一章所設定的角色來模擬流程的進行。

Step1＞在Infolight\EEP2010\EEPNetFLClient之下，我們可以找到一個EEPNetFLClient.exe，就是Workflow中的Client端程式，與之前的EEPNetClient是一樣的，差別是EEPNetFLClient多了Workflow的功能，如圖，我們以”003”的User去Login後，出現畫面如下(較新的版本中將會以多頁籤的方式顯示待辦/經辦/通知/逾時等各事項於不同的頁籤中)：

下方的區域是流程圖的呈現區，上方的三個項目，分別代表此User的個人待辦事項，經辦事項，逾時事項等等。

Step2＞點選「客戶申請」項目，將會打開Customers.Xoml這個流程圖，並在流程圖中點選「客戶申請」這個活動元件，此時將會打開CCustomer這個表單。

Step3＞在「客戶申請」表單中，我們依上圖資料內容輸入一筆簡單的資料，先按下Navigator中的「存檔」，然後按下「上呈」，將會出現以下的上呈確認畫面。

上面有一個重要單據與緊急單據，這是用來區分單據的重要程度與緊急程度，重要程度僅用在區分，但緊急程度則會影響到單據的逾時狀態，因為每個活動是可以根據緊急程度來個別設定不同的處理時限的。中間的意見說明用來讓上呈者輸入訊息所使用，下方的發送者角色，一個企業中，經常會發現一個User會扮演多個角色，因此在上呈時，可以選擇此User所扮演的角色，因為不同的角色其主管可能不同。最後按下「確定」的按鈕後，系統將會以此Xoml作為簽核活動，往下處理下一個活動，系統將呈現出來一個系統訊息，告知你已將此單據送往哪一個角色，並顯示出該角色是由誰扮演等等，因為我們使用了角色R01(業務)上呈，依組織設定其主管為R02(業務經理)。

Step4＞003這個User送出資料後，可以透過「經辦事項」來了解已經送往哪個活動哪一個經辦者等，如圖：

Step5＞接著，我們再打開EEPNetFLClient.exe，並用”005”這個User來Login，依設定，005扮演R02(業務經理)的角色，我們將同樣可以在主畫面中的待辦事項中找到R02業務經理的所有待辦資料，也就是剛剛那筆客戶資料，接著我們可以按下Mouse右鍵，選擇「開啟」打開此待辦單據，如圖：

Step6＞打開「客戶申請」單據後，因為當初的「主管審核」活動的NavigatorMode設定為Normal，因此我們是無法修改資料的，只能針對資料進行「審核」與「退回」，在此我們按下「審核」後，同樣會出現如圖的確認畫面，請同樣加註意見於「意見說明」欄位中，最後按下「確認」，因為本流程在「主管審核」活動後面並沒有其他的活動，因此就會回應一個「本單據以完成流程」的訊息，到此，該流程也已經確定結案。如下圖：

Step7＞最後，如果透過003這個User(角色為R01業務)來查看其「經辦事項」資料時，可以對「經辦事項」Mouse右鍵的「更新」功能來顯示最新資料，此時因為客戶編號=C001這個單據已經結案，所以不會有任何資料顯示在經辦事項上，但如果你想查的是「已結案」的經辦資料時，就可以隊「已結案」勾選起來，如圖即可顯示曾經上呈或簽核過的單據明細，如果資料過多，還可以用左上角的下拉選項來過濾選擇單一的流程名稱。


Workflow基礎設計實作

本章說明內容之大綱摘要：

v 3-1 條件式活動

v 3-2 主管審核活動與通知

v 3-3 取回與退回

v 3-4 會簽活動處理

v 3-5 動態的參考角色


3-1條件式活動

接著我們根據上一章的實例，要來設定一個有條件的流程活動，就是會根據不同的條件來決定不同的流程路線，可讓不同條件有不同的流程活動，我們可以利用上一節中的Customers.Xoml來修改，如下：

Step1＞重新使用Workflow Designer打開 Customers.Xoml這個流程圖，並在流程圖中將「ifElseActivity」拖入到『主管審核』的下方，為了本流程容易讓User閱讀，請將ifElseActivity1的Name改成「信用額度審核」，並在「ifElseBranchActivity1」的條件分支中將Name改成「小於10萬」，再將「ifElseBranchActivity2」的條件分支中將Name改成「大於10萬」，如圖：

Step2＞再將「ifElseBranchActivity2」的Description設定為CreditAmount>=100000，ifElseActivity活動中，我們是將條件判斷式設定在Description這個屬性中，不是設定在Condition，其中CreditAmount 這是一個Customers資料表的欄位，用來當作條件的判斷，此代表如果信用額度超過或等於100000時，就會流向ifElseBranchActivity2這個支流。

Step3＞再從流程活動元件區中拖入一個「FLStand」活動元件到ifElseBranchActivity2的下方，如圖：

現將信用審核的活動元件，屬性設定如下：

(Name)：活動名稱，直接輸入中文 信用審核。

FormName：請選擇一個Windows的表單名稱，同樣選擇CCustomers.CCustomers這個表單，當然，目前是因為申請與審核的表單是同一個，如果信用審核需要不同的表單來呈現，是可以設定不同的表單，但必須另外設計表單。

NavigatorMode：設定打開此表單後，要控制其Navigator的進入的狀態，此活動為審核的狀態，因此我們將其設定為Normal，代表不能對資料進行更改的動作(不能新增/更改/刪除/查詢資料等等)，如果你是希望此角色需要可以更改，則可設定為Modify的模式。

FLNavigatorMode：在此設定為Approve，代表將顯示「審核」與「退回」的按鈕，而不是Summit的「上呈」按鈕。

SendToKind：活動的對象種類，我們設定為Role，代表此活動指定了一個特定的角色來進行審核的動作（由角色的設定來對應所要簽核的Users）。

SendToRole：活動的簽核角色，當本活動設定SendToKind為Role之後，就必須在SendToRole中來定義簽核角色。因為我們是要交給行政經理來負責信用的審核，因此我們設定為R03，可以透過此SendToRole右方的下拉選項來選擇角色代號。

Step4＞最後，我們將此Customers.Xoml存檔。

Step5＞接著同樣用EEPNetFLClient來執行Workflow的測試，同樣使用003 (角色：R01業務)來Login，打開「客戶申請」這個Customers.Xoml後，點選「客戶申請」這個活動來打開CCustomers這個表單，接著我們輸入兩筆客戶資料，如下：

送出的這兩筆資料中，第一筆的信用額度為50000，另一筆為150000，依Customers.Xoml流程將呈送給了R02(業務經理)。

Step6＞以005來Login到EEPNetFLClient中，此時會有「待辦事項」，如圖，可以直接在待辦事項中，以右鍵選擇「Approve」來直接審核，此方式是直接針對待辦事項來審核無須打開單據。

Step7＞當005審核第一張單據時，C002這個客戶的信用額度為50000，因此依Customer.Xoml流程將會自動結案，結束流程，審核第二張單據C003這個客戶的信用額度為150000，送往後端的流程引擎處理後，將會送往R03行政經理(用戶代號為002)來進行信用審核。如下圖：

Step8＞最後，我們再以002這個User來登入到EEPNetFLClient中，同樣在「待辦事項」直接以右鍵選擇「Approve」來直接審核，如圖，審核過之後，同樣會讓此單據結束流程。透過此方式我們可以來了解使用條件活動元件可以來控制流程的邏輯與單據資料的配合。


3-2主管審核活動與通知

前面的客戶審核流程只有一個主管審核，在多數的公司體制中是少見了，因此本節要介紹一個專門用來進行主管審核的活動元件，能根據不同的單據條件進行不同層級的主管審核，另一個就是通知的活動元件，他是用來通知申請者或其他參予的角色者來回報流程進度或狀況的特殊活動。

Step1＞在FLDesigner中將原來Customer.Xoml流程打開，如圖，我們將原來的「主管審核」刪除(點選到該活動，按下Del鍵即可刪除)，改用另一個FLApprove的活動元件，同樣從活動元件區中將FLApprove拖入到原來的位置上：

現將主管審核的活動元件，屬性設定如下：

(Name)：活動名稱，直接輸入原來的主管審核。

FormName：同樣選CCustomers.CCustomers這個表單。

NavigatorMode：此活動為審核的狀態，因此我們將其設定為Normal，代表不能對資料進行更改的動作(不能新增/更改/刪除/查詢資料等等)。

FLNavigatorMode：在此固定為Approve，不能更改設定，代表將顯示「審核」與「退回」的按鈕，而不是Summit的「上呈」按鈕。

SendToKind：活動的對象種類，我們設定為Manager，代表此活動會根據上一個活動者來找到其主管並進行審核。

ApproveRights：主管審核的授權等級設定，在前面的組織中，我們都有設定每個主管的職級，因此，透過這個屬性，就是要來設定什麼樣的條件下，要授權給那一種職級的主管去簽核，由於我們上文中所設定的組織只有兩層，最高為總經理，部門主管為經理的職級，因此我們依照下文來設定兩個職級。設定時，是在ApproveRights的右方按下「…」的按鈕，並進行設定。

設定Expression為True代表沒有條件，所有的申請者，都必須給職級為經理去審核，但如果其主管高過此職級，則可以跳過本職級審核。

在總經理這個職級條件中，我們設定Expression為CreditAmount>=200000，代表除了經理審核外，如果該信用額度超過20萬者，將交由總經理審核。最後，我們重新將Customers.Xoml存檔即可。

Step2＞同樣用EEPNetFLClient來執行測試，同樣使用003 (角色：R01業務)來Login，打開「客戶申請」這個Customers.Xoml後，點選「客戶申請」這個活動來打開CCustomers這個表單，接著我們輸入一筆客戶資料，如下：

請將此筆資料的信用額度輸入為25萬，並按下「上呈」後，依照FLApprove活動，會先呈送給003的主管R02(業務經理)，USER則為005。

Step3＞使用005登入EEPNetFLClient，再從「待辦事項」中找到C004這個申請單，同樣在待辦事項中以右鍵選擇「Approve」來直接審核，如圖，因為005簽核後，FLApprove會根據ApproveRights屬性來找下一個可能要簽核的主管，因為此客戶的信用額度為25萬，超出ApproveRights所定義的20萬必須經過總經理簽核的條件，因此，往下就呈送給R00(總經理)這個角色(使用者代號是001)。

Step4＞使用001總經理登入EEPNetFLClient，同樣從「待辦事項」中找到C004這個申請單並直接右鍵「Approve」審核，因為超過15萬，所以後面還要經過R03行政經理審核，當然，正常的流程應該將總經理的審核放在行政經理審核之後，如過要這樣處理，必須讓FLApprove的ApproveRights不要設定到總經理，先經過單位主管審核(可能有多個)，再到財務部門進行信用審核，最後才讓總經理審核，這樣將較為合理，在此我們只是範例說明工作流程的運作，因此我們不做調整。

Step5＞接著要來說明FLNotify的使用方式，我們在Customers.Xoml的例子當中，當申請者申請的客戶通過審核時，並不會被告知的，只能消極在「經辦事項」中查詢，如果沒有出現在「經辦事項」中就代表已經通過審核了，因此，我們如下圖在流程結束前貼上FLNotify活動，這樣就可以在流程結束前，發出一個通知的待辦給上呈的申請者，此通知活動有個重要的特性與其他的活動不太一樣，就是他只是會發生一個『通知的待辦』，不管該對象是否有處理(審核或過目)，流程引擎都會繼續往下執行，不會理會通知的對象。在這個例子中，流程引擎發生給上呈者通知待辦後，會立即結案該流程。

現將通知的活動元件，屬性設定如下：

(Name)：活動名稱，直接輸入中文通過通知。

FormName：同樣選擇CCustomers.CCustomers這個表單。

NavigatorMode：在此固定為Normal，代表不能對資料進行更改的動作(不能新增/更改/刪除/查詢資料等等)。

FLNavigatorMode：在此固定為Notify，不能更改設定，代表將顯示「通知刪除」與「通知」的按鈕，其中「通知刪除」是代表將此通知的待辦刪除，因為如果不刪除，通知待辦將會越累積越多；另一個「通知」的按鈕是可以將此通知再通知給其他的使用者或角色等等。

SendToKind：活動的對象種類，我們設定為 Applicate，代表此通知活動會根據最原始的申請者來通知其對象，也可以使用AllRoles來通知所有參與本簽核的所有角色。

最後，我們重新將 Customers.Xoml存檔即可。

Step6＞同樣用EEPNetFLClient來執行測試，這次我們改用006 (角色一樣是R01業務)來Login，打開「客戶申請」這個Customers.Xoml後，點選「客戶申請」這個活動來打開CCustomers這個表單，接著我們輸入一筆客戶資料，如下：

輸入的客戶C005中，為了簡化流程，我們將信用額度設為30000。最後按下「上呈」，因為006的主管也是R02(業務經理)，因此同要送到R02的待辦上。

Step7＞使用005登入EEPNetFLClient，再從「待辦事項」中找到C005這個申請單，同樣在待辦事項中以右鍵選擇「Approve」來直接審核，如圖，005簽核後，因為此客戶信用額度只有3萬，因此不必經過總經理與行政經理的審核，將會直接結束流程。

Step8＞流程雖然已經結束，但透過FLNotify活動，在申請人006本身，已經有一個通知的事項在那，我們再用006登入EEPNetFLClient，從「通知事項」中找到C005這個通過通知，如圖，最後將此單據打開，並且使用「刪除」來將此通知事項刪除。

在通過通知事項中，右鍵Open這個申請單。

最後按下「刪除」來刪除通知的待辦。


3-3取回與退回

前面說的流程都是往前前進的流程狀態，但在流程中，難免會有退回的需求，退回在我們的流程引擎中是可以退回到前一活動，也可以退回到前面的任一個活動，但一般都建議用戶退回到前一活動，因為如果退回前面太多個活動時，已經簽核過的對象是無法知悉這個退回動作，將造成被跨越的退回對象產生混淆的現象。另一個動作就是取回，用在當上呈者已經將單據往下呈送後，當後面活動的簽核者尚未簽核之前，可以透過「經辦事項」中，將該單據「取回」，但前提就是該單據尚未被簽核，否則就必須請簽核者幫你取回。

Step1＞以 003這個User來登入EEPNetFLClient中，與之前一樣，打開「客戶申請」這個Customers.Xoml後，點選「客戶申請」這個活動來打開CCustomers這個表單，接著我們輸入一筆客戶資料，如下：

輸入此C006客戶時，為了讓流程單純，我們也將信用額度輸入為50000即可，存檔後請按「上呈」，透過Customers.Xoml流程，同樣會送往R02業務經理的待辦上。

Step2＞使用005登入EEPNetFLClient，再從「待辦事項」中找到C006這個申請單，在待辦事項中以右鍵選擇「Open」來打開該申請單，或可以直接用右鍵的「Return」功能直接退回，如圖，在客戶申請單中以「退回」功能將此客戶退回。

按下「退回」後，將出現此確認表單，可以在此輸入退回原因，並可以選擇退回到那一個活動，在此之前只有一個活動，所以我們選擇「退回到前一個活動」即可，按下『確認』後則系統會告知退回到用戶003的待辦上。

Step3＞在原來003所登入EEPNetFLClient中，可以從「待辦事項」中找到C006這個退回單，在待辦事項中以右鍵選擇「Open」來打開此退回申請單，並重新按下「上呈」，如圖，會再次出現上呈確認的視窗，如圖：

按下『確認』後，再次上呈到R02業務經理的待辦上。

Step4＞接著我們繼續利用這個C006客戶申請單，來示範『取回』的功能，在原來003所登入EEPNetFLClient中，因為該User已經又把C006送到R02業務經理的待辦中，因此必須透過「經辦事項」來取回來，如圖，可以透過「經辦事項」的右鍵「Return」功能來將已經送出去的單據取回，但前提是R02這個主管尚未審核。

按下「Return」取回時，會有一個「取回成功」的訊息，此時該單據將會由「經辦事項」被取回到自己的「待辦事項」中，如果無法立即更新，可以利用右鍵「Refresh」來更新。

Step5＞透過「待辦事項」中的 「Open」重新打開單據，如需更改單據者可以按下「修改」的按鈕，並在FLNavigator中按下「上呈」來重新上呈該單據，如此即可完成「取回」單據的動作。如圖，本例的取回目的就是為了重新更正「意見說明」的內容。


3-4會簽活動處理

在企業的簽核單據中，經常會有多個人一起簽核意見的情況，當然我們也可以一個個依次貼入多個活動元件來讓個別的對象簽核，但這樣會有時效性的問題，就是必須上一個人簽完後才能讓下一個人簽核，因此，在EEP WF的系統中，我們提供了一個 ParallelActivity活動元件來專門處理這種多個對象同時簽核的情況，這種活動會平行觸發多條方向同時簽核，可以提高企業的運作效率。另外，此活動元件中也可以設定多個活動是「AND」或「OR」的關係，一般沒有設定都是代表「AND」，就是所有活動中都必須全部簽核才能到下一個活動(我們稱之會簽功能)，否則會一直等待簽核；「OR」則代表平行的活動中，只要有一人審核了，就自動往下一個活動(我們稱之為平行簽核)，端看你的流程需求而定。

Step1＞在原來的Customers.Xoml當中，經過主管審核後，我們希望這個客戶的申請能指派一個服務窗口給他，因為服務窗口的指派與信用審核不衝突，因此，我們在主管審核後分流同時進行服務窗口與信用審核的指派，並且在信用審核與服務窗口指派都必須被簽核過關後，才會進入「通過通知」的活動中，為此，我們特別在Customers這個資料表中，增加了ServiceRole欄位(nVarchar 20)，代表服務窗口的角色代號(Groups的GroupID)，如下：

Step2＞因為SCustomers.dll這個Server端的模組，之前我們是使用「Select * From Customers」的方式下達SQL語句，因此SCustomers.dll就無須重新編譯，即可取出新的ServiceRole欄位。接著，我們打開CCustomers這個專案，並將之前的CCustomers.cs的表單打開，如下圖，我們用Mouse將idCustomers這個InfoDataSet點兩下，會出現一個「DataSet Column Selector」的視窗，然後，我們可以選擇Customers這個Table的ServiceRole這個新欄位拖入表單當中，如果你Customers中找不到ServiceRole欄位者，可以將idCustomers的「Active」屬性先設為False，在設為True即可，如果還是不行，就須對SCustomers.dll重新編譯。另一個要注意的就是「服務窗口」的資料字典由來，你可以事先在「EEPManager」的「Data Dictionary」中事先定義即可。

Step3＞重新對CCustomers這個專案編譯，即可得到最新的CCustomer表單。

Step4＞以FLDesigner打開Customers.Xoml，首先在「主管審核」與「信用額度審核」間拖入ParallelActivity活動元件，如圖，拖入後，請立即將「信用額度審核」的IfElseActivity活動元件整個拖入右邊的ParallelActivity間(在sequenceActivity2的下方)。注意，ParallelActivity的「Description」是用來設定是否為會簽或平行簽核，設為「AND」代表為會簽，設為「OR」代表為平行簽核，預設為AND。

Step5＞接著，我們再拖入一個FLStand標準活動於ParallelActivity的左方(在sequenceActivity1的下方)，如圖，我們按下文來設定此活動元件。

現將這個FLStand的活動元件，屬性設定如下：

(Name)：活動名稱，直接輸入中文指定服務窗口。

FormName：請選擇一個Windows的表單名稱，同樣選CCustomers .CCustomers 這個表單。

NavigatorMode：設定打開此表單後，要控制其Navigator的進入的狀態，此活動因為要能夠讓其對象可以更改，因此我們設定為Modify，代表可以對資料進行更改的動作 (不能新增/刪除/查詢資料等等)，目前是可以更改所有欄位，如果要控制只能輸入ServiceRole欄位，我們將在進階設計中來說明如何控制。

FLNavigatorMode：在此設定為Approve，代表將顯示「審核」與「退回」的按鈕，而不是Summit的「上呈」按鈕。

SendToKind：活動的對象種類，我們設定為 Role，代表此活動指定了一個特定的角色來指定服務窗口的動作。

SendToRole：活動的簽核角色，當本活動設定SendToKind為Role之後，就必須在SendToRole中來定義簽核角色。因為我們是要交給客服經理來負責服務窗口的指定，因此我們設定為R05，可以透過此SendToRole右方的下拉選項來選擇角色代號。

最後別忘了對此Customers.Xoml進行存檔。

Step6＞同樣以003這個User來登入EEPNetFLClient中，與之前一樣，打開「客戶申請」這個Customers.Xoml後，點選「客戶申請」這個活動來打開CCustomers這個表單，接著我們輸入一筆客戶資料，如下：

其中，信用額度我們輸入11萬，目的是為了不經過總經理審核，但又需經行政經理信用審核，服務處窗口我們暫時不輸入。最後我們按下「上呈」後，會自動送往R02業務經理待辦中。

Step7＞使用005登入EEPNetFLClient，再從「待辦事項」中找到C007這個申請單，在待辦事項中以右鍵選擇「Approve」來直接審核，如圖，當按下「確認」時，系統會告知同時送往 R05客服經理(指定服務窗口)，與R03行政經理(信用審核)等兩個活動，代表此兩個角色會同時收到此單據。

Step8＞我們先使用002登入EEPNetFLClient，再從「待辦事項」中找到C007這個申請單，在待辦事項中以右鍵選擇「Approve」來直接審核，如圖，當按下「確認」時，系統會告知「等待對象」R05(客服經理)，此代表在會簽當中，不管有多少對象，系統會清楚告知還要等待多少對象。

此會簽會有一個現象，就是必須大家協同一致的方向，不能有的是選擇審核，有的選擇退回，這樣系統會提出「你不能退回/前進，因為另一個的狀態為前進/退回」。

Step9＞接著使用007登入EEPNetFLClient，再從「待辦事項」中找到C007這個申請單，在待辦事項中以右鍵選擇「Open」來打開此單據，如圖，可以按下「更改」來更改「服務窗口」的欄位，此時我們設定為R04，代表指定某一個工程師的角色，為了配合下一節的動態角色，我們在此還是輸入角色代號，不然一般情況下，都會以USER代號為主。

更改後按下「存檔」，最後按下「審核」，因為後面只剩下申請者003的通過通知活動而已，因此系統會告知本流程已結案的訊息。


3-5動態的參考角色

前面所使用的活動對象大都是固定的角色或是呈送者的直屬主管，但有些特殊情況下，會用到動態的角色，無法事先知道要送往哪一個對象，我們可以從FLStandard或FLApprove的「SendToKind」屬性中來了解動態的參考角色意義。其中共有RefRole與RefManager兩種參考角色，前者RefRole代表簽核的對象為該單據的某一個指定欄位內容，如上例中的ServiceRole欄位就存放著一個角色的代號，是在簽核過程的「指定服務窗口」時才被決定為R04，如果下一個活動被設定為RefRole者，將會送往該欄位所指定的角色R04的待辦中；後者RefManager則代表會送往該欄位指定角色的直屬主管，如上例中服務窗口為R04，則會送往R04的主管，依組織設定則為R05。

Step1＞沿著Customers.Xoml流程往下做，在FLDesigner打開Customers.Xoml，在「指定服務窗口」下方拖入一個FLStand標準活動，目的用來讓服務窗口確認，因為服務窗口是動態決定的，因此就必須使用到RefRole的型態，如圖。

現將這個FLStand的活動元件，屬性設定如下：

(Name)：活動名稱，直接輸入中文服務窗口確認。

FormName：請選擇一個Windows的表單名稱，同樣選擇CCustomers.CCustomers這個表單。

NavigatorMode：設定打開此表單後，要控制其Navigator的進入的狀態，此活動是不允許更改的，所以我們設定為Normal，代表不可以對資料進行任何的動作 (不能新增/更改/刪除/查詢資料等等)。

FLNavigatorMode：在此設定為Continue，代表只顯示「上呈」的按鈕，而不會顯示「審核」與「退回」的按鈕，目的就是讓此活動可以讓該角色得以確認，按下「上呈」的按鈕後即可讓流程往下持續。

SendToKind：活動的對象種類，我們設定為 RefRole，代表此活動指定了一個動態的參考的角色，必須另外定義SendToField來指定哪一個欄位名稱存有該參考角色的內容。

SendToField：當SendToKind為RefRole或RefManager時，即用此屬性來定義一個欄位名稱，用來存放該活動的對應角色，在此可以下拉選擇欄位名稱，我們選 ServiceRole這個欄位。

最後在FLDesigner中將本Customers.Xoml存檔。

Step2＞同樣以 003這個User來登入EEPNetFLClient中，與之前一樣，打開「客戶申請」這個Customers.Xoml後，點選「客戶申請」這個活動來打開CCustomers這個表單，接著我們輸入一筆客戶資料，如下：

我們將信用額度輸入為5萬，可以免簽總經理與行政經理，以簡化簽核流程。

Step3＞使用005登入EEPNetFLClient，再從「待辦事項」中找到C008這個申請單，在待辦事項中以右鍵選擇「Approve」來直接審核，當按下「確認」時，系統只會告知送往R05客服經理(指定服務窗口)，因為信用額度不超過10萬，所以不會送往R03行政經理(信用審核)的活動中。

Step4＞接著使用007登入EEPNetFLClient，再從「待辦事項」中找到C007這個申請單，在待辦事項中以右鍵選擇「Open」來打開此單據，如圖，可以按下「更改」來更改「服務窗口」的欄位，此時我們設定為R04，代表指定某一個工程師的角色，因為R04(工程師)有兩個USER(分別為004與011)，因此會有兩個工程師收到待辦，如果你希望「服務窗口」必須為一個工程師負責，你就必須將004與011兩個User設定成不同的角色(Groups)，如設定成R04A代表004，R04B代表011就可以做到。

更改後按下「存檔」，最後按下「審核」，因為後面活動是根據ServiceRole來決定的，因此系統會告知已經送往 R04 (工程師)，對象有004與011等。

Step5＞我們使用004登入EEPNetFLClient(使用011登入也可以)，再從「待辦事項」中找到C007這個申請單，在待辦事項中以右鍵選擇「Open」來打開此單據，如圖，因為此FLNavigator為Continue ，所以只能往下呈送，呈送後往下為『通過通知』活動，所以不會停在申請者的待辦上，會自動將流程結案。


Workflow Web設計實作

本章說明內容之大綱摘要：

v 4-1 用Web設計流程

v 4-2 用Web來執行流程

v 4-3 Windows與Web整合

v 4-4 任意通知

v 4-5 Email發送處理

v 4-6 加簽處理


4-1用Web設計流程

前面章節都是使用Windows的表單作為我們開發的介面，本章開始，將要為你使用Web來設計表單，並利用Web的介面，來進行Workflow的簽核，以下就是使用Web來設計一個基本的表單流程所做的說明，請依步驟實作開發：

Step1＞之前在FLDesigner所設計的 Customers.Xoml這個流程是可以持續在Web中來使用，我們只要利用EEP 2010的Web環境來開發一個Web的表單即可，透過EEP Web Form Wizard我們來快速產生一個Web表單，如圖：

在WebSite中，我們選擇EEPWebClient這個目錄，並選擇「Add To Exist Folder」為MyWebs。如果你WebSite內沒有MyWebs這個目錄，則可以用「Add To New Folder」來增加MyWebs這個目錄。按下「Next」來選擇「WSingle1」這個Template，因為這個Template是一個FormView的單檔，輸入「Form Name」為WCustomers這個aspx，「Form Title」請輸入為 客戶申請，再按下「Next」，選擇所有的欄位，最後按下「Done」結束後，將自動出現如圖所顯示的Web表單。

自動產生一個FormView的Web表單。

Step2＞接著，我們將有「OK」「CANCEL」的WebTranslate元件刪除，因為我們將使用一個FLWebNavigator來取代使用者的資料操作，如圖：

改貼了WebNavigator後，接著設定以下屬性：將BindingObject設定連到WebFormView1上，然後設定ShowDataStyle為FormViewStyle，如下圖：

設計好了之後，請將此WCustomers.aspx存檔起來。

Step3＞設計好了前面的Web表單後，接著我們利用FLDesigner來打開之前設計好了Customers.Xoml，並將Web表單定義到這個流程當中，因此我們可以在Web與Windows中，都可以使用相同的一個流程制度，我們將在下節中來說明整合的方式。如圖，將整個流程的所有的Activity活動都設上Web的表單名稱，可以在XOML直接設定「WebFormName」即可。

如上圖將XOML的「WebFormName」屬性設定為 TEST.WCustomers，可以點選該屬性右方的「…」來選擇Web Form，前面是目錄名稱，WCustomers為ASPX的程式名稱。最後別忘了將Customers.Xoml檔案存檔。

Step4＞為了Web的界面中也可以像Windows一樣打開Xoml流程檔案，因此我們可以用EEPManager的「Menu Utility」來將此流程定義上來，如圖，在WROOT的WEB根目錄上新增一個節點。

請輸入「Caption」為客戶申請，「Module Type」為 Flow，並在「Package」中選擇EEPNetServer\Workflow之下的FL\Customers.Xoml檔案，按下「OK」存檔，最後設定「Access Groups」，選擇Everyone並存檔。


4-2用Web來執行流程

接著我們使用Web的介面來執行流程的結果，如下的操作步驟。

Step1＞在Workflow的系統中，我們另外設計了一個Workflow專用的主頁面「WebClientMainFlow.aspx」，我們可以在WebSite中，如目錄為「C:\Program Files\Infolight\EEP2010\EEPWebClient」之下，找到一個「WebClientMainFlow.aspx」，按下右鍵，執行「在瀏覽器中檢視」，即可打開流程的主畫面，如圖：

註：User也可以不用WebClientMainFlow頁面來登入Workflow，而是直接設置Web.Config（登入更加方便），然後通過InfoLogin.aspx頁面來執行Workflow。後續的內容中，我們將直接登入InfoLogin進行操作。如下圖所示：

Step2＞進入workflow的主畫面後，請點選 「客戶申請」，打開此客戶申請的流程，在Web可以打開Xoml檔案是因為當初在FLDesigner.exe中對此Xoml檔案存檔的同時，系統會自動將此Xoml存成相對的JPG檔案，並自動存放在「EEPWebClient\Image」目錄之下□，好讓Web可以打開流程檔案。如圖，我們在「客戶申請」這個Activity活動上，按一下左鍵，即可打開此客戶申請的Web表單。

Step3＞打開客戶申請單後，因為NavigatorMode為「Insert」，所以只能按下「新增」來輸入客戶資料，如圖輸入一個C009的客戶，為了減化流程，我們將「信用額度」輸入為80000元，最後按下「存檔」。

Step4＞這個客戶資料雖已經存到資料表中了，但其FlowFalg的內容為空白，代表尚未經過審核的程序，因此我們必須再按下「上呈」的按鈕，將此客戶以流程來申請。如圖，透過此確認的視窗，來選擇是否為「重要單據」與「緊急單據」(緊急單據的時效與一般的單據不一樣)。接著選擇「發送者角色」，因為此User可能有多個角色，就必須選擇一個角色來呈送，最後按下「確認」後，系統將告知送往哪一個角色哪一個使用者。

Step5＞我們再度以User 005來登入「InfoLogin.aspx」，在主畫面中，可以在「待辦事項」中找到「C009」這個客戶，可以透過下圖中的三個圖示來操作這張申請單，最左邊的圖示代表「打開」，可以打開該單據並進行流程的操作，中間則為「審核」，可以直接審核該單據，最右邊的為「退回」，用來將單據退回，如圖，我們將該單據「審核」。

審核後，將會出現另一個確認事項的視窗，主管輸入意見後，按下「確認」後，系統將會告知送往R05客服經理，使用者為007。

Step6＞以User 007登入「InfoLogin.aspx」，在主畫面中，在「待辦事項」中找到「C009」這個客戶按下「打開」的圖示，此時將出現如下的頁面，按下「修改」的按鈕後，將「服務窗口」設定為R04，按下「存檔」後，同樣將其「審核」往下呈送，如圖：

往下呈送後，將會出現確認事項的視窗，可以輸入審核的意見，系統將告知送往R04工程師，並讓004或011使用者來確認。

Step7＞最後，如以User 004登入，即可得到一筆「C009」客戶申請的待辦事項，並讓其來做確認的動作，當此工程師打開此單據，按下「往下呈送」並確認後，該流程將會自動結束，系統會在此流程結束時，自動將該資料的FlowFlag設定為「Z」，代表該資料已通過審核。


4-3 Windows與Web整合

接下來我們將使用Window Form和Web Form整合進行Work Flow流程的執行。

Step1＞我們以003為User登入到EEPNetFLClient中，進行Windows的流程操作。打開「客戶申請」這個Customers.Xoml後，點選「客戶申請」這個活動來打開CCustomers這個表單，接著我們輸入一筆客戶資料，如下：

將此筆資料存檔並按下「上呈」之後，依Customers.Xoml流程將呈送給了R02 (業務經理)。

Step2＞接著我們來看一下，流程是否會在Web Form中繼續承接下去。我們再次以「InfoLogin.aspx」進來，在登入畫面中，我們以005為User進入。在「待辦事項」中找到剛輸入「C010」這個申請單。

按下該申請單的「打開」圖示，此時將出現如下的頁面，由於此時的Navigator的狀態處於Approve狀態，因此Navigator上的「新增」、「修改」和「刪除」的按鈕都為不可操作的狀態。

Step3＞確認資料無誤的情況下，可直接「審核」往下呈送，如圖。當按下「確認」時，系統會告知同時送往 R05客服經理(指定服務窗口)，代表此該角色會收到此單據。

Step4＞接著使用007登入Windows的EEPNetFLClient.EXE，再從「待辦事項」中找到C010這個申請單。

在待辦事項中以右鍵選擇「Open」來打開此單據，如圖，可以按下「更改」來更改「服務窗口」的欄位，此時我們設定為R04，代表指定某一個工程師的角色，到此，我們就可以理解，在WF中同時可以支援Web的表單與Windows的表單，由Web申請可在Windows審核，相反的，由Windows申請，也可以在Web審核。

Step5＞更改後按下「存檔」，最後按下「審核」，因為後面活動是根據ServiceRole來決定的，因此系統會告知已經送往 R04 (工程師)，對象有004與011等。

Step6＞我們使用004登入EEPNetFLClient或InfoLogin.aspx(使用011登入也可以)，再從「待辦事項」中找到C010這個申請單，在待辦事項中以右鍵選擇「Open」來打開此單據，因為此FLNavigator為Continue ，所以只能往下呈送，呈送後往下為『通過通知』活動，所以不會停在申請者的待辦上，會自動將流程結案。

這裡要說明，並非流程的申請須在Windows開始，同樣我們也可以以003為User在Web申請, 以005為User在Windows上來簽核。Windows和Web在流程的執行過程中可以進行交互的操作。


4-4任意通知

前面我們有舉例說明FLNotify這個Activity的功能是用於流程當中來通知申請者或相關的角色，但其實在流程進行當中，任何一個參與的角色在讀取該單據的同時，都可利用流程Navigator上的一個特殊的『Notify』按鈕來通知其他的角色或使用者，這種我們稱之任意通知的功能。因為通知在流程中的動作並不會影響到流程的時效，就好像我們使用Email的轉寄一樣方便，讓這些流程單據能夠讓更多的使用者或角色共同參予但不進行決策或提供意見，透過通知所收到的流程活動系統會自動列在「通知事項」中。

Step1＞同樣以 003這個User來登入InfoLogin.aspx中，與之前一樣，打開「客戶申請」這個Customers.Xoml後，點選「客戶申請」這個活動來打開表單，接著我們輸入一筆客戶資料，如下：

將此筆資料存檔並按下「上呈」之後，依Customers.Xoml流程將呈送給了R02(業務經理)。

Step2＞以 005這個User來登入InfoLogin.aspx，在「待辦事項」中按下該申請單的「打開」圖示，此時將出現如下的頁面，由於FLWebNavigator處於Approve的狀態下，因此Work Flow操作按鈕只有「審核」、「退回」、「通知」和「查看」4個選項。

Step3＞按下「通知」後，系統自動彈出如下對話框，供User選擇所要通知的對象，此處我們在選擇使用者處選入007(TOBY)，選擇角色處選入R04(工程師)，確認通知對象之後，選擇「確認」按鈕，系統即刻會將通知訊息告知選擇的對象。

這裡要說明，送往User與Role的差異，選擇使用者時將會將通知訊息告知給選擇的User，而使用選擇角色時，系統會將信息傳送給一個角色中對應的多個User (可能為一個或多個User)，如上例，選擇的Role為R04時，系統即會將訊息傳送給004(LILY)和011(SAM)。

Step4＞以 007這個User(按之前的通知的對象為使用者)來登入InfoLogin.aspx，在「通知事項」中找到C011這個單據的通知。

按下該通知事項中以「打開」圖示，此時將出現如下的頁面，由於FLWebNavigator處於Notify的狀態下，因此Work Flow操作按鈕只有「通知」、「刪除」和「查看」3個選項。因此在這個狀態下只可進行Delete此通知，或可以再通知的動作。

Step5＞以 004這個User (按之前的通知對象為角色)來登入InfoLogin.aspx，在「通知事項」中找到C011的通知。按下「打開」之後，為了配合後面的資料安全管制功能，在此我們先暫時不要使用Delete將此通知刪除。

Step6＞由於上面的任意通知功能，是很容易透過這種方式將資料轉寄給更多的使用者或角色，因此為了單據在流程中的資料安全性，我們可以用FLNavigator的兩個屬性來達到資料保密的目的，如下：

FLNotifyOFF (通知開關)：當FLNotifyOFF=true時，FLNavigator或FLWebNavigator上的Notify按鈕將不顯示，這樣就不會有任意通知的功能。

FLNotifySecControl(通知安全控制)：如果為True時，會根據FLNavigator或FLWebNavigator的MenuID來查詢Menu Utility中該表單授權給哪些Users或Groups，此會讓Notify所打開的角色與User選單時，可以根據 GroupMenus與UserMenus去過濾選擇對象來執行Notify。

如下圖，我們將FLNotifyOFF設為False，將FLNotifySecControl 設定為True，代表要過濾通知的使用者或角色，並將MenuID設定為 105，請注意MenuID不一定為105,這選的意義是代表『客戶申請』這個申請流程的MenuID剛好為105，請依照自己的MenuID來設定。

Step7＞接著，我們進入EEPManager.exe的「Security Manager」/「Menu Utility」來對Web中的”客戶申請”進行使用權的設定，如下圖，我們將客戶申請這個Menu設定其「Access Users」為004與010這兩個Users。

Step8＞同樣我們繼續以 004這個User來登入InfoLogin.aspx，在「通知事項」中找到C011的通知(剛剛那筆)。按下「打開」之後，我們再次按下「通知」來通知別的User，此時，會出現如圖的Dialog Box，在User群組中，只會出現004與010這兩個Users。


4-5 Email發送處理

上面章節中所介紹的Work Flow流程中，不管是Web或Windows每個用戶必須透過登入系統之後才能夠了解到有哪些待辦事項是正在等待該User的處理，這一節我們將為大家介紹Email發送處理的功能，此功能能夠大幅度的提高工作的時效性，可以自己設定哪些作業活動(Activity)須以即時Email發送的方式來告知該活動的User所要處理的待辦事項。下面我們一起來看一下Email發送處理的設

計方法。

Step1＞在FLDesigner.EXE的Workflow Designer中打開 Customers.Xoml這個流程圖，如下：

接著，分別找到主管審核與指定服務窗口兩個Activity，並將這兩個Activity的SendEmail設定為True，代表在此活動送出的同時，將發送Email給本個活動的對象(找到角色再找到該User)。其中，發送的目的Email為EEPManager中每個User設置的電子郵件地址。

Step2＞打開EEPManager，進入Security後在USERS中分別設定005 (ACER)與007 (TOBY)的電子郵件的值。

Step3＞在開始操作之前，必須先對NetServer上的Work Flow Config進行設定，具體指派發送告知Mail的STMP伺服器，以及Mail的Title、Body。打開EEPNetServer.exe，找到「Work Flow Config」。

在「Work Flow Config」中需要設定「Email」、 「Password」、 「SMTP Server」、「Mail Subject」以及「Email Body」。「Email」和「Password」表示發送mail時所使用的發送者以及該mail用戶的密碼；「SMTP Server」為發送mail的伺服器； 「Mail Subject」用於設定Mail的主題顯示內容，共有四個選項Sender(發送者)、FlowName(流程名稱)、ActivityName(流程活動名稱)以及Description(意見說明)；「Email Body」表示發送的mail的正文內容，其中包括Sender(發送者)、FlowName(流程名稱)、ActivityName(流程活動名稱)、Content(單據主要內容)、Description(意見說明)、Date Time(流程申請日期)以及HyperLink(該申請單超鏈接)，如下圖，請依照你的Email與SMTP Server的資訊來設定此資訊。

Step4＞接著，我們先以Web為入口， 使用003為User Login，打開「客戶申請」這個Customers.Xoml後，點選「客戶申請」這個活動來打開表單，接著我們輸入一筆客戶資料將其「存檔」後「上呈」本筆資料。輸入資料內容如下：

接著我們按下「確認」的按鈕後，如果可以成功送往下一個Activity活動者，則系統將會自動發出該筆提交的訊息以Email的方式Email給acer@infolight.com.tw，完成了Mail通知。

Step5＞接著我們可以透過Email的System中，以 Acer@infolight.com接收到Email，並可以找到系統發送的一個mail，在mail的正文內容中可以看到該單據的超鏈接，按下HyperLink，eMail中的項目名稱可以透過Sysmsg.xml語言檔案來定義多語的項目名稱。

按下Hyperlink時，如果系統尚未Login會自動出現Login，已Login則會自動打開該待辦的單據在頁面上，如下圖為未Login的頁面。

images拷貝 注意：如果尚未Login的User，須先透過Login的頁面來輸入UserID與密碼，所以Login之後須再一次按下Email中的HyperLink才會自動打開此單據，自動HyperLink後，可直接打開如下圖的單據。

Step6＞確認該單據可通過後，按下「Approve」，並在下面的頁面中按下「確定」，同樣的系統在提交成功後發出下一步流程的對象Email通知。這裡由於之前在「指定服務窗口」的Activity中，我們已經將SendToMail設定為True，所以系統會自動向007 (toby@infolight.com.tw) 這個User發送告知Mail。

Step7＞透過另一個User的Email System，接收Toby@infolight.com.tw郵件時，同樣即可取得一下待辦的資料：

Step8＞按下HyperLink後，可顯示單據詳細資料，並往下按下「Approve」進行流程的上呈動作，繼而使流程往下進行。

透過Activity的SendMail屬性，即可自由設定哪些Activity活動需要另外以Email的方式來通知企業內的User與角色。


4-6加簽處理

在流程進行當中，有些是可以用制度事先規劃好的，如甚麼條件下應該給誰簽核，但是有些單據或簽核是無法事先規劃好制度或遇及特殊情況必須特殊處理等，因此加簽就是要來面臨此情況下來提供流程的彈性，此可以讓簽核者自由決定要讓哪一個角色進行加簽的動作，最後還會回到簽核者身上，來決定是否往下進行。加簽與任意通知很類似，但加簽是一定會回來加簽者的待辦，會等待被加簽者的簽核，但通知則不會回來，也不會讓流程等待通知者。

Step1＞使用FLDesigner.EXE的Workflow Designer打開 Customers.Xoml這個流程圖。

Step2＞找到主管審核，將該Activity的PlusApprove設為True，代表在此流程活動中允許進行加簽。

Step3＞同樣以 003為User Login 到 WebClientMain上，打開「客戶申請」流程，並輸入一筆 C013的客戶，內容如下：

Step4＞資料輸入完成之後，進行存檔並「上呈」到下一步流程，在確認的頁面

中按下「確認」，系統將送往下一活動對象005(ACER)的待辦中。

Step5＞接著，以005 作為Login的User登入後，在「待辦事項」中找到C013這筆申請單，點開「打開」圖標進入資料明細查看，此時可以發現在FLNavigator上多了一個『加簽』的按鈕。

Step6＞按下加簽，系統將會出現加簽選擇提示框，在選擇角色裡我們選擇R07專案經理，代表會將該單據發送給R07所對應的User進行加簽，並等待這個角色的處理。

images拷貝 注意：加簽對象是可以多個角色，可以同時送出，但在多角色的加簽的情況下必須同時等待多人簽核回來，才能往下流程簽核。

Step7＞接著，以010為User Login進入(此為專案經理)，此時該用戶的待辦事項中便會出現C013這筆客戶申請單。可以發現，加簽對象只可進行審核，沒有退回功能，此處我們直接審核。

User 010審核完成後，如下圖，可以看到，流程會回到005(即加簽送出者)，等待005審核後往下繼續流程。

Step8＞最後，我們以005重新Login後，可以看見C013這筆資料回到005的待辦事項中。

在很多企業的流程當中，都會遇到這種需要制度也需要彈性的現象，因此EEP WF的系統必須兼具為制度把關，又必須擁有國人習慣的彈性作為，否則很難滿足日益複雜與急速變化的企業環境，加簽的功


Workflow 進階設計

本章說明內容之大綱摘要：

v 5-1 連結與導覽

v 5-2 檢核活動

v 5-3 作廢活動

v 5-4 活動參數設定

v 5-5 後端處理程序

v 5-6 子流程處理

v 5-7 動態流程處理


5-1連結與導覽

在EEP的WF系統中，XOML除了用來設定作業流程外，也可以用來設計簡單的導覽圖，就是可以用於流程的UI中讓USER來操作這種HyperLink的動作，並透過本活動元件串接其他網頁表單或其他流程，此連結在流程引擎中是沒有任何作用的，只能拿來作為連結流程或頁面來使用。

在開始下面設計之前我們需做好如下準備工作：

1. 透過EEP Wizard的【Server Package Wizard】，來產生一個Server端的Package，我們將其命名為 SOrders，此Package為Orders-Order Details多檔結構。產生完成後，在EEPNetServer的【Package Manager】中，將SOrders.dll註冊到Solution1這個方案當中。

2. 透過EEP Wizard的【Web Form Wizard】，產生一個Web Client表單Package，選擇WebSite為安裝目錄\EEPWebClient，Folder為TEST(若此Folder不存在，請選擇Add to New Folder)，FormName也是WOrder1，Provider選擇剛剛SOrders.dll的Orders這個Table， EEP Web Template Forms選擇WMasterDetail1，MasterFields則選擇所有欄位，最後產生一個WOrder1.aspx的WebForm Page。

3. 將WOrder1.aspx中的WebNavigator1刪除，由於此Form將會被使用在Work flow中，因此需使用到FLWebNavigator。我們從ToolBox中拖拉出FLWebNavigator1，將其BindingObject設為wfvMaster，ShowDataStyle設為FormView。

完成以上工作後，我們展開下面的實例操作了。

Step1＞透過FLDesigner.exe按下File/New之後將會自動產生一個空的流程，並將其命名為ORDERLINK. XOML。流程新建完成後，從【流程活動元件區】中拖入兩個FLHyperLink (鏈接)活動元件。

Step2＞接著，我們將第一個FLHyperLink的Name設定為客戶申請，LinkFlow設定為前例中使用的CUSTOMERS. Xoml，表示在此流程節點將開啟CUSTOMERS.xoml的流程。

Step3＞接著，我們將第二個FLHyperLink的Name設定為訂單管理，在WebFormName選擇出之前已產生的WOrder1.aspx，表示在此流程節點將開啟一個Web Page。

images拷貝 注意：FLHyperLink做為一個鏈接活動元件，可以流程(xoml)，WebForm(aspx)和WinForm(dll) 3種形式來打開鏈接。

Step4＞完成設定後，我們必須執行一個重要步驟，SaveActivityLocation。SaveActivityLocation功能：因為系統只會自動計算並記住第一個Activity的座標外，第二個Activity以後的座標是無法計算的，必須讓開發者事先以此SaveActivityLocation功能來記錄Mouse感應區的座標與範圍。

images拷貝 注意：SaveActivityLocation執行時，最好在該Activity的中心點處按下右鍵，可以讓RunTime的User的Mouse感應區得以更加準確。

Step5＞流程設定好了之後，我們將利用EEPManager來設定此Xoml流程檔案的權限，進入Security Manager後，在Menu Utility中，新增一個”訂單處理流程”的項目，將其設定在Web的ROOT下，如圖：

最後設定「Access Groups」，設定為”EveryOne”代表所有人都可以使用。

Step6＞我們以「InfoLogin.aspx」進來，在登入畫面中，我們以003為User進入。在「訂單處理流程」中找到「客戶申請」雙按。此時畫面將轉入到CUSTOMERS.xoml的流程圖中，如下圖：

當我們完成了「客戶申請」的流程後，雙按「訂單管理」，此時將會進入WOrder1.aspx中。

透過上面例子我們可發現，我們可以讓USER來操作這種HyperLink的動作，進行快速串接其他網頁表單或其他流程，使流程操作更加順暢。


5-2檢核活動

流程當中有時需要有一些動態的檢核功能，當然這些也可以寫在表單存檔的過程中來檢驗會比較有一些整體感，但是，如果有些條件須在流程中來定義的，或是流程中為了管理目的需在流程中加入檢核點等等，就會用到FLValidate來達到檢核或稽核的目的。也就是說FLValidate可以設定一個稽核條件，條件通過則往下流動，不通過則自動退回，用來強迫檢查單據的資料是否滿足流程的規定。

Step1＞透過FLDesigner.exe打開Customers.XOML，我們在此流程中新增一個FLValidate，將其Name設定為檢驗窗口，Expression設定為ServiceRole != ""，Expression處用於輸入條件判斷式，具體格式規則請參考《附錄E-Expression格式說明》。

Step2＞我們以「Infolight.aspx」進來，在登入畫面中，我們以003為User進入。在「客戶申請」中輸入 C014 信息如下圖，輸入完成後將其上呈於005，再以005為User登入簽核後，將此單據發送給007。

Step3＞接著，以007為User登入，在「待辦事項」中找到「C014」這個客戶，透過最左邊的「打開」圖示，打開該單據並進行流程的操作。

當007忘了設定服務窗口，直接審核時，系統將發出驗證失敗的訊息。

Step4＞點選Colse後，回到輸入畫面，我們將”服務窗口”設定為”R04”後，重新審核後，此時提供提示驗證成功的訊息，並且流程流向下一步。


5-3作廢活動

FLReject是Workflow設計中用來終止流程的活動，就是讓此流程終止進行簽核，與人為的作廢是一樣的意思，FLReject在終止流程時會很像FLNotify通知活動類似，發出對應的角色告知終止此流程。

Step1＞進入原先的CUSTOMER.xoml，將前面的FLValidate刪除，貼入IfElseActivity 並在ifElseBranchActivity2中貼入FLReject。

Step2＞接著，我們找到IfElseActivity後，將其Name設定為是否作廢。往下我們就要對IfElseActivity的兩個分支進行設定，將ifElseBranchActivity1的Name設定為有服務窗口，下圖為ifElseBranchActivity2設定值：

Name表示此活動的名稱，Description設定過濾欄位條件。

Step3＞接著，設定FLReject屬性，將這個Activity的Send To Kind設定為Applicate，代表此活動的對象為最原始的申請者，在WebFormName找到前幾章中創建的WCustomers.aspx，Name設定為客戶作廢。當流程執行到這個活動元件時，表示這個流程會自動終止。

Step4＞我們以「Infolight.aspx」進來，在登入畫面中，我們以003為User進入。在「客戶申請」中輸入 C015 訊息如下圖，同前文的步驟執行流程。

Step5＞當送至 007後，以007為User登入「待辦事項」，在沒有設定服務窗口情況下，按下「審核」按鈕，此時將會出現”本單據已被取消”的提示。

Step6＞最後，再以003為User登入，在「通知事項」中，我們發現多了一個客戶作廢的通知。

images拷貝 注意：作廢活動會讓流程表單內的FlowFlag欄位自動設為”X”，並不會將資料刪除，好讓系統可以應用在別的用途。如果要刪除原本資料，須使用 Navigator的刪除功能，而不是此處的作廢功能。


5-4活動參數設定

在EEP WF系統中，各個Activity活動可以使用不同的表單來進行流程的簽核，就因為此，所以讓各個作業能有自己獨特的彈性與特殊的使用者畫面，但大多數的表單畫面都是很接近的，只有小小的差異就要設計成不同的表單與頁面，確實很浪費時間，因此，我們也可以透過在Activity活動中的Parameters參數來傳入同一個表單或頁面中，這樣就可以共用一個頁面，只須在這個頁面中以傳入的Parameters來做特別的控制。

Step1＞在 Customers.XOML中，將”指定客戶窗口”活動的Parameters設為 P1=SERVICE，P1代表參數名稱，SERVICE代表參數內容，可以自由設定，此參數可以在透過Web的連結頁面傳入網頁的Request的參數中，通過Requst.QueryString[“參數名稱”]取得。

Step2＞在WCustomers.aspx這個表單中，在FLWebNavigator1中增加這個Command事件，來控制哪些欄位不能輸入(只有服務窗口欄位可以輸入)。

protected void FLWebNavigator1_Command(object sender, CommandEventArgs e)

{

if (e.CommandName == "cmdUpdate" && this.Request.QueryString["P1"]=="SERVICE")

{

// 設定哪些欄位要設為ReadOnly

List<string> Textboxlist = new List<string>(new string[] { "CustomerIDTextBoxE", "CompanyNameTextBoxE", "ContactNameTextBoxE", "ContactTitleTextBoxE", "AddressTextBoxE", "CityTextBoxE", "RegionTextBoxE", "PostalCodeTextBoxE", "CountryTextBoxE", "PhoneTextBoxE", "FaxTextBoxE", "OrderedAmountTextBoxE", "flowflagTextBoxE", "CreditAmountTextBoxE","LastOrderedDateDateTimePickerE" });

string js=""; // 將各個設為ReadOnly的欄位累加到此java Script中

foreach (string s in Textboxlist)

{

js = js + "document.getElementById('WebFormView1_" + s + "').readOnly = true;";

}

// 預先註冊一段JavaScript，並在網頁返回時執行

this.Page.ClientScript.RegisterStartupScript(this.GetType(), "updateScript", js , true);

}

}

images拷貝 注意：List<string> Textboxlist中保存的都是WebFormView在EditTemplate下每個欄位對應的元件名稱。

Step3＞以「Infolight.aspx」進來，在登入畫面中，我們以003為User進入。新增一筆C016客戶資料如下圖，新增完畢後，將資料呈上後送給005，005簽核後流程流至指定客服窗口將此資料送給007。

Step4＞以007為User登入，在「待辦事項」中找到C016的客戶資料，點擊「修改」按鈕對資料進行修改時，可以發現此時只能更改「服務窗口」，其餘欄位都無法更改。

從上面的實例中可以發現，通過傳遞參數的方法就可以在某個流程環節進行操作功能的控制，使之成為一個較具有彈性的操作流程。


5-5後端處理程序

在流程的流動當中，除了單據會轉移到不同的角色上之外，可能有一些後端的商業邏輯處理須跟著配合，但因為無法保證流程一定會結案，所以多數的商業邏輯處理會放在結案前的一個活動來處理，以確定此單據是被確認的，但也有一些例外，是在流程的進行當中，就需處理一些商業邏輯，但後者一定需注意到該單據可能會被退回去而重覆執行，或者因為被作廢而不一致。而FLProcudure活動是專門用來設計Workflow後端處理程序或商業邏輯程序等的活動元件，可以隨著Workflow引擎執行到此活動時被觸發執行。

準備工作：

開始下面實例之前確認是否在Customers中存在LastOrderedDate欄位，若不存在請予執行如下SQL語句：Alter table Customers Add LastOrderedDate DateTime null

Step1＞在SCustomers中，增加一個WriteCloseDate的Server Method：

首先，對 ServiceManager的ServiceCollection 進行設定，新增一個ServerMethod就必須在ServiceManager中新增一個Service來告知系統。

點開ServiceCollection右側按鈕，在Service Collection Editor中，新增一個Service，將ServiceName與DelegateName都設為WriteCloseDate。

Step2＞在Component.cs中，增加下列程式：

public object WriteCloseDate(object[] objParam)

{

object[] ret = new object[] { 0, 0 };

DataRow dr = (DataRow)objParam[0]; // 取得流程資料表的資料內容

string Today= System.DateTime.Today.ToShortDateString(); //取得今天日期

string CustomerId = dr["CustomerId"].ToString(); // 取得目前客戶編號

IDbConnection conn = this.AllocateConnection("ERPS"); // 取得資料連線

if (conn.State == ConnectionState.Closed) conn.Open();

try

{

IDbTransaction trans = conn.BeginTransaction(); // 起始交易

string sql = "Update
Customers Set LastOrderedDate='" + Today + "'
Where CustomerID='" + CustomerId + "'";

this.ExecuteCommand(sql, conn, trans); // 送出SQL語句

trans.Commit(); // 確認交易

}

finally

{

this.ReleaseConnection("ERPS", conn) ; // 保證釋回資料連線

}

return ret; // 傳回值: 無

}

images拷貝 注意：在完成上面的設定後，必須將已修改的Server端程式重新建置(build)，使NetServer取得最新Server的dll。

Step3＞回到FLDesigner.exe，在CUSTOMERS.XOML中，貼入FLProcedure活動元件，將元件Name設為「結案處理」。此元件用於完成調用ServerMethod的動作。

接著，我們要設定ModuleName與MethodName，在ModuleName選擇SCustomers，表示CallMethod在那個Server程式中；MethodName設定為WriteCloseDate，表示流程當進入此處時，將執行SCustomers中的WriteCloseDate方法。

Step4＞在「Infolight.aspx」中我們以003為User 登入，輸入如下 C017資料，輸入完畢後將資料上呈至005，005登入簽核後，送至007(指定客服窗口)，007確認服務窗口為R04後上呈資料，此時系統將此筆資料送給004，004上呈資料後流程進入結案處理，此時系統會根據Server Method中的方法，將LastOrderedDate寫入當前日期。

Step5＞我們可以透過VS所提供的Server Explorer來查看C017資料的LastOrderedDate內容，如下：

Step6＞接著，我們試著從Server Method中來了解User對流程是進行往下的前進動作，還是往前退回動作，因此，我們特別將指定服務窗口下面的IfElseActivity活動刪除，並將FLProcedure活動拖拉到指定服務窗口與服務窗口確認中間，如圖：

為了能讓「服務窗口確認」可以退回，因此我們將「服務窗口確認」的FLNavigatorMode由Continue改為Approve。

Step7＞我們將上例中Component.cs中的Server Method更改如下：

try

{

IDbTransaction trans = conn.BeginTransaction();

int FlowDirection = (int)objParam[1]; // 在流程中有傳遞第二個參數代表方向

string sql="";

if (FlowDirection ==1) // 1代表往下，2 代表退回

{

sql = "Update Customers Set
LastOrderedDate='" + Today + "'
Where CustomerID='" + CustomerId + "'";

}

else

{

// 退回時清空

sql = "Update Customers Set LastOrderedDate=null Where CustomerID='" + CustomerId + "'";

}

this.ExecuteCommand(sql, conn, trans);

trans.Commit();

}

Step8＞以003為User 登入「Infolight.aspx」，輸入如下 C018資料，輸入完畢後將資料上呈至005，005登入簽核後，送至007(指定客服窗口)，007確認服務窗口為R04後上呈資料，此時系統將此筆資料送給004。

Step9＞此時，透過Server Explorer來查看C018的LastOrderedDate為今天的日期。

Step10＞如果讓004登入，並使用「退回」功能將C018退回給007後，此時，透過Server Explorer來查看C018的LastOrderedDate為NULL。


5-6子流程處理

在EEP WF中有一個專門用來整合另一個子流程的活動元件，就是FLSubFlow元件，它可以整合另一個子流程到本流程來，除了可以縮小流程的篇幅外，另一個目的就是可以讓子流程也可以自行獨立運作，不必依賴主流程來運作。

Step1＞透過FLDesigner.exe新建一個CUSTCREDIT.XOML。在此流程中，新增三個FLStand，分別將它們的名稱改換為「信用申請」、「信用初審」和「信用審核」，如下圖：

在「信用申請」中，我們將起FLNavigatorMode設為Submit，表示FLNavigator的功能上呈現的狀態為上呈；NavigatorMode為Insert，表示作為Navigator功能時，顯示新增狀態；SendToKind設置為Applicate，表示使用最原始的申請者的上呈對象。在WebFormName選擇TEST.WCustomers，在下面的兩個「信用初審」以及「信用審核」將還是使用WCustomers這個Web表單。

images拷貝 注意：在「信用初審」以及「信用審核」中，我們將起FLNavigatorMode設為Approve，表示FLNavigator的功能上呈現的狀態為審核；NavigatorMode為Normal，表示此頁面中的Navigator是無法執行新增/更改/刪除的功能的；在SendToKind設置為Role，表示根據SendToRole中選定的角色對象進行上呈。信用初審使用R09財務會計來審核，信用審核則使用R03行政經理來審核。

Step2＞在EEPManager中，新增一個信用審核流程，將前面製作完成的CUSTCREDIT.xoml文件新增到Package中，這個流程是可以直接輸入申請單據。

Step3＞以003為User 登入「Infolight.aspx」，打開「信用審核」後，點選「信用申請」，如下圖顯示，透過此流程同樣可以獨立申請客戶並對客戶進行信用審核。

Step4＞接著，在FLDesigner.exe中打開 CUSTOMERS.XOML，如下圖，由於在上面介紹的CUSTCREDIT.XOML中已經產生一個信用審核功能的流程，爲了能夠簡化本例的流程，我們將整個ParallelActivity刪除，取而代之的是一個FLSubFlow活動元件。我們透過FLSubFlow活動元件來訪問CUSTCREDIT.XOML的流程，因而得以簡化流程。

Step5＞我們將FLSubFlow活動元件貼於「主管審核」之後，將其Name改為「信用審核流程」，並設定XomlName為CUSTCREDIT.XOML這個流程檔案，表明此子流程的xoml文件。同時，設定IncludeFirstActivity為False代表不包含對方流程的第一個Activity(就是信用申請那個Activity)，否則執行到此子流程時，將會多出這個活動元件而造成困擾。

images拷貝 注意：子流程內的Activity名稱請避免與父流程內的Activity名稱重複，否則在申請單據時會發生錯誤）。

Step6＞以003為User 登入「Infolight.aspx」打開「客戶申請」，輸入如下 C019資料，輸入完畢後將資料上呈至005。

以005為User登入，在「待辦事項」中找到C019，將其簽核後，此時流程則會送往子流程的第二個活動元件—信用初審，並呈送給009。

接著，以009為User登入，在「待辦事項」中找到C019，簽完資料將往下送給了行政經理002，Activity則停在「信用審核」(子流程的第三個活動)，最後再以002登入，簽核後該流程會自動回到父流程中來，因為父流程往下為「通過通知」的活動，所以此單據便會往下結案。


5-7動態流程處理

在一般情況下，作業流程都是事先規劃好並被XOML事先定義好了，但有些流程是無法事先定義好的，必須由呈送者來指定呈送流程，因此如果要滿足動態決定的流程，就須透過FLDetails來動態設定流程的步驟與其呈送對象。下文中，我們將此客戶申請流程改用動態的決定方式，交給申請者自行決定流程，如下的設計步驟：

Step1＞先準備好一個CustomerFLDetails這個Table，結構如下：

其中Primary Key主鍵欄位設定為 CustomerID; SeqID。

SQL語法如下：

create table CustomerFLDetails

(

CustomerID nchar(5) not null,

SeqID nvarchar(2) not null,

RoleID nvarchar(10) null,

Parallel char(1) not null,

constraint PK_CustomerFLDetails PRIMARY KEY(CustomerID,SeqID)

)

Table創建完成以後，在EEPManager.exe/DataDictionary中新增CustomerFLDetails這個table，並對其做如下設定：

FieldName | Caption | Control Type
CustomerID | 客戶編號 |
SeqID | 次序 |
RoleID | 對象角色 | RefValBox
Parallel | 會簽處理 |

Step2＞接著使用Server Wizard產生一個名為SCustomers2的Package，其中選擇Customers為主檔，CustomerFLDetails為明細檔，Customers.CustomerID與CustomerFLDetails.CustomerID作為Relation。

Build完成SCustomers2.DLL後，在EEPNetServer中將此DLL註冊到PackageManager中。

Step3＞使用Web Form Wizard產生一個WMasterDetail1為Template的Web Form，我們將其命名為WCustomers2，產生時，Details選次序、對象角色和會簽處理三個欄位即可，次序則為動態產生活動的順序，對象角色使用RefValBox用選的(在D.D.中定義)，會簽處理如果為’Y’代表該活動與上一個活動為平行會簽。產生完成後，同樣將Navigator更換為FLNavigator，別忘了設定Navigator的BindingObject設為wfvMaster，ShowDataStyle設為FormView。

Step4＞進入 FLDesigner.exe，打開 CUSTOMERS.XOML，將原來的「信用審核流程」(FLSubFlow)刪除，改用FLDetails，並將其命名為「客戶資料簽核」。

接著，我們進行屬性設定，定義如下圖，這裡要說明如下的屬性：

DetailsTableName：FLDetails活動元件參照Table名稱；

RelationKeys：主檔Table與FLDetails活動元件參照Table名稱關聯欄位；

ParallelField：會簽參照欄位，當此欄位的值為”Y”，代表該活動與上一個活動為平行會簽；

SendToField：簽核指定角色欄位。

為了配合這個流程的設定，請將Customers.xoml中的其他活動的WebFormName都改成WCustomers2這個Web表單。

Step5＞以003為User 登入「Infolight.aspx」打開「客戶申請」即CUSTOMERS.XOML，開啟WCustomers2.aspx，輸入如下 C020資料，在Detail中輸入三個角色，前兩個客服經理與專案經理為會簽，往下則還有行政經理簽核等。輸入完畢後將資料上呈至005。

003送出後，同樣會呈送給005業務經理，當005業務經理審核後，則透過FLDetails首先會送出給007客服經理及010的專案經理，等這兩位一起會簽完畢後，會繼續給002行政經理來簽核，最後等002簽核完畢才會送出通過通知，並結束該流程。


EF WorkFlow的處理

本章說明內容之大綱摘要：

v 6-1 設計表單

v 6-2 設計工作流程

v 6-3 簡易的流程呈送

v 6-4 參數傳遞與控制


6-1設計表單

Step1> 首先，用Wizard產生一個【SCustomers】的WCF服務端程式。也就是所說的基於EF技術的Server程式。選擇VS的Tools中的EEP Wizard，在彈出窗口中選擇WCF Server Wizard，點擊Next

Step2> 設定需要產生的Server的程式名稱，這裡將其設定為SCustomers

Step3> 此時，系統產生一個SCustomers工程，同時，呼叫VS自帶的Entity Data Model Wizard，通過這個Wizard我們來產生連接資料庫的Entity。如下開始窗口中我們選擇Generate from database然後點擊Next

Step4> 我們將Save entity connectin setting in App.config as前面的勾去掉。然後點選Next按鈕。

註：如果之前沒有可以連接成功的連接字符串，則需要點擊“New Connection”先建立資料庫鏈接，然後再點擊Next Button。

Step1> 在接下來的畫面中，我們需要點開Tables的箭頭，然後勾選到Customers，最後點選Finish。

Step2> 到這裡Entity已經完全產生了，現在我們需要將這些entity與我們的server端連接起來，所以我們點Add按鈕，將Customers。

Step3> 完成後，點擊Done,這樣Wizard將自動產生Server工程。

產生完之後掛到EEPNetServer的WCF的PackageManager上面，最後按下【Reload】按鈕。另外，在設計Silverlight的WebForm之前別忘記使用VS的Tools中的UpdateReference功能，用來更新EFClientTools和SLTools.Service下面的EFServerReference，並重新Build一下EFClientTools和SLTools.Service。

下麵我們就來用EEP2010的Wizard來設計一個Silverlight的WebForm：

Step1> 首先，選擇【Silverlight Client Wizard】，按下Next按鈕。

Step2> 選擇SLClient下面的MyWebs，若沒有的話，就選擇【Add To New Folder】新建一個，按下Next按鈕。

Step3> 本節我們做個單檔的Customer表單，因此選擇SLSingle即可，按下Next按鈕。

Step4> 選擇第一節中設計好的服務端的SCustomers的DLL，按下Next按鈕。

Step5> 在這裡選擇View的欄位，全選即可，按下Next按鈕。

Step6> 同樣，這邊也全選，按下Next按鈕，將會自動產生Silverlight的WebForm。

最後將sLNavigator1的FLActive屬性設為True。SDSMaster的AlwaysClose屬性設為True

設計完表單之後先不要掛到EEPManager上。待下一節，我們設計完WorkFlow的工作流程之後，掛上WorkFlow的流程我們再來流覽bCustomers表單。


6-2設計工作流程

本節，我們來設計一個工作流程，打開FLDesigner，請跟著以下步驟來做：

Step1＞新建一個流程，在Description中輸入【客戶申請】。TableName選【Customers】，Keys選【CustomerID】，WebFormName選我們上一節設計好的bCustomers.xaml。

Step2＞從【流程活動元件區】中拖入一個FLStand(標準流程)活動元件，如下圖：拖入FLStand活動時，需在Start與End間的區域上放開Mouse左鍵即可。如下圖，定義流程活動：

(Name)：活動名稱，為了讓User可以貼切瞭解，我們直接輸入中文客戶申請。

NavigatorMode：設定打開此表單後，要控制其Navigator的進入的狀態，因為流程表單被打開後，就無法像之前的表單打開一樣，可以讓User任意新增/更改/刪除/查詢資料等等，在流程中動作表單，必須控制Navigator只能操作某些動作，不是任意可以讓User操作，在此設定為Insert，代表只能讓User可以新增資料，無法操作其他功能。

FLNavigatorMode：此與NavigatorMode很類似，但此用來控制流程按鈕的狀態，因為表單我們改貼了FLNavigator後，多了幾個流程按鈕，因此透過此流程活動的屬性，來控制此FLNavigator哪些流程按鈕可以執行，哪些則要隱藏等等。在此設定為Submit，代表只能讓User可以操作上呈與暫停的操作，(暫停是指呈送者先暫時存在自己的待辦事項中)。

SendToKind：用來設定此活動的對象種類，對象種類有Role/RefRole/Manager/Applicate等等，Role代表對象為一個角色，RefRole代表為參考角色，就是根據某個欄位內容做為動態的角色，Manager則代表對象為上呈者的主管(根據組織的設定)，Applicate則代表最原始的申請者等等。在此因為是流程的第一個活動，所以應該被設定為Applicate。

Step3＞從【流程活動元件區】中拖入一個FLApprove的活動元件，如下圖，定義流程活動：

(Name)：活動名稱，直接輸入原來的主管審核。

NavigatorMode：此活動為審核的狀態，因此我們將其設定為Normal，代表

不能對資料進行更改的動作(不能新增/更改/刪除/查詢資料等等)。

FLNavigatorMode：在此固定為Approve，不能更改設定，代表將顯示「審

核」與「退回」的按鈕，而不是Summit的「上呈」按鈕。

SendToKind：活動的對象種類，我們設定為Manager，代表此活動會根據上

一個活動者來找到其主管並進行審核。

ApproveRights：主管審核的授權等級設定，在前面的組織中，我們都有設定

每個主管的職級，因此，透過這個屬性，就是要來設定什麼樣的條件下，要

授權給那一種職級的主管去簽核，由於我們上文中所設定的組織只有兩層，

最高為總經理，部門主管為經理的職級，因此我們依照下文來設定兩個職級。

設定時，是在ApproveRights的右方按下「…」的按鈕，並進行設定。

Step4＞從【流程活動元件區】中拖入一個「ParallelActivity」活動元件到『主管審核』的下方，注意，ParallelActivity的「Description」是用來設定是否為會簽或平行簽核，設為「AND」代表為會簽，設為「OR」代表為平行簽核，預設為AND。如圖：

Step5＞將「ifElseActivity」拖入到右邊的ParallelActivity間(在sequenceActivity2的下方),為了本流程容易讓User閱讀，請將ifElseActivity1的Name改成「信用額度審核」，並在「ifElseBranchActivity1」的條件分支中將Name改成「小於10萬」，再將「ifElseBranchActivity2」的條件分支中將Name改成「大於10萬」，再將「ifElseBranchActivity2」的Description設定為CreditAmount>=100000，ifElseActivity活動中，我們是將條件判斷式設定在Description這個屬性中，不是設定在Condition，其中CreditAmount 這是一個Customers資料表的欄位，用來當作條件的判斷，此代表如果信用額度超過或等於100000時，就會流向ifElseBranchActivity2這個支流。如圖：

Step6＞再從流程活動元件區中拖入一個「FLStand」活動元件到ifElseBranchActivity2的下方，如圖：

現將信用審核的活動元件，屬性設定如下：

(Name)：活動名稱，直接輸入中文 信用審核。

NavigatorMode：設定打開此表單後，要控制其Navigator的進入的狀態，此

活動為審核的狀態，因此我們將其設定為Normal，代表不能對資料進行更改

的動作(不能新增/更改/刪除/查詢資料等等)，如果你是希望此角色需要可以更

改，則可設定為Modify的模式。

FLNavigatorMode：在此設定為Approve，代表將顯示「審核」與「退回」

的按鈕，而不是Summit的「上呈」按鈕。

SendToKind：活動的對象種類，我們設定為Role，代表此活動指定了一個特

定的角色來進行審核的動作（由角色的設定來對應所要簽核的Users）。

SendToRole：活動的簽核角色，當本活動設定SendToKind為Role之後，就

必須在SendToRole中來定義簽核角色。因為我們是要交給行政經理來負責信

用的審核，因此我們設定為R03，可以透過此SendToRole右方的下拉選項來

選擇角色代號。

Step7＞接著，我們再拖入一個FLStand標準活動於ParallelActivity的左方(在sequenceActivity1的下方)，如圖，我們按下文來設定此活動元件。

現將這個FLStand的活動元件，屬性設定如下：

(Name)：活動名稱，直接輸入中文指定服務視窗。

NavigatorMode：設定打開此表單後，要控制其Navigator的進入的狀態，此活動因為要能夠讓其對象可以更改，因此我們設定為Modify，代表可以對資料進行更改的動作 (不能新增/刪除/查詢資料等等)，目前是可以更改所有欄位，如果要控制只能輸入ServiceRole欄位，我們將在進階設計中來說明如何控制。

FLNavigatorMode：在此設定為Approve，代表將顯示「審核」與「退回」的按鈕，而不是Summit的「上呈」按鈕。

SendToKind：活動的對象種類，我們設定為 Role，代表此活動指定了一個特定的角色來指定服務視窗的動作。

SendToRole：活動的簽核角色，當本活動設定SendToKind為Role之後，就必須在SendToRole中來定義簽核角色。因為我們是要交給客服經理來負責服務視窗的指定，因此我們設定為R05，可以透過此SendToRole右方的下拉選項來選擇角色代號。

Step8＞在「指定服務視窗」下方拖入一個FLStand標準活動，目的用來讓服務窗口確認，因為服務窗口是動態決定的，因此就必須使用到RefRole的型態，如圖:

現將這個FLStand的活動元件，屬性設定如下：

(Name)：活動名稱，直接輸入中文服務視窗確認。

NavigatorMode：設定打開此表單後，要控制其Navigator的進入的狀態，此

活動是不允許更改的，所以我們設定為Normal，代表不可以對資料進行任何

的動作 (不能新增/更改/刪除/查詢資料等等)。

FLNavigatorMode：在此設定為Continue，代表只顯示「上呈」的按鈕，而

不會顯示「審核」與「退回」的按鈕，目的就是讓此活動可以讓該角色得以確認，按下「上呈」的按鈕後即可讓流程往下持續。

SendToKind：活動的對象種類，我們設定為 RefRole，代表此活動指定了一個動態的參考的角色，必須另外定義SendToField來指定哪一個欄位名稱存有該參考角色的內容。

SendToField：當SendToKind為RefRole或RefManager時，即用此屬性來定義一個欄位名稱，用來存放該活動的對應角色，在此可以下拉選擇欄位名稱，我們選 ServiceRole這個欄位。

Step9＞在此Work Flow Designer中，選擇File/Save Workflow AS 功能，此時請選擇一個目錄，請注意，目錄必須在Infolignt\EEP2010\EEPNetServer\Workflow之下，可以建立一個子目錄來存放，例如我們在此建一個FL目錄來存放此WorkFlow的XOML檔案(XOML為.net3.0新的XML檔案)，檔案命名為 Infolignt\EEP2010\EEPNetServer\Workflow\FL\CustomersForEF.Xoml。流程設定好了之後，我們將利用EEPManager來設定此Xoml流程檔案的權限，進入Security Manager後，在Menu Utility中，新增一個”客戶申請”的項目，最後設定「Access Groups」，選擇Everyone並存檔。如圖：


6-3簡易的流程呈送

接著我們使用Web的介面來執行流程的結果，如下的操作步驟。

Step1＞打開Login畫面，用003用戶登錄進去。

Step2＞進入workflow的主畫面後，請點選 「客戶管理」，打開此客戶申請的流程，在Web可以打開Xoml檔案是因為當初在FLDesigner.exe中對此Xoml檔案存檔的同時，系統會自動將此Xoml存成相對的JPG檔案，並自動存放在「EEPWebClient\Image」目錄之下，好讓Web可以打開流程檔案。如圖，我們在「客戶申請」這個Activity活動上，按一下左鍵，即可打開此客戶申請的Web表單。

Step3＞打開客戶申請單後，因為NavigatorMode為「Insert」，所以只能按下「新增」來輸入客戶資料，如圖輸入一個C020的客戶，為了減化流程，我們將「信用額度」輸入為80000元，最後按下「存檔」。

Step4＞這個客戶資料雖已經存到資料表中了，但其FlowFalg的內容為空白，代表尚未經過審核的程式，因此我們必須再按下「上呈」的按鈕，將此客戶以流程來申請。如圖，透過此確認的視窗，來選擇是否為「重要單據」與「緊急單據」(緊急單據的時效與一般的單據不一樣)。接著選擇「發送者角色」，因為此User可能有多個角色，就必須選擇一個角色來呈送，最後按下「確認」後，系統將告知送往哪一個角色哪一個使用者。

Step5＞我們再度以User 005來登入「LogOn.aspx」，在主畫面中，可以在「待辦事項」中找到「C020」這個客戶，可以透過下圖中的三個圖示來操作這張申請單，最左邊的圖示代表「打開」，可以打開該單據並進行流程的操作，中間則為「審核」，可以直接審核該單據，最右邊的為「退回」，用來將單據退回。在這裡我們選擇「打開」，然後再按下Navigator上的「審核」按鈕。

審核後，將會出現另一個確認事項的視窗，主管輸入意見後，按下「確認」後，系統將會告知送往R05客服經理，使用者為007。

Step6＞以User 007登入「LogOn.aspx」，在主畫面中，在「待辦事項」中找到「C020」這個客戶按下「打開」的圖示，此時將出現如下的頁面，按下「修改」的按鈕後，將「服務窗口」設定為R04，按下「存檔」後，同樣將其「審核」往下呈送，如圖：

往下呈送後，將會出現確認事項的視窗，可以輸入審核的意見，系統將告知送往R04工程師，並讓004使用者來確認。

Step7＞最後，如以User 004登入，即可得到一筆「C020」客戶申請的待辦事項，並讓其來做確認的動作，當此工程師按下「往下呈送」並確認後，該流程將會自動結束，系統會在此流程結束時，自動將該資料的FlowFlag設定為「Z」，代表該資料已通過審核。


6-4參數傳遞與控制

在EEP WF系統中，各個Activity活動可以使用不同的表單來進行流程的簽核，就因為此，所以讓各個作業能有自己獨特的彈性與特殊的使用者畫面，但大多數的表單畫面都是很接近的，只有小小的差異就要設計成不同的表單與頁面，確實很浪費時間，因此，我們也可以透過在Activity活動中的Parameters參數來傳入

同一個表單或頁面中，這樣就可以共用一個頁面，只須在這個頁面中以傳入的

Parameters來做特別的控制。

Step1＞在 Customers.XOML中，將”指定客戶窗口”活動的Parameters設為 P1=SERVICE，P1代表參數名稱，SERVICE代表參數內容，可以自由設定，此參數可以在透過Web的連結頁面傳入網頁的Request的參數中，通過HtmlPage.Document.QueryString[“參數名稱”]取得。

Step2＞在bCustomers.xaml這個表單中，在fvMaster中增加這個ContentLoad事件，來控制哪些欄位不能輸入(只有服務窗口欄位可以輸入)。

if (e.Mode == DataFormMode.Edit && HtmlPage.Document.QueryString["P1"] == "SERVICE")

{

foreach (var item in ((Grid)e.Content).Children)

{

if (((DataField)item).Content.Name == "TextBoxServiceRole")

{

//設定哪些欄位可編輯

((Control)((DataField)item).Content).IsEnabled = true;

}

else

{

//設定哪些欄位不可編輯

((Control)((DataField)item).Content).IsEnabled = false;

}

}

}

Step3＞以「LogOn.aspx」進來，在登入畫面中，我們以003為User進入。新增一筆C016客戶資料如下圖，新增完畢後，將資料呈上後送給005，005簽核後流程流至指定客服窗口將此資料送給007。

Step4＞以007為User登入，在「待辦事項」中找到C016的客戶資料，點擊「修改」按鈕對資料進行修改時，可以發現此時只能更改「服務窗口」，其餘欄位都無法更改。

從上面的實例中可以發現，通過傳遞參數的方法就可以在某個流程環節進行操作功能的控制，使之成為一個較具有彈性的操作流程。


A、WorkFlow元件屬性說明

B、WorkFlow活動屬性說明

C、WorkFlow系統資料表結構說明

D、WorkFlow系統檔案說明

E、WorkFlow Expresssion格式


附錄A、WorkFlow元件屬性說明

FLNavigator

NavigatorConverter

FLWizard

FLWebNavigator

FLWebWizard


FLNavigator

【功能說明】

用途：使用於Win Client端，繼承InfoNavigator的基礎上，增加了WorkFlow各個按鈕操作功能。

【元件屬性】

Name(名稱)(string)

元件名稱，用於識別該元件。

BindingSource ( 資料源 )( InfoBindingSource)

要對應的 BindingSource ，所有 Navigator 的動作都是會自動與指定的 BindingSource 相互作用。

FLActive(WorkFlow Navigator啟用)(bool)

該屬性設置後Navigator可以為Workflow所使用，設為False可暫時不提供Workflow功能，所有的Workflow按鈕都會被自動隱藏。

FLNotifyOff(關閉通知功能)(bool)

設定是否使用通知功能，預設為False，表示會顯示通知按鈕；反之無法顯示。

FLNotifySecControl(通知權限控制)(bool)

該屬性表示是否控制通知的權限，配合MenuID屬性一起使用。當該屬性設為true後，在流程中通知其他User或角色時，如果在EEPManager的MenuUtility中對該表單的Menu權限中設定了User或群組的使用權後，就可以讓此通知的對象可以被限制成有使用權的人才能選擇。預設值為false。

MenuID(對應功能表)(String)

對應到一個Menu功能表中的一個MenuID(存在MenuTable中)，此屬性是為了搭配FLNotifySecControl所使用。

FlowID(目前流程)(string)

定義一個後端的FlowID(就是Flow的XOML檔案)，用此Flow來執行流程控管，本屬性一般不必設定，當User按下Workflow的活動後，由Activity傳入表單中。

FLStates(WorkFlow狀態)(Collection)

表示用來控制此工作流程的所有按鈕狀態，預設有以下幾個狀態：

Submit(上呈)/Notify(通知)/Return(退回)/Approve(審核)/Notify(通知)/ Inquery(結束作業中來查詢單據的簽核歷程)/Continue(繼續)/None/Plus(加簽)/Lock(鎖定)/RSubmit(退回到原始)/Fsubmit(取回到原始)。

Description（狀態描述）(String)：用來說明狀態。

StateText（狀態名稱）(String)：狀態的名稱，也是狀態的文字說明，配合DescriptionItem屬性可以顯示狀態文字於Navigator上。

VisibleControls（顯示的按鈕）(Enum)：設定要在此狀態下要讓那些按鈕可見，可以設定多個。

ApproveItem ( 審核按鈕 )( ToolStripButton)

對應 的審核按鈕，無需設定，系統 會自 動設定。 ApproveItem 用 來目前筆 工作流進行審核的 動作。

CommentItem ( 查看按鈕 )( ToolStripButton)

對應的 查看 按鈕，無需設定，系統會自動設定。 CommentItem 用來目前筆資料進行查看到當前為止工作流的所有狀態記錄動作。

FlowDeleteItem ( 删除通知按鈕 )( ToolStripButton)

對應的 删除通知按鈕，無需設定，系統會自動設定。 FlowDeleteItem 用來對目前筆通知刪除的動作。

NotifyItem ( 通知按鈕 )( ToolStripButton)

對應的 通知按鈕，無需設定，系統會自動設定。 NotifyItem 用來在當前流程中進行相互通信的動作。

PauseItem ( 暫停按鈕 )( ToolStripButton)

對應的 暫停按鈕 ， 無需設定 ， 系統會自動設定。 PauseItem 用來對當前流程進行暫停的動作。

PlusItem ( 加簽按鈕 )( ToolStripButton)

對應的 加簽按鈕 ， 無需設定 ， 系統會自動設定。 PlusItem 用來對當前流程進行加簽的動作。

RejectItem ( 作廢按鈕 )( ToolStripButton)

對應的 作廢按鈕，無需設定，系統會自動設定。 RejectItem 用來對當前流程進行作廢的動作。

SubmitItem ( 呈上按鈕 )( ToolStripButton)

對應的 呈上按鈕，無需設定，系統會自動設定。 SubmitItem 用來對當前流程進行提交的動作。

AutoSubmit(自動上呈)(bool)

用於存檔資料時，自動上呈數據。當AutoSubmit=True時，User去Apply資料時，會自動執行 Submit(上呈)的動作。AutoSubmit預設為False。

【功能函數】

Bool Submit()

上呈的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Approve()

審核的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Return()

退回的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Pause()

暫停的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Plus()

加簽的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Notify()

通知的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Reject()

作廢的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool FlowDelete()

刪除的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Comment()

顯示簽核過程意見的Method，讓User自己可以用程式呼叫。

【其他說明】

FLWebNavigator的事件、屬性和其他功能函數繼承了InfoNavigator。


NavigatorConverter

【功能說明】

用途：當原Client端設計時使用Windows的InfoNavigator之後，爲了方便User將InfoNavigator轉換為FLNavigator所使用的特殊元件。

【元件屬性】

Name(名稱)(string)

元件名稱，用於識別該元件。

FLNavigator(轉換FLNavigator)(FLNavigator)

該屬性用來設定將要被轉換的InfoNavigator，表示該元件將會被轉換成FLNavigator。

【其他說明】

需要注意的是，在轉換之前應該先將寫好的InfoNavigator的類(Class)轉換為FLNavigator。轉換方式如下：

應該有2個地方需要更改，如下找到new的地方：

將上面 Srvtools.InfoNavigator()改成

this.infoNavigator1 = new FLTools.FLNavigator();

再往下找，應該會找到private的物件處，如下：

請將這列程式改成

private FLTools.FLNavigator infoNavigator1;

【其他說明】

請注意本元件專用在Design模式下用來轉換成FLNavigator所使用，在RunTime時是不會用到本元件的，如有必要也可以轉換後刪除。


FLWizard

【功能說明】

用途：workflow系統會把所有的待辦單據放在SYS_TODOLIST與SYS_TODOHIS兩個系統Table上，其中SYS_TODOLIST是存放待辦的單據，SYS_TODOHIS則存放待辦簽核的歷史紀錄，本元件專門用來自動產生此USER的待辦單據與經辦且未結案的單據查詢SQL語法給後端InfoCommad去下載資料到Client端的InfoBindingSource中。

【元件屬性】

Name(名稱)(string)

元件名稱，用於識別該元件。

Active(啟用Wizard)(bool)

表明是否啟動FLWizard該元件，預設值為false，表示不啟動；否則為啟動。

DataSource(對應資料表)(InfoBindingSource)

該屬性表示對應資料表，要產生SQL的InfoBindingSource名稱，系統會自動下達對應的SQL並取得Server端數據後，會傳到此InfoBindingSource中。

SqlMode(SQL模式)(enum)

用來表明存放那種類型的數據，共有四種形式，如下：

ToDoList：待辦單據明細，查詢出此User的所有待辦單據明細。

ToDoListStatist：待辦單據統計，查詢出此User的所有待辦單據統計，以流程與

作業來統計待辦數量。

ToDoHist：經辦追蹤明細，查詢出此User的所有經辦且未結案的單據明細。

ToDoHistStatist：經辦追蹤統計，查詢出此User的所有經辦且未結案的單據統計，以流程與作業來統計經辦數量。其中預設值為ToDoList。

【功能函數】

Open()

依SQLMode的待辦或經辦去打開相對的表單單據。

SQLMode為ToDoList時，代表打開ToDoList待辦的單據；SQLMode為ToDoHist時，代表打開ToDoHist經辦的單據。

Refresh()

重新送SQL命令給相對的後端InfoCommad，並令InfoBindingSource 重新更新最新的待辦或經辦資料。

Approve()

可以讓User直接在待辦事項中審核，不必打開單據，傳回True/False代表成功失敗。

Return()

可以讓User直接在待辦事項中退回的Method，不必打開單據，傳回True/False代表成功失敗。

Reject()

可以讓User直接在待辦事項中作廢的Method，不必打開單據，傳回True/False代表成功失敗。


FLWebNavigator

【功能說明】

用途：使用於Web Client端，繼承WebNavigator的基礎上，增加了WorkFlow各個按鈕操作功能。

【元件屬性】

ID(名稱)(string)

元件名稱，用於識別該元件。

BindingObject(連結元件) (string)

指示FLWebNavigator所控制的資料元件，一般對應的資料元件適合的有WebGridView，WebDetailsView，WebFormView等元件。FLWebNavigator是無法直接連接到WebDataSource資料元件當中，而必須改連接到要顯示的資料元件上。

FLActive(WorkFlow Navigator啟用)(bool)

該屬性設置後Navigator可以為Workflow所使用，設為False可暫時不提供Workflow功能，所有的Workflow按鈕都會被自動隱藏。

FLNotifyOff(關閉通知功能)(bool)

設定是否使用通知功能，預設為False，表示會顯示通知按鈕；反之無法顯示。

FLNotifySecControl(通知權限控制)(bool)

該屬性表示是否控制通知的權限，配合MenuID屬性一起使用。當該屬性設為true後，在流程中通知其他User或角色時，如果在EEPManager的MenuUtility中對該表單的Menu權限中設定了User或群組的使用權後，就可以讓此通知的對象可以被限制成有使用權的人才能選擇。預設值為false。

MenuID(對應功能表)(String)

對應到一個Menu功能表中的一個MenuID(存在MenuTable中)，此屬性是為了搭配FLNotifySecControl所使用。

FlowID(目前流程)(string)

定義一個後端的FlowID(就是Flow的XOML檔案)，用此Flow來執行流程控管，本屬性一般不必設定，當User按下Workflow的活動後，由Activity傳入表單中。

FLStates(WorkFlow狀態)(Collection)

表示用來控制此工作流程的所有按鈕狀態，預設有以下幾個狀態：

Submit(上呈)/Notify(通知)/Return(退回)/Approve(審核)/Notify(通知)/ Inquery(結束作業中來查詢單據的簽核歷程)/Continue(繼續)/None/Plus(加簽)/Lock(鎖定)/RSubmit(退回到原始)/Fsubmit(取回到原始)。

Description（狀態描述）(String)：用來說明狀態。

StateText（狀態名稱）(String)：狀態的名稱，也是狀態的文字說明，配合DescriptionItem屬性可以顯示狀態文字於Navigator上。

VisibleControls（顯示的按鈕）(Enum)：設定要在此狀態下要讓那些按鈕可見，可以設定多個。

AutoSubmit(自動上呈)(bool)

用於存檔資料時，自動上呈數據。當AutoSubmit=True時，User去Apply資料時，會自動執行 Submit(上呈)的動作。AutoSubmit預設為False。

【功能函數】

Bool Submit()

上呈的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Approve()

審核的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Return()

退回的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Pause()

暫停的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Plus()

加簽的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Notify()

通知的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Reject()

作廢的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool FlowDelete()

刪除的Method，讓User自己可以用程式呼叫，傳回True/False代表成功失敗。

Bool Comment()

顯示簽核過程意見的Method，讓User自己可以用程式呼叫。

【其他說明】

FLWebNavigator的事件、屬性和其他功能函數繼承了WebNavigator。


FLWebWizard

【功能說明】

用途：FLOW系統會把所有的待辦單據放在SYS_TODOLIST與SYS_TODOHIS兩個系統Table上，其中SYS_TODOLIST是存放待辦的單據，SYS_TODOHIS則存放待辦簽核的歷史，本元件來自動產生此USER的待辦單據與經辦且未結案的單據下載到Web Client端的頁面當中。

【元件屬性】

ID(名稱)(string)

元件名稱，用於識別該元件。

Name(名稱)(string)

元件名稱，用於識別該元件。

Active(啟用Wizard)(bool)

表明是否啟動FLWizard該元件，預設值為false，表示不啟動；否則為啟動。

BindingObjectID(顯示資料的對象)(string)

該屬性表示顯示FLOW系統資料的對象。

SqlMode(SQL模式)(enum)

用來表明存放那種類型的數據，共有四種形式，如下：

ToDoList：待辦單據明細，查詢出此User的所有待辦單據明細。

ToDoListStatist：待辦單據統計，查詢出此User的所有待辦單據統計，以流程與

作業來統計待辦數量。

ToDoHist：經辦追蹤明細，查詢出此User的所有經辦且未結案的單據明細。

ToDoHistStatist：經辦追蹤統計，查詢出此User的所有經辦且未結案的單據統計，以流程與作業來統計經辦數量。其中預設值為ToDoList。

【功能函數】

String OpenUrl ()

依SQLMode去打開表單的script腳本傳回。

SQLMode為ToDoList時，代表打開ToDoList待辦的單據；SQLMode為ToDoHist 時，代表打開 ToDoHist經辦的單據。
Refresh()

重新送SQL命令給相對的DataSet，並令DataSet 重新更新最新的待辦或經辦資

料。

Approve()

可以讓User直接在待辦事項中審核，不必打開單據。

string ApproveUrl()

將審核時彈出框的script腳本傳回給User。

Return()

可以讓User直接在待辦事項中退回的Method，不必打開單據。

string ReturnUrl()

將退回時彈出框的script腳本傳回給User。

Reject()

可以讓User直接在待辦事項中作廢的Method，不必打開單據，傳回True/False代表成功失敗。


FLApprove

【功能說明】

用途：FLApprove是Workflow設計中的審核活動元件，專門用於主管簽核所使用，可以設定多層簽核。

【元件屬性】

Name(名稱)(string)

活動名稱，可以通過對Name的設定，來命名流程的作業名稱，為了讓User更直覺，可輸入中文名稱來命名，單一流程中的活動名稱不能重複。

FormName(操作畫面名稱)(string)

用於設定此活動是使用那一個Windows Form來呈現資料，請選擇一個Windows的表單名稱，可以按下右方的選取按鈕，選擇回來的格式為DllName.FormName。

WebFormName(Web操作畫面名稱)(string)

用於設定此活動是使用那一個Web的表單名稱，選擇回來的內容格式應是Web的Aspx名稱，須包含Path。

NavigatorMode(Navigator狀態)(string)

設定打開此表單後，要控制其Navigator進入的狀態，因為流程表單被打開後，就無法像之前的表單打開一樣，可以讓User任意新增/更改/刪除/查詢資料等等，在流程中操作表單，必須控制Navigator只能操作某些動作，不是任意可以讓User操作。

FLNavigatorMode(Workflow Navigator狀態)(string)

表單我們改貼了FLNavigator後，會多了幾個流程按鈕，須透過此屬性來控制此FLNavigator那些流程按鈕可以執行，那些則要隱藏等等，在此因為代表審核，所以固定為Approve模式。

ApproveRights(審核權限)(collection)

主管審核的授權等級設定，透過這個屬性，可以設定什麼樣的條件下，要授權給哪一種職級的主管去簽核，可以設定多層級的主管與條件，只要條件滿足就會往下呈送給更高階的主管。在ApproveRights設定可以使用一個Collection來設定多層的簽核，Collection說明如下：

Grad(級別)(string)：設定審核的職級，職級設定於SYS_ORGLEVEL資料表中，請下拉選擇一個職級，必須由小到大，最小的是1，最大的職級是9，另外有一個0直屬主管，是個特殊的職級，就是不管誰送呈單據，不管職級大小都會找其主管來審核，除非送出者為最高主管。

Expression(條件)(string)：該職級要簽核的條件，可以設定流程表單中的任意欄位作為條件運算式，如果沒有條件，可以設定為True，代表都必須簽核，Expression的格式請參考附錄E，Expression格式說明。

SendToKind(對象類別)(string)

用來設定此活動的對象種類，對象種類只能有Manager或RefManager，Manager則代表對象為上呈者的主管(根據組織的設定)：RefManager則代表參考主管，與RefRole類似，不同的是RefManager所根據該欄位內容的動態角色去找他的主管，不是動態角色內容本身。

SendToField(參考角色欄位)(string)

參考主管的欄位名稱，如果本活動的角色是動態不固定角色，就是SendToKind為RefManager時，那麼就必須使用本屬性來定義其流程主檔的某一欄位，其欄位的內容存放這本作業的角色代號(GroupID)，並以此角色代號去找他的主管來簽核。

Parameters(參數)(string)

此參數會透過待辦事項或經辦事項的資料，傳入Win Form或Web Form的Parameters中，這些Parameters很像EEPManager的Menu Utility中所設定的Parameters參數是一樣的，用來令活動與Windows或Web FORM可以互動。

ExpTime(作業時限)(decimal)

設定本活動的作業時限，其時限單位定義於TimeUnit屬性中，可以用此來作為該活動作業是否逾時的依據。

UrgentTime(緊急時限)(decimal)

設定本活動的緊急作業時限，其時限單位定義於TimeUnit屬性中，與ExpTime搭配使用，ExpTime代表一般單據的作業時限，UrgentTime則代表緊急單據的作業時限，當然須比ExpTime來得很小。

TimeUnit(時限單位)(enum)

設定時限的單位，可以為Hour或Day。

PlusApprove(加簽)(bool)

用於設定是否可以加簽，預設為False，代表無需加簽，加簽的動作是由該活動的簽核者來決定是否加簽給其他主管或參與者，可以同時加簽給多個角色，所有參與者加簽後，又會回到自己本身，再決定往下呈送或退回。

SendEmail(發送E-Mail)(bool)

是否在流程引擎送給本活動接收者的同時，發送出Email來通知該接收者連結到該活動作業並進行簽核，此功能需配合EEPNetServer的Workflow Config設定與Users中的Email帳後設定才會生效。預設為False代表不發送。

DelayAutoApprove(逾時自動簽核)(bool)

設定是否進行逾時自動簽核，當DelayAutoApprove=True時, 如果此活動發生了逾時狀況時，就可以透過Scheduling排程系統來自動讓這些逾時的待辦可以自動往下審核，來解決非要處理不可的單據。Scheduling的排程請設定為FLRuntime這個Dll中的Approve2()這個Server Method即可。


FLDetails

【功能說明】

用途：FLDetails是專門用來設計動態的活動流程，因為在一般情況下，作業流程都是事先規劃好並被XOML事先定義好了，但有些流程是無法事先定義好的，必須由呈送者來指定呈送流程，因此須透過此FLDetails來動態設定流程的步驟與其呈送對象。由於動態流程很複雜，所以必須透過FLDetails來定義一個明細資料表，利用此明細資料表來定義流程的步驟及其呈送對象。

【元件屬性】

Name(名稱)(string)

活動名稱，可以通過對Name的設定，來命名流程的作業名稱，為了讓User更直覺，可輸入中文名稱來讓User更為直覺，注意！單一流程中的活動名稱不能重複。

DetailTableName(明細資料表)(string)

即以此明細資料表作為流程活動的依據及呈送對象，也就是說流程引擎會讀取該資料表的相對資料，自動產生多個流程活動，如果相對資料有多筆就會有多個活動產生，至於對象或是否會簽(平行處理)，則可分別根據 SendToField與ParallelField來決定之。

RelationsKeys(關連鍵值欄位)(string)

用來定義取得DetailTableName相對資料的關聯鍵值欄位名稱，一般是定義DetailTableName與整個Flow的TableName資料表間的關聯欄位，此屬性需與DetailTableName配合設定才能使本活動正確運作。

FormName(操作畫面名稱)(string)

統一設定該FLDetails的所有活動是使用那一個Windows Form來呈現資料，請選擇一個Windows的表單名稱，可以按下右方的選取按鈕，選擇回來的格式為 DllName.FormName。

WebFormName(Web操作畫面名稱)(string)

統一設定該FLDetails的所有活動是使用那一個Web的表單名稱，選擇回來的內容格式應是Web的Aspx名稱，須包含Path。

NavigatorMode(Navigator狀態)(string)

統一設定打開此表單後，要控制其Navigator進入的狀態，因為流程表單被打開後，就無法像之前的表單打開一樣，可以讓User任意新增/更改/刪除/查詢資料等等，在流程中操作表單，必須控制Navigator只能操作某些動作，不是任意可以讓User操作。

FLNavigatorMode(Workflow Navigator狀態)(string)

表單我們改貼了FLNavigator後，會多了幾個流程按鈕，須透過此屬性來控制此FLNavigator那些流程按鈕可以執行，那些則要隱藏等等，在此都固定為Approve 模式，用來專門使用在審核的模式中。

SendToKind(對象類別)(string)

用來設定此活動的對象種類，對象種類固定為 RefRole，因為每一個動態活動都是使用動態的角色來處理其對象的。

SendToField(參考角色欄位)(string)

參考角色的欄位名稱，也就是選擇 DetailsTableName中的一個字串欄位名稱，來作為此多筆動態活動(一筆代表一個活動)的對象角色內容，本屬性不能不設定，否則無法作業。

ParallelFields(平行活動欄位)(string)

是否為平行活動的欄位名稱，也就是選擇 DetailsTableName中的一個字串欄位名稱，來作為此多筆動態活動(一筆代表一個活動)是否為平行處理活動，如果該欄位的內容為”AND”或”Y”代表與上一個活動是平行處理個關係，就是同時會分流多個活動；反之為空白或NULL時則代表依次序一步一步往下流動。若本屬性不設定時，則代表每個活動都是依次序步驟往下的。

ParallelRate(平行通過比率)(int)

當ParallelFields設定為”AND”或”Y”時，可以設定一個通過比率，用來決定有多少角色比率通過即代表通過，如設定為50，代表半數的角色審核後就通過。

Parameters(參數)(string)

此參數會透過待辦事項或經辦事項的資料，傳入Win Form或Web Form的Parameters中，這些Parameters很像EEPManager的Menu Utility中所設定的Parameters參數是一樣的，用來令活動與Windows或Web FORM可以互動。

ExpTime(作業時限)(decimal)

統一設定本活動的所有作業時限，其時限單位定義於TimeUnit屬性中，可以用此來作為該活動作業是否逾時的依據。

UrgentTime(緊急時限)(decimal)

統一設定本活動的緊急作業時限，其時限單位定義於TimeUnit屬性中，與ExpTime搭配使用，ExpTime代表一般單據的作業時限，UrgentTime則代表緊急單據的作業時限，當然須比ExpTime來得很小。

TimeUnit(時限單位)(enum)

設定時限的單位，可以為Hour或Day。

SendEmail(發送E-Mail)(bool)

統一設定是否在流程引擎送給本活動接收者的同時，發送出Email來通知該接收者連結到該活動作業並進行簽核，此功能需配合EEPNetServer的Workflow Config設定與Users中的Email帳後設定才會生效。預設為False代表不發送。


FLHyperLink

【功能說明】

用途：FLHyperLink專門用於流程的UI操作所使用，為了配合User在U/I操作時的HyperLink動作，可透過本活動元件串接其他網頁表單或其他流程，在流程引擎中本活動是沒有任何作用的。

【元件屬性】

Name(名稱)(string)

連結活動名稱，可以通過對Name的設定，來命名活動名稱，可輸入中文連結標題意義來命名，好讓User更直覺，單一流程中的活動名稱不能重複。

Description(活動說明)(string)

連結活動的說明，僅用來備註或說明此條件的用途。

FormName(操作畫面名稱)(string)

用於設定此活動將連結打開那一個Windows Form，請選擇一個Windows的表單名稱，可以按下右方的選取按鈕，選擇回來的格式為DllName.FormName，User按下本活動時，將打開此指定Windows表單。

WebFormName(Web操作畫面名稱)(string)

用於設定此活動將連結打開那一個Web的表單名稱，選擇回來的內容格式應是Web的Aspx名稱，須包含Path，User按下本活動時，將打開此指定網頁。

LinkFlow(流程連接)(string)

用於設定此活動將連結打開那一個Workflow的流程名稱，選擇回來的內容格式應是Workflow目錄下的XOML檔案名稱，會包含Path，User按下本活動時，將打開此流程表單。

Parameters(參數)(string)

Parameters中，這些Parameters很像EEPManager的Menu Utility中所設定的Parameters參數是一樣的，用來令活動與Windows或Web FORM可以互動。


FLNotify

【功能說明】

用途：FLNotify是專門用來做為通知的活動元件，就是當流程執行到此作業時，會以通知的形式知會此活動的角色，此活動將不會影響到流程的停滯，因為發出了通知活動後，流程引擎會自動執行下一個活動。

【元件屬性】

Name(名稱)(string)

活動名稱，可以通過對Name的設定，來命名流程的作業名稱，為了讓User更直覺，可輸入中文名稱來命名，單一流程中的活動名稱不能重複。

FormName(操作畫面名稱)(string)

用於設定此活動是使用那一個Windows Form來呈現資料，請選擇一個Windows的表單名稱，可以按下右方的選取按鈕，選擇回來的格式為DllName.FormName。

WebFormName(Web操作畫面名稱)(string)

用於設定此活動是使用那一個Web的表單名稱，選擇回來的內容格式應是Web的Aspx名稱，須包含Path。

FLNavigatorMode(Workflow Navigator狀態)(string)

在通知的狀態下，在此固定為Notify，不能更改，代表僅可執行通知/通知刪除按鈕，其餘不顯示。

NavigatorMode(Navigator狀態)(string)

在通知的狀態下，在此固定為Normal，不能更改，代表所有Navigator的按鈕都不能使用，無法新增/更改/刪除/查詢。

SendToKind(對象類別)(string)

用來設定此活動的通知對象種類，對象種類有Role/RefRole/Manager/RefManager/Applicate等等，如下的說明：

Role：代表對象為一個角色。

RefRole：代表為參考角色，就是根據某個欄位內容做為動態的角色。

AllRoles：代表會發通知給所有簽核過的角色。

Manager：則代表對象為上呈者的主管(根據組織的設定)。

RefManager：與RefRole類似，不同的是RefManager所根據該欄位內容的動態角色去找他的主管，不是動態角色內容本身。

Applicate: 則代表最原始的申請者等。

SendToField(參考角色欄位)(string)

參考角色的欄位名稱，如果本活動的角色是動態不固定角色，就是SendToKind為RefReole或RefManager時，那麼就必須使用本屬性來定義其流程主檔的某一欄位，其欄位的內容存放這本作業的角色代號(GroupID)。

SendToRole(對象角色)(string)

當對象類別為角色(Role)時，本屬性則代表活動的對象角色代號，選角色時，只可能選擇到Groups中ISROLE欄位為’Y’的角色資料。

Parameters(參數)(string)

此參數會透過待辦事項或經辦事項的資料，傳入Win Form或Web Form的Parameters中，這些Parameters很像EEPManager的Menu Utility中所設定的Parameters參數是一樣的，用來令活動與Windows或Web FORM可以互動。

ExpTime(作業時限)(decimal)

設定本活動的作業時限，其時限單位定義於TimeUnit屬性中，可以用此來作為該活動作業是否逾時的依據。

UrgentTime(緊急時限)(decimal)

設定本活動的緊急作業時限，其時限單位定義於TimeUnit屬性中，與ExpTime搭配使用，ExpTime代表一般單據的作業時限，UrgentTime則代表緊急單據的作業時限，當然須比ExpTime來得很小。

TimeUnit(時限單位)(enum)

設定時限的單位，可以為Hour或Day。

SendEmail(發送E-Mail)(bool)

用於確定是否要發送E-Mail，預設值為false，表示無需發送Mail。


FLProcudure

【功能說明】

用途：FLProcudure是專門用來設計Workflow後端的處理程序或商業邏輯程序等，可以隨著Workflow引擎執行到此活動時被觸發執行。

【元件屬性】

Name(名稱)(string)

處理程序活動名稱，可以通過對Name的設定，來命名活動名稱，可輸入中文條件意義來命名，好讓User更直覺，單一流程中的活動名稱不能重複。

Description(活動說明)(string)

處理程序活動的說明，用來備註或說明此程序的用途，供其他開發者了解。

ModuleName(Server模組名稱)(string)

代表Server Method所在的Server DLL模組名稱。

MethodName(方法名稱)(string)

表示所要呼叫ModuleName中的Server Method名稱。

ErrorLog(錯誤Log)(bool)

用來設定此程序如果發生錯誤時，是否要進行Log的動作。當發生Exception時，會將此Error記錄到 FLErrLog.XML中，但不管ErrorLog為True/ False除了Log到此之外，還會回應給User知道流程後端的程序已經發生的錯誤，方便User來告知系統人員。

ErrorToRole(錯誤通知角色)(string)

設定當發生錯誤時，可通知一個負責的角色。

注意事項：

在FLProcedure去呼叫ServerMethod的參數是系統固定的，與Expression的呼叫方式相似，差別多了傳遞第二個參數FlowDirection，為一個integer型態，0，代表流程已結案的處理程序(不可逆向)，1代表往後流動，2代表往前流動，如退回，可以用此FlowDirection來控制處理程序的應變方案。

可以在Server DataModule中，開發如下的Method範例：

public object[] ServerProc(object[] objParam)

{

object[] ret = new object[] { 0, 0 };

DataRow dr=(DataRow) objParam[0]; //取得流程資料表的資料欄位

int FlowDirection = (int)objParam[1]; //取得流程方向

…. 你的流程商業處理

return ret;

}


FLQuery

【功能說明】

用途：FLQuery是專門用來查詢Workflow所有的簽核表單資料所使用，透過這個活動可以將過去經過簽核的資料表單加以查詢，並可以透過FLNavigator的批示歷程(Comment)來了解整個批示的過程。在流程引擎中，本活動也是沒有任何作用的一個元件，ㄧ般貼在End(結束)前一個活動。

【元件屬性】

Name(名稱)(string)

活動名稱，可以通過對Name的設定，來命名流程的作業名稱，為了讓User更直覺，可輸入中文名稱來命名，單一流程中的活動名稱不能重複。

Description(活動說明)(string)

查詢活動的說明，用來備註或說明此程序的用途，供其他開發者了解。

FormName(操作畫面名稱)(string)

用於設定此活動是使用那一個Windows Form來呈現資料，請選擇一個Windows的表單名稱，可以按下右方的選取按鈕，選擇回來的格式為DllName.FormName。

WebFormName(Web操作畫面名稱)(string)

用於設定此活動是使用那一個Web的 表單名稱，選擇回來的內容格式應是Web的Aspx名稱，須包含Path。

Parameters(參數)(string)

此參數會透過待辦事項或經辦事項的資料，傳入Win Form或Web Form的Parameters中，這些Parameters很像EEPManager的Menu Utility中所設定的Parameters參數是一樣的，用來令活動與Windows或Web FORM可以互動。


FLReject

【功能說明】

用途：FLReject是Workflow設計中用來終止流程的活動，就是讓此流程終止進行簽核，與人為的作廢是一樣的意思，FLReject在終止流程時會很像FLNotify通知活動類似，發出對應的角色告知終止此流程。

【元件屬性】

Name(名稱)(string)

活動名稱，可以通過對Name的設定，來命名流程的作業名稱，為了讓User更直覺，可輸入中文名稱來命名，單一流程中的活動名稱不能重複。

FormName(操作畫面名稱)(string)

用於設定此活動是使用那一個Windows Form來呈現資料，請選擇一個Windows的表單名稱，可以按下右方的選取按鈕，選擇回來的格式為DllName.FormName。

WebFormName(Web操作畫面名稱)(string)

用於設定此活動是使用那一個Web的表單名稱，選擇回來的內容格式應是Web的Aspx名稱，須包含Path。

FLNavigatorMode(Workflow Navigator狀態)(string)

在終止的狀態下，在此固定為Notify，不能更改，代表僅可執行通知/通知刪除按鈕，其餘不顯示。

NavigatorMode(Navigator狀態)(string)

在終止的狀態下，在此固定為Normal，不能更改，代表所有Navigator的按鈕都不能使用，無法新增/更改/刪除/查詢。

SendToKind(對象類別)(string)

用來設定此活動的終止對象種類，對象種類有Role/RefRole/Manager/RefManager/Applicate等等，如下的說明：

Role：代表對象為一個角色。

RefRole：代表為參考角色，就是根據某個欄位內容做為動態的角色。

AllRoles：代表會發通知給所有簽核過的角色。

Manager：則代表對象為上呈者的主管(根據組織的設定)。

RefManager：與RefRole類似，不同的是RefManager所根據該欄位內容的動態角色去找他的主管，不是動態角色內容本身。

Applicate：則代表最原始的申請者等。

SendToField(參考角色欄位)(string)

參考角色的欄位名稱，如果本活動的角色是動態不固定角色，就是SendToKind為RefReole或RefManager時，那麼就必須使用本屬性來定義其流程主檔的某一欄位，其欄位的內容存放這本作業的角色代號(GroupID)。

SendToRole(對象角色)(string)

當對象類別為角色(Role)時，本屬性則代表活動的對象角色代號，選角色時，只可能選擇到Groups中ISROLE欄位為’Y’的角色資料。

Parameters(參數)(string)

此參數會透過待辦事項或經辦事項的資料，傳入Win Form或Web Form的Parameters中，這些Parameters很像EEPManager的Menu Utility中所設定的Parameters參數是一樣的，用來令活動與Windows或Web FORM可以互動。

ExpTime(作業時限)(decimal)

設定本活動的作業時限，其時限單位定義於TimeUnit屬性中，可以用此來作為該活動作業是否逾時的依據。

UrgentTime(緊急時限)(decimal)

設定本活動的緊急作業時限，其時限單位定義於TimeUnit屬性中，與ExpTime搭配使用，ExpTime代表一般單據的作業時限，UrgentTime則代表緊急單據的作業時限，當然須比ExpTime來得很小。

TimeUnit(時限單位)(enum)

設定時限的單位, 可以為Hour或Day。

SendEmail(發送E-Mail)(bool)

用於確定是否要發送E-Mail，預設值為false，表示無需發送Mail。


FLSequentialWorkflow

【功能說明】

此為EEP Workflow Foundation的基礎類別元件，當新建一個流程時，首先我們需要對這個流程的基本屬性進行一些設定，來設定該流程名稱以及連接資料庫類型等等。

【屬性】

Name(名稱)(string)

該流程的名稱，在此可以不必設定，系統將會以此文件(XOML)為流程的名稱，而XOML檔案我們習慣是使用英文的檔案名稱，因此，如果要在待辦事項中讓USER以中文的名稱來識別流程時，須設定Description屬性中。

Connection Type(連接類型)(string)

本流程系統會使用到幾個系統資料表來進行流程的處理，因此在此需事先定義此資料表的資料庫類型，可以選擇SqlClient/ OracleClient/ OleDB/ ODBC等，預設為SqlClient。

EEPAlias(指定資料庫)(string)

用於選擇一個資料庫名稱，此資料庫名稱定義在EEPNetServer的DB Manager中。

OrgKind(組織代號)(string)

代表本流程所要使用的公司組織代號，系統允許公司有多個組織，依不同的組織來找到不同的角色與不同的作業流程，一般可以在此設定預設的組織，或是可以在User上呈前再來決定公司的組織。預設為公司組織0 (代號為0的公司組織是系統事先預設好的)。

TableName(資料表名稱)(string)

本流程一定要有一個主要的資料表來對應，因此必須在此填入相對的TableName，可以用下拉的方式來選TableName，作為流程的主Table，並注意此Table必須包含一個系統欄位FlowFlag才可以與EEP WF來整合搭配。

Keys(鍵值)(string)

指TableName屬性中的Key Fields，代表該Table的主鍵欄位，在一般情況下，本屬性可以省略不必設定，只有在該流程中有使用到FLDetails這個Activity活動元件時，才須設定此屬性，設定時可以定義多個，中間以’ ; ’隔開即可。

Base(繼承類別)(string)

代表此流程的類別，固定都繼承自 FLTools.FLSequentialWorkflow這個類別，目前無法更改。

Description(流程說明)(string)

流程的說明，一般對User來說，此是真正User所認知的流程名稱，待辦/經辦事項的流程名稱也會是以本屬性為主。

Enable(致能)(bool)

代表此流程是否啟用，請固定設為True。

FormName(操作畫面名稱)(string)

用於設定整個流程是使用那一個Windows Form來呈現資料，請選擇一個Windows的表單名稱，可以按下右方的選取按鈕，選擇回來的格式為 DllName.FormName。當流程內的Activity沒有設定 FormName時, 會以此設定的FormName為主，這樣就可以不必每個Activity都須設定FormName。

WebFormName(Web操作畫面名稱)(string)

用於設定整個流程是使用那一個Web的表單名稱，選擇回來的內容格式應是Web的Aspx名稱，須包含Path。當流程內的Activity沒有設定 WebFormName時，會以此設定的WebFormName為主，這樣就可以不必每個Activity都須設定WebFormName。


FLStand

【功能說明】

用途：FLStand是Workflow設計中的標準簽核活動元件，為最常用也是最基礎的Workflow活動元件之一。

【元件屬性】

Name(名稱)(string)

活動名稱，可以通過對Name的設定，來命名流程的作業名稱，為了讓User更直覺，可輸入中文名稱來讓User更為直覺，注意！單一流程中的活動名稱不能重複。

FormName(操作畫面名稱)(string)

用於設定此活動是使用那一個Windows Form來呈現資料，請選擇一個Windows的表單名稱，可以按下右方的選取按鈕，選擇回來的格式為DllName.FormName。

WebFormName(Web操作畫面名稱)(string)

用於設定此活動是使用那一個Web的表單名稱，選擇回來的內容格式應是Web的Aspx名稱，須包含Path。

NavigatorMode(Navigator狀態)(string)

設定打開FormName或WebFormName指定的表單後，要控制其Navigator的進入的狀態，因為流程表單被打開後，就無法像之前的表單打開一樣，可以讓User任意新增/更改/刪除/查詢資料等等，在流程中操作表單，必須控制Navigator只能操作某些動作，不是任意可以讓User操作。本模式共有下列幾種：

Normal：全部Disable，所有Navigator的功能都不能使用，無法新增/更改/刪除/查詢，應用於審核過程中都不能更改資料。Insert：只有新增可以執行，其餘都不能使用，無法更改/刪除/查詢，此模式用於流程的第一個活動作業，專門用來新增申請單所使用。

Modify：只有更改可以執行，其餘都不能使用，無法更改/刪除/查詢，此用來審核過程中，還可以對表單進行修改。

Inquery：僅可以查詢資料，其餘的功能都不能使用。使用於歷史單據的資料查詢，禁止User去更改已經審核的資料，所以新增/更改/刪除都無法使用。

Prepare：與Inquery相似，差別的是在查詢到資料後，是可以讓User進行修改資料的，此模式用來處理資料變更申請，或刪除作廢或跨流程的申請所使用。

FLNavigatorMode(Workflow Navigator狀態)(string)

此與NavigatorMode很類似，但此用來控制FLNavigator流程按鈕的狀態，因為表單我們改貼了FLNavigator後，會多了幾個流程按鈕，因此透過此流程活動的屬性，來控制此FLNavigator那些流程按鈕可以執行，那些則要隱藏等等。我們將Mode模式分列如下：

Submit：僅上呈/暫停/通知按鈕可以執行，其餘不顯示，此用在第一個活動的申請上呈中來使用。

Approve：僅審核/退回/通知按鈕可以執行，其餘不顯示，用在主管審核的活動中。

Return：僅上呈/暫停/通知/作廢按鈕可以執行，其餘不顯示，用在第一個活動的取回動作(上呈後自行取回)或被主管退回時使用，此模式不必設定，系統會自行決定此模式。

Notify：僅通知/通知刪除按鈕可以執行，其餘不顯示，專用於通知的活動。

Inquery：除了簽核批示(Comment按鈕)可以執行外，其他都不顯示，專用於查詢該單據的整個簽核中的歷程與所有批示。

Continue：僅上呈/通知按鈕可以執行，其餘不顯示，專用於印表或確認的活動作業中來使用。

SendToKind(對象類別)(string)

用來設定此活動的對象種類，對象種類有Role/RefRole/Manager/RefManager/Applicate等等，如下的說明：

Role：代表對象為一個角色。

RefRole：代表為參考角色，就是根據某個欄位內容做為動態的角色。

Manager：則代表對象為上呈者的主管(根據組織的設定)。

RefManager：與RefRole類似，不同的是RefManager所根據該欄位內容的動態角色去找他的主管，不是動態角色內容本身。

Applicate：則代表最原始的申請者等，如果是流程的第一個活動作業，請設為Applicate。

SendToField(參考角色欄位)(string)

參考角色的欄位名稱，如果本活動的角色是動態不固定角色，就是SendToKind為RefReole或RefManager時，那麼就必須使用本屬性來定義其流程主檔的某一欄位，其欄位的內容存放這本作業的角色代號(GroupID)。

SendToRole(對象角色)(string)

當對象類別為角色(Role)時，本屬性則代表活動的對象角色代號，選角色時，只可能選擇到Groups中ISROLE欄位為’Y’的角色資料。

Parameters(參數)(string)

此參數會透過待辦事項或經辦事項的資料，傳入Win Form或Web Form的Parameters中，這些Parameters很像EEPManager的Menu Utility中所設定的Parameters參數是一樣的，用來令活動與Windows或Web FORM可以互動。

ExpTime(作業時限)(decimal)

設定本活動的作業時限，其時限單位定義於TimeUnit屬性中，可以用此來作為該活動作業是否逾時的依據。

UrgentTime(緊急時限)(decimal)

設定本活動的緊急作業時限，其時限單位定義於TimeUnit屬性中，與ExpTime搭配使用，ExpTime代表一般單據的作業時限，UrgentTime則代表緊急單據的作業時限，當然須比ExpTime來得很小。

TimeUnit(時限單位)(enum)

設定時限的單位，可以為Hour或Day。

PlusApprove(加簽)(bool)

用於設定是否可以加簽，預設為False，代表無需加簽，加簽的動作是由該活動的簽核者來決定是否加簽給其他主管或參與者，可以同時加簽給多個角色，所有參與者加簽後，又會回到自己本身，再決定往下呈送或退回。

SendEmail(發送E-Mail)(bool)

是否在流程引擎送給本活動接收者的同時，發送出Email來通知該接收者連結到該活動作業並進行簽核，此功能需配合EEPNetServer的Workflow Config設定與Users中的Email帳後設定才會生效。預設為False代表不發送。

DelayAutoApprove(逾時自動簽核)(bool)

設定是否進行逾時自動簽核，當DelayAutoApprove=True時, 如果此活動發生了逾時狀況時，就可以透過Scheduling排程系統來自動讓這些逾時的待辦可以自動往下審核，來解決非要處理不可的單據。Scheduling的排程請設定為FLRuntime這個Dll中的Approve2()這個Server Method即可。


FLSubFlow

【功能說明】

用途：FLSubFlow是專門用來整合另一個子流程的活動元件，就是可以整合另一個流程到此流程來，除了可以縮小流程的篇幅外，另一個目的就是可以讓子流程也可以自行獨立運作，不必依賴主流程來運作。

【元件屬性】

Name(名稱)(string)

活動名稱，可以通過對Name的設定，來命名流程的作業名稱，為了讓User更直覺，可輸入中文名稱來命名，單一流程中的活動名稱不能重複。

Description(活動說明)(string)

活動的說明，用來備註或說明此程序的用途，供其他開發者了解。

IncludeFirstActivity(包含第一個活動)(bool)

在整合複製了指定的子流程進來時,此屬性可以控制是否包含對方的第一個Activity，預設為False,此目的是為了讓此SubFlow也可以為獨立的流程，因為允許獨立所以第一個Activity通常是Insert/Submit的模式，因此在整合SubFlow後的流程是無需包括這個Insert/Submit的Activity的。

XomlName(子流程Xoml文件名稱)(string)

用於設定子流程的XomlName文件名稱，通過右側的按鈕可在視窗中找到Xoml文件。


FLValidate

【功能說明】

用途：FLValidate是在Workflow流程中專門用來檢核資料所使用的活動元件，可以設定一個稽核條件，條件通過則往下流動，不通過則自動退回，用來強迫檢查單據的資料是否滿足流程的規定。

【元件屬性】

Name(名稱)(string)

稽核條件活動名稱，可以通過對Name的設定，來命名活動名稱，可輸入中文條件意義來命名，好讓User更直覺，單一流程中的活動名稱不能重複。

Description(活動說明)(string)

稽核條件活動的說明，僅用來備註或說明此條件的用途。

Expression(檢核條件)(string)

用來設定流程表單中的資料檢核條件，可以使用流程資料表的欄位來做為條件，也可以用 ServerDll.ServerMethod()方式來呼叫Server Method，以此ServerMethod傳回True/False來決定是否退回該流程，Expression的格式說明請參考附錄E。


IfElseActivity

【功能說明】

用途：IfElseActivity是用來設計Workflow中的條件式判斷，根據條件要走向那一個流程分支，可以同時設定多個條件多個分支。

【元件屬性】

Name(名稱)(string)

條件活動名稱，可以通過對Name的設定，來命名活動名稱，可輸入中文條件意義來命名，好讓User更直覺，單一流程中的活動名稱不能重複。

Description(活動說明)(string)

僅用來讓開發者備註與說明，與User無關。

Enable(致能)(bool)

表明此活動是否可操作，請固定設為True。

【補充說明】

對於IfElseActivity活動元件的條件式設定，我們可以通過對其下的ifElseBranchActivity(分支條件)來設定，並可以在IfElseActivity按右鍵來新增多個ifElseBranchActivity分支條件，ifElseBranchActivity的屬性說明如下：

ifElseBranchActivity

【屬性】

Name(名稱)(string)

分支條件活動名稱，可以通過對Name的設定，來命名活動名稱，可輸入中文條件意義來命名，好讓User更直覺，單一流程中的活動名稱不能重複。

Description(活動說明)(string)

活動的分支條件，將條件的判斷表達式寫入該屬性中，可以直接使用流程表單的欄位作為表達式的條件，表達式請參考附錄E，Expression格式說明。

如果有多個ifElseBranchActivity時，可以允許一個沒設定Description的分支條件，代表為如果沒有滿足其他分支條件時，就執行該分支(Else的意思)，所以只有兩個分支的ifElseActivity，可以只設定一個ifElseBranchActivity即可。


ParallelActivity

【功能說明】

用途：ParallelActivity是專門用來設計Workflow的平行會簽活動元件，可以同時發出給多個角色一起會簽，並整合意見。

【元件屬性】

Name(名稱)(string)

平行會簽活動名稱，可以通過對Name的設定，來命名活動名稱，可輸入中文條件意義來命名，好讓User更直覺，單一流程中的活動名稱不能重複。

Description(活動說明)(string)

此有特殊的用途，不是一般的備註與說明，是用來設定是否為平行會簽或平行單一簽核，設為「AND」代表為會簽，設為「OR」代表為單一簽核，也可以使用「RATE：」的方式來決定會簽的通過比率，如下：

Description空白：代表AND, 需100%才能通過，每個子流程都須通過。

Description輸入AND：同上，需100%。

Description輸入OR：代表只要有一個子流程通過就通過。

Description輸入RATE： 須依比率才能通過，超過或等於此RATE才能通過，如"RATE:50"代表需過半數的人通過才會通過(>=50%)。

在平行的分支，可以透過ParallelActivity活動元件的右鍵來增加或減少其分支數量，其下所產生的分支sequenceActivity則可以不必設定，只要在sequenceActivity下方拖入希望會簽的其他Activity活動元件即可。


AppendixC

Appendix C WorkFlow系統資料表結構說明

Table_Name | Column_Name | Description
Group; (角色，用於存放類別或角色基本資料，用來存放GROUP訊息。) | GROUPID | 組織或角色編號
 | GROUPNAME | 組織或角色名稱
 | DESCRIPTION | 描述
 | MSAD | 是否使用Domain
 | ISROLE | 是否為角色，‘Y’表示參加角色
Primary Key：GROUPID

Table_Name |  | Column_Name |  | Description
SYS_ORG; (組織基本資料，用來存放公司組織的訊息，用UPPER_ORG可以構成一個樹狀的結構的組織。) |  | ORG_NO |  | 組織代碼
 |  | ORG_DESC |  | 組織名稱
 |  | ORG_KIND |  | 組織類別，對應到SYS_ ORGKIND預設為’0’代表公司組織，組織可以有多個
 |  | UPPER_ORG |  | 上層組織
 |  | ORG_MAN |  | 組織主管，主管角色代號(GroupID)，對應到GROUPS欄位ISROLE=’Y’的資料
 |  | LEVEL_NO |  | 主管層級，對應到SYS_ ORG LEVEL
 |  | ORG_TREE |  | 組織樹，暫沒有使用
 |  | END_ORG |  | 最底層組織，暫沒有使用
 |  | ORG_FULLNAME |  | 組織全名，暫沒有使用
Primary Key：ORG_NO
 | Table_Name |  | Column_Name |  | Description
 | SYS_ORGKIND; (組織基本資料，用來存放公司組織的訊息，依照公司的組織情形建立資料。) |  | ORG_KIND |  | 組織類別代號，公司組織的類別，至少要有一筆’0’代表公司組織
 |  |  | KIND_DESC |  | 組織類別名稱
 | Primary Key：ORG_KIND

Table_Name | Column_Name | Description
SYS_ ORGLEVEL; (公司的職務級別，用來定義組織中各主管的級別，在Flow中用在辨別核決的權限與等級。) | LEVEL_NO | 職級編號
 | LEVEL_DESC | 組織類別名稱
Primary Key：LEVEL_NO

Table_Name | Column_Name | Description
SYS_ ORGROLES; (某個組織下的所有成員明細，內容為角色代號。) | ORG_NO | 組織編號，對應到SYS_ORG
 | ROLE_ID | 角色代碼，對應到GROUPS欄位ISROLE=’Y’的資料
 | ORG_KIND | 組織類型，預設為’0’，從SYS_ ORG中帶下來
Primary Key：ORG_NO,ROLE_NO

Table_Name | Column_Name | Description
SYS_ROLES_AGENT; (定義某個角色的代理人) | ROLE_ID | 角色代碼，對應GROUPS欄位ISROLE=’Y’的資料
 | AGENT | 代理人，對應USERS的USERID欄位
 | FLOW_DESC | 流程名稱，此代理定義可以指定某些流程來代理，如果沒指定代表所有流程皆代理
 | START_DATE | 開始日期
 | START_TIME | 開始時間
 | END_DATE | 結束日期
 | END_TIME | 結束時間
 | PAR_AGENT | 平行代理人，‘Y’為平行代理人，‘N’為一般代理人
 | REMARK | 說明
Primary Key：ROLE_ID,AGENT

Table_Name | Column_Name | Description
SYS_ TODOHIS; (存放所有簽核的歷史記錄) | LISTID | 待辦事項唯一序號，會自動編號，因為一個流程的經辦可能有多筆，所以可以允許重複，此序號來自SYS_ FLINSTANCESTATE的FLInstanceId。
 | FLOW_ID | 流程代號，根據WorkFlow引擎所產生的流程為依序號，用來與Workflow Foundation溝通時使用，此序號來自SYS_FLDEFINITION的FLTypeId欄位
 | FLOW_DESC | 流程名稱，來自到WorkFlow的XOML的Description屬性的定義
 | ROLE_ID | 角色代碼，經辦人(記錄角色代碼，GroupID)
 | S_ROLE_ID | 上一活動的發送者
 | S_STEP_ID | 上一活動的元件名稱
 | D_STEP_ID | 下一活動的元件名稱
 | S_STEP_DESC | 上一個活動說明
 | S_USER_ID | 上一活動的發送者角色
 | USER_ID | 簽核者的使用者代碼
 | USERNAME | 簽核者使用者名稱
 | FORM_NAME | 對應的Windows表單名稱
 | WEBFORM_NAME | 對應的Web表單名稱
 | S_USERNAME | 上一活動發送者的使用者
 | NAVIGATOR_MODE | 目前活動的Navigator的控制模式
 | FLNAVIGATOR_MODE | 目前活動的流程FLNavigator的控制模式
 | PARAMETERS | 目前活動要傳入表單的的控制參數
 | STATUS | 單據狀態
 | PROC_TIME | 簽核處理所花費的時間
 | EXP_TIME | 一般單據作業時限
 | URGENT_TIME | 緊急單據作業時限
 | TIME_UNIT | 時間單位，指EXP_TIME語URGENT_TIME的時間單位
 | FLOWIMPORTANT | 重要待辦(Y/N)
 | FLOWURGENT | 緊急待辦(Y/N)
 | FORM_TABLE | 待辦的資料表
 | FORM_KEYS | 待辦資料的鍵值欄位
 | FORM_PRESENTATION | 資料的鍵值欄位與其鍵值內容
 | REMARK | 簽核意見
 | VERSION | 待辦的版本號碼
 | VDSNAME | 暫沒有使用
 | SENDBACKSTEP | 退回的指定活動元件名稱
 | LEVEL_NO | 簽核主管的層級
 | UPDATE_DATE | 簽核日期
 | UPDATE_TIME | 簽核時間
 | FORM_PRESENT_CT | 資料的鍵值欄位的DD中的定義與其鍵值內容
Primary Key：LIST_ID

Table_Name | Column_Name | Description
SYS_ TODOLIST; (存放目前待簽核的單據) | LISTID | 待辦事項唯一序號，會自動編號，因為一個流程的待辦可能有多筆，所以可以允許重複，此序號來自SYS_ FLINSTANCESTATE的FLInstanceId
 | FLOW_ID | 流程代號，根據WorkFlow引擎所產生的流程為依序號，用來與Workflow Foundation溝通時使用，此序號來自SYS_FLDEFINITION的FLTypeId欄位
 | FLOW_DESC | 流程名稱，來自到WorkFlow的XOML的Description屬性的定義
 | APPLICANT | 原始申請人的使用者代號
 | S_USER_ID | 上一活動的發送者
 | S_STEP_ID | 上一活動的活動元件名稱
 | S_STEP_DESC | 上一活動的說明
 | D_STEP_ID | 下一活動的活動元件名稱
 | D_STEP_DESC | 下一活動的說明
 | EXP_TIME | 一般單據作業時限
 | URGENT_TIME | 緊急單據作業時限
 | TIME_UNIT | 時限時間單位
 | USERNAME | 發送者的姓名
 | FORM_NAME | 目前活動單據的表單
 | NAVIGATOR_MODE | 目前活動的資料Navigator的控制模式
 | FLNAVIGATOR_MODE | 目前活動的流程FLNavigator的控制模式
 | PARAMETERS | 目前活動傳入表單中的控制參數，流程參數定義在每個Activity活動元件中
 | SENDTO_KIND | 待辦者的類別，為‘1’代表角色(GroupID)，或’2’代表UserID
 | SENDTO_ID | 待辦角色代號，對方的GroupID或UserID(如果SENDTO_KIND=’2’)
 | FLOWIMPORTANT | 重要待辦(Y/N)
 | FLOWURGENT | 緊急待辦(Y/N)
 | STATUS | 待辦的狀態，‘N’代表是新建的流程，’F’代表是通知的流程，’Z’代表已結案
 | FORM_TABLE | 待辦的資料表Table名稱
 | FORM_KEYS | 待辦資料的鍵值欄位
 | FORM_PRESENTATION | 待辦資料的鍵值欄位與其鍵值內容
 | FORM_PRESENT_CT | 鍵值內容表示方式，會加上資料字典的欄位翻譯，好讓User可以看懂
 | REMARK | 批示意見內容
 | PROVIDER_NAME | 指Server端相對的資料供應者(DLL的模組名稱)
 | VERSION | 待辦的版本號碼
 | EMAIL_ADD | 待辦者(D_USER_ID)的E-Mail地址
 | EMAIL_STATUS | E-Mail發送狀態，’Y’代表已發送成功
 | VDSNAME | 暫沒有使用
 | SENDBACKSTEP | 退回的指定活動名稱
 | LEVEL_NO | 簽核的主管層級
 | WEBFORM_NAME | 目前活動的Web表單名稱
 | UPDATE_DATE | 呈送日期
 | UPDATE_TIME | 呈送時間
 | FLOWPATH | 當前完成的流程深度，此為系統內部使用
 | PLUSAPPROVE | 是否加簽(Y/N)
 | PLUSROLES | 加簽後的對方角色代號
 | MULTISTEPRETURN | 是否可以退回(Y/N)，由系統內部自行控制
 | SENDTO_NAME | 待辦者的用戶名稱
Primary Key：LIST_ID

Table_Name | Column_Name | Description
SYS_FLDEFINITION; (存放Work Flow所有版本的訊息。) | FLTypeId | 流程XOML唯一編號，系統會自動編號，系統會將此編號紀錄在SYS_TODOLIST資料表中
 | FLTypeName | Work Flow的類型名稱(Class Name)
 | FLDefinition | Work Flow該版本的xml內容，保留在此欄位中
 | Version | Work Flow版本號碼
Primary Key：FLTypeId

Table_Name | Column_Name | Description
SYS_ FLINSTANCESTATE; (存放目前在流程引擎正在處理的單據，處理完畢也會留存在此表當中。) | FLInstanceId | Work Flow Foundation在備申請一個單據時，會建立一個實例，系統會自動建立編號，並記錄在SYS_TODOLIST中。
 | State | 目前流程引擎中最新的處理狀態，記錄該實例的當前流程狀態。
 | Status | 流程狀態，目前皆為0
 | Info | 暫沒有使用
Primary Key：FLInstanceId


AppendixD

Appendix D WorkFlow系統檔案說明

在WorkFlow基本架構下發展而來的EEP2006 WF設計系統，在它正常運行的過程當中，需要一些系統檔案的支持。本章節下面的內容主要介紹WorkFlow所要用到的一些系統文件。

檔案名稱 | 說明與功用 | 存在路徑 | 備註
System.Workflow.Activities.dll | 定義可以加入至工作流程的活動，以建立並執行工作處理依序的可執行檔表示。 | 在Program Files\Reference Assemblies\Microsoft\Framework\v3.0之下 | 安裝Workflow後產生，只需在設計Web站點時，自行加入引用即可。
System.Workflow.ComponentModel.dll | 提供了基本的Classes，介面，以及核心模型結構供開發者使用。 | 同上 | 同上
System.Workflow.Runtime | 為Microsoft Workflow Foundation的執行引擎。 | 同上 | 同上
Microsoft.Workflow.Extension.dll | 為Microsoft Workflow Foundation的擴展引擎。 | 安裝路徑\InfoLight\EEP2 008\EEPNetServer | 隨著EEP2006或EEP2008的安裝目錄。
FLTools.dll | 為EEP所提供常用的工作流程活動元件，可以很快速與EEP表單結合，達到簽核的目的，開發者也可以自行繼承或新增自已的流程活動元件，此模組中有部分使屬於U/I的元件，使用在Web或Windows的Client中為了配合流程簽核的操作所使用，並不是所有的元件都是屬於Acitivity。 | 安裝路徑\InfoLight\EEP2 008\EEPNetServer | 隨著EEP2006或EEP2008的安裝目錄。
FLRunTime.dll | 用來實際執行每個工作流程實例，與控制整個執行時期的狀態，他會交給微軟的WF Engine來執行，以增加流程的可靠度與穩定度，另外，此RunTime引擎中有特別去支援Sequential依序的活動可以被逆流退回。 | 安裝路徑\InfoLight\EEP2 006\EEPNetServer | 同上
FLCore.dll | 為EEP的基本類型與基本相互溝通的核心程式庫，用來溝通FLTools的元件與FLRunTime以及FLDesigner所共同的元件類型與程式接口。 | 安裝路徑\InfoLight\EEP2 006\EEPNetServer | 同上


AppendixE

Appendix E WorkFlow Expresssion格式說明

在WorkFlow Activity設計中，部分的Activity元件可以設定一些條件判斷式，這些條件的運算式可決定流程的流動方向或者用來判斷是否成立等等，我們將這些Expression的規則定義如下，供大家參考：

A. 字符串類型

字符串類型(包括日期類型)的欄位在WorkFlow的運算式可以寫成：『Column Name』+『Operator』+ ”『value』”，注意Valuse也可以是另一個欄位，此時Value請不要使用雙引號，下面介紹不同的Operator(運算元)的作用：

運算元 | 含義 | 說明
= | like查詢 | ColumnName= ”value” 表示為『Column Name』like ‘value%’的意思，如：; Addresss=”台北市”，代表地址為”台北”開頭
== | 等於 | Column Name== ”value” 表示為『Column Name』等於value; 注意：當表達式表示為Column Name== ””時，代表欄位是否為空，如：; UserCode==”A03”，代表UserCode是否為”A03”; Grade==””，代表Grade為空時; Address1==Address2，代表Address1是否等於Address2
!= | 不等於 | Column Name!= ”value” 表示為『Column Name』不等於value的意思，注意！當表達式表示為Column Name!= ””時，代表欄位是否不為空白，如：; UserName!=””，代表UserName是否不為空白; Unit!=”天”，代表Unit是否不為”天”的單位
>= | 大於等於 | 如：; CreateDate>=”2007-01-01”代表CreateDate是否大於等於2007年01月01日，注意日期的格式須遵照我們的格式
<= | 小於等於 | 如：; OrderDate<=”2008-04-30”代表OrderDate是否小於等於2008年04月30日; OrderDate<=CreateDate，代表OrderDate是否小於CreateDate
> | 大於 | 如：; Grade>’A’，Grade是否大於’A’
< | 小於 | 如：; Style<’4’，Style小於’4’; OrderDate<=CreateDate，代表OrderDate是否小於CreateDate

B. 數值類型

當在運算式中欄位類型為數值類型時，也是與字串相似的，差別的是將『value』前後的引號去除即可。表達方式為：『Column Name』+『Operator』+ 『value』，下面介紹不同的Operator(運算元)的作用：

運算元 | 含義 | 說明
= | 等於 | Column Name= Value表示為『Column Name』是否等於Value，如：; Term=3，代表Term是否等於3
>= | 大於等於 | Column Name>=Value表示為『Column Name』是否大於等於Value，如：; TotalAmt>=5000，代表TotalAmt是否等於5000
<= | 小於等於 | Column Name<=Value表示為『Column Name』是否小於等於Value，如：; UnitPrice<=10000，代表TotalAmt是否小於等於10000
> | 大於 | 如：; Days>3，代表Days是否大於3天
< | 小於 | 如：; OrderAmount<3000，代表OrderAmount是否小於3000
!= | 不等於 | 如：; UnitPrice!=0，代表UnitPrice是否不等於0

簡易AND與OR的處理：

Expression支援簡易的 && (AND)與 || (OR)處理，如下：

OrderAmount>=3000 && Level>”3”

OrderDate>=”2008-06-01” || OrderAmount>=5000

Server Method的Validate處理：

可以透過Server Method的方式來處理Validate，如下的格式：

ServerModuleDllName.ServerMethodName()

ServerModuleDllName代表Server端的DLL模組名稱。

ServerMethodName代表Server Method的名稱，注意需在ServiceManager的ServiceCollection去設定此ServerMethod，否則無法被呼叫。

範例如下：

在Expression這樣設定： SOrders.CheckServer()

public object[] CheckServer(object[] objParam)

{

object[] ret= new object[] { 0,0};

DataRow dr=(DataRow) objParam[0]; //取得流程資料表的欄位明細

if ( Convert.ToInt16(dr["TotalAmt"]) >= 1000) //對TotalAmt做比較

{

ret[1] = true; // 成功傳回True (只能傳回True/False)

}

else

{

ret[1] = false; // 否則傳回False

}

return ret;

}