Kolumne: SharePoint ganz praktisch

Felddefinition und Inhaltstypen (Teil 1)
Kommentare

In den vorherigen Ausgaben dieser Kolumne wurden verschiedene Möglichkeiten der programmatischen Abfrage und Manipulation von Listendaten in SharePoint erläutert. Die heutige Ausgabe widmet sich der Planung und Definition eigener Datenstrukturen, um Daten strukturiert ablegen und verwalten zu können.

Die korrekte Planung von Datenstrukturen innerhalb von SharePoint ist nicht nur wichtig für eigene SharePoint-basierte Anwendungen. Auch bei der Einführung von SharePoint als Content-Management-System (CMS) oder als Zusammenarbeitsportal ist eine Planung von Datenstrukturen zwingend erforderlich. Geschieht dies nicht, ergeben sich im späteren Verlauf erhebliche Probleme, die bei größeren Datenmengen zunehmen.

Innerhalb von SharePoint stellen die so genannten Inhaltstypen (engl. Content Types) definierte Datenstrukturen dar. In Analogie zu einer Datenbank ist ein Inhaltstyp vergleichbar mit dem Schema einer Tabelle. Das bedeutet, ein Inhaltstyp ist nicht in der Lage, selbst Daten zu speichern. Er beschreibt lediglich eine Datenstruktur. Damit gemäß der definierten Struktur Daten gespeichert werden können, muss der Inhaltstyp einer konkreten Liste zugeordnet werden (Kasten „Listen und Inhaltstypen“). Wie in Abb. 1 erkennbar, können einer Liste zeitgleich mehrere Inhaltstypen zugeordnet werden. Der wesentliche Vorteil eines Inhaltstyps besteht in der Möglichkeit der Wiederverwendung. Außerdem können Inhaltstypen Funktionen bzw. Erweiterungen, wie z. B. Workflows und Ereignisempfänger (Event Receiver), zugeordnet werden. Laut MSDN definiert sich ein Inhaltstyp wie folgt [1]: „Ein Inhaltstyp ist eine wiederverwendbare Sammlung von Metadaten (Spalten), Workflows, Verhaltensweisen und anderen Einstellungen für eine Kategorie von Elementen oder Dokumenten in einer SharePoint-2013-Liste oder -Dokumentbibliothek. Mithilfe von Inhaltstypen können Sie die Einstellungen für eine Kategorie von Informationen zentral und so verwalten, dass Sie diese wiederverwenden können.“

Listen und Inhaltstypen SharePoint-Listen können mehreren Inhaltstypen zugeordnet werden. Somit wird es möglich, verschiedene Datenstrukturen innerhalb einer Liste abzulegen, was SharePoint-Listen von Datenbanktabellen unterscheidet. In der SharePoint-Oberfläche erkennt man über den Neueintrag im Listen- bzw. Bibliotheksmenü, ob mehrere Inhaltstypen möglich sind. Die freigegebenen Inhaltstypen stehen bei der Neuanlage eines Eintrags direkt zur Auswahl zur Verfügung (Abb. 1). Damit eine SharePoint-Bibliothek mehrere Inhaltstypen verwalten kann, muss die Einstellung „Allow management of content types“ auf „Yes“ eingestellt werden. Die Option ist innerhalb der Listeneinstellungen über General Settings | Advanced settings zu finden.

Abb. 1: Einer Liste bzw. Bibliothek zugewiesene Inhaltstypen

Abb. 1: Einer Liste bzw. Bibliothek zugewiesene Inhaltstypen

Aufbau von Inhaltstypen

Wie aus den oberen Erläuterungen bereits deutlich wurde, wird ein Inhaltstyp durch eine Menge von Feldern und Spalten zusammengesetzt. Zusätzlich besitzt jeder Inhaltstyp einen Namen und ist einer Gruppe zugordnet. Jeder Inhaltstyp wird von einem übergeordneten Inhaltstyp abgeleitet, d. h. in SharePoint existiert kein direkt verwendbarer Inhaltstyp ohne übergeordneten Inhaltstyp. Abb. 2 verdeutlicht dies anhand eines Ausschnitts der Inhaltstypenhierarchie in SharePoint. Eine vollständige Übersicht der Basisinhaltstypen ist unter [2] abrufbar. Wie erkennbar ist, leitet der Inhaltstyp Item vom versteckten Systeminhaltstyp System ab. Der Inhaltstyp System ist von seiner Stellung innerhalb der Hierarchie vergleichbar mit der .NET-Klasse Object. Alle weiteren Inhaltstypen der zweiten Ebene leiten dann vom Item-Inhaltstyp ab. Diese Ableitung bewirkt, dass alle Felder des übergeordneten Inhaltstyps auch im untergeordneten Inhaltstyp enthalten sind. Dieses Verhalten ist allerdings anpassbar, und die Vererbung kann unterbunden werden. Bleibt die Vererbung bestehen, können Änderungen, die am übergeordneten Inhaltstyp durchgeführt werden, per Push-down-Mechanismus auch für die abgeleiteten Inhaltstypen übernommen werden. Der umgekehrte Weg ist allerdings nicht möglich, d. h. Änderungen an untergeordneten Inhaltstypen werden nicht auf die übergeordneten Inhaltstypen übernommen. SharePoint selbst bringt schon einige eingebaute Inhaltstypen mit, die auch für eigene Zwecke verwendet werden können. Fehlen für eigene Anforderungen lediglich einige Felder bzw. Spalten, kann ein eigener Inhaltstyp erstellt werden, der vom gewünschten SharePoint-Inhaltstyp ableitet. Der so neu definierte Inhaltstyp kann dann um die fehlenden Spalten ergänzt werden. Passt kein vorhandener Inhaltstyp, kann ein vollständig neuer Inhaltstyp basierend auf dem Systeminhaltstyp definiert werden. Wie eigene Inhaltstypen anzulegen sind, wird nachfolgend erläutert.

Abb. 2: Inhaltstypenhierarchie

Abb. 2: Inhaltstypenhierarchie

Eigene Inhaltstypen

Wenn für eine eigene SharePoint-Anwendung ebenfalls Listen als Datenspeicher eingesetzt werden sollen, können die benötigten (Custom-)Listen entweder direkt über das SharePoint-Objektmodell erstellt oder es kann ein Inhaltstyp definiert werden. Basierend auf dem Inhaltstyp kann dann eine Liste erstellt werden. Die erste geschilderte Variante geht schneller, besitzt aber zwei wesentliche Nachteile:

  1. Für die eigene Liste existiert keine Vorlage, daher muss die Liste immer programmatisch bzw. manuell angelegt werden.
  2. Das Auffinden eigener erstellter Listen innerhalb der SharePoint-Hierarchie wird aufgrund des fehlenden Inhaltstyps erschwert. Gleiches gilt für die dort gespeicherten Informationen.

Der erste erläuterte Nachteil ist nicht sehr problematisch, gravierender ist der zweite Punkt. Werden eigene Listen – ohne gemeinsamen Inhaltstyp – programmatisch erstellt, haben die Listen zwar die gleiche Struktur, können aber nicht einfach aggregiert werden (Kasten „Suche nach Inhalten“).

Suche nach Inhalten Mithilfe des SharePoint-API ist es möglich, über eine CAML-Abfrage alle Listeneinträge zusammenzuführen, die einen gemeinsamen Inhaltstyp besitzen. So kann z. B. innerhalb einer Site Collection eine Abfrage definiert werden, die alle Aufgabeneinträge – also Listeneinträge, die auf dem Inhaltstyp „Aufgabe (Task)“ basieren – zu einer Liste zusammenführt. Dabei kann die Listenzusammenführung über die gesamte Site-Hierarchie erfolgen. SharePoint wertet dazu den Inhaltstyp der Einträge aus, um passende Einträge zu ermitteln.

Um einen Inhaltstyp anzulegen, existieren mehrere Wege. Ein Weg führt direkt über die SharePoint-Oberfläche. Auf der Seite Site Settings im Bereich Galleries befindet sich der Link Site Content Types. Wird dieser Link angewählt, erscheint eine Übersicht aller vorhandenen (sichtbaren) Inhaltstypen. Oberhalb der Seite befindet sich ein Link namens Create, der es erlaubt, einen eigenen Inhaltstyp anzulegen. Ein anderer Weg führt über den SharePoint Designer. Auch dieser ermöglicht die Anlage von Inhaltstypen. Weitere Informationen dazu sind unter [3] zu finden. Die beiden geschilderten Optionen eignen sich allerdings nicht für eine lösungsbasierte Bereitstellung via WSP-Paket. Die Erstellung eines WSP-Pakets für die Bereitstellung eigener Inhaltstypen geschieht wieder über Visual Studio. Unterschieden werden kann hierbei zwischen einer deklarativen und einer programmatischen Erstellung eines Inhaltstyps.

Deklarative Erstellung

Für die deklarative Erstellung eines Inhaltstyps existiert in Visual Studio eine Projektvorlage. Die initiale Erstellung verläuft wie folgt:

  1. Starten Sie Visual Studio und beginnen Sie über File | Project | New … ein neues Projekt.
  2. Für die Anlage eines Inhaltstyps steht die Vorlage „Content Type“ bereit. Sie befindet sich in der Kategorie SharePoint | 2013. Selektieren Sie diese Vorlage und vergeben Sie eine passende Projektbezeichnung in den unteren Eingabefeldern. Verlassen Sie danach den Dialog über OK.
  3. Wählen Sie im folgenden Dialog „Specify the site and security level for debugging“ eine gültige SharePoint-Testseite aus. Wählen Sie als Trust-Level „Deploy as a farm solution“. Wechseln Sie danach über die Schaltfläche Next zum nächsten Dialogschritt.
  4. Da jeder Inhaltstyp einen übergeordneten Inhaltstyp besitzt, muss dieser nun, wie in Abb. 3 zu sehen, spezifiziert werden.
  5. Dem neuen Projekt wurde nun ein Content-Type-Ordner hinzugefügt. Er trägt in der Regel zunächst den Namen „ContentType1“. Für unser Beispiel wird der Ordner in „Kunden“ umbenannt.
Abb. 3: Auswahl eines übergeordneten Inhaltstyps

Abb. 3: Auswahl eines übergeordneten Inhaltstyps

Innerhalb des Content-Type-Ordners „Kunden“ befindet sich eine elements.xml-Datei, die die Struktur des angelegten Inhaltstyps beschreibt. Listing 1 zeigt den aktuellen Inhalt der Datei. Der Knoten ContentType ist für die Definition eines Inhaltstyps zuständig. Die hier verwendeten Attribute sind vergleichbar mit den zu spezifizierenden Werten bei der manuellen Anlage eines Inhaltstyps. Der Knoten Content Type unterstützt noch weitere Attribute, eine vollständige Liste ist in der MSDN-Hilfe unter [4] abrufbar. Die Namen der meisten hier verwendeten Attribute erklären deren Funktion bereits. Das Attribut Inherits legt fest, ob spätere Änderungen, die an den übergeordneten Inhaltstypen vorgenommen werden, auf den untergeordneten Inhaltstyp übernommen werden sollen. Auf das ID-Attribut wird im nächsten Abschnitt weiter eingegangen.

 
http://schemas.microsoft.com/sharepoint/">
  
    
    
  

Conten-Type-ID

Wie in Listing 1 erkennbar, wurde dem neuen Inhaltstyp automatisch eine ID zugordnet. Diese definiert eine system- und weltweit eindeutige Kennung für den Inhaltstyp. Zusammengesetzt wird die ID aus der ID des übergeordneten Inhaltstyps plus einem weltweit eindeutigen GUID, wobei die sonst üblichen Bindestriche aus dem GUID entfernt werden. Um Ihnen dabei zu helfen, das Schema der ID-Zusammensetzung besser zu verstehen, zeigt Tabelle 1 einen Ausschnitt des Dokumenteninhaltstyps und stellt die Ableitungshierarchie der Inhaltstypen dar. Am Tabellenanfang ist der System Content Type mit der ID 0x aufgeführt. Von ihm leitet der Inhaltstyp Item ab. Dieser besitzt die eindeutige ID 0x01, wobei 0x auf den Systeminhaltstyp verweist. Von Item wird unter anderem der Document-Inhaltstyp abgeleitet. Dieser besitzt die ID 0x0101, wobei die ersten Bestandteile der ID wieder aus den IDs der übergeordneten Inhaltstypen zusammengesetzt wurden. Aus der Tabelle ergibt sich daher für die Zusammensetzung einer ID folgendes Schema: [Parent Content Type ID][XX], wobei XX eine zweistellige Nummer darstellt. Dieses Schema erklärt die oberen Einträge der Tabelle, jedoch nicht den letzten Eintrag. Der letzte Eintrag verwendet ein etwas abgewandeltes Muster. Zu Beginn werden hier auch wieder die IDs der übergeordneten Inhaltstypen aufgeführt. Den Abschluss bildet jedoch ein GUID mit entfernten Bindestrichen. Um die übergeordneten IDs und den GUID auseinanderhalten zu können, wurden zwei Nullen dazwischen eingefügt. Das hier verwendete Schema hat folgenden Aufbau: [Parent Content Type IDs]00[hexadezimale Guid]. Somit existieren zwei Möglichkeiten, ID-Werte für einen Inhaltstyp festzulegen. Die erste Variante wird für eingebaute Inhaltstypen benutzt. Dieses Schema macht es sehr einfach, die Vererbungshierarchie anhand der ID abzulesen. Eigene Inhaltstypen sollten diese Variante der ID-Generierung nicht verwenden, sondern immer die zweite Variante. Durch die Anwendung eines GUID als letzten Bestandteil der ID wird sichergestellt, dass diese weltweit eindeutig ist und somit Konflikte ausgeschlossen sind.

Content Type

Übergeordnet

Content-Type-ID

System

Keiner

0x

Item

System

0x01

Document

Item

0x0101

Basic Page

Document

0x010109

Web Part Page

Basic Page

0x01010901

List View Style

Document

0x010100734778F2B7DF462491FC91844AE431CF

Tabelle 1: Zusammensetzung der ID für einen Inhaltstyp

Felder entfernen und hinzufügen

Bisher hat der eigene Inhaltstyp den gleichen Aufbau wie der übergeordnete Kontaktinhaltstyp. Dies ist in der Regel nicht gewünscht. Daher wird nun demonstriert, wie beim neu erstellten Inhaltstyp einige geerbte Felder entfernt und neue Felder hinzugefügt werden können. Auch dieses geschieht wieder vollständig auf deklarative Art und Weise. Anzupassen ist die bereits erläuterte elements.xml-Datei. Bisher definiert sie nur den Rahmen des neuen Inhaltstyps, das Schema des Inhaltstyps wird innerhalb des Knotens ContentType festgelegt, die Feldauflistung ist über den Unterknoten FieldRefs modifizierbar. Innerhalb des Knotens können Felder hinzugefügt oder entfernt werden (Listing 2). Hinzugekommen ist im Vergleich zu Listing 1 der Knoten FieldRefs. Innerhalb des Knotens werden über die ersten drei RemoveFieldRef-Knoten die Felder State/Provence, WebPage und E-Mail2, die vom übergeordneten Inhaltstyp geerbt wurden, entfernt. Anschließend werden über FieldRef-Knoten dem Inhaltstyp drei neue Felder hinzugefügt. Den ersten beiden Feldern wird zusätzlich über das Attribut DisplayName ein neuer Anzeigetext zugewiesen. Bei den ersten beiden Feldern handelt es sich um bereits vorhandene, also eingebaute, SharePoint-Felder. Das letzte Feld existiert allerdings noch nicht in SharePoint und wird im zweiten diesbezüglichen Teil der SharePoint-Kolumne deklarativ angelegt.

 
http://schemas.microsoft.com/sharepoint/">
  
    
      
      
      
      
     
      
      
      
      
      
      
      
    

Zusammenfassung

Bisher wurde erläutert, wie Inhaltstypen aufgebaut sind und wie eigene Inhaltstypen erstellt werden können. Im nächsten Teil der Kolumne wird es um die Anlage eigener Felddefinitionen gehen, um die programmatische Erstellung von Inhaltstypen und darum, wie einmal installierte Inhaltstypen aktualisiert werden können. Weiterhin wird demonstriert, auf welchen verschiedenen Wegen Informationen basierend auf Inhaltstypen abgefragt werden können. Dabei wird die Wichtigkeit eigener Inhaltstypen noch deutlicher werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -