SharePoint Server 2010

Entwurf von SharePoint-Lösungen
Kommentare

Nachdem im ersten Kapitel der Aufbau der Entwicklungsumgebung erläutert und im vorherigen Kapitel die Grundlagen der verfügbaren Objektmodelle dargestellt wurden, ist man nun im Besitz des notwendigen Wissens, um SharePoint-Lösungen mithilfe des API umsetzen zu können. Hier stellt sich aber oft die Frage, welche Möglichkeiten der Erweiterungen existieren, und an welchen Punkten SharePoint funktionell erweitert werden kann.

Generell ist festzustellen, dass im SharePoint-Bereich funktional (fast) alles möglich ist. Eine Aussage wie: „Das kann nicht mit SharePoint realisiert werden“ ist im SharePoint-Entwicklungsbereich nicht gültig. Erst wenn die Aussage: „Das kann nicht mit dem .NET Framework realisiert werden“ gültig wäre, kommt SharePoint an seine Grenzen. SharePoint ist im Grunde nichts anderes als ein erweitertes .NET Framework für webbasierte Anwendungen. Wie in Abbildung 3.1 zu erkennen ist abstrahiert das .NET-Framework den Zugriff auf Betriebssystemfunktionen und erleichtert so dessen Verwendung. SharePoint ist als weitere Abstraktionsschicht zu sehen und stellt erweiterte sofort verwendbare Funktionen für den Entwickler bereit.

Abbildung 3.1: Die SharePoint-Plattform

Daher eignet sich der SharePoint Server hervorragend als Ausgangsbasis für eigene Webanwendungen. Ist im Unternehmen ein SharePoint-Portal vorhanden, sollten möglichst alle neuen und vorhandenen Anwendungen über das Portal zentralisiert und bereitgestellt werden. Im idealen Fall werden die Anwendungen in das Portal integriert, d. h., die Anwendungen nutzen vorhandene Funktionen des SharePoint Servers. Dieses Kapitel erläutert zunächst die Vorgehensweise, wie eine SharePoint-Lösung konzeptionell geplant werden sollte. Danach werden die speziellen Erweiterungsmöglichkeiten (Features) beschrieben, die darstellen, an welchen Stellen eigene Funktionen in den SharePoint Server eingebracht werden können. 

SharePoint als Lösungsplattform?

Im Folgenden soll geklärt werden, wann und warum SharePoint als Lösungsplattform verwendet werden kann. Die Entscheidung ist nicht immer einfach und abhängig von der konkreten fachlichen Anforderung. Fachliche Anforderungen werden zunächst losgelöst von jeglicher Technologie aufgenommen, gemäß dem klassischen Vorgehen. Darüber hinaus ist eine Fachabteilung in der Regel auch nicht in der Lage, eine bestimmte technologische Basis auszuwählen, geschweige denn, sie festzulegen. Die Fachabteilung sollte allerdings mit einbezogen werden, wenn aus mehreren gleichwertigen Technologien eine auszuwählen ist. Stehen die fachlichen Anforderungen fest, können sie durch die IT-Abteilung bewertet und klassifiziert werden.

Ob als technologische Basis SharePoint in Frage kommt, ist von mehreren Faktoren abhängig. Für den Einsatz des SharePoint Servers als Lösungsplattform sprechen folgende Kriterien:

  • Die neue Lösung soll als Web- oder Silverlight-Anwendung bereitgestellt werden
  • Es handelt sich im Schwerpunkt um Formulare, die verarbeitet werden sollen
  • Es ist bereits ein SharePoint Server vorhanden
  • Die Anwendung erfordert ein komplexes Berechtigungskonzept
  • Die Anwendung soll im Intra-, Extra- oder/und Internet verfügbar sein

Für die Umsetzung einer SharePoint-basierten Lösung spricht der erste Punkt. Wird als Oberflächentechnik HTML oder Silverlight verwendet, kann die neue Lösung nahtlos in den SharePoint Server integriert werden. Das bedeutet aber nicht automatisch, dass bei anderen Anwendungstypen SharePoint nicht in Frage kommt. Muss eine Windows-Presentation-Foundation- (kurz: WPF-)basierte Anwendung umgesetzt werden, kann die Anwendung im Hintergrund trotzdem auf SharePoint-Funktionen zurückgreifen. In diesem Szenario kapselt die WPF-Anwendung die SharePoint-Funktionen und stellt sie über die Anwendungsoberfläche bereit. Abbildung 3.2 zeigt dazu eine mögliche Anwendungsarchitektur.

Abbildung 3.2: SharePoint im Hintergrund

Auch Lösungen, die komplett im Hintergrund agieren, sind in der Lage, SharePoint-Funktionen zu verwenden. Als Beispiel kann hierfür ein klassischer Windows-Dienst (Windows Services) genannt werden, der ohne grafische Oberfläche seine Arbeit verrichtet.

Sollen durch die neu zu entwickelnde Anwendung im Schwerpunkt elektronische Formulare verarbeitet werden, eignet sich SharePoint 2010 ebenfalls hervorragend als Lösungsplattform. Elektronische Formulare, die auch browserfähig sind, können mittels Microsoft InfoPath 2010 realisiert und über den SharePoint Server publiziert werden. Microsoft InfoPath ist ein typisches Werkzeug für so genannte Power User, aber auch Entwickler können und sollten es nutzen. Denn InfoPath ermöglicht die Realisierung anspruchsvoller und komplexer Formulare mit relativ wenig Aufwand.

Profitipp

Bei der Verwendung von InfoPath lohnt es sich teilweise nicht, im Vorfeld einen (Formular-)Prototyp umzusetzen. Idealerweise wird das Formular gemeinsam mit der Fachabteilung direkt in InfoPath entworfen.

Weitere Informationen zu InfoPath sind in Kapitel 9 „Realisierung von Workflows“ zu finden.

Ein sehr wichtiger Punkt, der darüber entscheidet, ob SharePoint als Lösungsplattform eingesetzt werden kann, ist der dritte der oben angesprochenen Punkte. Ist bisher noch kein SharePoint Server im Unternehmen verfügbar, muss kritisch geprüft werden, ob eine Einführung sinnvoll ist. Bei kleinen Lösungen ist der zusätzliche Aufwand meist nicht vertretbar. Außerdem darf nicht vergessen werden, dass eine optimale SharePoint-Einführung von den Fachabteilungen getrieben werden sollte. Bei bestimmten Anwendungen ist jedoch die gleichzeitige Einführung einer SharePoint-Infrastruktur sinnvoll. Sollen z. B. interne Unternehmensprozesse, wie Urlaubsanträge, Versetzungen, Ein- und Austritte oder Hardwarebestellungen, durch elektronische Formulare unterstützt werden, lohnt sich die Einführung aus folgenden Gründen:

  • SharePoint Server 2010 in Kombination mit InfoPath ermöglicht die Realisierung und einfache Verteilung elektronischer Formulare.
  • Formulare durchlaufen in der Regel einen Genehmigungsprozess. SharePoint 2010 enthält bereits einen Freigabe-Workflow. Deckt der eingebaute Freigabeprozess nicht alle Anforderungen ab, kann er leicht erweitert werden. Als letzte Möglichkeit kann auch ein ganz neuer Workflow umgesetzt werden.
  • Das SharePoint-Berechtigungskonzept kann dazu verwendet werden, die Sichtbarkeit und die Zugriffe auf Formulare zu regeln.
  • Benutzer können ihre Formulare selbst verwalten und löschen. Mit dem verfügbaren Papierkorb können versehentlich gelöschte Anträge durch den Benutzer wiederhergestellt werden.
  • Über die eingebaute Benachrichtigungsfunktion (Alerts) können Antragsänderungen an Beteiligte zeitnah kommuniziert werden.

Dies sind nur einige Argumente, warum sich bei der oben genannten Anforderung eine SharePoint-Einführung rechtfertigt. Statt alle Funktionen selbst zu implementieren, können die vorhandenen SharePoint-Funktionen verwendet werden. Durch das offene API können sie auch problemlos in eigenen Anwendungen integriert werden.

Auch die mögliche Erreichbarkeit spricht für eine SharePoint-basierte Lösung. Die Anwendung ist bei entsprechender Infrastruktur im Intra-, Extra- oder auch im Internet verfügbar.

