Freigeben über

SharePoint-Add-Ins im Vergleich mit SharePoint-Lösungen

  • Artikel

Erfahren Sie, wann Sie Ihre SharePoint-Erweiterung als SharePoint-Add-In, als SharePoint-Farmlösung oder als codelose Sandkastenlösung entwickeln sollten.

In diesem Artikel werden Anwendungsfälle für SharePoint-Add-Ins, Farmlösungen und codelose Sandkastenlösungen (NCSSs) verglichen.

  • Neue SharePoint-Add-Ins sind eigenständige Erweiterungen, die möglicherweise cloudbasierte Logik und Daten, SharePoint-Komponenten und clientseitige Skripts, aber keinen benutzerdefiniert verwalteten Code enthalten, der auf SharePoint-Servern ausgeführt wird. Sie werden entweder über den Office Store oder den Add-In-Katalog einer Organisation installiert und können auf lokalen Farmen oder Microsoft SharePoint Online installiert werden. Eine Übersicht über SharePoint-Add-Ins finden Sie unter SharePoint-Add-Ins.
  • SharePoint-Farmlösungen sind Pakete mit SharePoint-Komponenten. Sie werden in einen farmweiten Katalog hochgeladen, aus dem sie installiert werden können. Sie können nicht über den Office Store verteilt werden und lassen sich nicht unter SharePoint Online installieren. Sie dürfen benutzerdefinierten verwalteten Code enthalten, der auf den Servern der SharePoint-Farm ausgeführt wird. Weitere Informationen zu den Grundlagen von Farmlösungen finden Sie unter Übersicht über Lösungen und Farmlösungen in SharePoint 2010.
  • NCSSs sind ebenfalls Pakete mit SharePoint-Komponenten, werden aber an einen Websitesammlungskatalog hochgeladen, aus dem sie installiert werden können. Sie können entweder in lokalen Farmen oder in SharePoint Online installiert werden, aber sie können nicht über den Office Store verteilt werden. Sie können fast die gleichen Arten von beschreibenden Komponenten wie SharePoint-Add-Ins enthalten, und sie können wie Add-Ins Über JavaScript verfügen, aber keinen benutzerdefinierten verwalteten Code enthalten, der auf den SharePoint-Servern ausgeführt wird. Unterschiede in den Bereitstellungssystemen von Add-Ins und NCSSs bedingen, dass NCSSs für einige wenige Szenarien die bessere Bereitstellungsoption sind. Informationen zu Sandkastenlösungen finden Sie unter Sandkastenlösungen in SharePoint 2010.

Wichtig

Zwar ist die Entwicklung von Sandkastenlösungen, die nur deklaratives Markup und JavaScript enthalten (von uns als "Sandkastenlösungen ohne Code" (No-Code Sandboxed Solutions, NCSS) bezeichnet), nach wie vor zulässig, jedoch wird die Verwendung von benutzerdefiniertem verwaltetem Code in der Sandkastenlösung von uns nicht mehr unterstützt. Als Ersatz für Szenarien, die verwalteten Code erfordern, haben wir das neue SharePoint-Add-In-Modell eingeführt. Das Add-In-Modell entkoppelt das SharePoint-Kernprodukt von der Add-In-Laufzeit. Dadurch sind Sie flexibler und können den Code in der Umgebung Ihrer Wahl ausführen. Uns ist bewusst, dass unsere Kunden bereits in codebasierte Sandkastenlösungen investiert haben, und wir werden dies bei der Einstellung dieser Lösungen entsprechend berücksichtigen. Bereits vorhandene codebasierte Sandkastenlösungen lassen sich bis auf Weiteres wie gewohnt in lokalen SharePoint-Farmen nutzen. Angesichts der Dynamik von Onlinediensten werden wir zukünftig ausgehend von der Kundennachfrage entscheiden, ob wir Unterstützung für codebasierte Sandkastenlösungen in SharePoint Online implementieren. Codelose Sandkastenlösungen (NCSS) werden weiterhin unterstützt. Unser Entwicklungsschwerpunkt wird jedoch zukünftig darauf liegen, das neue SharePoint-Add-In-Modell leistungsfähiger und funktionsreicher zu machen. Daher empfehlen wir Ihnen, für alle neuen Entwicklungsprojekte, wann immer möglich, das neue Add-In-Modell zu verwenden. In Szenarien, in denen Sie eine Farmlösung oder codebasierte Sandkastenlösung entwickeln müssen, empfehlen wir die Wahl eines Designs, das sich unkompliziert an ein stärker entkoppeltes Entwicklungsmodell anpassen lässt.

