Sharepoint

在企業內收集資料的好方法

Keith Deshaies

摘要:

• 收集和處理資料
• 區隔展示邏輯與資訊管理邏輯
• 使用 Microsoft Office 2007 技術來建造資料收集解決方案

下載本文程式碼: DataGathering2008_02.exe (567KB)

企業採用各式各樣的方法來收集大量的資訊。資料透過電子郵件、問卷、網路表單和其他資料收集機制接踵而至。有資料，通常

是好事。不過，管理一系列資料收集工具，以及各種不同的資訊並不容易。可靠的整合和安全分享資料是 IT 組織經常面臨的挑戰。各項標準和服務導向架構的不斷發展，方便 IT 專業人員讓資料更容易存取，也更安全。雖然您擁有所需的工具和技術來建置一套有效的企業架構，但卻常常受限於專有的介面 — 而這往往會使解決方案孤立無援。

舉 Microsoft® Office System 中提供的技術為例。您可以根據 Windows® SharePoint® Services 3.0 迅速建立部門問卷，但這是否是標準的解決方案，得看貴組織而定。 如果貴公司使用 ASP.NET 和 SharePoint 作為進行網路共同作業和資料整合的平台，那麼此問卷的確能提供標準的解決方案。但若是您的環境跟我使用的一樣，SharePoint 只不過是許多平台當中的一個。

沒錯，SharePoint 提供與 IBM、HP、Siebel 等系統整合的許多選項。這對於想要建立臨機操作解決方案，卻仍然希望資料結果流向各類後端系統的進階使用者來說，無非是個好消息。不過，如果您是解決方案架構設計師，甚至還有更棒的選擇 — InfoPath® 2007。

透過 InfoPath 2007 (它是 2007 Office System 的一部分)，您可以將解決方案的展示邏輯與伺服器上裝載的資訊管理邏輯相區隔。藉著 XML 架構的 InfoPath 技術，您便能建立適合企業使用的資料收集解決方案。而且，InfoPath 表單設計人員通常不用精通 XML、Web 服務、解決方案架構、ASP.NET，或是 SharePoint 物件模型。

在本文中，我將探討您要如何使用 InfoPath 2007、Office SharePoint Server 2007 和 Forms Services 來建置具彈性的資料收集解決方案。而且我還會向您說明 XML 如何讓您在多層式的企業架構中區隔展示邏輯與商務邏輯。

請注意，我所謂的「資料收集」是指以人為對象收集資訊的過程。收集資料當然還有其他方法，像是為資料來源編目，但是那些自動化的方法已超出本文討論範圍。

取得和處理資料

資料取得的需求可能很複雜，但是這些程序有一些共同的特色。以集中模組處理這些相似特性，同時以分散元件來滿足獨特需求，便能避免投入多餘的心力，並減少額外的維護負荷和擁有權總成本。

比方說，上市公司所遵循的規範會產生商務需求，進而轉化成全公司的資訊管理原則。這些原則會影響跨部門界限的資料收集解決方案，而且往往會導致個別的部門進行重複工作 — 例如，人事部門 (處理員工資訊) 和客服部門 (處理客戶資訊) 收集個人識別資訊的相關規則。即使是個別部門間類似卻不相關的商務處理流程，也會製造統合資訊管理解決方案的機會。

[圖 1] 顯示典型商務處理流程的範例。若員工想要與同事交換工作分派，他必須取得同事的同意，然後依序獲得經理或工作分派排程協調員，最後獲得監督員的核准。例如，這可能包括員工交換值班。雖然這些交換動作是發生在不同的部門，而且也可能仰賴不同的形式，可是工作流程和資訊管理邏輯也許可以在不同的部門解決方案之間共用。

[圖 1]** 可在部門間共用的資料收集程序範例 **(按影像可放大)

不用說，整合冗餘元件的工程浩大。在公司內推動組織方面的變革並不容易，但是透過 Office System 技術，您便能建置堅固的基礎來促進這些改變。InfoPath 2007 可讓個別的部門建立表單應用程式，與集中化、標準化的資訊管理系統整合。同時 SharePoint 2007 則可讓 IT 部門將網站集合、網站和文件庫的系統管理控制權，委派給個別的部門和小組。這樣一來，小組不太需要 IT 的參與，就可以建置和部署他們自己的解決方案，而由 IT 部門繼續控制所有共用的服務和元件，例如工作流程、資訊管理原則和備份程序等。