Wie deutlich wurde, kann nicht immer leicht beurteilt werden, ob SharePoint als Lösungsplattform verwendet werden kann oder nicht. Hierbei kommt es immer auf die konkreten Anforderungen an. Befindet sich bereits ein SharePoint Server im Unternehmen, ist die Entscheidung etwas einfacher. Generell sollten alle webbasierten Anwendungen über den SharePoint Server zur Verfügung gestellt werden. Neue dagegen sollten direkt integriert werden und vorhandene SharePoint-Funktion verwenden.

Beispiel

Ein Unternehmen plant die Einführung einer neuen ASP.NET-Anwendung. Wie nahezu jede (Unternehmens-)ASP.NET-Anwendung benötigt sie ein Berechtigungskonzept sowie ein einheitliches Layout. ASP.NET stellt hierfür bereits durch das ASP.NET-Rollenkonzept und Master Pages vorgefertigte Konzepte bereit. SharePoint hingegen stellt bereits einen funktionalen Rahmen zur Verfügung. Über Application Pages (siehe Beispiel in Kapitel 10) können ganze Anwendungen umgesetzt werden, die automatisch das Look and Feel des SharePoint-Portals besitzen. Typische Implementierungsschritte, die bei einer klassischen ASP.NET-Anwendung entstehen, werden somit minimiert bzw. entfallen. Auch kann auf die Verteilung eines zusätzlichen DNS-Eintrags (Host Header) für die Anwendung verzichtet werden.

Wurde aus den Anforderungen entschieden, SharePoint als Lösungsplattform zu verwenden, kann mit der genauen Analyse und Planung der Lösungsarchitektur begonnen werden.

Aufmacherbild: A group of users connected through cloud services von Shutterstock / Urheberrecht: Pictofigo

[header = Konzeptionelle Planung einer SharePoint-Lösung]

Konzeptionelle Planung einer SharePoint-Lösung

Im Grunde wird eine SharePoint-Lösung ähnlich realisiert wie eine normale Anwendung. Zu Beginn steht immer eine fachliche Anforderung bzw. ein (Geschäfts-)Prozess, der mittels EDV unterstützt werden soll. Im optimalen Fall kommen diese Anforderungen aus der jeweiligen Fachabteilung eines Unternehmens. Nach der Aufnahme der Anforderungen und Erstellung einer Leistungsbeschreibung kann anhand der beschriebenen Prozesse ermittelt werden, ob SharePoint als Lösungsplattform in Frage kommt. Im oberen Abschnitt wurden schon einige technische Kriterien aufgezeigt, die bei diesem Entscheidungsprozess zu berücksichtigen sind. Aus fachlicher Sicht gibt es ebenfalls Punkte, die den Einsatz des SharePoint Servers begünstigen. Die nachfolgenden Abschnitte gehen kurz auf diese Punkte ein.

Dokumentenzentriert

Ist die umzusetzende Lösung sehr dokumentenzentriert, eignet sich SharePoint als Lösungsplattform. SharePoint bietet im Bereich Dokumentenverwaltung bereits zahlreiche Funktionen, z. B. Versionsverwaltung sowie Check-in- und Check-out-Mechanismen.

Groupware

Ebenfalls eignet sich der Einsatz bei einer Lösung, die viele Groupware-Charakteristiken aufweist. Auch hier können viele eingebaute SharePoint-Mechanismen, z. B. automatische Benachrichtigungen, über das SharePoint-Objektmodell verwendet werden. Zusätzlich bietet SharePoint über gemeinsame Teamsites eine vorbereitete (Groupware-)Oberfläche, die um eigene Funktionen erweitert werden kann.

Einbindung von Fremdsystemen (Umsystemen)

In der Regel existieren in einem Unternehmen verschiedene IT-Systeme, die alle eine eigene Datenverwaltung besitzen. Andere Systeme benötigen teilweise Daten aus diesen Systemen. Heutzutage kommen dazu meist Web Services zum Einsatz, oder benötigte Daten werden direkt aus der Datenbank des Fremdsystems bezogen. Innerhalb von SharePoint kann dazu der Business Connectivity Service (BCS) verwendet werden. Damit steht bereits eine Infrastruktur bereit, um verschiedene (entfernte) Systeme über eine einheitliche Schnittstelle anbinden zu können. Über das SharePoint-Objektmodell ist die programmatische Nutzung des BCS möglich.

Formulare

Sollen innerhalb der neuen Lösung im Schwerpunkt Formulare verarbeitet werden, eignet sich hierfür der Einsatz von InfoPath. SharePoint enthält bereits eine eingebaute Formularbibliothek, über die Formulare leicht verteilt werden können. Ebenfalls können InfoPath-Formulare um eigene Funktionen erweitert und Daten aus Fremdsystemen relativ einfach eingebunden werden. Auf die Formulardaten kann aus eigenen SharePoint-Erweiterungen leicht zugegriffen werden, da diese innerhalb einer XML-Struktur gespeichert werden.

Prozessorientiert

SharePoint besitzt eine eingebaute Ablaufumgebung für Workflows, die um eigene Workflows erweitert werden kann. Besitzt die neue Lösung viele Prozesse mit einem Workflow-Charakter, eignet sich hierfür die Verwendung des SharePoint Workflow API. Bereits vorhandene Workflows können verwendet oder erweitert werden. SharePoint stellt somit den Host und damit die Ablaufumgebung für Workflows bereit. Die Umsetzung eines eigenen Hosts entfällt.

Weitere Punkte

Die oben aufgezählten Kriterien stellen die wichtigsten Entscheidungshilfen aus fachlicher Sicht für den Einsatz des SharePoint Servers dar. Generell sollten alle fachlichen Anforderungen gegen die bereits in SharePoint verfügbaren Funktionen geprüft werden. Je mehr Funktionen durch eingebaute Funktionen abgedeckt werden, desto eher kommt der Einsatz des SharePoint Servers in Frage. Dabei ist es aber nicht relevant, ob die SharePoint-Funktionen die Anforderungen vollständig abdecken. Es ist ausreichend, wenn die grundlegende Funktionalität verfügbar ist. Diese kann dann leicht erweitert und an eigene Anforderung angepasst werden.

[header = Entwicklungsmöglichkeiten]

Entwicklungsmöglichkeiten

In der Einleitung dieses Kapitels wurde bereits die grobe Architektur des SharePoint Servers dargestellt. Abbildung 3.3 zeigt nun ein erweitertes Bild aus dem Blickwinkel der Entwicklungsmöglichkeiten. Wie aus der groben Architektur bereits hervorging, benötigt der SharePoint Server ein Windows 64-bit-Betriebssystem. Aufbauend auf diesem wird ein SQL Server betrieben, der die notwendigen Datenbanken für die Verwaltung der SharePoint-Inhalte bereitstellt. Betrieben wird der SharePoint Server innerhalb eines Internet Information Servers (MS IIS). Dieser stellt die ASP.NET-Laufzeitumgebung bereit. Wichtig ist hierbei anzumerken, dass der IIS im Integrierten Modus ausgeführt werden muss. Neben den grundlegenden .NET APIs verwendet der SharePoint Server die speziellen .NET-Bibliotheken Windows Workflow Foundation, Windows Identity Foundation und die ADO.NET Data Services aus dem .NET Framework 3.5.1.

Hinweis

Wie bereits im ersten Kapitel erwähnt wurde, müssen eigene SharePoint-Erweiterungen ebenfalls das .NET Framework 3.5 verwenden. Die Verwendung von .NET 4.0 ist noch nicht möglich. Der SharePoint Server 2007 konnte durch einige Anpassungen der web.config auf die .NET-Plattform 3.5 aktualisiert werden. Ein ähnliches Vorgehen ist für den SharePoint Server 2010 allerdings nicht möglich. Der Grund liegt in der zugrunde liegenden Common Language Runtime (CLR). .NET Framework 2.0 und 3.5 basieren auf der gleichen CLR. Das .NET Framework 3.5 enthält lediglich erweiterte Bibliotheken, z. B. die AJAX-Erweiterung. Das .NET Framework 4.0 hingegen enthält eine neue CLR, die nicht einfach ausgetauscht werden kann.

Abbildung 3.3: Entwicklungs- und Erweiterungsmöglichkeiten