Entwickeln Sie wann immer möglich Add-Ins.

Unser wichtigster Ratschlag ist, wann immer möglich ein SharePoint-Add-In anstelle einer Farmlösung oder NCSS zu entwickeln. SharePoint-Add-Ins haben im Vergleich zu klassischen Lösungen die folgenden Vorteile:

  • Einfachster Such-, Erwerbs- und Installationsprozess für Benutzer
  • Sicherste SharePoint-Erweiterungen für Administratoren
  • Einfachstes Marketing- und Vertriebssystem auf der Basis eines Microsoft Online Add-In Stores
  • Maximale Flexibilität bei der Entwicklung zukünftiger Upgrades
  • Maximale Nutzung Ihrer vorhandenen Nicht-SharePoint-Programmierkenntnisse
  • Integration cloudbasierter Ressourcen auf reibungslosere und flexiblere Weise
  • Festlegen von Berechtigungen für Ihre Erweiterung, die sich von den Berechtigungen des Benutzers unterscheiden, der das Add-In ausführt
  • Verwendung von plattformübergreifenden Standards wie HTML, REST, OData, JavaScript und OAuth
  • Ermöglichen Sie es Ihnen, die Vorteile der domänenübergreifenden JavaScript-Bibliothek von SharePoint für den Zugriff auf SharePoint-Daten zu nutzen. Alternativ können Sie einen von Microsoft bereitgestellten sicheren Tokendienst verwenden, der OAuth-kompatibel ist, oder digitale Zertifikate verwenden, um die Autorisierung für SharePoint-Daten zu erhalten.

Entwerfen von Add-Ins oder NCSSs für Endbenutzer und Entwerfen von Farmlösungen für Administratoren

