Shortcuts - Sharepoint-Entwicklung für Einsteiger - Sharepoint-Entwicklung für Einsteiger


Preis: k.A.

Erhältlich ab:  Dezember 2012

Autoren / Autorinnen: Shortcut Autorenteam

Der Microsoft SharePoint Server ist die Plattform von Microsoft mit den höchsten Zuwachsraten weltweit. Letztes Jahr verkaufte Microsoft bereits über 125 Millionen SharePoint-Lizenzen, und laut Microsoft setzen 80% der Fortune-500-Unternehmen eine Produktvariante von SharePoint ein. Das unterstreicht den hohen Stellenwert von SharePoint in Unternehmen. Doch was macht diese Plattform so erfolgreich?

Es ist ein flexibles Baukastensystem, das sich individuell in die (Microsoft-) Systemlandschaft integrieren lässt. Die Anbindung und Integration von Office, Exchange, Lync, BizTalk, Datenbanken oder Active Directory ist ebenso einfach wie der Einsatz der Plattform in verschiedenen Anwendungsszenarien. Das Multitalent SharePoint kann als Portalumgebung, Web-Content-Management-System, Dokumentenmanagement, Kollaborationsplattform, Berichtcenter oder Geschäftsprozess-Engine auftreten – ganz ohne Programmierung, sondern einfach und intuitiv über die Weboberfläche konfigurierbar. Auch die Integration von Drittsystemen anderer Hersteller ist dank standardisierter Schnittstellen kein Problem.

1.1 SharePoint als Entwicklungsplattform

Technisch basiert das datenbankgestützte SharePoint-2010-System auf dem .NET Framework 3.5, genauer gesagt auf ASP.NET 3.5. Allerdings ist SharePoint keine reine ASP.NET-Anwendung, sondern erweitert dieses beträchtlich. Allein die Basisvariante SharePoint Foundation ergänzt mit über 7000 Klassen, Enumerationen und Interfaces das ASP.NET-Framework – die SharePoint Server Standard und Enterprise erweitern diese Anzahl noch um einiges.

Eine Plattform, die so zentral in den Unternehmen verankert ist, kann man natürlich auch für die individuellen Anforderungen anpassen und erweitern. Laut Microsoft tun dies bereits über 700 000 Entwickler weltweit. Daher ist SharePoint auch eine anspruchsvolle und mächtige Entwicklungsplattform. Welche Vorteile, aus Sicht eines Entwicklers, bietet denn SharePoint gegenüber anderen Webtechnologien z. B. natives ASP.NET oder ASP.NET MVC?

SharePoint…

  • bietet ein vollständiges Serverobjektmodell, das den (typ)sicheren Zugriff auf Daten in der SharePoint-Datenbank erlaubt. Es muss keine eigene Datenzugriffsschicht implementiert werden.
  • hat ein umfassendes Rechte- und Rollenkonzept, welches sich für eigene Webanwendungen nachnutzen lässt.
  • hat Portalvorlagen und eine fertige Navigation.
  • stellt unzählige fertige Steuerelemente, Ribbons und Utilklassen bereit.
  • hat diverse Schnittstellen wie z. B. SOAP WebServices, WCF Data Services, REST und auch ein Client Object Model für den Zugriff von unterschiedlichen Clientapplikationen auf SharePoint-Inhalte.

Fazit: Entwickler können auf der einen Seite viele fertige Elemente von SharePoint nachnutzen und sparen enorm viel Zeit, da „Basisfunktionen“ wie z. B. Datenbankzugriff, Navigation oder Berechtigungen bereits vorhanden sind.

1.2 Was enthält dieser shortcut?

Dieser shortcut ist eine Anleitung für Einsteiger in die SharePoint-Entwicklung. Hier werden also Grundlagen der SharePoint-Entwicklung beschrieben, die helfen, mit diesem Thema warm zu werden.

Der erste Teil des shortcuts beschreibt

  • die Entwicklungsumgebung
  • Visual Studio 2010 SharePoint Support
  • hilfreiche Entwickler-Tools

Der zweite Teil beschreibt so genannte Building Blocks, also Bausteine, mit denen man SharePoint-Erweiterungen oder ganze Applikationen aufbauen kann. Dazu gehören

  • das SharePoint-API
  • Application Pages
  • Web Parts
  • Event Receiver
  • Templates

Anhand von einfachen Beispielen wird vermittelt, wie diese Komponenten einzusetzen sind.