Basierend auf den drei zuvor erläuterten Modulen baut die SharePoint-Foundation-Infrastruktur auf. Die obere Abbildung zeigt die wichtigsten Bestandteile. Der im linken mittleren Bereich dargestellte Business Connectivity Service (BCS) ermöglicht die relativ einfache Einbindung von Fremdsystemen. Innerhalb von SharePoint werden die verbundenen Systeme als so genannte Externe Inhaltstypen (Externe Content Types) eingebunden. Der BCS bietet ein umfassendes API und kann in eigenen Lösungen verwendet werden. Webparts bieten ebenfalls eine gute Möglichkeit, um neue Funktionen in SharePoint zu integrieren. Kapitel 5 geht detailliert auf diese Option ein. Neu in SharePoint 2010 ist das Client-Objekt-Modell (Client Object Model). Dieses wurde bereits ausführlich in Kapitel 2 behandelt. Ebenfalls neu in SharePoint 2010 sind Sandkastenlösungen, die innerhalb eines isolierten Prozessraums ausgeführt werden. SharePoint-Erweiterungen, die für diese Ausführungsumgebung vorgesehen wurden, können daher auch von einem Nicht-Farm-Administrator installiert werden. Eine ausführliche Einführung in dieses Themenfeld erfolgte bereits im ersten Kapitel. SharePoint 2010 löst den aus älteren SharePoint-Versionen bekannten Shared Service Provider (SSP) durch eine neue Servicearchitektur ab. Die neue Dienstarchitektur ist wesentlich flexibler und erweiterbar, d. h., über das verfügbare und offene API der Dienstarchitektur können bei Bedarf eigene Dienste implementiert und bereitgestellt werden. In der heutigen Zeit werden viele Informationen über mobile Endgeräte abgerufen. Das trifft auch auf Informationen zu, die innerhalb des SharePoint Servers vorliegen. SharePoint unterstützt durch das Modul Mobile Pages and Web Part Adapters die Bereitstellung optimierter Inhalte für mobile Endgeräte. Ein weiterer wichtiger Bereich für eigene Erweiterung stellen eigene Listen und Inhaltstypen (Content Types) dar. Hierüber können eigene Datenstrukturen bereitgestellt und innerhalb von SharePoint-Lösungen verwendet werden. Oft besteht eine SharePoint-Lösung aus einer Reihe unterschiedlicher SharePoint-Erweiterungen, die über eine Site interagieren. Um die Installation und die Konfiguration solcher Lösungen zu vereinfachen, können vorgefertigte Vorlagen und Definitionen vorbereitet werden. Hierfür bietet der Bereich Site Templates and Definition die notwendigen Hilfsmittel. Einen weiteren wichtigen Bereich bilden die Workflows. SharePoint Workflows basieren auf der SharePoint Foundation 3.5 und erweitern sie um spezielle SharePoint-Aktivitäten. Kapitel 9 geht auf die Umsetzung von Workflows detailliert ein. Der letzte und wichtigste Bereich deckt das Thema Sicherheit ab. SharePoint besitzt bereits eingebaute Sicherheitsmechanismen, aber auch die Umsetzung spezieller Sicherheitsanbieter ist möglich.

Die SharePoint Foundation bildet die Infrastruktur, auf dem der SharePoint Server 2010 aufsetzt. Aufbauend auf den genannten Komponenten der SharePoint Foundation führt der Server neue Funktionalitäten hinzu. Auch die dort verfügbaren Funktionen können in eigenen Lösungen verwendet werden. Ein sehr nützlicher Dienst ist z. B. der Word Automation Service, über den Word-Dokumente serverseitig in andere Formate – z. B. in PDF Dokumente – überführt werden können. Auch der Word Automation Service besitzt ein offenes API und kann so in eigenen Lösungen eingesetzt werden. Wie aus der oberen Abbildung deutlich wird, gibt es zwei SharePoint-Versionen, die sich im Funktionsumfang unterscheiden. Bei der Planung von Lösungen muss dieser Umstand berücksichtigt werden, da u. U. nicht alle Funktionen bzw. Dienste verfügbar sind.

Wie anhand der Erläuterungen deutlich wurde, ist der SharePoint Server aus Entwicklersicht nichts anderes als eine Erweiterung des .NET Frameworks um weitere Programmierbibliotheken. Je nachdem, welche der drei Plattformen – SharePoint Foundation, SharePoint Standard oder SharePoint Enterprise – vorhanden ist, stehen mehr oder weniger Funktionen bereit. Die folgenden Abschnitte beschreiben kurz die wichtigsten Erweiterungsmöglichkeiten und deren Funktion.

Eigene Felder (Fields)

SharePoint enthält im Standard schon eine Menge an vorgegebenen Feldern. Ein Beispiel für ein Feld ist die Spalte Status innerhalb einer Aufgabenliste. Das Feld Status ist definiert als Auswahlfeld mit vorgegebenen Werten. Felder sind vergleichbar mit Datentypen, d. h., sie geben vor, welche Daten in welchem Format erfassbar sind. Felder können bereits Regeln besitzen und als Pflichtfeld ausgezeichnet werden. Neben einfachen Feldern gibt es auch zusammengesetzte Felder. Als Beispiel kann hier das Feld zur Erfassung einer Internetadresse genannt werden. Das Feld nimmt direkt die Informationen URL und eine Beschreibung auf. Somit kann jede Liste, die eine Internetadresse erfassen muss, auf das vorgefertigte Feld zurückgreifen. Für eigene Lösungen können ebenfalls die eingebauten Felder verwendet werden. Reichen sie nicht aus, können auch neue definiert und angelegt werden.

(Externe) Inhaltsdatentypen

Inhaltstypen sind im Groben vergleichbar mit Datenbanktabellen, denn auch Inhaltstypen beschreiben Datenstrukturen. Für die Definition der Datenstruktur wird auf die zuvor beschriebenen Felder zurückgegriffen. Neben der Bereitstellung einer Datenstruktur können Inhaltstypen auch ein Verhalten beschreiben. So ist es möglich, einen Inhaltstyp direkt mit einem Ereignisempfänger oder einem Workflow zu verknüpfen. Detaillierte Informationen zu Inhaltstypen sind in Kapitel 7 zu finden.

Externe Inhaltstypen bilden eine spezielle Art von Inhaltstypen, die über den Business Connectivity Service bereitgestellt werden. Hierbei handelt es sich um Daten(-strukturen), die über ein externes System eingebunden wurden.

Masterpages und Seitenvorlagen (Page Layouts)

In der Regel soll nach der Installation und Veröffentlichung eines neuen SharePoint-Portals die Oberfläche dem Look and Feel des Unternehmens entsprechen, d. h., es muss ein Branding der Oberfläche erfolgen. Wie bereits erläutert wurde, basiert der SharePoint Server auf ASP.NET und nutzt daher auch bewährte Konzepte der ASP.NET-Plattform. SharePoint-Seiten setzen sich daher aus einer MasterPage und eingebetteten Inhaltsseiten (Content Pages) zusammen. Im Standard wird die MasterPage v4.master verwendet. Es ist aber möglich, eine eigene SharePoint MasterPage umzusetzen, die nach der Installation aktiviert und verwendet werden kann. SharePoint unterstützt auch die Möglichkeit, mehrere MasterPages zu verwenden. Beispielsweise kann jede Abteilung mit einer eigenen SharePoint Site eine spezielle MasterPage zugewiesen bekommen. Die Umsetzung einer SharePoint MasterPage ist vergleichbar mit der Umsetzung einer klassischen ASP.NET MasterPage. Es müssen lediglich einige Platzhalter und spezielle CSS-Klassen verwendet werden. Der Schwerpunkt der Umsetzung liegt eher im grafischen Bereich.

Profitipp

Um eine gute MasterPage zu realisieren, sollte mit einem Designer das Layout erstellt werden. Ein Layout, das von einem Entwickler umgesetzt wurde, ist meist nicht optimal.

Im Gegensatz zu klassischen ASP.NET-Anwendungen werden Detailseiten mithilfe von Page Layouts abgebildet. Hierbei handelt es sich um Seiten, die eine vorgegebene Struktur besitzen und somit das Layout und den Aufbau der Seite vorgeben. Das ist sehr hilfreich, um einen durchgängigen und einheitlichen Seitenaufbau durchzusetzen. 

Menüband-Erweiterung (Ribbon)

SharePoint 2010 führt eine überarbeitete Navigationsstruktur ein und löst damit viele Probleme der Vorgängerversionen. Kernbestandteil der neuen Navigation bildet das Menüband, das eher unter der Bezeichnung Ribbon bekannt ist. Es verhält sich kontextbezogen und blendet automatisch verfügbare Aktionen je nach Kontext ein und aus. Wie alle anderen SharePoint-Elemente besitzt das Ribbon ein offenes API und kann darüber um eigene Elemente erweitert werden. Eine ausführliche Beschreibung dazu ist in Kapitel 6 zu finden.

Ereignisempfänger (Event Receiver)

Schon die ersten SharePoint-Versionen ermöglichten die Umsetzung eines Ereignisempfängers, seit der Version 2007 ist dies auch relativ problemlos möglich. Wie der Name schon andeutet, ist es hiermit möglich, auf Ereignisse zu reagieren. Es gibt viele verschiedene Arten von Ereignisempfängern, die detailliert in Kapitel 8 vorgestellt werden.

Webparts

Webparts gehören zu den wichtigsten Eigenschaften von SharePoint. Dabei sind sie keine Besonderheit von SharePoint, sondern auch innerhalb klassischer ASP.NET-Anwendungen verwendbar. Webparts stellen kleine funktionale Bausteine dar, die einer Webpart-fähigen Seite hinzugefügt werden können. Über diesen Weg können Seiten um neue Funktionen erweitert werden. Die Erstellung von Webparts wird genauer in Kapitel 5 beleuchtet. Generell muss in fast jedem SharePoint-Projekt mindestens ein Webpart umgesetzt werden.

Anwendungsseiten

Die Möglichkeit der Erstellung von Anwendungsseiten ermöglicht die Umsetzung komplexer Anwendungen in SharePoint. Über diesen Weg können vollständige ASP.NET-basierte Anwendungen in den SharePoint Server integriert und bereitgestellt werden. Technisch betrachtet handelt es sich bei Anwendungsseiten um klassische ASP.NET-Seiten (*.aspx), die innerhalb von SharePoint ausgeführt werden. Im Grunde kann jede ASP.NET-Anwendung über mehrere Anwendungsseiten in SharePoint abgebildet werden. Dieses Vorgehen hat mehrere Vorteile. Durch die direkte Integration in SharePoint muss keine neue MasterPage umgesetzt werden, die für eine klassische ASP.NET-basierte Anwendung nötig wäre. Eine zusätzliche Verteilung eines Host Headers und IP-Registrierung für die neue Anwendung entfallen ebenfalls. Zusätzlich können alle eingebauten SharePoint-Funktionen, z. B. Berechtigungsprüfung und Benutzerverwaltung, verwendet werden. In Kapitel 10 wird beispielhaft eine kleine Anwendung basierend auf Anwendungsseiten umgesetzt.

Zeitgesteuerte Aufträge (Timer Jobs)

Von Zeit zu Zeit müssen Aufräumarbeiten ausgeführt, Statistiken erstellt oder andere Aufgaben im Hintergrund durchgeführt werden. SharePoint nutzt dafür zeitgesteuerte Routinen, die in bestimmten Intervallen aktiviert werden. Eine Übersicht über alle eingeplanten Hintergrundaufgaben kann über die Zentraladministration (Central Administration) eingesehen werden, wie in Abbildung 3.4 dargestellt.

Abbildung 3.4: Eingeplante, zeitgesteuerte Hintergrundaktivitäten

Wie anhand der Menge an Einträgen deutlich wird, plant SharePoint mehr als nur eine zeitgesteuerte Hintergrundaktivität ein. Auch für eigene Zwecke kann diese Infrastruktur verwendet werden, und es besteht die Möglichkeit, eigene Hintergrundaufgaben zu definieren und einzuplanen. SharePoint bietet hierfür wieder ein vollständiges API und unterstützt somit die Erstellung spezieller Aktivitäten.

Dienstanwendungen

In SharePoint 2010 wurde die alte Shared-Service-Provider-Dienstarchitektur durch eine wesentlich flexiblere Architektur ersetzt. Die überarbeitete Architektur ermöglicht eine bessere Verwaltung und Nutzung der verschiedenen Dienste. Hierbei handelt es sich um ein offenes System, das leicht durch eigene Dienste erweitert werden kann. Eigene Dienste partizipieren dabei an der vorhandenen Dienstarchitektur und können somit vorgefertigte Funktionen nutzen.

Full Trust Proxies

Im Zusammenhang mit Sandkastenlösungen wird die Möglichkeit interessant, eigene Full Trust Proxies erstellen zu können. Da die Zugriffsmöglichkeiten auf das SharePoint API innerhalb einer Sandkastenlösung begrenzt sind, können erweiterte Funktionen über einen eigenen Full Trust Proxy bereitgestellt werden. Ein ausführliches Beispiel dazu ist in Kapitel 5.7.1 dargestellt.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -