Listen spielen bei SharePoint die zentrale Rolle. Mit SharePoint 2010 wurde der Umgang mit Listen verbessert. Neben einer Performance-Optimierung gibt es Datenintegrität und XSL-Unterstützung.
Für den Umgang mit sehr grossen Listen soll "List-Throttling" die Performance verbessern
Listen und Items sind bei SharePoint seit jeher die zentralen Bausteine für das Speichern von Daten aller Daten. Gleichzeitig bilden sie die Basis für die Dokumentbibliotheken. Bei SharePoint 2010 wurde der Umgang mit Listen und den darin gespeicherten Daten weiter verbessert. Wie LINQ to SharePoint den Umgang mit Listendaten im Programmcode vereinfacht, wurde in der letzten Folge beschrieben [1]. In dieser Folge geht es um die Themen Performance, Datenintegrität und die Anpassung von Listenansichten.
10 Millionen Items
Für den Umgang mit einer grossen Menge an Objekten wurde bei SharePoint 2010 die Listen und Dokumentbibliotheken zugrundeliegende Architektur (Datenspeicherung, Abfragen usw.) noch einmal optimiert. Selbstbewusst gibt man bei Microsoft die Zahl von 10 Millionen Items an, bei er sich eine Liste noch effizient nutzen lassen lässt. Eine als Archiv verwendete und wenig frequentierte Liste soll sogar bis zu 100 Millionen Items aufnehmen können. Wie bei den Vorgängerversionen kann es aber auch in SharePoint 2010 – je nach verwendeter Hardware und Komplexität der Liste – bei der Abfrage der Daten zu Performance-Engpässen kommen. Um diese Problematik zu entschärfen, hat Microsoft ein List Throttling eingeführt. Es erlaubt eine bessere Kontrolle über die Menge an Datensätzen, die eins Benutzer abrufen kann. Bei Listen mit Tausenden von Einträgen kann der Administrator verhindern, dass Anfragen ausgeführt werden, bei denen ein bestimmtes Limit an angeforderten Items (Default-Einstellung: 5000 Items) überschritten wird. Falls der angegebene Schwellwert doch überschritten wird, erhält der Benutzer nur die neuesten Listeneinträge angezeigt und wird gleichzeitig aufgefordert, seine Anfrage mit Filtern weiter einzuschränken (Bild 1).
List Throttling bietet eine ganze Reihe von weiteren Einstellungsmöglichkeiten. So kann etwa für Administratoren und Auditoren ein höherer Schwellwert für das Throttling festgelegt werden. Ausserdem lässt sich ein Zeitfenster (z.B. ausserhalb der Arbeitszeiten) definieren, während dessen die Abfrage auf umfangreiche Listen erlaubt werden soll. Für Entwickler interessant ist, dass sich die Throttling-Einstellungen über das SharePoint-Objektmodell (sofern der Administrator dies gewährt) überschreiben lassen. Die entsprechenden Eigenschaften sind in der Microsoft.SharePoint.Administration.SPWebApplication-Klasse zu finden [2]. Ausserdem verfügen die SPQuery- als auch SPSiteDataQuery-Klasse die RequestThrottleOverride-und QueryThrottleMode-Eigenschaften, über die sich das Verhalten des Throttlings manipulieren lässt [3]
Eindeutige Felder
Neu können in SharePoint-Listen eindeutige Felder definiert werden. Damit lässt sich sicherstellen, dass der Eintrag eines Feldes nur ein einziges Mal vorkommt (Auftragsnummer, E-Mailadresse etc.). Solche Unique Columns müssen zwingend indexiert werden und können zu einer schnelleren Ausführung von Abfragen beitragen. Bereits existierende Felder, lassen sich auch nachträglich als Unique Column festlegen, unter der Voraussetzung natürlich, dass die darin gespeicherten Daten entsprechend eindeutig sind. Neben den eindeutigen Columns gibt es zudem noch die Möglichkeit mehrere Spalten zu einem Index zusammenzufassen, was unter Umständen wiederum zu Performancevorteile führen kann. Pro Liste können insgesamt bis zu 20 Indizes angelegt werden. Dabei sollte man unbedingt beachten, dass sich mit jedem verwendeten Index auch der Speicherbedarf der Liste in der Content Database erhöht.
Echte Relationen
In SharePoint 2010 lassen sich erstmals echte Relationen zwischen Listen definieren, welche über die Möglichkeiten der bisherigen Lookup-Felder hinausgehen. Damit lässt sich die referenzielle Integrität, sprich die Abhängigkeit von Daten in verknüpften Listen, effektiv durchsetzen. Damit kann zum Beispiel das Löschen von Datensätzen verhindert werden, wenn sich in einer verknüpften Liste noch abhängige Einträge befinden. Zudem beherrscht SharePoint 2010 auch sogenannte Cascading Deletes, bei der beim Löschen eines List Items auch zwangsläufig alle abhängigen Items in verknüpften Listen eliminiert werden. Relationen zwischen Listen lassen sich wahlweise über die Web-UI, SharePoint Designer oder das Objektmodell festlegen. Auch die Lookup-Verbindungen haben eine gewichtige Veränderung erfahren. Über die sogenannten Projected Fields lassen mehrere Felder (Items) in einer Liste einbetten kann. Auf einer Zeile lassen sich zum Beispiel in einer Projektübersichtsliste gleich die wichtigsten Kontaktdaten aus einer Kundenliste einblenden (Bild 2).
Um über das API mit Joins arbeiten zu können, wurde die SPQuery-Klasse um das Property Joins erweitert. Dabei wird eine Verknüpfung in CAML-Syntax formuliert und anschliessend dem Joins-Property zugewiesen (analog wie beim Query-Property von SPQuery). Noch eleganter lassen sich Joins via LINQ to SharePoint [1] bewerkstelligen. Abfragen auf Listen können dabei direkt in C#- oder VB-Code mit LINQ in SQL-ähnlicher Syntax und mit Unterstützung von IntelliSense formuliert werden.
Flexiblere Ansichten mit XSLT
Wer in SharePoint 2003/2007 schon mal eigene Views basierend auf CAML (via schema.xml) erstellt hat, kennt die Problematik: Selbst für die Darstellung einer einfache Liste werden mehrere 1000 Zeilen CAML-Code benötigt. Bei SharePoint 2010 kommt in Listenansichten XSL (Extensible Stylesheet Language) zum Einsatz. Dadurch wird für die Definition einer View wesentlich weniger Code benötigt als bisher. Die Standard-Ansicht einer Custom List benötigt beispielsweise gerade mal noch rund 160 Zeilen CAML-Code. Die eigentliche Formatierung der Liste wird mit Hilfe einer ausgelagerten XSL-Datei (main.xsl) durchgeführt, die aus der CAML-Definition der Listenansicht referenziert wird. Die main.xls-Datei besteht wiederum aus einer Reihe von verschachtelten XSL-Files. Natürlich kann man hier auch eigene XSL-Stylesheets verwenden, um den Look der Listenansichten komplett den eigenen Bedürfnissen anzupassen. Damit erhalten Entwickler nun wesentlich bessere Möglichkeiten, um in das HTML-Rendering der Listenansichten einzugreifen. Passend zu den XSL-Views gibt es auch ein neues Web Part (XSLT List View WebPart), das für die Darstellung von Listeninhalten auf WebPart-Seiten zuständig ist. SharePoint Designer 2010 bietet entsprechende Werkzeuge, um die Listen und WebPart-Ansichten anpassen zu können [4]. Urs Bertschy ist Inhaber der auf Web- und SharePoint-Consulting/-Development spezialisierten Bertschy Informatik AG. Unter http://www.bertschy.ch/blog unterhält er einen Technologieblog, der sich vor allem SharePoint- aber auch anderen IT-Themen widmet. Links [1] http://www.computerworld.ch/businesspraxis/developerworld/artikel/linq-mehr-komfort-fuer-sharepoint-56304/ [2]http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.aspx [3] http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spquery.aspx