Der letzte Teil des shortcuts beschreibt erweiterte Konzepte wie den Umgang mit der FluentUI (Ribbons) und dem Dialogframework. Ferner gibt es einen Einblick in den Umgang mit Rollen und Berechtigungen sowie den Zugriff von Clientanwendungen aus.

Wird man Experte in Sachen SharePoint-Entwicklung sein, wenn man den shortcut durchgelesen hat? Sicherlich nicht! Weil SharePoint einfach ein Ungetüm von einer Plattform ist.

Vor zwei Jahren habe ich zusammen mit Kollegen ein umfangreiches Buch über SharePoint-2010-Entwicklung geschrieben: „SharePoint 2010 as a Development Platform“. Obwohl es über 1200 Seiten umfasst und 1,5 kg wiegt, lautete einer der ersten Kommentare in etwa: „Das Buch ist zu oberflächlich und deckt nicht alle Bereiche ab“. Überrascht? Bestimmt, aber der Kommentator liegt absolut richtig. Trotz des Umfangs konnten wir nicht alle Bereiche und Features von SharePoint ausführlich und tiefgehend beschreiben.

Daher stellt diese kurze Einführung in die SharePoint-2010-Entwicklung auch nur einen Einstiegspunkt dar: Sie zeigt Basiskonzepte auf. Für weiterführende Themen eignet sich das erwähnte Buch [1].

1.3 Für wen ist dieser shortcut?

SharePoint-Entwicklung ist sehr anspruchsvoll. Erfahrene ASP.NET Entwickler haben einige Vorteile beim Einstieg in die SharePoint-Entwicklung – in jedem Fall erwartet den geneigten .NET-Entwickler aber eine steile Lernkurve. Denn SharePoint vereint unterschiedliche Technologien, die man beherrschen und verstehen muss, um erfolgreich Applikationen für SharePoint entwickeln zu können.

Die folgenden Technologien und Sprachen sollte man als SharePoint-2010-Entwickler beherrschen:

  • .Net Framework 3.5
  • ASP.NET 3.5
  • XML
  • Javascript/jQuery
  • Webservices
  • HTML/CSS
  • Workflow Foundation
  • Ebenfalls in SharePoint sinnvoll
  • RSS /ATOM
  • REST
  • SQL
  • XSLT
  • Silverlight

Bevor SharePoint-Anfänger mit der SharePoint Entwicklung beginnen, wird empfohlen, sich mit dem SharePoint Server und den Basiskonzepten wie z. B. Listen, Dokumentbibliotheken, WebParts und Webseiten vertraut zu machen, denn alle SharePoint-Inhalte, -Funktionen und -Einstellungen finden sich in entsprechenden Klassen mit Attributen und Methoden wieder. Der Einstieg in die SharePoint-Entwicklung fällt deutlich leichter, wenn man die SharePoint-Plattform als Anwender schon kennt.

Wie eine adäquate Entwicklungsumgebung für SharePoint aussieht, erfahren Sie im nachfolgenden Abschnitt.

1.4 Die richtige Entwicklungsumgebung

Um für SharePoint 2010 entwickeln zu können, benötigt man vor allem eines: einen SharePoint Server. Das Visual Studio 2010 bzw. Visual Studio 2012 setzt für die Entwicklung von SharePoint-Lösungen voraus, dass man lokal einen SharePoint Server installiert hat. Vorbedingung für diesen sind wiederum entsprechende Betriebssystem- und Ressourcenanforderungen, welche allerdings in einem Entwicklungssystem etwas reduziert werden können. Die folgenden Software- und Hardwareressourcen sollten in der Entwicklungsumgebung bereitgestellt werden:

  • Windows Server 2008 R2 64 Bit oder Windows 7 64 Bit
  • Dual-Core oder Quad-Core-CPU
  • 4 GByte - 8 GByte RAM
  • mind. 50 GByte HDD
  • Visual Studio 2010/2012 Professional, Premium oder Ultimate
  • SharePoint 2010 Server oder SharePoint Foundation als Standalone Server
  • SQL Server 2008 (64 Bit)
  • Optional: Office 2010
  • Optional: Team Foundation Server

Als Entwicklungsumgebung kann die oben spezifizierte Maschine auch virtualisiert sein. Für den produktiven Einsatz eigenen sich virtuelle Maschinen nur für bestimmte SharePoint-Serverrollen. Windows 7 wird lediglich als Entwicklungssystem von Microsoft unterstützt, nicht jedoch als Produktivumgebung. In jedem Fall ist ein 64-Bit-Betriebssystem notwendig, da sonst schon die Installation verweigert wird. Das gilt auch für den obligatorischen SQL-Server. Dieser kann ausgelagert oder lokal auf dem SharePoint Server installiert sein, aber in jedem Fall als 64-Bit-Version. Bei der Wahl der SharePoint Server Systems kann man die kostenlose SharePoint Foundation empfehlen, es sei denn man möchte explizit bestimmte Features, Services oder Bibliotheken nutzen, die nur bei den SharePoint-Server-Versionen enthalten sind. Ansonsten enthält die SharePoint Foundation bereits alle grundlegenden Funktionen und Bibliotheken und ist sehr viel ressourcenschonender, da die Foundation nicht annähernd so viele Services und Serviceapplikationen enthält wie der SharePoint 2010 Server. Für die Installation von SharePoint auf einem Windows 7 64-Bit-System muss man zunächst die Installationsdatei mit der folgenden Zeile entpacken:

SharePoint.exe /extract:C:\SharePointInstall

Anschließend fügt man der Datei Files\Setup\Config.xml die folgende Zeile hinzu, damit das SharePoint-Setup-Programm Windows 7 als Betriebssystem akzeptiert.

<Setting Id=AllowWindowsClientInstall“ Value=“True“/>

Bei einem Entwicklungssystem kann man den SharePoint Server ohne Probleme als Standalone-System installieren, d. h. der SharePoint Server wird zusammen mit dem Microsoft SQL Server auf einer Maschine installiert und kann nicht durch weitere SharePoint Server zu einer Farm organisiert werden. Im Gegensatz dazu gibt es auch die Option, den SharePoint Server als Teil einer SharePoint Farm zu installieren. Mehrere SharePoint Server kann man in einer SharePoint-Farm organisieren, in der die Server verschiedene Rollen haben, typischerweise WebFrontend-Server für die Verwaltung und Anzeige der Portalseiten sowie Application-Server für das Hosting der zahlreichen SharePoint Services und Serviceapplikationen. Eine SharePoint-Farm ist im Produktivbetrieb hervorragend, um Services und Last zu verteilen, für Entwickler hingegen ungeeignet, da die implementierten Lösungen in einer SharePoint-Farm auf ggf. allen SharePoint Server verteilt werden müssen, was je nach Größe der Farm bis zu zehn Minuten dauern kann. Bei häufigem Ausprobieren und Ändern ist das Entwickeln in einer SharePoint Farm sehr zeitraubend.

Beim Visual Studio 2010 oder 2012 kann man im Prinzip alle Versionen verwenden, außer der kostenlosen Express-Version, welche nicht die Projekt- und Itemvorlagen für SharePoint 2010 enthält, sowie die Unterstützung im Solution Explorer. Entwickelt man eine SharePoint-Erweiterung oder -Anwendung in Zusammenhang mit Office 2010, kann man dieses ebenfalls auf der Entwicklungsmaschine installieren. Auch einige SharePoint-Funktionen wie z. B. Mehrfachupload, Datenblattansicht und Bildbearbeitungstool sind Funktionen, die über das Office-2010-Paket über den Punkt „SharePoint 2010 Support“ installiert werden.

Pehlke_SharePoint_Development_1.png

Abbildung 1.1: Aufbau einer Entwicklungsumgebung für SharePoint

Als Faustregel gilt: Einen SharePoint Server pro Entwickler, da mehrere Entwickler, die den gleichen SharePoint Server nutzen, sich gegenseitig stören würden, z. B. beim Deployen von Lösungen und Überschreiben von Dateien im SharePoint Root, also dem Installationsverzeichnis von SharePoint. Damit Entwicklerteams auch zusammen SharePoint-Lösungen implementieren können, empfiehlt sich der Einsatz der Team Foundation Servers, um den gemeinsamen SharePoint-Quellcode zu verwalten. Abbildung 1.1 zeigt den grundsätzlichen Aufbau einer SharePoint-Entwicklungsumgebung. In der Abbildung sind die Systeme von drei SharePoint-Entwicklern dargestellt, die alle separate SharePoint-Standalone-Systeme haben. Die Abbildung beschreibt lediglich eine Entwicklungsumgebung für die SharePoint-Entwicklung im Team. Der Team Foundation Server dient in der Regel als Code Repository und in vollständigen Application-Lifecycle-Management-Szenarien auch zur Verwaltung von Anforderungen, Work-Packages und Bugs.

Wer SharePoint-Anwendungen entwickelt, muss auch eine Staging- bzw. Test-Umgebung mit einbeziehen – und natürlich die Produktivumgebung, auf der die Anwendung nach erfolgreichen Tests laufen soll. Die Staging- und Produktivumgebung haben idealerweise den gleichen Aufbau und gleiche Ressourcen. Abbildung 1.2 zeigt ein Deployment Konzept für das Gesamtszenario. Während in die eine Richtung die Anwendung oder Erweiterung als SharePoint-Solution-Datei verteilt wird, sollte man auch die Rückrichtung beachten, indem man aus dem Produktivsystem, soweit möglich, Live-Daten auf dem Testsystem nutzt und ggf. sogar auf dem Entwicklungssystem. Entwicklung und Tests sind deutlich effizienter mit „echten“ Daten, da Fehler, die im Zusammenhang mit generischen Testdaten gemacht werden, von vornherein vermieden werden. Ebenfalls bei der SharePoint Entwicklung unerlässlich ist die Einbeziehung von Backend-Systemen. Active Directory, Exchange, WebServices und ggf. weitere Datenbanken müssen auch bei Test- und Qualitätssicherung berücksichtigt werden.

Pehlke_SharePoint_Development_2.png

Abbildung 1.2: Deploymentkonzept für SharePoint Entwicklung

1.5 Visual Studio 2010 SharePoint Unterstützung

Im Gegensatz zu Visual Studio 2008 bietet das Visual Studio 2010 eine deutlich verbesserte Unterstützung für SharePoint-Entwicklung. Das Visual Studio 2010 startet man mit Administratorrechten, da zum Deployen eines Projekts Administratorrechte auf dem SharePoint 2010 Server benötigt werden. Beim Erstellen eines neuen Projekts gibt es mehrere vorgefertigte Projekt-Templates, mit denen man ein SharePoint-2010-Projekt beginnen kann. Abbildung 1.3 zeigt den Auswahldialog. Typischerweise werden für SharePoint Erweiterungen wie z. B. WebParts, Event Receiver oder Workflows entwickelt. Daher gibt es auch entsprechende Vorlagen für diese Projekte. Wählt man Visual WebPart aus, erscheint ein Wizard-Dialog, der fragt, auf welchem SharePoint Server bzw. -Portal man das Projekt deployen möchte. Ferner besteht die Auswahl zwischen einer Sandbox Solution und einer Farm Solution. Die Sandbox Solution kann man nur für eingeschränkte Lösungen verwenden: Zum einen laufen diese Lösungen in einem eigenen Sicherheitskontext, zum anderen gibt es bezüglich der Ressourcenverwendung einige Spielregeln. Diese Art von Lösungen wird vor allem in Office-365- oder SharePoint-Online-Umgebungen eingesetzt, wo man keinen Serverzugriff hat. In den meisten Fällen implementiert man Farm Solutions, die nicht eingeschränkt sind. Einige Erweiterungen und Anwendungen sind als Sandbox Solution nicht möglich, wie z. B. das Visual WebPart, da hier Dateien auf dem SharePoint Server deployt werden müssen, um das WebPart verwenden zu können.

Pehlke_SharePoint_Development_3.png

Abbildung 1.3: Projektvorlagen für SharePoint 2010 Projekte im Visual Studio 2010

Nach dem Erstellen eines neuen SharePoint-Projekts werden im Solution Explorer einige Komponenten sichtbar, siehe Abbildung 1.4:

Package – ist das Paket, das auf dem SharePoint Server deployt wird. Es enthält alle Artefakte, Features und Quellcode aus dem Projekt. Beim Doppelklick auf das Package öffnet sich der Package Explorer, in dem man sehen kann, welche Artefakte und Module enthalten sind. Neben dem Titel der Solution kann man hier auch zusätzliche Assemblys definieren, die mit- deployt werden sollen. Über das Property-Fenster kann man noch einige zusätzliche Attribute definieren, wie z. B. eine eindeutige Solution ID oder eine Beschreibung.

Features – Features sind kleine Pakete und dienen als Transportcontainer, die Erweiterungen und Funktionalitäten für SharePoint enthalten können, z. B. auch Web Parts. Diese Features werden im Solution Explorer in einem eigenen Abschnitt aufgelistet. Beim Doppelklick auf ein Feature öffnet sich der Feature Manager. Hier kann man den Titel, die Beschreibung und den Scope des Features festlegen, sowie welche Projektinhalte über das Feature deployt werden sollen. In unserem Beispiel ist der Scope auf „Site“ festgelegt, da WebParts nur für eine WebSite-Sammlung bereitgestellt werden können und nicht für einzelne Sites (Scope: „Web“). Über die Property Window können noch zusätzliche Attribute konfiguriert werden, z. B. ein Icon, das Deploymentverhalten, die eindeutige FeatureID usw. Features können auch EventHandler verwenden, um automatisch Aktionen auszuführen, wenn sie installiert/aktiviert werden oder deinstalliert/deaktiviert. Dazu muss man lediglich im Solution Explorer auf dem Feature die rechte Maustaste drücken und „EventReceiver“ auswählen. Die EventReceiver-Klasse wird automatisch erzeugt, d. h. man muss lediglich die entsprechenden Methoden überschreiben.

Key.snk – Die Schlüsseldatei, die für das Signieren der Projekt-Assembly-Datei notwendig ist, weil diese in der Regel im Global Assembly Cache deployt wird.

Visual WebPart – enthält alle Config- und Codedateien, die für diesen „Baustein“ erforderlich sind. Ein WebPart in SharePoint 2010 ist ein wiederverwendbarer Funktionsbaustein, der aus einem Katalog über die Weboberfläche auf den Webseiten hinzugefügt werden kann. Das Visual WebPart enthält die Datei „name.webpart“, die den Namespace, Assembly, Namen und Beschreibung des WebParts für die WebPart-Gallerie in SharePoint spezifiziert. Um ein WebPart grafisch zu editieren, also ein Visual WebPart, wird lediglich ein ASP.NET UserControl verwendet und vom WebPart eingebunden.

Um die Applikation zu kompilieren und zu starten, sind bei SharePoint-Anwendungen ein paar Schritte mehr nötig. Die folgenden Aktivitäten werden durchgeführt, wenn man auf F5 bzw. den „Play“-Button drückt:

  1. Das Projekt wird kompiliert und die Assembly wird erstellt.
  2. Alle Projektinhalte, die in dem Package Explorer spezifiziert sind, werden in eine .wsp-Datei gepackt, zusammen mit einer manifest.xml-Datei, die spezifiziert, wo welche Elemente auf dem SharePoint Server deployt werden.
  3. Die fertige .wsp-Datei wird in der Zentraladministration im zentralen Solution Store hinzugefügt.
  4. Die hinzugefügte .wsp-Datei wird für das SharePoint-Portal, das man anfangs angegeben hat bzw. über die Site URL Property des Projekts veröffentlicht, inklusive der Aktivierung der Features.
  5. Eine Instanz des Default-Browsers wird gestartet, und der Visual Studio 2010 Debugger wird an den w3wp.exe-Workerprozess des IIS angehängt, welcher für den Application Pool verwendet wird, in dem die SharePoint-Webapplikation läuft.
  6. Nach dem Ende des Debuggens, d. h. wenn man auf „Stop“ drückt oder das Browser-Fenster schließt, wird der Debugger abgehängt.
  7. Die Solution wird aus dem Solution Store zurückgezogen, also deaktiviert.
  8. Die Solution wird aus dem Solution Store entfernt.
  9. Die einzelnen Schritte kann man auch als „Deployment Configuration“ konfigurieren oder einzeln ausführen über das Kontextmenü des Projekts im Solution Explorer.

Nach der Beschreibung der SharePoint-spezifischen Komponenten im Visual Studio 2010 und dem Deploymentvorgang kann man nun beginnen, sein eigenes Projekt auszubauen und mit Inhalten zu füllen.

Pehlke_SharePoint_Development_4.png

Abbildung 1.4: Ein Visual WebPart Projekt im Solution Explorer

1.6 Tools

Prinzipiell stellt Visual Studio 2010/2012 alle notwendigen Tools bereit, die man zur Entwicklung von SharePoint-Erweiterungen und -Anwendungen benötigt. Aber in einigen Fällen können Tools die Arbeit sehr viel einfacher und komfortabler machen. Daher empfehle ich die folgenden Tools:

1.6.1 Dispose Checker

Der Dispose Checker ist eine Visual Studio Extension von Microsoft. Da man sehr schnell Performanceprobleme bekommen kann, wenn man SharePoint-Kontext-Objekte (SPWeb, SPSite) nicht nach der Verwendung dispost, also die Ressource wieder freigibt, prüft dieses Tool die korrekte Verwendung dieser Objekte. Man kann das Tool konfigurieren, damit es in den Kompilierungsprozess integriert werden kann, mit Warnungen oder Fehlermeldungen. Sogar die offizielle Microsoft-Zertifizierung 70-573 SharePoint 2010 Application Development stellt Fragen zur Verwendung dieses Tools.

1.6.2 CSKDev Community Tools

Die CKSDEV Community Tools sind ebenfalls eine Visual Studio Extension. Sie erweitern das Kontextmenü eines SharePoint-Projekts um einige Komfortfunktionen. Diese Funktionen sind:

  • Copy to SharePoint Root
  • Copy to GAC/BIN
  • Copy Both
  • Recycle Project Application Pool
  • Recycle All SharePoint Application Pools
  • Restart IIS
  • Restart User Code Process
  • Restart OWS Timer Process
  • Attach to All SharePoint Processes
  • Attach to IIS Worker Process
  • Attach to User Code Process
  • Attach to OWS Timer Process
  • Attach to VSSPHost4Process

Ferner bietet diese Extension diverse Projekt- und Itemvorlage für SharePoint-Projekte, mit denen man viel Zeit sparen kann.

1.6.3 Fiddler

SharePoint ist ein webbasiertes Anwendungsframework. Daher muss man sich zwangsläufig mit Web-Protokollen, Page Lifecycles, Web-Technologien und Authentifizierung auseinandersetzen. Es kann sein, dass man bei der Entwicklung von SharePoint-Anwendungen auf Probleme trifft, die man im Debugger nicht sehen geschweige denn lösen kann, weil die Probleme auf der Netzwerkschicht bzw. Protokollschicht auftreten und nicht in der Anwendung.

Fiddler ermöglicht es, den gesamten Datenverkehr zwischen dem Client und dem SharePoint Server zu überwachen, indem er als Proxy im Netzwerk fungiert und alle GET-, POST-, Authentifizierungsfehler usw. protokolliert.

1.6.4 CAML Builder

CAML ist eine XML-basierte Abfragesprache, die in SharePoint an verschiedenen Stellen zum Einsatz kommt. Unter anderem wird CAML für Datenabfragen inklusive Feldauswahl, Filter, Sortierungen, Joins etc. verwendet sowie zur Definition von Listenvorlagen und Webserviceaufrufen. Da diese CAML-Statements immer als Zeichenketten geschrieben werden – ohne Syntaxprüfung –, ist die Gefahr von Tipp- und logischen Fehlern hoch. Der CAML Builder von U2U kann auf bestehende SharePoint-Portale zugreifen und CAML-Abfragen über einen Wizard generieren. Zusätzlich verwendet Computacenter selbstimplementierte Klassen und Enumerationen, um die CAML-Statements sicher zu erzeugen sowie Tipp- und Syntaxfehler auszuschließen.

1.6.5 Internet Explorer Developer Toolbar

Die Developer Toolbar des Internet Explorers wird hier stellvertretend für die WebDebugger-Tools verschiedener Browser wie Mozilla Firefox oder Google Chrome genannt. Diese WebDebugger erlauben es, clientseitig zu debuggen, z. B. um JavaScript-Funktionen zu untersuchen. Ferner können CSS-Attribute und der Seitenquelltext analysiert werden.

1.6.6 Developer Dashboard

Das SharePoint Developer Dashboard (Abbildung 1.5) ist in SharePoint integriert und kann auf Wunsch aktiviert werden, z. B. per Powershell-Kommando oder stsadm.exe. Dieses Developer Dashboard zeigt sämtliche Methodenaufrufe einer Webseite sowie zugehörige Datenbankaufrufe, Zugriffs- und Wartezeiten. Die Möglichkeit, eigene Methoden von dem Dashboard tracken zu lassen, hilft bei der Identifikation von langsamen Zugriffs- und Ladezeiten.

Pehlke_SharePoint_Development_5.png

Abbildung 1.5: Developer Dashboard einer SharePoint-Website

1.7 Der SharePoint Kontext

Um von einer selbstimplementierten Webseite oder Applikation auf SharePoint zugreifen zu können, benötigt man den SharePoint-Kontext. Implementiert man Webseiten, Timer Jobs oder Event Receiver für SharePoint, hat man den SharePoint-Kontext automatisch. Bei einer Konsolenanwendung, die auf dem SharePoint Server laufen soll, muss man hingegen den SharePoint-Kontext zunächst laden. Das Server Object Model bietet dafür entsprechende Klassen und Methoden an. Es ist in der Microsoft.SharePoint.dll Bibliothek vorhanden, die sich auf dem SharePoint Server im Global Assembly Cache befindet.

Mit dem Aufruf

SPSite site = new SPSite(“http://servername);

initialisiert man ein SiteCollection Objekt bzw. hat Zugriff auf die Websitesammlung. Da eine Websitesammlung aber eher eine Art Container für die eigentlichen SharePoint-Sites sind, muss man noch die gewünschte Portalseite über ein SPWeb-Objekt initialisieren. Das Portal in der obersten Ebene erhält man über

SPWeb web = site.RootWeb;

Dabei ist zu beachten, dass, wenn man diese Objekte mit dem new-Operator erzeugt, sehr viele Ressourcen gebunden werden, die nur schlecht vom Garbage Collector wieder freigegeben werden. Daher müssen diese Objekte durch explizites Aufrufen der Dispose()-Methode wieder vernichtet werden. Alternativ verwendet man das Using-Statement in Listing 1.1, um die Objekte wieder zu vernichten.

Hinweis: Achtung! Verwendet man nicht dieses Dispose-Pattern, können SPSite und SPWeb Objekte, die in einer Schleife immer wieder neu erzeugt werden, ohne dispost zu werden, zu erheblichen Performanceeinbußen führen – bis hin zum Absturz des IIS-Worker-Prozesses, in dem die SharePoint Anwendung läuft.

Using (SPsite site = new SPSite(“http://servername”))
{
Using (SPWeb web = site.RootWeb)
{
//tue irgendwas
}
}

Listing 1.1: Korrekte Verwendung der SharePoint-Kontext-Objekte

Zur Unterstützung des Dispose Pattern bietet Microsoft unter [2] ein Tool an, das sich in das Visual Studio 2010 integriert und eine Prüfung beim Kompilieren veranlasst.

Befindet man sich allerdings in Elementen, die direkt im SharePoint-Kontext laufen, wie z. B. Webseiten, Timer-Jobs oder Event Receiver, kann man unmittelbar auf den aktuellen Kontext zugreifen. In Application Pages, die von der Basisklasse LayoutsPageBase erben, gibt es z. B. das Attribut this.Web. Ähnlich ist es in den Event Receivern, in denen der SharePoint-Kontext als Parameter in den Event Receiver Properties übergeben wird. Bei allen anderen SharePoint-Elementen erhält man den SharePoint-Kontext über die statische Klasse SPContext. Die aktuelle Portalseite bekommt man über

SPWeb web = SPContext.Current.Web;

Hinweis: Achtung! Dieses Objekt darf nicht dispost werden, weil es den aktuellen Kontext nur referenziert und nicht über den new-Operator eine neue Instanz erzeugt.

In unserem laufenden Beispiel sind dank der Visual-Studio-Vorlage die notwendigen Bibliotheken automatisch referenziert und alle notwendigen Elemente angelegt. In dem Visual Webpart – genauer gesagt, in dem zugehörigen UserControl – können wir nun auf diese Weise auf den SharePoint-Kontext zugreifen.

Listing 1.2 zeigt den Programmcode, der in dem Visual Webpart auf die zur Laufzeit aktuelle Portalsite zugreift und sowohl den Titel als auch alle vorhandenen Listen und Bibliotheken in dem WebPart auflistet. Die dabei verwendeten Klassenobjekte werden im nächsten Abschnitt erläutert.

private const string _ascxPath = @"~/_CONTROLTEMPLATES/MeinVisualWebPart/VisualWebPart1/VisualWebPart1UserControl.ascx";

protected override void CreateChildControls()
{
//aktueller SharePoint-Kontext
SPWeb web = SPContext.Current.Web;
//Ausgabe des Portaltitels
this.Controls.Add(new Label() { Text = "Titel des Portals: " + web.Title + "<br>" });
//Anzeige aller Listen und Bibliotheken in dem Portal
foreach (SPList list in web.Lists)
{
this.Controls.Add(new Label() { Text = "Liste: " + list.Title + "<br>" });
}
//Hinzufügen des Usercontrols
Control control = Page.LoadControl(_ascxPath);
Controls.Add(control);
}

Listing 1.2: Auslesen aller Listen der aktuellen Website und Anzeige im WebPart

1.8 Von SPFarm zu SPListItem

Das Server-Objekt-Model von SharePoint reflektiert die Komponenten und Inhalte in SharePoint, die man über den Webbrowser erreichen kann. Von der Organisation her ist SharePoint hierarchisch aufgebaut. Entsprechend sind die Komponenten wie folgt geordnet:

  • Farm – besteht aus mehreren SharePoint Servern, die unterschiedliche Rollen haben.
  • Webanwendung – entspricht einem Application Pool im IIS und läuft in einem eigenen Prozess auf einem Port, z. B. Port 80.
  • Websitesammlung – ist eine Containerstruktur für Websites.
  • Website – ist eine SharePoint-Portalseite mit Inhalten wie Gruppen, Listen, Webseiten, Dokumenten.
  • Listen – bzw. auch Dokumentbibliotheken – dienen als Datenablage und können verschiedene Metadatenfelder und Ansichten haben.
  • Felder – Ähnlich wie bei Datenbanken können die Felder von verschiedenen Datentypen sein.
  • Ansichten – sind eine Menge von Metadatenfelder zusammen mit Filter- und Sortiervorgaben.
  • Listeneinträge/Dokumente – sind die konkreten Inhalte in den Listen bzw. Bibliotheken.

Da die obersten beiden Ebenen eher administrativer Natur sind, benutzt man als SharePoint-Entwickler in der Regel die inhaltlich bezogenen Objekte ab der Ebene Websitesammlung. Wer sich bereits in SharePoint auskennt und über die Weboberfläche mit Listen, Ansichten und Dokumenten umgehen kann, wird auch alle Attribute und Funktionen im Server-Objekt-Modell wiederfinden, wie z. B. Name und Beschreibung von Listen, Filter bei Ansichten oder Empfangen von eingehenden E-Mails.

Listing 1.3 beschreibt, wie man Listen und Felder in SharePoint anlegt sowie einen Listeneintrag erstellt. Zunächst wird der Website-Kontext über die SPWeb-Klasse referenziert. Anschließend wird der List-Collection über die Methode AddList() eine neue benutzerdefinierte Liste hinzugefügt. Benutzerdefiniert heißt, dass noch keine individuellen Metadaten als Spalten hinzugefügt sind. Alternativ können auch Listenvorlagen, etwa für Kalender, Aufgabenlisten oder Dokumentbibliotheken, verwendet werden.

private void CreateList()
{
//SharePoint-Kontext laden
SPWeb web = SPContext.Current.Web;
//Erstellt eine benutzerdefinierte Liste und gibt die eindeutige GUID der Liste zurück
Guid newListGuid = web.Lists.Add("Projekte", "Alle Projekte der Firma", SPListTemplateType.GenericList);
//Instanziieren der Liste
SPList projektList = web.Lists[newListGuid];
if (projektList != null)
{
//Erzeuge drei Metadatenspalten
projektList.Fields.Add("Bemerkung", SPFieldType.Note, false);
projektList.Fields.Add("Phase", SPFieldType.Choice, true, false, new StringCollection() { "Presales", "Initiation", "Execution", "Close" });
projektList.Fields.Add("StartDatum", SPFieldType.DateTime, false);
//Speichere die Änderungen an der Liste
projektList.Update();

//Erstelle neuen Listeneintrag
var newItem = projektList.Items.Add();
newItem["Title"] = "Mein neues Projekt";
newItem["Phase"] = "Presales";
newItem["StartDatum"] = DateTime.Now;
newItem["Bemerkung"] = "Das wird ein spannendes Projekt";
newItem.Update();
}

}

Listing 1.3: Liste, Metadatenfelder und Listeneintrag erstellen

Nach dem Anlegen der Liste wird die Liste über die SPList-Klasse referenziert, und es werden drei Spalten angelegt: ein Bemerkungsfeld, ein Kategoriefeld und ein Datumsfeld. Anschließend wird ein neuer Listeneintrag angelegt, der die ausgefüllten Metadaten beinhaltet. Abbildung 1.6 zeigt den auf diese Weise erstellten Listeneintrag in der SharePoint-2010-Oberfläche.

Pehlke_SharePoint_Development_6.png

Abbildung 1.6: Per Code erstellter Listeneintrag in SharePoint 2010

1.9 Zusammenfassung

SharePoint 2010 ist dank des .NET Frameworks und der optimalen Unterstützung durch Visual Studio 2010 eine vielseitige und mächtige Entwicklungsplattform. Obwohl SharePoint-Entwicklung nicht trivial ist und SharePoint seine Eigenarten hat, können erfahrene SharePoint-Entwickler das enorme Potential der Plattform sehr gut nutzen.

Im nächsten Kapitel wird auf Building Blocks eingegangen, also die Entwicklung grundlegender SharePoint-Komponenten wie WebParts, Application Pages, Event Receiver und Templates. Im dritten Kapitel werden weiterführende Themen behandelt, wie z. B. die Erweiterung und Nutzung der Ribbon-Oberfläche, Datenzugriff per Webservice und ClientObject Model.

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang