SharePoint

Standardisieren der Datenverwaltung mit benutzerdefinierten Inhaltstypen

Pav Cherny

Kurz zusammengefasst:

• Inhaltslebenszyklusverwaltung mit SharePoint
• Erstellen von Dokumentinformationsbereichen
• Bearbeiten von Office- und SharePoint-Dokumenten über InfoPath

Laden Sie den Code für diesen Artikel herunter: ContentTypes2008_02.exe (779KB)

Die große Anzahl an Dokumenten und anderen Inhaltselementen, die in der Regel in einer Unternehmensumgebung vorzufinden sind, machen es in betrieblicher und technischer Hinsicht schwierig, die Dokumente, ihre

Metadaten und ihre Verhaltensweisen auf zentralisierte und wiederverwendbare Weise zu verwalten. Microsoft® Office SharePoint® Server 2007 fördert die unternehmensweite Zusammenarbeit, indem unterschiedlichen Teams innerhalb einer Organisation ermöglicht wird, Arbeitsbereiche auf Websites, Dokumentbibliotheken und Listen gemeinsam zu nutzen.

SharePoint 2007 ermöglicht es, viele Aspekte von Inhalts- und Lebenszyklusmerkmalen durch Inhaltstypen zu standardisieren. Websiteinhaltstypen sind Metadatendefinitionen, die unabhängig von einer bestimmten Websitesammlung, Website, Liste oder Dokumentbibliothek eingerichtet werden können. Dies ermöglicht ein konsistentes Einrichten unternehmensweiter Eigenschaften, Workflows, Informationsverwaltungsrichtlinien und anderer Elemente und erlaubt zugleich einzelnen Abteilungen oder Websitebesitzern, Inhaltstypen für bestimmte Zwecke anzupassen.

In diesem Artikel wird die Verwendung des mit Windows® SharePoint Services (WSS) 3.0 und Microsoft Office SharePoint Server (MOSS) 2007 eingeführten neuen SharePoint-Inhaltsmodells aufgezeigt, um basierend auf allgemeinen Merkmalen Hierarchien für Unternehmensinhalte zu erstellen. Diese Inhaltshierarchien ermöglichen die einheitliche Anwendung von Metadaten, Workflows und Informationsverwaltungsrichtlinien auf globaler Ebene und bieten zugleich die Flexibilität, einzigartige Inhaltsverwaltungsanforderungen auf der Ebene von Websitesammlungen, Websites, Dokumentbibliotheken und Listen zu erfüllen.

Um einige der untergeordneten Aspekte von SharePoint-Inhaltstypen zu veranschaulichen, wurden im Begleitmaterial eine Reihe benutzerdefinierter Tools sowie den Quellcode aufgenommen, mit dem Sie die Tools bei Bedarf gemäß Ihren spezifischen Anforderungen erweitern können. Bedenken Sie dabei jedoch, dass diese Tools nicht gründlich getestet wurden und daher nicht in einem Produktionssystem verwendet werden sollten. Sie können den Code von der Website des TechNet Magazins unter technetmagazine.com/code08.aspx herunterladen.

Inhaltslebenszyklus und Inhaltstypdefinitionen

SharePoint-Ressourcen

• InfoPath-Teamblog
• Workflows in Office SharePoint Server 2007
• TechNet-Webcast: Installieren und Konfigurieren der Suche in SharePoint Server 2007
• InfoPath Forms Services

Beim Verwalten von Dokumenten und anderen Inhalten in einer Organisation müssen viele Details berücksichtigt werden. Unter anderem muss definiert werden, welche Person oder welcher Prozess beim Erstellen, Veröffentlichen, Archivieren und Löschen von Inhalt welche Aktion durchführen muss. In einer Organisation ist es darüber hinaus erforderlich, bestimmte Vorlagen für die Inhaltserstellung zu entwickeln, Rollen zu definieren, um Benutzern Zuständigkeiten und Zugriffsberechtigungen zuzuweisen, Versionskontrolle bereitzustellen, die Einhaltung von Richtlinien sowie Speicher und Archive zu überwachen, Metadaten zu definieren und so weiter.

Wie komplex ein bestimmter Inhaltslebenszyklus auch sein mag, erkennt das SharePoint-Inhaltsmodell, dass es einige allgemeine Merkmale und typische Phasen gibt, die bestimmen, wie die einzelnen Inhaltselemente behandelt werden müssen. Sie können beispielsweise die Inhaltserstellung durch Vorlagen und Eingabeformulare sowie Inhaltsanzeigen und Suchvorgänge in Metadaten strukturieren. Weiterhin können Sie Bearbeitungs-, Genehmigungs- oder andere Workflowanforderungen sowie Archivierungsanforderungen, Ablauffristen und anwendbare Informationsverwaltungsrichtlinien verwenden, um zwischen einzelnen Inhaltselementen zu unterscheiden. Manche Inhalte erfordern möglicherweise keine besonderen Vorlagen oder werden nie archiviert, aber selbst dies sind Lebenszyklusmerkmale, die diese Elemente von anderen Elementen unterscheiden.

Das SharePoint-Inhaltsmodell ermöglicht Ihnen, einzelne Inhaltstypen zu definieren und hierarchische Beziehungen einzurichten. In einer hierarchischen Beziehung erben untergeordnete Inhaltstypen allgemeine Merkmale von übergeordneten Inhaltstypen und fügen je nach Bedarf bestimmte Merkmale hinzu.

Dies lässt sich am besten durch eine Untersuchung der integrierten Inhaltstypen von SharePoint veranschaulichen. WSS 3.0 und MOSS 2007 enthalten eine Reihe vordefinierter Inhaltstypen für typische Elemente, die in einer Dokumentbibliothek oder einer Liste gespeichert werden können, z. B. Dokumente und Aufgaben. Sie können die Definitionen dieser standardmäßigen Inhaltstypen auf einem SharePoint Server im Ordner „%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes“ finden. Dort befindet sich eine Manifestdatei namens „feature.xml“. Bei näherer Untersuchung dieser Datei stellen Sie fest, dass SharePoint die standardmäßigen Inhaltstypdefinitionen als verborgenes Feature (Hidden="TRUE") mit einem Websitesammlungsbereich (Scope="Site") implementiert und dass die Element-Manifestdatei, in der die eigentlichen Inhaltstypelemente enthalten sind, „ctypeswss.xml“ heißt (<ElementManifest Location="ctypeswss.xml" />).

Wenn Sie mehr über SharePoint-Features erfahren möchten, empfehle ich Ihnen den Office-Space-Artikel von Ted Pattison im MSDN® Magazin mit dem Titel „Features für SharePoint“, der unter msdnmagazine.com/issues/07/05/OfficeSpace verfügbar ist.

Öffnen Sie nun die Datei „ctypeswss.xml“ in Editor, um die standardmäßigen Inhaltstypen unabhängig davon zu untersuchen, ob sie in der SharePoint-Benutzeroberfläche sichtbar sind. Sie dürfen „ctypeswss.xml“ nicht verändern. Wenn Sie vorhaben, die Datei „ctypeswss.xml“ zu bearbeiten, um standardmäßigen Inhaltstypen neue Felder hinzuzufügen oder verborgene Inhaltstypen sichtbar zu machen, damit SharePoint-Benutzer neue Inhaltstypen ableiten können, dann beachten Sie bitte, dass dies normalerweise nicht erforderlich ist. Außerdem führt dies zu nicht unterstützten Konfigurationen, und es ist möglich, dass spätere Installationen von Service Packs Ihre Anpassungen überschreiben und Ihre Inhaltsverwaltungslösungen zerstören.

Eine viel bessere Methode besteht darin, alles für Sie Erforderliche in eine neue Element-Manifestdatei zu kopieren, nach Bedarf alle notwendigen Anpassungen hinzuzufügen und danach Ihre benutzerdefinierten Inhaltstypen als neues Feature mit einem Websitesammlungsbereich bereitzustellen, damit sie für alle Websites innerhalb der Websitesammlung verfügbar sind.

Hier ist die CAML (Collaborative Application Markup Language)-basierte Definition des System-Inhaltstyps zu sehen, wie sie in „ctypeswss.xml“ angegeben ist:

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

Die Group- und Sealed-Attribute zeigen an, dass der System-Inhaltstyp verborgen und versiegelt ist, damit er in der SharePoint-Benutzeroberfläche nicht geändert werden kann. Der System-Inhaltstyp besitzt nur ein einziges FieldRef-Element, das auf eine integrierte Websitespalte namens „ContentType“ verweist. Dies ist die höchste Abstraktionsstufe. Alle anderen SharePoint-Inhaltstypen erben diese Eigenschaft vom System-Inhaltstyp. Auf diese Weise stellt SharePoint sicher, dass alle Inhaltselemente, die in Dokumentbibliotheken oder Listen gespeichert sind, diese Eigenschaft gemeinsam haben.

Abbildung 1 zeigt ein Webpart namens „ContentTypeHierarchy“, das im Begleitmaterial für diesen Artikel enthalten ist und die Hierarchien auf anschaulichere Art demonstriert. System befindet sich an der Wurzel aller anderen Inhaltstypen, gefolgt von Item und so weiter. Der Item-Inhaltstyp stellt beispielsweise die nächste Detailstufe dar. Bei einer Überprüfung von „ctypeswss.xml“ können Sie sehen, dass Item ein einzelnes Metadatenfeld definiert, das auf eine Websitespalte namens „Title“ verweist. Daher besitzen alle integrierten Inhaltstypen niedrigerer Stufen eine Eigenschaft namens „Title“.

Abbildung 1** Hierarchie der in WSS 3.0 integrierten Inhaltstypen **(Klicken Sie zum Vergrößern auf das Bild)

Es ist auch möglich, ein geerbtes Feld zu entfernen, wie die Document-Inhaltstypdefinition in „ctypeswss.xml“ demonstriert. Der Document-Inhaltstyp umfasst mehrere entsprechende RemoveFieldRef-Elemente, doch Sie sollten in Ihren benutzerdefinierten Inhaltstypen das Feld „Title“ beibehalten, weil die Spalte „Title“ den Zugriff auf das Dropdownmenü „Edit Control Box (ECB)“ (Feld zum Bearbeiten des Steuerelements) in der SharePoint-Dokumentbibliothek und den Listenansichten gewährt.

Ein gutes Beispiel zum Veranschaulichen, wie geerbte Felder umbenannt werden, bildet der Inhaltstyp „Far East Contact“ in der Datei „ctypeswss.xml“. Suchen Sie nach der entsprechenden Inhaltstyp-ID „0x0116“, und überprüfen Sie danach das FieldRef-Element mit dem Attribut „Name="Title"“, um zu sehen, wie Sie das DisplayName-Attribut zum Umbenennen eines Felds in der Benutzeroberfläche verwenden können. In diesem speziellen Beispiel ändert das DisplayName-Attribut den Namen des Title-Felds in der Benutzeroberfläche zu einem lokalisierten Datenwert, auf den durch „$Resources:core,Last_Name;“ verwiesen wird.

Bei näherer Betrachtung von Abbildung 1 erkennen Sie, dass das ID-Attribut des ContentType-Elements den Inhaltstyp eindeutig identifiziert und die hierarchische Beziehung einrichtet. Alle IDs beginnen mit der ID des übergeordneten Inhaltstyps, an die zusätzliche hexadezimale Werte angefügt wurden. An standardmäßige Inhaltstypen werden in der Regel zwei zusätzliche hexadezimale Werte angefügt, um eine neue eindeutige ID für den untergeordneten Inhaltstyp zu erstellen. Ein weiteres Verfahren besteht darin, den Wert „00“ und eine hexadezimale GUID anzufügen. Auf diese Weise werden beispielsweise die Inhaltstypen „Office Data Connection File“ und „Universal Data Connection File“ vom Document-Inhaltstyp abgeleitet.

Hierbei müssen die Benutzer unbedingt daran denken, dass das ID-Attribut des ContentType-Elements nicht länger als 1.024 Zeichen sein darf. Dies kann in einer umfangreichen hierarchischen Beziehung zu einem Problem werden, falls alle Inhaltstypen dasselbe Verfahren der hexadezimalen GUID-Adressierung verwenden. Es wäre jedoch keine gute Idee, mit dem kürzeren Verfahren zu beginnen, weil diese IDs möglicherweise nicht eindeutig sind.

Damit Eindeutigkeit gewährleistet ist, verwenden Sie das GUID-Verfahren, um einen globalen Namespace für Ihre unternehmensinternen Inhaltstypen einzurichten, und wechseln Sie danach innerhalb dieses Namespace zum kürzeren Verfahren. Ausführliche Informationen zum ID-Attribut und zu anderen Elementen von Inhaltstypdefinitionen finden Sie unter dem Thema „Inhaltstypdefinitionsschema“ im WSS 3.0-SDK.

Inhaltstypabhängigkeiten

Als Nächstes geht es um die Frage, wie SharePoint-Inhaltstypen dazu verwendet werden können, die Verwaltung von Inhaltselementen zu strukturieren. Sie müssen mehrere Abhängigkeiten in Betracht ziehen, z. B. die Abhängigkeiten zwischen Dokumentbibliotheken und Listen, Inhaltstypen, Websitespalten und Feldtypen. Bibliotheken und Listen verweisen auf Inhaltstypen, die auf Websitespalten verweisen, die wiederum auf Feldtypen (z. B. die standardmäßigen WSS-Feldtypen „text“, „note“, „choice“, „number“, „currency“ und so weiter) verweisen, die sich in Microsoft .NET Framework-Assemblys wie der WSS-Kernassembly „Microsoft.SharePoint.dll“ befinden.

Als Beispiel wird erneut der System-Inhaltstyp herangezogen, der bereits bei der CAML-Definition des Manifestdateieintrags für den System-Inhaltstyp vorgeführt wurde. Wie Sie dort gesehen haben, enthält dieser Inhaltstyp ein FieldRef-Element, das auf eine Websitespalte namens „ContentType“ verweist. Beachten Sie, dass die Inhaltstypdefinition nicht die Websitespalte „ContentType“ selbst definiert. ContentType ist ein Text-Feld, das in der Elements-Manifestdatei „fieldswss.xml“ definiert wird, die sich im Ordner „%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields“ befindet. Der Text-Feldtyp wiederum ist in der Datei „fldtypes.xml“ definiert, die sich im Ordner „%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML“ befindet. Ein wichtiger Punkt, den Sie aus dieser Abhängigkeitsstruktur erkennen sollten, besteht darin sicherzustellen, dass alle Ressourcen auf Ihren SharePoint-Servern verfügbar sind.

Die Inhaltstypen, die Sie verwenden möchten, müssen auf der Websiteebene Ihrer Dokumentbibliotheken und Listen oder auf einer noch höheren Stufe der Websitehierarchie erstellt werden. In ähnlicher Weise müssen die Metadatenfelder Ihrer Inhaltstypen auf vorhandene Websitespalten verweisen. Sie können Ihren Inhaltstypen standardmäßige oder benutzerdefinierte Websitespalten hinzufügen, die auf standardmäßigen oder benutzerdefinierten Feldtypen basieren, müssen aber sicherstellen, dass die Websitespalten auf dem lokalen Standort existieren. Wenn Sie benutzerdefinierte Feldtypen verwenden möchten, müssen Sie darüber hinaus sicherstellen, dass die zugrunde liegenden .NET-Assemblys auf Ihren SharePoint-Servern installiert sind.

Ähnliche Abhängigkeiten bestehen bei Inhaltstypen, die auf Dokumentvorlagen, benutzerdefinierte Ereignisempfänger, Workflows und andere Komponenten verweisen. So kann beispielsweise die Inhaltstypdefinition ein DocumentTemplate-Element enthalten, das auf die mit dem Inhaltstyp verknüpfte Dokumentvorlage zeigt. Die Inhaltstypdefinition kann auch ein XmlDocuments-Element mit einem oder mehreren untergeordneten XmlDocument-Elementen enthalten, die zusätzliche Merkmale des Inhaltstyps wie Namespacedefinitionen, Dokumentinformationsbereichsdefinitionen oder benutzerdefinierte Informationen definieren.

Einrichten globaler Inhaltstypen

Benutzer mit Dokumenterstellungsberechtigungen können direkt in der SharePoint-Benutzeroberfläche neue Inhaltstypen und Websitespalten erstellen, aber die Inhaltstypen stehen dann in der Websitehierarchie nur am lokalen Standort und darunter zur Verfügung. Benutzerdefinierte Websitespalten sind nur am lokalen Standort verfügbar. Dies genügt nicht, wenn Sie globale Inhaltstypen einrichten möchten. Sie müssen sicherstellen, dass globale Inhaltstypen in allen Websitesammlungen Ihrer Umgebung verfügbar sind. An diesem Punkt sind SharePoint-Features sehr nützlich. SharePoint-Features lassen sich auf einfache Weise in mehreren Websitesammlungen installieren und aktivieren, um die entsprechenden Websitespalten- und Inhaltstypdefinitionen konsistent an allen Standorten anzuwenden.

Im Begleitmaterial zu diesem Artikel ist ein Beispielfeature namens „AdventureWorks“ enthalten, das demonstriert, wie ein globaler Inhaltstyp eingerichtet wird. Das Feature definiert einen allgemeinen Inhaltstyp namens „Customer Documentation“ (Kundendokumentation), der dazu verwendet werden kann, beliebige Kundenmaterialien wie Angebote und Werbebriefe zu erstellen. Es kann ohne Weiteres angenommen werden, dass alle diese Arten von Dokumenten mit Kundeninformationen wie Firmenname, Kontaktdetails und Adresse verknüpft werden müssen. Ich habe speziell für Ihren Inhaltstyp ein benutzerdefiniertes Feld namens „Customer Name“ (Kundenname) erstellt und einige integrierte Felder, z. B. „Department“ (Abteilung) und „Primary Phone“ (Primäre Telefonnummer), hinzugefügt. Sie können den Inhaltstyp und die Felder durch Bearbeiten der Datei „ContentTypes.xml“ ändern. Die Feldverweise können durch Bearbeiten der Datei „SiteColumns.xml“ geändert werden, die im Beispiel des Begleitmaterials enthalten ist.

Wenn Sie das Feature wie in der Datei „readme.htm“ beschrieben bereitstellen, können Sie es konsistent in mehreren Websitesammlungen aktivieren. Danach ist der Inhaltstyp „Customer Documentation“ global verfügbar. Dadurch können die einzelnen Abteilungen durch abgeleitete Inhaltstypen, die mit gezielten Dokumentvorlagen verknüpft sind, spezielle Kundendokumentationen erstellen. Das Begleitmaterial enthält Beispieldokumentvorlagen, die in Vertrieb und Beratung eingesetzt werden können. Abbildung 2 zeigt die resultierenden Inhaltstypen.

Abbildung 2** Über- und untergeordnete Inhaltstypen für die Kundendokumentation **(Klicken Sie zum Vergrößern auf das Bild)

Es stehen mehrere Optionen zur Wahl, um Features für benutzerdefinierte Websitespalten und Inhaltstypen in WSS 3.0 und MOSS 2007 zu erstellen. Sie können sich auch in das WSS 3.0-SDK einarbeiten und XML-Dateien von Grund auf neu schreiben. Außerdem können Sie wählen, mit SharePoint Designer eine Liste in ein persönliches Webpaket zu exportieren, die resultierende .fwp-Datei in eine .cab-Datei umbenennen, aus der .cab-Datei die Datei „manifest.xml“ extrahieren und danach in der Datei „manifest.xml“ nach ContentType-Definitionen suchen. Leider sind beide Verfahren unpraktisch und fehlerbehaftet.

Im Gegensatz dazu ist es erstaunlich einfach, in der SharePoint-Benutzeroberfläche benutzerdefinierte Websitespalten und Inhaltstypen zu erstellen. Bisher bietet diese Benutzeroberfläche noch keine Option, um die XML-Dateien eines Features zu bearbeiten. Features sind eine effiziente Möglichkeit für das Bereitstellen von SharePoint-Ressourcen, aber nach der Bereitstellung existieren die Ressourcen lediglich in der Inhaltsdatenbank. Vielleicht wird eine zukünftige Version von WSS auch die Möglichkeit bieten, ähnlich wie beim Export von Webparts auch Websitespalten und Inhaltstypen über die SharePoint-Benutzeroberfläche in XML-Dateien zu exportieren. Vorläufig müssen Sie mit den angebotenen Funktionen arbeiten.

Das Begleitmaterial enthält ein Webpart namens „ContentTypeSchema“, das als Ausgangspunkt dienen kann. Es verwendet das SharePoint-Objektmodell, um die SchemaXML-Eigenschaft aus dem ausgewählten Inhaltstyp zu extrahieren. Durch XSLT (Extensible Stylesheet Language Transformation)-basierte Transformationen leitet das Webpart entweder Field-Definitionen oder ContentType-Definitionen ab, je nachdem, welche Option Sie in der Benutzeroberfläche auswählen, bevor Sie auf die Schaltfläche „Display“ (Anzeigen) klicken.

Abbildung 3 zeigt dieses Webpart in Aktion. Es zeigt den Active Directory®-Inhaltstyp „Documentation“ an, auf dem der Inhaltstyp „Customer Documentation“ basiert wurde. Der Active Directory-Inhaltstyp „Documentation“ ist mit einer benutzerdefinierten Microsoft Word-Vorlage („Active Directory Template.dot“) verknüpft. Beachten Sie, dass dieser Inhaltstyp keine zusätzlichen Felder besitzt. Alle Felder werden vom übergeordneten Inhaltstyp geerbt.

Wenn Sie planen, das Webpart „ContentTypeSchema“ in Ihrer eigenen Umgebung zu verwenden, müssen Sie bedenken, dass dieses Webpart nicht gründlich getestet wurde. Das Webpart verwendet relativ komplizierte XSL-Transformationen, um ein Delta zwischen der SchemaXML-Eigenschaft des momentan ausgewählten Inhaltstyps und seines übergeordneten Inhaltstyps zu erstellen. Noch ist XSLT 1.0 nicht wirklich für erweiterte XML-Dokumentkonvertierungen konzipiert. Es gibt kein integriertes Feature zum Vergleichen von XML-Knoten. Darüber hinaus bereiten XML-Namespaces sowie CDATA-Abschnitte Schwierigkeiten, die XSLT 1.0 nicht effizient bewältigen kann.

SharePoint speichert die Definition von Websitespalten und Websiteinhaltstypen, die durch die SharePoint-Benutzeroberfläche oder das SharePoint-Objektmodell erstellt werden, innerhalb der Inhaltsdatenbank in einer Tabelle namens „ContentTypes“. Sehen Sie sich in Abbildung 3 die ID des benutzerdefinierten Inhaltstyps an. Danach würde die folgende T-SQL-Anweisung exakte Ergebnisse liefern: SELECT Definition FROM ContentTypes WHERE ContentTypeId = <Inhaltstyp-ID>.

Abbildung 3** Benutzerdefinierte Inhaltstypdefinition im ContentTypeSchema-Webpart **(Klicken Sie zum Vergrößern auf das Bild)

Für welches Verfahren Sie sich auch immer entscheiden, das Erstellen von Features für unternehmensweite Inhaltstypen ist äußerst einfach, sobald Ihnen die Websitespalte und die Inhaltstypdefinitionen vorliegen. Es wird empfohlen, ein einziges Feature für alle globalen Websitespalten und Inhaltstypen Ihrer Abteilung oder Ihres Unternehmens zu verwenden. Dadurch ist immer klar, wo neue Websitespalten- und Inhaltstypdefinitionen hinzugefügt werden müssen.

Unternehmensweite Suchvorgänge anhand benutzerdefinierter Metadaten

Ein unmittelbarer Vorteil von Inhaltstyphierarchien besteht darin, dass alle untergeordneten Inhaltstypen die Metadatenfelder des übergeordneten Inhaltstyps erben. Da alle Inhaltstypen gemeinsame Metadatenfelder besitzen, ist es für Benutzer recht leicht, in den Dokumentbibliotheken benutzerdefinierte Ansichten und Filter zu erstellen.

Dies wird durch das Beispielfeature „AdventureWorks“ einleuchtend demonstriert. Unabhängig vom Inhalt, den ein Berater oder Vertriebsmitarbeiter erstellt, erfordert das Speichern des resultierenden Word 2007-Dokuments in der Dokumentbibliothek die Angabe eines „Customer Name“ (Kundennamen), weil der übergeordnete Inhaltstyp „Customer Documentation“ dieses Metadatenfeld als obligatorisch definiert. Durch Gruppieren oder Filtern der Elemente in einer Dokumentbibliotheksansicht nach „Customer Name“ können Berater und Vertriebsmitarbeiter, wie in Abbildung 4 gezeigt, schnell und unkompliziert die gesamte vorhandene Dokumentation für einen Kunden finden.

Abbildung 4** Gruppieren verschiedener Dokumente in einer Bibliothek basierend auf gemeinsamen Metadaten **(Klicken Sie zum Vergrößern auf das Bild)

Gemeinsame Metadaten erleichtern es außerdem, mit den Suchfunktionen von WSS 3.0 und MOSS 2007 über mehrere Dokumentbibliotheken und Websites hinweg Inhalte zu finden. WSS unterstützt innerhalb einer einzigen Websitesammlung die Suche in mehreren Bibliotheken, Listen und Websites. MOSS 2007 geht über diese Grundfunktionen noch hinaus, indem das Implementieren eines unternehmensweiten Suchcenters sowie das Verwalten benutzerdefinierter Metadaten in der Benutzeroberfläche der Zentraladministration von SharePoint 3.0 ermöglicht wird. Aus diesem Grund beziehen sich die folgenden Erklärungen in erster Linie auf MOSS 2007.

Wenn Sie in MOSS 2007 einen Anbieter für gemeinsame Dienste (Shared Service Provider, SSP) konfigurieren und Ihre SharePoint-Websites crawlen, kann MOSS 2007 automatisch die in den Inhaltsquellen verwendeten benutzerdefinierten Metadatenfelder erkennen. Dementsprechend können Sie die benutzerdefinierten Metadatenfelder in der Liste der gecrawlten Eigenschaften finden.

In SharePoint-Features definierte Metadatenfelder gehören in der Regel in die SharePoint-Kategorie. Um deren Position in der SharePoint-Zentraladministration zu finden, klicken Sie im Menü „Schnellstart“ unter „Verwaltung der gemeinsamen Dienste“ auf den Link zu Ihrem SSP. Klicken Sie dann auf „Sucheinstellungen“, auf „Eigenschaftenzuordnungen für Metadaten“, im Menü „Schnellstart“ auf „Gecrawlte Eigenschaften“, und öffnen Sie anschließend die SharePoint-Kategorie.

Dies soll anhand eines Beispiels aus der Praxis demonstriert werden. Das Customer Name-Metadatenfeld wird am Ende zur gecrawlten Eigenschaft namens „ows_Customer_x0020_Name“. SharePoint versieht gecrawlte Eigenschaften mit dem Präfix „ows_“, und „_x0020_“ ist die codierte Version eines einzigen Leerzeichens. Wenn Sie die Details dieser gecrawlten Eigenschaft anzeigen möchten, werden Sie feststellen, dass diese standardmäßig im Suchindex enthalten ist, damit Benutzer mithilfe der Werte dieser gecrawlten Eigenschaft Inhaltssuchvorgänge ausführen können. Um die Suchpräzision zu erhöhen, sollten Sie die gecrawlte Eigenschaft jedoch nicht einer verwalteten Eigenschaft zuordnen, damit die Benutzer explizit anhand des Kundennamens nach Inhalten suchen können.

Beim Zuordnen gecrawlter Eigenschaften zu verwalteten Eigenschaften haben Sie zwei Möglichkeiten. Sie können für jede gecrawlte Eigenschaft automatisch eine neue verwaltete Eigenschaft generieren lassen oder gecrawlte Eigenschaften manuell verwalteten Eigenschaften zuordnen. Das erste Verfahren ist möglich, wenn Sie die Einstellungen der gewünschten Kategorie gecrawlter Eigenschaften anzeigen. (Wenn Sie die gecrawlten Eigenschaften in einer Kategorie wie der SharePoint-Kategorie anzeigen, klicken Sie in der Verknüpfung „Schnellstart“ auf die Option „Kategorie bearbeiten“.) Unter „Einstellungen für massengecrawlte Eigenschaft“ müssten Sie das Kontrollkästchen „Automatisch eine neue verwaltete Eigenschaft für jede gecrawlte Eigenschaft in dieser Kategorie generieren“ auswählen. SharePoint versieht automatisch erstellte verwaltete Eigenschaften mit dem Präfix „ows_“ und codiert Leerzeichen durch die ESC-Sequenz „x0020“. Die verwaltete Eigenschaft für die gecrawlte Eigenschaft „ows_Customer_x0020_Name“ heißt demnach „owsCustomerx0020Name“. Dies ist allerdings kein besonders benutzerfreundlicher Eigenschaftsname.

Eine bessere Strategie wäre es vielleicht, gecrawlte Eigenschaften manuell verwalteten Eigenschaften zuzuordnen, nachdem Sie die unternehmensweiten Inhaltstypen bereitgestellt haben. Sie können eine gecrawlte Eigenschaft einer oder mehreren verwalteten Eigenschaften zuordnen. Um neue verwaltete Eigenschaften zu erstellen, klicken Sie in der SharePoint-Zentraladministration im Menü „Schnellstart“ unter „Verwaltung der gemeinsamen Dienste“ auf den Link zu Ihrem SSP, klicken Sie auf „Sucheinstellungen“, dann auf „Eigenschaftenzuordnungen für Metadaten“ und anschließend auf „Neue verwaltete Eigenschaft“, um die erforderlichen Informationen anzugeben und die neue verwaltete Eigenschaft mit der gewünschten gecrawlten Eigenschaft zu verknüpfen.

Danach können die Benutzer relevante Inhaltselemente finden, indem sie entweder die verwalteten Eigenschaften mit der Syntax-Eigenschaft: oder die erweiterte Suche verwenden. Wenn Sie beispielsweise die gecrawlte Eigenschaft „ows_Customer_x0020_Name“ einer verwalteten Eigenschaft namens „Customer“ (Kunde) zuordnen, können die Benutzer anschließend nach allen Dokumenten eines Kunden suchen, indem sie einfach im Standardsuchfeld „Customer: <Kundenname>“ eingeben (Beispiel: „Customer: Contoso“).

Es ist auch eine gute Idee, verwaltete Eigenschaften für die wichtigsten Metadatenfelder Ihrer Inhaltstypen in die Eigenschaftsliste auf der Seite „Erweiterte Suche“ aufzunehmen. Um dies zu erreichen, öffnen Sie die Seite „Erweiterte Suche“, klicken Sie auf „Websiteaktionen“, und wählen Sie den Befehl „Seite bearbeiten“ aus. Jetzt können Sie im Feld „Erweiterte Suche“ auf „Bearbeiten“ klicken, um die Option „Freigegebenes Webpart bearbeiten“ auszuwählen. Wenn Sie die Properties-Kategorie erweitern und den Cursor in das entsprechende Textfeld setzen, können Sie auf die Schaltfläche klicken, um das Properties-XML-Dokument zu bearbeiten. Sie müssen dem <PropertyDefs>-Element eine Eigenschaftsdefinition (z. B. <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>) hinzufügen. Zusätzlich müssen Sie unter einem ResultType-Element (z. B. dem Element <ResultType DisplayName="All Results" Name="default">) einen Verweis auf diese Eigenschaftsdefinition (z. B. <PropertyRef Name="Customer" />) hinzufügen. In Abbildung 5a ist die resultierende Benutzeroberfläche der erweiterten Suche dargestellt. Abbildung 5b zeigt die Ergebnisse dieser Suche.

Abbildung 5a** Suche nach IT-Infrastrukturdokumentation anhand des Kundennamen **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 5b** Die Ergebnisse der Kundennamenssuche **(Klicken Sie zum Vergrößern auf das Bild)

Gewährleisten von Informationskonsistenz

Jetzt habe Sie auf der Grundlage von MOSS 2007 erfolgreich die wichtigsten Metadatenfelder und Inhaltstypen standardisiert und Suchfunktionen über Websitesammlungen in Ihrem Unternehmen hinweg erweitert. Es muss nun unbedingt sichergestellt werden, dass die Benutzer korrekte Informationen in die Metadatenfelder eingeben.

Dies lässt sich auf zwei Arten einrichten. Erstens können Sie den Standarddokumentinformationsbereich in Ihren Dokumentvorlagen durch ein benutzerdefiniertes InfoPath®-Formular ersetzen, das Benutzern wie in einem Listenfeld eine vordefinierte Auswahl von Eingabeoptionen bietet. Zweitens können Sie einen Ereignisempfänger an den Inhaltstyp binden und danach die Richtigkeit der Metadaten und sonstiger Informationen überprüfen, sobald Benutzer entsprechende Inhaltselemente erstellen, ändern oder löschen.

Beide Möglichkeiten ergänzen sich gegenseitig. Ein InfoPath-Formular stellt in erster Linie eine praktische Möglichkeit bereit, die Eigenschaften eines SharePoint-Inhaltstyps zu bearbeiten, ein Ereignisempfänger dagegen kann auch dann gültige Metadaten gewährleisten, wenn Benutzer die Inhaltstypeigenschaften außerhalb des InfoPath-Formulars bearbeiten. Sie können Ereignishandler an einen bestimmten Inhaltstyp binden, was Ihnen die Möglichkeit bietet, unabhängig von der Dokumentbibliothek für alle mit einem bestimmten Inhaltstyp verknüpften Dokumente in allen Websitesammlungen Ereignisse festzulegen. Weitere Informationen zum Entwickeln und Bereitstellen von Ereignishandlern finden Sie unter msdn2.microsoft.com/ms453149.

Die einfachste Methode, um einen Inhaltstyp mit einem benutzerdefinierten Dokumentinformationsbereich zu verknüpfen, besteht wahrscheinlich darin, auf einem Computer, auf dem InfoPath 2007 installiert ist, die Dokumentinformationsbereichseinstellungen des Inhaltstyps in der SharePoint-Benutzeroberfläche anzuzeigen. Danach können Sie unter „Vorlage für den Dokumentinformationsbereich“ auf die Verknüpfung „Eine neue benutzerdefinierte Vorlage erstellen“ klicken, um InfoPath 2007 im Entwurfsmodus zu starten. Wenn Ihr Websiteinhaltstyp jedoch Websitespalten ohne explizites SourceID-Attribut enthält, könnte die Situation eintreten, dass InfoPath kein gültiges XSD-Schema für das Dokumentinformationsbereichsformular erstellen kann. So enthält beispielsweise der an früherer Stelle eingeführte Inhaltstyp „Customer Documentation“ verschiedene kontaktbezogene Spalten, z. B. „Department“ (Abteilung), „Office“ (Büro) und „e-mail“ (E-Mail-Adresse), die dieses Problem verursachen könnten, wie in Abbildung 6 zu sehen ist.

Abbildung 6** XSD-Schema-Inkompatibilitäten in InfoPath 2007 **(Klicken Sie zum Vergrößern auf das Bild)

Derzeit haben Sie beim Auftreten dieses Problems zwei Möglichkeiten. Sie können entweder Verweise auf Websitespalten ohne explizites SourceID-Attribut aus der Inhaltstypdefinition entfernen oder die integrierten Websitespalten, die das Problem verursachen, durch benutzerdefinierte Websitespalten ersetzen, die mit InfoPath 2007 kompatibel sind. Bedenken Sie dabei, dass die Feldverweise eines auf CAML basierenden Inhaltstyps nicht geändert werden können, nachdem er in der Inhaltsdatenbank bereitgestellt wurde, insbesondere dann, wenn bereits untergeordnete Inhaltstypen erstellt wurden. Sie können nicht mehr einfach die Definitionsdatei des auf CAML basierenden Inhaltstyps aktualisieren, und Sie können auch keine Änderungen an untergeordnete Inhaltstypen weitergeben, denn Windows SharePoint Services verfolgt keine Änderungen, die an der Definition des übergeordneten Inhaltstyps vorgenommen werden.

Um Änderungen nach unten weiterzugeben, müssen Sie den übergeordneten Inhaltstyp über die SharePoint-Benutzeroberfläche oder das SharePoint-Objektmodell ändern oder einen neuen, aus dem vorhandenen Inhaltstyp abgeleiteten Inhaltstyp definieren. Das zuletzt genannte Verfahren ermöglicht Ihnen, die kritischen Felder zu entfernen und neue Spalten hinzuzufügen. Danach können Ihre Benutzer zukünftige Inhaltstypen vom neuen Inhaltstyp ableiten. Um zu verhindern, dass Benutzer den falschen Inhaltstyp auswählen, fügen Sie den vorherigen Inhaltstyp der Inhaltstypgruppe „_Hidden“ hinzu.

Wie bereits erwähnt, können auf CAML basierende Inhaltstypen nach ihrer Bereitstellung und Aktivierung nicht mehr aktualisiert werden. Daher ist es wichtig, globale Inhaltstypen vor der Bereitstellung zu testen. Weitere Informationen finden Sie im MSDN-Artikel „Aktualisieren von Inhaltstypen“ unter msdn2.microsoft.com/aa543504.

Wenn Sie einen Inhaltstyp mit geeigneten Feldverweisen erstellt haben, können Sie in InfoPath 2007 einen benutzerdefinierten Dokumentinformationsbereich erstellen. Die beste Strategie dazu besteht darin, die Websitebesitzer benutzerdefinierte Dokumentinformationsbereiche für ihre untergeordneten Inhaltstypen erstellen zu lassen. InfoPath 2007 bietet die Möglichkeit, den benutzerdefinierten Dokumentinformationsbereich direkt im ausgewählten Inhaltstyp zu veröffentlichen, was das Bereitstellungsszenario vereinfacht. Es ist aber auch möglich, das InfoPath-Formular an einem zentralen Ort wie in einer Dokumentbibliothek zu veröffentlichen und in den Inhaltstyp einen Verweis auf den Dokumentinformationsbereich aufzunehmen. Dies ist die beste Vorgehensweise, wenn Sie planen, einen benutzerdefinierten Dokumentinformationsbereich zusammen mit Ihren CAML-Inhaltstypen bereitzustellen. Abbildung 7 veranschaulicht die Implementierungsarchitektur.

Abbildung 7** XSN-Dateiimplementierung an einem zentralen Ort in MOSS 2007 **(Klicken Sie zum Vergrößern auf das Bild)

Der Download für diesen Artikel beinhaltet ein Feature namens „AdventureWorks_Update“, das das vorherige Feature „AdventureWorks“ um zusätzliche Websitespalten erweitert, die mit InfoPath 2007 funktionieren. Das Feature „AdventureWorks_Update“ markiert den ursprünglichen Inhaltstyp „Customer Documentation“ als verborgen und leitet einen neuen Inhaltstyp namens „Customer Docs“ ab, der die geerbten integrierten Felder durch die neuen Websitespalten ersetzt und dem neuen Inhaltstyp einen benutzerdefinierten Dokumentinformationsbereich zuordnet.

Die neue Inhaltstypdefinition „Customer Docs“ enthält ein XmlDocument-Element, das Informationen zum Dokumentinformationsbereich bereitstellt. Insbesondere das xsnLocation-Element zeigt auf das InfoPath-Formular „http://companyresources/DIPs/customerDIP.xsn“, von dem der Dokumentinformationsbereich implementiert wird. Ausführliche Anleitungen dazu, wie das Feature „AdventureWorks_Update“ angewendet wird, finden Sie in der Datei „readme.htm“ im Ordner „AdventureWorks_Update“.

Schlussbemerkung

Sie können SharePoint-Inhaltstypen verwenden, um Metadatenrichtlinien zu erstellen und sie konsistent im gesamten Unternehmen zur Inhaltsverwaltung einzusetzen. Die Hierarchie der Inhaltstypen ermöglicht Ihnen, Merkmale, die für die ganze Unternehmensumgebung wichtig sind, zu standardisieren und sie durch Vererbung gleichmäßig auf alle Websites anzuwenden.

Unter anderem ist es möglich, die integrierten Suchfunktionen von MOSS 2007 zu erweitern, damit Benutzer bestimmte Inhalte schneller und einfacher finden können. Es ist auch möglich, in Bezug auf Metadaten eine Informationskonsistenz durchzusetzen und zentralisierte Informationsverwaltungsrichtlinien einzurichten. Die beste Strategie dazu besteht darin, globale Inhaltstypen mit den abstraktesten Metadatenmerkmalen zu standardisieren, um den Bedarf an zukünftigen Änderungen zu minimieren. Die auf einem sorgfältig konzipierten Inhaltsmodell basierenden SharePoint-Inhaltstypen können neue Funktionen bereitstellen, um die Verwaltung des Inhaltslebenszyklus im gesamten Unternehmen zu standardisieren.

Pav Cherny ist Präsident der Biblioso Corporation und hat sich als IT-Experte und Autor auf Microsoft-Technologien für Zusammenarbeit und einheitliche Kommunikation spezialisiert. Seine bisherigen Veröffentlichungen befassen sich mit IT-Vorgängen und Systemverwaltung.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.