集中進行資料收集

企業經常提供小組部門應用程式伺服器，以配合個別的資訊管理需要。IT 部門的責任只限於確保硬體和作業系統能順利運作，而解決方案的其他層面則須由個別部門自行負責。部門之間缺乏足夠的協調，使得資訊的共用難以成行。

集中進行資料收集的技術挑戰，主要是出在安全性、效能、維護和支援共用環境中裝載的自訂元件上。舉例來說，如果個別的解決方案是裝載在部門的應用程式伺服器上，就可以將運作失常的元件所產生的衝擊加以隔離。然而在共用的環境中，運作失常的元件可能會大規模地影響商務處理流程。IT 部門緊接著便得針對在集中式系統上部署和維護自訂元件，建立嚴格的原則。

要在中央伺服陣列上裝載部門的 SharePoint 解決方案，您必須在中央應用程式伺服器上部署和維護這些部門解決方案的所有自訂元件。其中一套解決方案可能有賴自訂欄位類型，以後端 Web 服務所填入的下拉式清單來擴充解決方案的 UI。另一套解決方案針對相同的目的，可能是依賴網頁組件，而其他解決方案可能是使用自訂工作流程 — 這些全都寫在 Managed 程式碼中，而且部署成 Microsoft .NET Framework 組件。

即使是移動極少數的 SharePoint 解決方案到中央應用程式伺服陣列，也可能導致艱難的設定和支援問題。如果組件必須部署在全域組件快取 (GAC) 的話，更會因為這些組件是以完全信任的權限來執行而出現安全性問題。設計不良的元件可能會敞開系統的大門引發 SQL 插入式攻擊、跨站台指令碼處理，或是拒絕服務等攻擊。您必須確保各個元件不但能支撐一般的工作負載，也能應付尖峰的需要和長時間執行的作業。您必須確保各個元件不會封鎖其他處理序，同步處理事件，而且元件可執行可靠的輸入驗證 — 以免使用者將 SQL 陳述式或指令碼插入用來更新資料庫或遠端 Web 系統的資料行。

簡而言之，目的是要強調以標準產品功能為基礎的伺服器設定既安全又可擴充。憑藉著可重複使用、經過徹底測試的解決方案，您便能免於陷入必須建立無數自訂元件的困境。這解釋了為什麼要讓前端保持分散，而後端保持集中。關鍵是要以鬆散的連結方式來整合元件，以便促進現有解決方案的重複使用效益。

分割商務邏輯

那麼您要如何建置富於彈性且能夠在伺服器上設定的資料收集解決方案呢？最佳的策略是將解決方案架構劃分成各個不同的階層，如 [圖 2]：資料存放、商務邏輯和展示或 UI。現在的 UI 一般是以瀏覽器為主，而商務邏輯則是存在 Web 應用程式伺服器上。這些會轉而存取資料庫和非關聯式資料儲存機制。

[圖 2]** 以三層式架構為基礎建置的典型企業解決方案 **(按影像可放大)

商務邏輯通常包含交易邏輯，確保交易是以不可分割的方式套用到各個資料庫管理系統。商務邏輯也可透過 HTTP、訊息佇列、RPC 等等與多個中間層服務相整合。然而，解決方案的整體架構基本上會保持三層式模型。

[圖 2] 並沒有顯示出商務邏輯在企業環境中的複雜性。此圖中的應用程式伺服器看起來只著重於產生以瀏覽器為主的表單和處理提交的資料，但當中並沒有將工作流程、循規或資訊管理需求列入考慮。若要解決這些需求，您必須將商務邏輯一分為二：展示邏輯和資訊管理邏輯。這樣您就可以在必要時混搭中間層元件，而不需要為每個解決方案從頭重建各個元件。

[圖 3] 說明了此架構，最核心是內容或資料，外圍是資訊管理邏輯，掌管著整個生命週期的內容。展示邏輯介面與資訊管理邏輯則透過使用者介面提供對資料的存取。

[圖 3]** 將展示邏輯與資訊管理邏輯加以分隔 **

收集和處理 XML

在服務導向的應用程式 (SOA) 環境中，XML 是用來定義和共用元件間的資料和資料結構的主要標準。因此 XML 非常適合作為展示和資訊管理元件之間的介面。

通訊必須雙向進行：您必須將 XML 轉譯成瀏覽器可讀取的文件，也必須轉譯表單產生的 XML 文件。直至最近，建置 XML 架構的表單應用程式都需要相當熟練的程式設計技能。尤其當產生的 XML 資料必須符合業界結構描述，以利在組織間進行資料交換時更是如此。

InfoPath 2007 使得開發 XMl 架構表單的工作更加簡單。詳悉 XML 當然有幫助，但是表單設計人員和進階使用者不必是 XML 專家，也可以建置 XML 架構的表單應用程式。表單設計人員只需要將 XML 文件或 XML 結構描述匯入 InfoPath，然後將來自該資料來源的個別屬性和元素節點對應到表單中的欄位就行了。表單設計人員也可以從 Web 服務或 SQL Server® 資料庫著手，或是使用空白的範本，然後從頭建置表單，然後讓 InfoPath 在背景自動建立基本的結構描述和資料繫結。

使用 InfoPath 和 XML 結構描述的標準化表單有幾項優點。如果您已經有一個定義完善的 XML 結構描述，表單設計人員和工作流程與資訊管理元件的開發人員就可以比照相同的資料結構來建立解決方案。如果表單設計人員從頭開始進行，開發人員就必須等待表單完成後，才能觀察它對基礎資料結構有何影響。資料結構一經定義之後，如果未來的解決方案 (例如新表單範本) 也是仰賴相同的資料結構，就可以重複使用現有的工作流程和資訊管理元件。而未來的工作流程和資訊管理元件便可與現有的表單和資料搭配運作。如果您是根據既定的業界結構描述來建置資料收集解決方案，結果甚至將更具彈性。事實上，這些解決方案將與其他使用相同結構描述的公司所建置的解決方案相容。

我建立了一個簡單的 DirectReports 結構描述，使員工與經理產生關聯。經理可以使用產生的表單來評估他們的部屬。在本文所附的下載中的 [Direct Reports] 資料夾內，您可以找到結構描述、表單和內含指示的 readme.htm 來重建此表單，下載網址是 technetmagazine.com/code08.aspx。表單很基本，但它為我們說明了一般的概念。

在這裡有一點很重要：我並沒有在 InfoPath 中建立任何驗證邏輯，但 InfoPath 仍要求以特定的格式 (網域\帳戶，和 recipient@domain.tld) 輸入使用者識別碼和電子郵件地址。若沒有這個動作，所得的 XML 文件將會無效。這是因為 XML 結構描述已定義這些格式。您可以儲存含無效資料的表單，但是您將無法提交它，如 [圖 4] 所示 (我在表單加入了一條虛擬的提交規則，供您進行測試而不用實際將資料提交到任何位置)。InfoPath 2007 驗證作業會自動確保表單已完整填寫，而且沒有這類錯誤。

[圖 4a]** 驗證錯誤阻止使用者提交表單 **(按影像可放大)

[圖 4b]** 產生的錯誤訊息 **(按影像可放大)

XML 結構描述的作用是扮演展示邏輯與資訊管理邏輯的有效合約。InfoPath 會鎖定結構描述，讓表單設計人員無法故意變更資料結構。它之所以重要是因為變更既定的 XML 結構描述有可能會破壞現有的企業解決方案，例如您打算與新表單範本搭配使用的工作流程模組。

InfoPath 提供豐富的功能，讓您在表單應用程式中建置進階的展示邏輯。您可以從 XML 檔案、Web 服務、SharePoint 文件庫和清單、資料庫等等取用資料，以提取出有意義的預設值。您可以根據使用者透過規則進行的選項來變更欄位值、納入驗證邏輯、加入 Managed 程式碼以滿足最先進的自訂需求，以及使用 Forms Service 透過網路提供表單範本。無論是哪一種情況，表單的資料最終都會以符合結構描述定義的 XML 文件形式，抵達資訊管理邏輯。

使用 XML 或中繼資料