SharePoint-Add-Ins und NCSSs verwenden eins der SharePoint-Clientobjektmodelle oder einen der REST-Endpunkte, um auf SharePoint-Inhalte und -Komponenten zuzugreifen. Diese Client-APIs ermöglichen SharePoint-Erweiterungen, die auf Endbenutzer ausgelegt sind. („Endbenutzer" sind in diesem Kontext Administratoren von Websitesammlungen, Websitebesitzer und Websitemitglieder.) Das Serverobjektmodell bietet zusätzliche APIs, die programmatische Erweiterungen der Verwaltung, Konfiguration und Sicherheit von SharePoint ermöglichen. Dazu zählen Erweiterungen der Zentraladministration, benutzerdefinierte Windows PowerShell-Befehle, Zeitgeberaufträge und benutzerdefinierte Sicherungen. Weitere Informationen zu den Arten von administrativen Erweiterungen, die Sie entwickeln können, finden Sie unter Windows SharePoint Services Administration. Diese administrativen Erweiterungen werden in SharePoint-Features auf Farm-, Webanwendungs- oder Websitesammlungsebene bereitgestellt. SharePoint-Farmlösungen werden zudem von Farmadministratoren installiert, während Add-Ins und NCSSs von Administratoren von Mandanten und Websitesammlungen installiert werden können.

Das Serverobjektmodell verfügt auch über APIs zum Erstellen, Lesen, Aktualisieren und Löschen (CRUD) für Listen, Bibliotheken und Websites sowie für Vorgänge mit anderen SharePoint-Komponenten. Dies bedeutet, dass das Serverobjektmodell für Erweiterungen verwendet werden kann, die für Endbenutzer bestimmt sind, aber aus den im vorherigen Abschnitt angegebenen Gründen sind Farmlösungen in der Regel nicht die beste Wahl für solche Erweiterungen. Daher ist es kein Wunder, dass Farmlösungen nicht auf Microsoft Office SharePoint Online installiert werden können. Da Microsoft die gesamte Verwaltung von SharePoint Online übernimmt, sind keine administrativen Erweiterungen erforderlich. Weitere Informationen zu den verschiedenen APIs in SharePoint und zu den Überlappungen finden Sie unter Auswählen des richtigen API-Satzes in SharePoint.

Die Clientobjektmodelle und REST-Endpunkte sind keine Duplizierung der verwaltungsorientierten APIs des Serverobjektmodells. Darüber hinaus können Sie diese administrativen APIs nicht aufrufen, da weder eine SharePoint-Add-In noch eine NCSS benutzerdefinierten Code enthalten kann, der auf den SharePoint-Servern ausgeführt wird. Zusätzlich müssen alle Features in SharePoint-Add-Ins über den Websitebereich und Features in NCSSs entweder den Websitesammlungs- oder Websitebereich verfügen. Daher ist eine verwaltungsorientierte SharePoint-Erweiterung mit einer SharePoint-Add-In oder einer NCSS nicht wirklich möglich. Das zweite Prinzip, aber keine absolute Regel, ist also, dass Add-Ins und NCSSs für Endbenutzer und Farmlösungen für Administratoren vorgesehen sind.

Entwerfen von NCSSs für Branding und vorlagenartige Erweiterungen

Möglicherweise treffen Sie auf eines der geringen Anzahl von SharePoint-Entwicklungsszenarien, für die das Add-In-Modell nicht gut geeignet ist, das Sie aber auch nicht mit einer Farmlösung implementieren können, vielleicht weil die Lösung in SharePoint Online oder von einem Websitesammlungsadministrator installierbar sein muss. Es gibt zwei breite und überlappende Kategorien für derartige Szenarien.

  • Branding: SharePoint-Benutzer möchten das Design ihrer SharePoint-Websites und SharePoint Online-Websites häufig individuell anpassen, mit eigenen Farben, Formatvorlagen, Layouts und Logos. Das lässt sich im Allgemeinen leichter mit NCSS umsetzen als mit SharePoint-Add-Ins. SharePoint-Add-Ins können lediglich die Darstellung ihres eigenen Add-In-Webs deklarativ steuern. Zum Hostweb können sie deklarativ lediglich Menüband-Schaltflächen und Menüelemente (sowie Add-In-Parts) hinzufügen. Alle anderen Änderungen am Hostweb oder der übergeordneten Websitesammlung, dem Mandanten oder der lokalen SharePoint-Webanwendung müssen mittels Code oder Skript umgesetzt werden. Dabei muss eines der SharePoint-Clientobjektmodelle verwendet werden. Neue Symbole oder CSS-Dateien beispielsweise müssten programmgesteuert bereitgestellt werden. Dieser Code könnte vom Add-In selbst ausgeführt werden, nachdem es installiert wurde, oder im Ereignishandler für die Add-In-Installation. Allerdings wäre die Erstellung dieses Codes sehr arbeitsintensiv. Darüber hinaus würde das Add-In zur Änderung von Websites außerhalb seines eigenen Web und Hostweb Berechtigungen benötigen, die für die gesamte Websitesammlung gelten. Soll es mehr als nur seine übergeordnete Websitesammlung ändern können, bräuchte es Berechtigungen, die für den gesamten Mandaten gelten. Eine NCSS mit Branding lässt sich jedoch in jeder Websitesammlung bereitstellen und aktivieren und könnte lediglich einige rein deklarative Komponenten enthalten.

    Hinweis

    SharePoint-Farmlösungen eignen sich für Brandingzwecke potenziell besser als NCSS oder SharePoint-Add-Ins, stehen aber in SharePoint Online nicht zur Verfügung.

  • „Vorlagenartige" Erweiterungen: Nehmen wir an, Sie müssen eine Krisenmanagementerweiterung für SharePoint für die gemeinsame Analyse und Lösung von Geschäftskrisen erstellen. Ihre Erweiterung enthält einige benutzerdefinierte Listentypen, codelose Workflows und andere SharePoint-Komponenten, die alle in einer benutzerdefinierten Webvorlage kombiniert sind. Nehmen wir weiterhin an, Sie beschließen, die Erweiterung als NCSS zu packen und bereitzustellen. Nachdem das Feature in der Lösung aktiviert wurde, können Benutzer ein Unterweb für das Krisenmanagement ihrer SharePoint-Website erstellen, wann immer es zu einer Krise kommt. Sie können die Website mit speziell für die Krise relevanten Daten füllen. Andererseits könnten Sie dieselbe Erweiterung als SharePoint-Add-In implementieren und dabei exakt dieselbe Sammlung von SharePoint-Komponenten verwenden. Wenn das Add-In auf der Teamwebsite installiert ist, wird das Unterweb (das als „Add-In-Web" bezeichnet wird) sofort erstellt. Auch hier füllen Benutzer die Website mit relevanten Daten.

    Was geschieht jetzt aber, wenn es zu einer zweiten Krise kommt? Wenn Sie die Erweiterung als NCSS implementiert haben, können Ihre Benutzer lediglich ein weiteres Unterweb aus Ihrer benutzerdefinierten Webvorlage erstellen. Wenn die Erweiterung jedoch als SharePoint-Add-In implementiert wurde, haben seine Benutzer ein Problem. Sie können keine zweite Instanz des gleichen Add-Ins auf der übergeordneten Website installieren. In einem Hostweb kann nur eine Instanz eines Add-Ins installiert werden. Das Beste, was Sie tun können, ist die Erstellung eines Unterwebs der übergeordneten Website, das dann als Standort für eine weitere Instanz des zu installierenden Add-Ins dient. Wenn das Add-In installiert ist, wird ein neues Add-In-Web, das ein Unter-Unterweb der übergeordneten Website ist, für die Add-In-Komponenten erstellt. Dieser Vergleich zeigt ein allgemeines, aber nicht absolutes Prinzip: SharePoint-Erweiterungen, die eine „vorlagenartige" Eigenschaft haben - das heißt, eine wiederverwendbare Sammlung von Komponenten, die für jeden speziellen Anwendungsfall konfiguriert werden muss, natürlicherweise aber über mehrere Instanzen verfügt, die mit derselben SharePoint-Website verbunden sind - passen besser zum NCSS-Bereitstellungsmodell als zum Add-In-Modell. In diesem Beispiel ist das variable Element die Krise, aber Sie können sich leicht vorlagenartige SharePoint-Erweiterungen vorstellen, in denen sich die Instanzen nach Region, Datum oder beliebigen anderen Eigenschaften unterscheiden.

Informationen zum Erweitern der Möglichkeiten von SharePoint-Add-Ins finden Sie unter Konservatives Verwenden von Add-In-Ereignishandlern und Add-Ins, die Erweiterungen erstellen.

Add-In-gerechte Lösungen für Funktionen

Wie bereits erwähnt, ist benutzerdefinierter Code, der auf den SharePoint-Servern ausgeführt wird, in SharePoint-Add-Ins nicht zulässig. Dies ist keine wesentliche Einschränkung. Das ist keine bedeutende Einschränkung, sondern heißt einfach, dass Ihre benutzerdefinierte Geschäftslogik entweder „nach unten" zum Clientgerät oder „nach oben" in die Cloud verschoben wird. In jedem Fall können Sie den SharePoint-REST-/OData-Dienst verwenden, um auf SharePoint-Websites, Listen und andere Daten zuzugreifen. Auch ein Remotezugriff auf SharePoint-Daten ist über die SharePoint-JavaScript-, Silverlight- oder .NET Framework-Clientobjektmodelle möglich. Auf Windows Phones schließlich erfolgt der Zugriff auf SharePoint über das SharePointWindows Phone-Objektmodell. Weitere Informationen zu den verschiedenen APIs in SharePoint finden Sie unter Auswählen des richtigen API-Satzes in SharePoint.

Ein ähnlicher Punkt ist, dass Features in SharePoint-Add-Ins keinen Websitesammlungs-, Webanwendungs- oder Farmbereich haben können. Dennoch müssen Sie nicht auf Benutzeroberflächenenelemente oder -funktionalität verzichten. Dies bedeutet, dass die Implementierung der Komponente aus SharePoint in eine Client- oder Remotewebanwendung oder Remotedatenbank verschoben wird.

In der folgenden Tabelle sind die SharePoint-Komponenten aufgeführt, die nicht in einem SharePoint-Add-In bereitgestellt werden können. Außerdem wird beschrieben, wie Sie dieselbe Funktionalität auf „Add-In-gerechte Weise" erhalten können.

Wenn Sie die folgende Funktionalität haben möchten ... ... probieren Sie die folgenen Ansätze aus.
Benutzerdefinierte Webparts
 Ein SharePoint-Add-In kann Remoteseiten enthalten, die benutzerdefinierte Webparts enthalten. Eine weitere Option besteht darin, eine Seite von einer Remotewebanwendung in einem Add-In-Webpart auf einer SharePoint -Websiteseite bereitzustellen. Die Remoteseite kann im Grunde die gleichen Benutzeroberflächensteuerelemente und -funktionen wie ein Webpart aufweisen. Weitere Informationen finden Sie unter Erstellen von Add-In-Webparts zur Installation mit Ihrem SharePoint-Add-In.
Ereignis- und Funktionsempfänger Ein SharePoint-Add-In kann funktional äquivalente Remoteereignisempfänger enthalten. Weitere Informationen finden Sie unter Behandeln von Ereignissen in SharePoint-Add-Ins.
Benutzerdefinierte Feldtypen (Spaltentypen) Ein Add-In kann ein neues Feld (Spalte) bereitstellen, das auf einem der vorhandenen Feldtypen basiert. Die Feldtypen Calculated und Computed sind besonders flexibel. Eine weitere Möglichkeit besteht darin, Ihre Daten mithilfe von benutzerdefinierten Steuerelementen oder Rastern auf einer Remotewebseite darzustellen.
Benutzerdefinierte Webdienste, die auf dem SharePoint Service Application Framework basieren Sie können Ihre benutzerdefinierten Webdienste als Remotedienste entwickeln.
Anwendungsseiten Ein SharePoint-Add-In kann Remotewebseiten enthalten, die auf jeder Website verfügbar sind, auf der das Add-In installiert ist. Ein Add-In kann auch alle integrierten SharePoint-Webparts auf Websiteseiten verwenden.

Einige unten aufgeführte SharePoint-Komponenten werden in Endbenutzerszenarien verwendet, weisen jedoch keine Entsprechungen im SharePoint-Add-In-Modell auf und können nicht in NCSSs bereitgestellt werden. Für diese müssen Sie Farmlösungen verwenden.

Konservativer Einsatz von Add-In-Ereignishandlern

Sie können einige der Einschränkungen von SharePoint-Add-Ins überwinden, indem Sie Handler für das Installationsereignis, das Updateereignis und das Deinstallationsereignis von Add-Ins erstellen. Diese Handler sind Webdienste, die auf Webservern außerhalb der SharePoint-Farm, möglicherweise in der Cloud, gehostet werden. Sie können das SharePoint-Clientobjektmodell oder die REST-APIs verwenden, um CRUD-Vorgänge bei SharePoint-Komponenten durchzuführen, einschließlich der Komponenten im Hostweb. Theoretisch könnten Sie solche Handler verwenden, um einige Bereitstellungseinschränkungen in den Branding- und vorlagenartigen Erweiterungselementen zu überwinden, die zuvor dargestellt wurden. Sie sollten solche Handler jedoch nur als letztes Mittel verwenden, wenn keinerlei andere Möglichkeit vorhanden ist, Kunden die Funktionalität bereitzustellen, die in Ihrem Anwendungsfall erforderlich ist. Bedenken Sie Folgendes bei der Entscheidung, ob Sie einen Handler erstellen sollten:

  • Für die programmgesteuerte Bereitstellung an das Hostweb muss das Add-In Vollzugriff auf das Hostweb anfordern. Add-Ins, die diese Berechtigungsstufe benötigen, können nicht über den Office Store verkauft werden.
  • Die Bereitstellung von Komponenten an das Hostweb untergräbt oft die Sicherheitsvorteile, die es mit sich bringt, wenn Sie SharePoint-Komponenten in ein Add-In-Web mit einer eigenen Domäne stellen.
  • Das Erstellen und Debuggen von umfangreichem Bereitstellungscode bedeutet im Vergleich mit dem beschreibenden Bereitstellungs-Markup, das für Add-In-Webkomponenten und in NCSSs verwendet werden kann, eine Menge Arbeit.
  • Es gibt einige wichtige bewährte Methoden, die bei der Erstellung von Add-In-Ereignishandlern befolgt werden müssen. Ihr Code muss eine Rollback-Logik enthalten, um alle bisher durchgeführten Aktionen rückgängig machen zu können, wenn es zu einem Fehler kommt. Außerdem muss die SharePoint-Infrastruktur über den Fehler informiert werden, damit die Infrastruktur ein Rollback aller bisher von ihr durchgeführten Aktionen ausführen kann.
  • Add-In-Ereignishandler sind mit der Art von SharePoint-Add-In, die als von SharePoint gehostet bezeichnet werden, nicht möglich.

Weitere Informationen zu Add-In-Ereignishandlern finden Sie im SDK-Knoten Behandeln von Ereignissen in SharePoint-Add-Ins. Informationen zur Rollbacklogik finden Sie im Abschnitt Hinzufügen von Rollbacklogik zum Handler des Themas Erstellen eines Handlers für das Updateereignis in SharePoint-Add-Ins. Letzteres Thema wird im Kontext des aktualisierten Add-In-Ereignisses geschrieben, aber die Grundprinzipien gelten für alle Add-In-Ereignishandler.

Add-Ins, die Erweiterungen erstellen

Eine weitere Möglichkeit, das SharePoint-Clientobjektmodell oder seine REST-APIs zu verwenden, um Komponentenbereitstellungsprobleme mit SharePoint-Add-Ins zu beheben, besteht darin, CRUD-Code innerhalb des Add-Ins selbst und nicht in einem Add-In-Ereignishandler zu verwenden. Das Add-In wird dann zu einer Art Factory für einen Benutzerdefinierten Erweiterungstyp. Beispielsweise kann ein von SharePoint gehostetes Add-In das SharePointJavaScript-Objektmodell verwenden, um Bereitstellungs- und andere CRUD-Vorgänge im Hostweb oder an anderer Stelle im Mandanten oder in der Webanwendung durchzuführen. Ein weiteres Beispiel finden Sie im Abschnitt Schnellstart in die Remotebereitstellung unter Websitebereitstellungstechniken und Remotebereitstellung in SharePoint, in dem beschrieben wird, wie ein vom Anbieter gehostetes SharePoint-Add-In verwendet wird, um die Bereitstellung von Unterwebs ähnlich wie die Bereitstellung von Unterwebs in SharePoint zu ermöglichen. Es gibt jedoch eine Menge Raderfindung und daher eine Menge Arbeit beim Erstellen eines SharePoint-Add-Ins für die Factory. Darüber hinaus kann diese Art von Add-In nicht über den Office Store verkauft werden, da das Add-In Vollzugriff auf das Hostweb erfordert.

Siehe auch