Sharepoint

透過自訂內容類型將資料管理標準化

Pav Cherny

摘要:

• 透過 SharePoint 管理內容生命週期
• 建立文件資訊面板
• 透過 InfoPath 編輯 Office 和 SharePoint 文件

下載本文程式碼: ContentTypes2008_02.exe (779KB)

企業環境中往往累積了龐大的文件等內容項目，要以集中、可重複使用的方式管理文件、中繼資料及其行為，無非是

商務和技術上的一大挑戰。Microsoft® Office SharePoint® Server 2007 針對這點推出全公司通用的合作方式，方便企業內部職能各異的小組透過網站、文件庫和清單共用工作區，從而提升企業整體的合作效率。

透過內容類型，SharePoint 2007 可將內容和生命週期的各種特性標準化。網站內容類型是獨立於任何具體網站集合、網站、清單或文件庫而建立的中繼資料定義。有了它，您可以採用一貫作法建立應用全公司的屬性、工作流程、資訊管理原則及其他元素，同時又容許個別部門或網站擁有者根據具體用途自訂內容類型。

本文就要告訴您，如何使用 Windows® SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 所附隨的全新 SharePoint 內容模型，根據一般特性建立企業內容的各個階層。這些內容階層一方面容許全域統一應用中繼資料、工作流程和資訊管理原則，另一方面又能夠彈性配合網站集合、網站、文件庫和清單方面獨特的內容管理需求。

為了示範部分低階的 SharePoint 內容類型，我在隨附的資料當中加入一些自訂工具，還另附原始程式碼，方便讀者根據個人需求進行擴充。不過請記住，這些工具尚未經過徹底測試，不應用於實際執行系統。您可以從 TechNet Magazine 網站下載程式碼，網址為 technetmagazine.com/code08.aspx。

內容生命週期和內容類型定義

SharePoint 資源

• InfoPath 小組部落格
• Office SharePoint Server 2007 的工作流程
• TechNet 網路廣播：在 SharePoint Server 2007 安裝和設定搜尋
• InfoPath Forms Services

管理公司文件等內容時要考量很多細節，像是建立、發佈、封存和處置內容時，必須定義由誰或哪個程序負責執行什麼動作。公司通常必須進行的工作有：建立出內容製作專用範本、界定角色以分派工作和使用者存取權、提供版本控制、監視相容性、儲存與封存，以及定義中繼資料等等。

內容生命週期的確是相當複雜，不過 SharePoint 內容模型已經從個別內容項目的處理方式找出一般特性和標準階段。比方說，可以透過範本和輸入表單來制定建立內容的結構，以及透過中繼資料來制定顯示和搜尋內容的結構。您也可以藉由編輯、核准或其他工作流程需求、封存需求、到期時間範圍以及適用的資訊管理原則，劃分出有哪些個別內容。有些內容也許不需要特別的範本，也許永遠都不必封存，但即使如此，這些都是區分項目與項目的生命週期特性。

SharePoint 內容模型可讓您定義個別的內容類型，並且建立階層關係。在階層關係中，子系繼承了父系內容類型的一般特性，也可以根據自身需求添加具體特性。

這點可以從 SharePoint 的內建內容類型看出。WSS 3.0 和 MOSS 2007 含有針對文件和工作等一般項目預先定義的內容類型，可以儲存在文件庫或清單中。這些標準內容類型的定義位在 SharePoint 伺服器的 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes 資料夾當中，其中有個名為 feature.xml 的資訊清單檔。從這個檔案可以看出，SharePoint 實作的標準內容類型定義是附有網站集合範圍 (Scope="Site") 的隱藏功能 (Hidden="TRUE")，而含有實際內容類型元素的 Element 資訊清單檔則是 ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />)。

如果您有興趣深入瞭解 SharePoint 功能，建議您閱讀《MSDN® Magazine》的《Office Space》專欄中，由 Ted Pattison 所寫的＜適用於 SharePoint 的功能＞一文 (msdnmagazine.com/issues/07/05/OfficeSpace)。

無論 SharePoint 使用者介面中是否看得見標準內容類型，我們都可以用記事本開啟 ctypeswss.xml 檔案察看標準內容類型，不過別修改這個檔案。有些 SharePoint 使用者希望修改 ctypeswss.xml，在標準內容類型另添欄位或將顯示原為隱藏的內容類型，好衍生出新的內容類型。這種做法不但沒有必要，還會產生不支援的設定，稍後安裝的 Service Pack 也會覆寫您的自訂，結果將內容管理解決方案搞得一團亂。

理想的做法是將需要的內容類型複製到新的元素資訊清單檔案中，根據需要另添自訂的內容類型，最後再將自訂的內容類型部署為含有網站集合範圍的新功能，方便網站集合中所有的網站加以使用。

下面就是 ctypeswss.xml 所指定之 System 內容類型的共同應用程式標記語言 (CAML) 定義：

<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>

Group 和 Sealed 屬性表示 System 內容類型已經隱藏密封，不得在 SharePoint 使用者介面中變更。System 內容類型只有一個 FieldRef 元素會參考一個稱為 ContentType 的內建網站欄，這是最高的抽象層，其他的 SharePoint 內容類型一概從 System 內容類型繼承這個屬性。因此，SharePoint 便可確保所有儲存在任何文件庫或清單的內容項目，全部具有這個共同屬性。

[圖 1] 顯示的是本文隨附贈資料內含的 ContentTypeHierarchy 網頁組件，圖解說明的階層更加直接易懂。System 是所有內容類型的根目錄，接下來是 Item，然後依此類推。舉例來說，Item 內容類型會建立下一層的詳細資料。您只要查看 ctypeswss.xml，就會發現 Item 負責定義一個參考 Title 網站欄的中繼資料欄位。因此，所有比它低階的內建內容類型都會具備 Title 屬性。

[圖 1]** WSS 3.0 內建內容類型階層 **(按影像可放大)

您也可以比照 ctypeswss.xml 中的 Document 內容類型定義，移除一個繼承的欄位。Document 內容類型包含好幾個相對應的 RemoveFieldRef 元素，不過最好把 Title 欄位保留在自訂內容類型中，因為 Title 欄可讓您存取 SharePoint 的 [文件庫] 和 [清單] 檢視中的 [編輯控制項方塊] (ECB) 下拉式功能表。

如果您想知道如何重新命名繼承的欄位，不妨參考 ctypeswss.xml 中的 Far East Contact 內容類型一例。請搜尋對應的內容類型識別碼 0x0116，然後檢查屬性為 Name="Title" 的 FieldRef 元素，看看如何使用 DisplayName 屬性，在使用者介面中重新命名欄位。在這個範例中，DisplayName 屬性把使用者介面的 Title 欄位名稱，改成一個 "$Resources:core,Last_Name;" 所參考的當地語系化資料值。

如果您再細看 [圖 1]，就知道 ContentType 元素的 ID 屬性是唯一識別該內容類型、並且負責建立階層關係的屬性。所有的識別碼，都以另外附加其他十六進位值的父系內容類型的識別碼開頭。標準內容類型通常都會額外附加兩個十六進位值，目的是為子系內容類型建立新的專屬識別碼。另一種方法是附加 "00" 和十六進位 GUID。比方說，「Office 資料連線檔案」和「通用資料連線檔案」內容類型，就是以這種方式從 Document 內容類型衍生出來。

使用者還必須記住一點，ContentType 元素的 ID 屬性不能多於 1,024 個字元。如果大型階層關係中所有的內容類型都使用十六進位 GUID 定址技術的話，可能會產生問題。但是以較短的定址技術開頭也不見得理想，因為這些識別碼未必是專屬識別碼。

為了確保它的專屬性，您可以使用 GUID 技術，為企業內容類型建立一個全域命名空間，然後再切換到該命名空間中較短的定址技術。如需有關 ID 屬性及內容類型定義之其他元素的詳細資訊，請參閱 WSS 3.0 SDK 中的＜內容類型定義架構＞一文。

內容類型依存關係

現在讓我們看看如何使用 SharePoint 內容類型來制定內容項目管理的結構。您必須考量幾個依存關係，例如文件庫和清單、內容類型、網站欄及欄位類型之間的相互依存性。文件庫和清單會參考內容類型，內容類型會參考網站欄，網站欄會轉而參考欄位類型 (例如，標準 WSS 欄位類型文字、附註、選項、號碼和貨幣等等)，而欄位類型位於 Microsoft .NET Framework 組件中，例如 WSS 核心組件 Microsoft.SharePoint.dll。

為了舉例說明，讓我們回到之前在 System 內容類型資訊清單檔案項目的 CAML 定義中所說明的 System 內容類型。如您所見，這個內容類型包含一個 FieldRef 元素會參考 ContentType 網站欄。請注意，內容類型定義並不會定義實際的 ContentType 網站欄。ContentType 是一個文字欄位，定義在 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 資料夾的 Elements 資訊清單 fieldswss.xml 中。您可以在 SharePoint 伺服器的 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes 資料夾中，找到這些標準內容類型的定義。在使用這個依存樹狀目錄時，您必須確保 SharePoint 伺服器上所有的資源都能夠使用。

您要使用的內容類型，必須在文件庫和清單的網站層級、或網站階層中的更高層級建立。同樣地，內容類型的中繼資料欄位也必須參考現有的網站欄。您可以根據標準或自訂欄位類型，在內容類型新增標準或自訂網站欄，但是您必須確保這些網站欄都在本機網站上。此外，如果要使用自訂欄位類型，也必須將基礎 .NET 組件部署到 SharePoint 伺服器上。

參考文件範本、自訂事件接收器、工作流程和其他元件的內容類型也有類似的依存性。比如，內容類型定義可以包含一個 DocumentTemplate 元素，指向與該內容類型相關聯的文件範本。內容類型定義也可以包含一個含有一或多個 XmlDocument 子元素的 XmlDocuments 元素，負責定義內容類型的其他特性，例如命名空間定義、文件資訊面板定義或任何自訂資訊。

建立全域內容類型

具有製作權限的使用者，可以直接在 SharePoint 使用者介面，建立新的內容類型和網站欄，但是內容類型只能用在網站階層中的本機網站以及本機網站以下。自訂網站欄只能用在本機網站。如果您要建立全域內容類型，這還不夠，您必須確保全域內容類型都能用在環境中所有的網站集合才行。這時候 SharePoint 功能就派上用場了。要在多個網站集合安裝和啟動 SharePoint 功能，以便在所有的地方一致套用相對應的網站欄和內容類型定義，是很簡單的程序。

本文隨附的資料包含一個名為 AdventureWorks 的範例功能，它可以示範建立全域內容類型的方法。這項功能會定義一個名為「客戶說明文件」的一般內容類型，該內容類型可用來建立任何類型的客戶資料，例如提案和業務信件。您大可假設上述類型的文件都應該與公司名稱、連絡人詳細資料和地址等客戶資訊相關聯。我特別針對您的內容類型建立了叫做 [客戶名稱 (Customer Name)] 的自訂欄位，並且加入 [部門 (Department)] 和 [主要電話號碼 (Primary Phone)] 等內建欄位。您可以在隨附的範例中編輯 ContentTypes.xml 檔案來變更內容類型，以及編輯 SiteColumns.xml 檔案來變更欄位參照。

如果您根據 readme.htm 檔的說明來部署該功能，就可以在多個網站集合一致啟動它。接著「客戶說明文件」內容類型就可以全域使用。這麼一來，個別部門就可以透過與指定文件範本相關聯的衍生內容類型，建立特定的客戶文件。隨附的資料中還包括銷售和諮詢用的範例文件範本。[圖 2] 顯示最後得出的內容類型。

[圖 2]** 客戶文件的父系和子系內容類型 **(按影像可放大)

要在 WSS 3.0 和 MOSS 2007 建立自訂網站欄和內容類型的功能，方法有好幾種。您可以研讀 WSS 3.0 SDK，從頭撰寫 XML 檔案；也可以選擇使用 SharePoint Designer，將清單匯出到個人網頁套件、把得出的 .fwp 檔重新命名為 .cab 檔案、從 .cab 檔案擷取 manifest.xml 檔案，然後再搜尋 manifest.xml 檔案中的 ContentType 定義。不過這兩種方法都不太方便，而且很容易出錯。

相較之下，在 SharePoint 使用者介面建立自訂網站欄和內容類型，要容易得多。但是，介面無法讓您編輯某功能的 XML 檔案。功能雖然足以提供 SharePoint 資源，但是它們所提供的資源只位於內容資料庫中。也許未來的 WSS 可以透過 SharePoint 使用者介面，將網站欄和內容類型匯出到 XML 檔案，就像匯出網頁組件一樣，但是目前您只能使用手邊現有的功能。

您也可以從隨附的資料內含的網頁組件 ContentTypeSchema 著手。這個網頁組件利用 SharePoint 物件模型，從選定的內容類型擷取 SchemaXML 屬性。然後透過以 eXtensible 樣式表語言轉換 (XSLT) 為基礎的轉換，您在按下 [顯示] 按鈕之前，網頁組件會根據您在使用者介面選取的選項，衍生 Field 定義或 ContentType 定義。

[圖 3] 所顯示的就是這個網頁組件。它顯示了我以「客戶說明文件」內容類型為基礎而建立的「Active Directory® 說明文件」內容類型。「Active Directory 說明文件」內容類型與一個自訂 Microsoft Word 範本 (Active Directory Template.dot) 相關聯。請注意，這個內容類型並沒有額外的欄位，所有的欄位都是繼承自父系的內容類型。

如果您打算在自己的環境內使用 ContentTypeSchema 網頁組件，請記住，這個網頁組件尚未經過完整的測試。我的網頁組件是使用相當複雜的 XSL 轉換，來建立目前所選內容類型及其父系內容類型的 SchemaXML 屬性差異值。但是，XSLT 1.0 並非真的針對進階 XML 文件轉換而設計，它沒有內建功能可以比較 XML 節點。另外，XML 命名空間和 CDATA 區段，都表示 XSLT 1.0 無法有效處理。

SharePoint 會儲存以 SharePoint 使用者介面或 SharePoint 物件模型所建立之網站欄和網站內容類型的定義，而 SharePoint 使用者介面或 SharePoint 物件模型是位於表格 ContentTypes 的內容資料庫中。[圖 3] 就是我的自訂內容類型識別碼。根據這一點，下面這個 T-SQL 陳述式會得出明確的結果：SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>。

[圖 3]** SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>。 網頁組件 **(按影像可放大)

無論您決定使用哪一種方法，只要取得網站欄和內容類型定義，就不難建立全企業內容類型的功能。我建議您在貴公司或貴部門的所有全域網站欄和內容類型上，只採用單一功能，這麼一來，就能一眼看出該在哪裡加入新的網站欄和內容類型定義。

全企業搜尋自訂中繼資料

內容類型階層有一個現成的優點，那就是所有的子系內容類型都會繼承父系內容類型的中繼資料欄位。由於所有的內容類型都有共同的中繼資料欄位，因此使用者很容易就可以在文件庫中建立自訂檢視和篩選器。

AdventureWorks 範例功能說明得相當清楚。無論顧問或業務人員建立的內容是什麼，只要您想把得出的 Word 2007 文件儲存在文件庫中，都必須指定一個「客戶名稱」，因為「客戶說明文件」父系內容類型會在必要時，定義這個中繼資料欄位。顧問和業務小組成員可以根據「客戶名稱」，將文件庫檢視中的項目加以分組或篩選，以便快速方便的找到客戶所有的現有文件，如 [圖 4] 所示。

[圖 4]** 根據共同的中繼資料將文件庫中的各種文件加以分組 **(按影像可放大)

共同的中繼資料也方便您使用 WSS 3.0 和 MOSS 2007 的搜尋功能，尋找多個文件庫和網站上的內容。WSS 容許您在一個網站集合內的各文件庫、清單和網站進行搜尋，而 MOSS 2007 更超越這些基本功能，容許您實作全企業的搜尋中心，並且在 SharePoint 3.0 管理中心使用者介面上管理自訂中繼資料。因此，下面我們將把重點擺在 MOSS 2007。

當您在 MOSS 2007 設定共用服務提供者 (Shared Service Provider，SSP)，以及在 SharePoint 網站上進行編目時，MOSS 2007 會自動發現內容來源所用的自訂中繼資料欄位。因此，您可以在編目屬性清單中，找到自訂中繼資料欄位。

在 SharePoint 功能中定義的中繼資料欄位，通常都落在 SharePoint 類別下。若要尋找它在 SharePoint 管理中心的位置，請在 [快速啟動] 功能表的 [共用服務管理] 下方，按一下連至您 SSP 的連結、按一下 [搜尋設定]、按一下 [中繼資料屬性對應]、再按一下 [快速啟動] 功能表的 [編目屬性]，然後再開啟 SharePoint 類別。

我會提供一個運作範例。稱為 [Customer Name (客戶名稱)] 的中繼資料欄位最後會變成編目屬性，名叫 ows_Customer_x0020_Name。SharePoint 在編目屬性前面加上 "ows_" 作為首碼，而 "_x0020_" 則代表編碼版的一個空格。只要顯示這個編目屬性的詳細資料，就會發現它預設包含在搜尋索引中，因此使用者可以使用這個編目屬性的值來執行內容搜尋。但是為了提高搜尋精準度，您可能不希望將編目屬性對應到 Managed 屬性，這樣使用者才能依據客戶名稱明確搜尋內容。

您有兩種方式可以將編目屬性對應到 Managed 屬性。您可以為每一個編目屬性自動產生一個新的 Managed 屬性，也可以手動將編目屬性對應到 Managed 屬性。當您顯示所要的編目屬性類別設定時 (要顯示某類別中的編目屬性 (例如 SharePoint 類別)，請按一下 [快速啟動] 連結上的 [編輯類别] 選項)，可以採用第一個方法。您必須在 [大量編目屬性設定] 下方，勾選 [為每個再此類別中探索到的編目屬性自動產生新的Managed 屬性] 核取方塊。但是 SharePoint 會自動在您所建立的 Managed 屬性前面加上 "ows" 作為首碼，並且以 "x0020" 建立空格。編目屬性 ows_Customer_x0020_Name 的 Managed 屬性是 owsCustomerx0020Name，不過這並不是一個令人一目瞭然的屬性名稱。

所以也許在部署全企業內容類型之後，再手動將編目屬性對應到 Managed 屬性，是比較理想的方式。您可以將一個編目屬性對應到一或多個 Managed 屬性。若要建立新的 Managed 屬性，請在 SharePoint 管理中心的 [快速啟動] 功能表的 [共用服務管理] 下方，按一下連至您 SSP 的連結、按一下 [搜尋設定]、再按一下 [中繼資料屬性對應]，然後再按一下 [新增 Managed 屬性]，指定所需的資訊，並且將新的 Managed 屬性關聯到您所要的編目屬性。

接著使用者就可以在 property: 語法中或者使用進階搜尋來使用 Managed 屬性，藉此尋找相關的內容項目。比方說，如果您將編目屬性 ows_Customer_x0020_Name 對應到 Customer Managed 屬性，使用者只要在標準搜尋方塊指定 Customer:<客戶名稱> (例如 Customer:Contoso)，就可以搜尋客戶的所有文件。

您也可以針對內容類型最重要的中繼資料欄位，加入 Managed 屬性 (內容類型位於 [進階搜尋] 網頁上的屬性清單中)。做法是先顯示 [進階搜尋] 網頁，然後按一下 [動作]，再選取 [編輯網頁] 命令。現在您就可以按一下 [進階搜尋] 方塊的 [編輯]，選取 [修改共用的網頁組件] 選項。當您展開 [屬性] 類別，並將游標放在相對應的文字欄位時，可以按一下按鈕來編輯屬性 XML 文件。您必須在 <PropertyDefs> 元素加入一個屬性定義 (例如 <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>)，另外還要在 ResultType 元素 (例如，元素 <ResultType DisplayName="All Results" Name="default">) 下方，加入這個屬性定義的參考，例如 <PropertyRef Name="Customer" />。[圖 5a] 顯示的是最後得出的 [進階搜尋] 使用者介面。[圖 5b] 顯示的是搜尋結果。

[圖 5a]** 依照客戶名稱搜尋 IT 基礎結構文件 **(按影像可放大)

[圖 5b]** 客戶名稱搜尋的結果 **(按影像可放大)

確保資訊一致性

這時候，我已順利將最重要的中繼資料欄位和內容類型標準化，並且根據 MOSS 2007，在我企業中擴充網站集合的搜尋能力。接下來就是確保使用者在中繼資料欄位輸入精確的資訊。

做法有兩種：第一，您可以把文件範本中的標準文件資訊面板，替換成自訂 InfoPath® 表單，提供使用者預先定義的輸入選項，例如您在清單方塊中的選項。第二，您可以將事件接收器繋結到內容類型，然後每當使用者建立、修改或刪除相對應的內容項目時，就檢查中繼資料及其他資訊的精確性。

這兩個選項彼此互補。InfoPath 表單主要在提供一個方便的方式，讓您編輯 SharePoint 內容類型的屬性，而事件接收器則是確保中繼資料有效 (即使使用者在 InfoPath 表單外面編輯內容類型屬性也一樣)。您可以將事件處理器繫結到特定的內容類型，讓您針對所有網站集合中所有與個別內容類型相關聯的文件，指定事件及其回應，而不論文件庫為何。有關如何開發和部署事件處理器的其他相關資訊，請參閱 msdn2.microsoft.com/ms453149。

如果要將內容類型關聯到自訂文件資訊面板，最簡單的方式應該是在裝有 InfoPath 2007 的電腦的 SharePoint 使用者介面中，顯示內容類型的 [文件資訊面板] 設定，然後按一下 [文件資訊面板範本] 下方的 [建立新的自訂範本] 連結，以設計模式啟動 InfoPath 2007。但是，如果您的網站內容類型包含沒有明確 SourceID 屬性的網站欄，InfoPath 可能就無法為 [文件資訊面板] 表單建立有效的 XSD 結構描述。比方說，之前介紹的「客戶說明文件」內容類型包含了好幾個連絡人專屬欄 (例如，[部門]、[辦公室] 和 [電子郵件])，而這些專屬欄都有可能導致這個問題，如 [圖 6] 所示。

[圖 6]** InfoPath 2007 的 XSD 結構描述不相容 **(按影像可放大)

如果這時候遇到這個問題，有兩種方法可以解決。您可以從內容類型定義，移除沒有明確 SourceID 屬性的網站欄參考，也可以把導致問題的內建網站欄替換成與 InfoPath 2007 相容的自訂網站欄。請記住，一旦將 CAML 內容類型的欄位參考提供到內容資料庫之後，就不可以變更它，如果您已建立子系內容類型的話更是不行。您不可以只是更新 CAML 內容類型定義檔，也不可以將變更下推至子系內容類型，因為 Windows SharePoint Services 不會追蹤您對父系內容類型定義所做的變更。

如果要下推變更，必須透過 SharePoint 使用者介面或物件模型，變更父系內容類型，否則就必須從現有內容類型衍生並定義新的內容類型。後者可讓您移除重要欄位，加入新欄。接著使用者可以再從新的內容類型衍生未來的內容類型。為了不讓使用者選錯內容類型，請在 _Hidden 內容類型群組加入前一個內容類型。

我之前說過，CAML 內容類型一經部署和啟動之後，就不可以更新。因此在部署之前，一定要測試全域內容類型。如需詳細資訊，請參閱 MSDN 文章＜更新內容類型＞，網址為 msdn2.microsoft.com/aa543504。

只要建立含適當欄位參考的內容類型之後，就可以在 InfoPath 2007 建立自訂文件資訊面板。最妥當的方法是讓網站擁有者建立其子系內容類型的自訂文件資訊面板。您可以使用 InfoPath 2007，把自訂文件資訊面板直接發佈到選定的內容類型，以方便您部署。不過您也可以在中心位置 (例如，文件庫) 發佈 InfoPath 表單，並且在內容類型加入文件資訊面板的參考。如果您打算連同 CAML 內容類型一起提供自訂文件資訊面板，這是最佳的選擇。[圖 7] 說明的是實作架構。

[圖 7]** 在 MOSS 2007 的中心位置實作 XSN 檔案 **(按影像可放大)

本文隨附的下載檔案還包括一項名為 AdventureWorks_Update 的功能，它另外新增了一個網站欄與 InfoPath 2007 搭配使用，藉此延伸之前的 AdventureWorks 功能。AdventureWorks_Update 功能將原始的「客戶說明文件」內容類型標示為隱藏，並且衍生一個新的內容類型「客戶文件」，它把繼承而來的內建欄位取代成新的網站欄，並且把新的內容類型關聯到自訂文件資訊面板。

新的「客戶文件」內容類型定義包含一個提供文件資訊面板相關資訊的 XmlDocument 元素。特別的是，xsnLocation 元素會指向 InfoPath 表單 ，來實作文件資訊面板。有關如何套用 AdventureWorks_Update 功能的詳細資訊，請參閱 AdventureWorks_Update 資料夾中的 readme.htm 檔。

總結

您可以使用 SharePoint 內容類型來建立中繼資料原則，並且全面導入企業以進行內容管理。內容類型的階層可讓您把與整個企業環境有關的特性標準化，並且藉由繼承關係，將它們統一套用到所有的網站上。

除此之外，還可以延伸 MOSS 2007 的內建搜尋功能，讓使用者更快速且更方便的尋找特定的內容。您也可以強制將中繼資料相關資訊一致化，並且建立中央資訊管理原則。最理想的方式就是將最抽象的中繼資料特性的全域內容類型標準化，盡量降低日後變更的需要。SharePoint 內容類型是以審慎設計的內容模型為基礎，可以提供新的功能，將整個企業的內容生命週期管理標準化。

Pav Cherny 是 Biblioso Corporation 總裁暨 IT 專家與作者，專攻 Microsoft 共同作業與整合通訊技術。其出版著作多半集中於 IT 作業與系統管理領域。

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