您可能不確定是否應該將資訊管理邏輯直接套用到提交的 XML 文件中，或是改用剖析器將必要的資訊擷取成中繼資料。SharePoint 兩種方法都支援。開發人員都習慣直接使用 XML 文件，但中繼資料其實提供更大的彈性。

為了示範這一點，我建立了一個簡單的 Web 服務，來剖析從 [圖 4] 所示的 Direct Reports 表單傳入的 XML 文件 (您可以在附隨下載中的 XMLParsingWebService 資料夾內找到原始程式碼、安裝檔案，以及含逐步說明的 readme.htm)。Web 服務會直接從 XML 文件讀取經理的使用者識別碼，將使用者識別碼分成網域和使用者名稱兩部分，根據這些部分建立訊息，然後發出泛型例外狀況，在 InfoPath 的表單中以虛擬錯誤訊息的形式傳回和顯示處理過的資訊。這是在資料提交後，於 InfoPath 內顯示對話方塊的簡單方法。Web 服務很好用沒錯，但要是您變更基礎資料來源 (例如，將 DirectReports.xsd 中的 OrgPerson 元素重新命名為 Manager，並以 readme.htm 檔案中所述的新結構描述來更新 InfoPath 表單)，Web 服務就會失敗。不過這種情形應該可以預料得到，因為 XML 文件現在已經不同，而存取使用者識別碼元素的舊 XPath 運算式也已無效。OrgPerson 和 Manager 結構描述幾乎如出一轍，InfoPath 表單完全一樣，而且所要的處理結果也相同，可是即使差異微乎其微，您還是需要部署和維護重複的 Web 服務。

如果您想要盡量減少應用程式伺服器上的自訂程式碼量，這並不是妥當的作法。相反地，將 XML 節點對應到中繼資料欄位，然後根據中繼資料來執行處理作業，可讓您將相同的工作流程和資訊管理邏輯運用於類似的資料結構，即使 XML 結構描述截然不同也可行。您只要確定子元素對應到正確的中繼資料欄位，而且該資料格式符合處理需求便可 — 之後您就可以重複使用現有的程式碼。

將 XML 節點對應到中繼資料欄位與將 XML 節點繫結到 InfoPath 表單中的 UI 控制項類似，如 [圖 5] 所示。在 SharePoint 中，中繼資料欄位會與在網站或清單層級定義且在內容類型定義中所參考的資料行相對應。內容類型定義著內容項目的特性，例如中繼資料欄位、工作流程和表單。SharePoint 仰賴內建的 XML 剖析器來執行屬性升級和降級作業，藉以讓內容類型的中繼資料欄位與相關聯 XML 文件中對應的節點保持同步。在屬性升級期間，XML 剖析器會將 XML 文件的節點值擷取到文件庫上相對應的資料行。屬性降級指的則是相反的程序，在此資料行值會自文件庫取得，然後寫入文件中。最重要的一點是，XML 剖析器會使中繼資料欄位與對應的 XML 節點保持同步。

[圖 5]** InfoPath 和 SharePoint 之間的 XML 結構描述對應 **(按影像可放大)

當使用 SharePoint 物件模型時，網頁組件、工作流程和資訊管理邏輯除了可與中繼資料欄位搭配使用外，也可與基礎 XML 文件搭配運作。變更對應的中繼資料欄位的值，也會變更 XML 文件中的節點值，反之亦然。不過，直接使用 XML 文件可將商務邏輯與 XML 結構描述緊密結合。另一方面來說，對應的中繼資料欄位則可提高程式碼的重複使用性。很顯然地，您必須決定哪種方法最適合您的環境，但仰賴中繼資料欄位的 SharePoint 解決方案一般來說提供比較大的彈性，也比較有利於重複使用程式碼。

我在隨附的材料當中涵蓋了一項 SharePoint 功能，以提供自訂文件庫 (請參閱 OrgPersonContentType.xml 檔案，此檔案位於附隨的下載中的 OrgPersonLib 資料夾內)，來示範 SharePoint 如何建立 XML 節點與中繼資料欄位的關聯。OrgPerson 內容類型會參考四個欄位：UserID、FullName、EMail 和 Direct_x0020_Reports。FullName 和 EMail 是內建欄位，而 UserID 和 Direct_x0020_Reports 則是 OrgPersonSiteColumns.xml 中的自訂欄位。

欄位定義相當直接明瞭，您可以直接在欄位定義內將欄位繫結至 XML 節點，也可以在內容類型中覆寫這項資訊。我決定使用後者，因為這個方法除了可以讓我將自訂欄位用於與 XML 文件不相關的內容類型外，也可以用於在仰賴不同 XML 結構的內容類型。OrgPerson 內容類型將中繼資料欄位繫結至符合我稍早提到的 OrgPerson 結構描述配置的 XML 節點。另外還有一個 AdditionalContentTypes.xml 檔案，定義著其他將相同中繼資料欄位繫結到不同 XML 節點的內容類型。如果在 Node 屬性中查看一下 XPath 運算式，就可以看出當中的差別。

OrgPersonLib 型別的文件庫可以存放不同類型的 XML 文件，而節點值則是透過相同的文件庫資料行公開。這套簡單的對應方法也可讓您重複使用工作流程和資訊管理邏輯，因為四個內容類型 (OrgPerson、Manager、Supervisor 和 User) 都是參考同一組中繼資料欄位。

[圖 6] 說明 FieldRef 元素，這是來自 Direct_x0020_Reports 的 OrgPerson 內容型別，它會根據 XPath 運算式 /OrgPerson/direct-report/user-id，將欄位對應到部屬的使用者識別碼節點。由於 XML 文件可以包含多個部屬項目，因此務必要指定 Aggregation 屬性。這個屬性定義了 XML 剖析器將如何處理傳回的值集合。如果您忽略此屬性，XML 剖析器便只會擷取第一個節點值。支援的彙總值有 sum、count、average、min、max、merge、plain text、first 和 last。

[圖 6]** 對應到 XPath 運算式的中繼資料欄位 **(按影像可放大)

所有的範例內容類型都是使用標準 upload.aspx 網頁作為 DocumentTemplate，所以您可以在按下 SharePoint UI 裡面的 [新增] 按鈕時，將 XML 檔案上載至文件庫。只要是以 .xml 檔案副檔名上載檔案，SharePoint 就會自動呼叫內建的 XML 剖析器 (唯一的例外是 WordProcessingML 檔案，針對這個檔案，SharePoint 會呼叫 WordProcessingML 剖析器)。XML 剖析器會檢查上載的 .xml 檔案，來判定相關聯的內容類型。這麼一來，它就可以從欄位定義內指定的位置擷取節點值，並執行屬性升級 (您可以在上載 OrgPersonLib\XMLFiles 資料夾中內含的 OrgPerson.xml 檔案時驗證此程序)。這個 XML 文件的結構符合 OrgPerson 內容類型定義中指定的 XPath 運算式。SharePoint 會據此從 .xml 檔案擷取資料，將該資料寫入相對應的文件庫資料行，並將該資料顯示在 EditForm.aspx 網頁中，以便您驗證和更新未標示為唯讀的文件屬性。[圖 7] 說明了內含自 OrgPerson.xml 擷取的資料的 EditForm.aspx 表單。

[圖 7]** 內含擷取資料的 EditForm.aspx 表單 **(按影像可放大)

如果您變更 EditForm.aspx 中的 [User ID (使用者識別碼)]、[Full Name (完整名稱)] 或 [E-Mail (電子郵件)] 值，SharePoint 便會執行屬性降級來變更基礎 XML 文件內的節點值。不過，要注意的一點是，除非您自行在表單中實作必要的邏輯，否則 SharePoint 不會強制執行 XML 結構描述限制。

SharePoint 也不會執行表單應用程式的展示邏輯。比方說，當您變更 [User ID (使用者識別碼)] 時，SharePoint 並不會驗證新值是否符合 NetBIOS 慣例，也不會自動更新 [Full Name (完整名稱)] 和 [E-Mail (電子郵件)] 欄位來對應新的選項。因此，若是變更個別欄位可能會導致不一致的話，您應該將內容類型定義中相對應的資料行標示為唯讀。這可強迫使用者使用表單應用程式 (例如 InfoPath) 來更新資料。而 XML 剖析器也會將 XML 文件的任何變更升級到 SharePoint 中相對應的中繼資料欄位。

在 OrgPersonLib 範例中，您可以上載 OrgPersonLib\XMLFiles 資料夾中的任何 .xml 檔案。.xml 檔案使用的資料結構截然不同，但是 SharePoint 可以辨識出內容類型，並將正確的節點值升級到網站資料行。這是因為我使用 XML 檔案中的處理指示來建立 XML 文件與其相對應內容類型的關聯。不過，OrgPerson.xml 檔案並不包含此資訊，可是這並不成問題。如果 SharePoint 無法透過處理指示或是文件範本建立 XML 文件與內容類型的關聯，它會使用預設的內容類型。在 OrgPersonLib 的例子中，這剛好是 OrgPerson 內容類型，因此 XML 文件的剖析正確無誤。

[圖 8] 說明您如何明確建立 XML 文件與內容類型的關聯。MicrosoftWindowsSharePointServices 處理指示將 ContentTypeID 定義成 0x010100668E393E4F0EFF4294DBD202D5D8321D。這剛好是 User 內容類型的識別碼，如 AdditionalContentTypes.xml 中所定義。

[圖 8]** User.xml 範例檔案的處理指示和 XML 資料 **(按影像可放大)

XML 剖析器會處理 MicrosoftWindowsSharePointServices 處理指示，並將 ContentTypeID 值寫入 ContentType metadata 中繼資料欄位。所有的 SharePoint 內容類型都共用這個中繼資料欄位，因為它是在 System 內容類型中的根層級定義的。如果您在 SharePoint 伺服器上開啟 fieldswss.xml 檔案 (位於 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 資料夾中)，然後搜尋 MicrosoftWindowsSharePointServices，就可以看到 SharePoint 如何建立處理指示與 ContentType 欄位的關聯。PITarget 屬性指向 MicrosoftWindowsSharePointServices (這是處理指示)，而 PIAttribute 指向 ContentTypeID (當中包含 User 內容類型的識別碼)。

InfoPath 中的內容類型關聯

許多表單設計人員對 XML 剖析和內容類型關聯的專有名詞都敬而遠之，但是 InfoPath 2007 會處理好所有這些枝微末節。隨附在 OrgPersonLib 範例中的 readme.htm 檔案包含了相關指示，可讓您在 SharePoint 中發佈 Direct Reports 表單範本，以及建立繫結至相同中繼資料欄位 (UserID、FullName、EMail 和 Direct_x0020_Reports) 的內容類型。您可以在 SharePoint UI 中輕鬆地加入新的內容類型到 OrgPersonLib 文件庫中。但是新的內容類型也會指向 InfoPath 表單範本，作為在更新現有 XML 文件時呼叫表單應用程式的文件範本。[圖 9] 舉例說明「InfoPath 發佈精靈」如何簡化 XML 節點值與 SharePoint 網站資料行之間的屬性對應工作。再次強調，如果您將節點值與現有的網站資料行建立關聯，就可以重複使用現有的 SharePoint 元件。

[圖 9]** InfoPath 2007 中的屬性對應 **(按影像可放大)

結論

其他線上資源

• InfoPath 2007 小組部落格
• W3C XML 結構描述規格和開發
• XML 結構描述簡介 (XML 設計工具)
• Office SharePoint Server 2007 的工作流程
• InfoPath 2007 Forms Services

透過 Office 所提供的技術，企業架構設計師得以建置資料收集解決方案，輕易地促進程式碼重複使用和資訊交換。InfoPath 2007 容許部門建立各種解決方案，從不同來源提取資料的，然後將該資料提交至不同的系統，例如 SharePoint。SharePoint 也提供開發人員一組完整的 Web 服務和介面，來建置工作流程和資訊管理元件。憑藉著將這些元件裝載在集中式 SharePoint 伺服器上，各個部門便有所需的基礎結構來建置各自的應用程式。

同時，各個部門還可以更迅速地建立他們的資料收集解決方案。循規和其他一般商務需求可以在跨部門的層級加以解決，並且隨著應用程式伺服器上使用的自訂元件變少，IT 環境的易管理性和可靠性因而可獲得提升。

Keith Deshaies 是一名自由技術作家，也是大型電信公司的 IT 分析師。他專長於 Microsoft Office 和 SharePoint 技術，而且是技術通訊社團 (Society for Technical Communications) 的一員。

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.