SharePoint-Add-Ins

There are two basic kinds of SharePoint Add-ins: SharePoint-hosted and provider-hosted. To make the best decision about the right kind to develop for your scenario, start by learning what both types of SharePoint Add-ins have in common.

• Ein SharePoint-Add-In ist eine eigenständige Funktion, die die Funktionen von SharePoint-Websites erweitert, um ein klar definiertes Geschäftsproblem zu lösen.
• Add-ins don't have custom code that runs on SharePoint servers. Instead, all custom logic moves "up" to the cloud, or "down" to client computers, or "over" to an on-premises server that is outside the SharePoint farm or SharePoint Online subscription. Keeping custom code off SharePoint servers provides reassurance to SharePoint administrators that the add-in can't harm their servers or reduce the performance of their SharePoint Online websites.
• Die Geschäftslogik in einer SharePoint-Add-In greift über mehrere Client-APIs, die in SharePoint enthalten sind, auf SharePoint-Daten zu. Welche API Sie für ein Add-In verwenden, hängt von bestimmten Entscheidungen ab, die Sie hinsichtlich des Designs treffen.
• Fast alle Haupttypen von SharePoint-Komponenten kann Teil einer SharePoint-Add-In sein, einschließlich Seiten, Listen, Workflows, benutzerdefinierte Inhaltstypen, Listenvorlagen, Webparts und vieles mehr.
• The SharePoint websites where SharePoint Add-ins are installed, and from which users launch them, are called host webs. The SharePoint components, however, are generally in a special child web of the host web called the add-in web.
• SharePoint-Add-Ins können auf verschiedene Weise in eine SharePoint-Website integriert werden:
  • : Umfassende ganzseitige Erfahrung, die das Aussehen und Verhalten einer SharePoint-Seite aufweisen kann.
  • : Als Teil einer Webseite, die ein spezielles Steuerelement verwendet, das als Add-In-Part bezeichnet wird und mit dem ein iFrame-Element mit dem Add-In verfügbar gemacht wird.
  • : Als Benutzeroberflächenbefehle, die Menübänder und Menüs erweitern – für Listen, Dokumente und vieles mehr.
• All SharePoint Add-ins that users install get a tile on the Site Contents page of the SharePoint website. Clicking the tile runs the add-in.
• Eine SharePoint-Add-In wird durch ein Add-In-Manifest konfiguriert. Dies ist eine XML-Datei, in der deklariert wird, welche grundlegenden Eigenschaften das Add-In hat, wo es ausgeführt wird und welche Aktion SharePoint beim Starten des Add-Ins ausführen soll. Das Manifest kann unter anderem festlegen, welche Sprachen das Add-In unterstützt, von welchen SharePoint-Diensten und -Funktionen es abhängt und welche Berechtigungen für das Hostweb erforderlich sind, das vom Add-In benötigt wird. (SharePoint-Add-Ins haben Vollzugriff auf ihr eigenes Add-In-Web.)
• You distribute SharePoint Add-ins in add-in packages that always include at least the add-in manifest. (If there are no SharePoint components, the add-in manifest may be the only thing in the add-in package.) If the add-in has SharePoint components in an add-in web, these are included in the package as a set of XML files. Remote components that are hosted outside of SharePoint, such as a remote web application or database, are not included in the package and are deployed separately from the add-in package. (However, the add-in manifest does specify the URLs of the remote components.)
• Add-in packages can also include Office Add-ins. When the SharePoint Add-in is installed, the Office Add-in is added to an Office Add-ins catalog in SharePoint. Users can install it from the catalog into Office applications such as Word or Excel.

Einige Hinweise für erfahrene SharePoint-Entwickler

Sandkastenlösungen, die benutzerdefinierten serverseitigen Code enthalten, werden nicht mehr unterstützt. Sandkastenlösungen „ohne Code“ und Sandkastenlösungen, die nur JavaScript enthalten, werden weiterhin unterstützt.

SharePoint Add-ins don't use the server-side SharePoint object model. The client-side object models are greatly expanded in SharePoint. Although some APIs in the SharePoint server object model aren't available in the client object models, these are almost entirely administrative and security-related classes. Custom SharePoint logic that addresses these areas is more appropriate for a Windows PowerShell script or classic SharePoint farm solution. To learn how to choose among SharePoint Add-ins, classic SharePoint farm solutions, and sandboxed solutions, see SharePoint Add-ins compared with SharePoint solutions.

Zwei Möglichkeiten zum Verteilen oder Verkaufen eines Add-In-Pakets

Sie haben zwei Möglichkeiten zum Verteilen eines Add-In-Pakets:

• To an organization's add-in catalog, which is a dedicated SharePoint site collection in the SharePoint Online subscription or on-premises farm. This method is used when the add-in is custom-made for a particular organization.
• To the Office Store. The store handles the marketing process for you, from discovery to purchase to updates. Microsoft has a Seller Dashboard to help you sell add-ins through the Office Store.

Nachdem Sie das Add-In anhand einer der beiden Möglichkeiten bereitgestellt haben, steht es auf der Seite zum Hinzufügen eines Add-Ins auf den SharePoint-Websites zur Verfügung. Wenn das Add-In Berechtigungen für das Hostweb oder das übergeordnete Abonnement benötigt, fordert SharePoint den Benutzer, der das Add-In installiert, zum Gewähren dieser Berechtigungen auf.

Wenn Sie ein Add-In aktualisieren müssen, um einen Fehler zu beheben oder Funktionen hinzuzufügen, nehmen Sie die Änderungen vor, und erhöhen Sie die Versionsnummer des Add-Ins im Manifest. Stellen Sie das Add-In-Paket dann neu im Store oder Add-In-Katalog bereit. Benutzer erhalten innerhalb von 24 Stunden eine Benachrichtigung in der SharePoint-UI, dass ein Update verfügbar ist. Sie können das Update mit nur einem Klick installieren.

Zwei Arten von SharePoint-Add-Ins: von SharePoint-gehostet und vom Anbieter gehostet

SharePoint-hosted SharePoint-Add-Ins

Von SharePoint gehostete Add-Ins bestehen fast nur aus SharePoint-Komponenten in einem Add-In-Web. Daher wird auch gesagt, dass sie ihren „Schwerpunkt“ in SharePoint haben.

Like all SharePoint Add-ins, a user can run a SharePoint-hosted add-in from a tile on the Site Contents page of the SharePoint website to which it's installed. Optionally, it can also have two other kinds of UI components in the host web: add-in parts and custom actions (that is, custom ribbon buttons or menu items). Everything else in a SharePoint-hosted add-in is deployed to the add-in web. These components are defined declaratively using XML files, and they can include, among others:

• Benutzerdefinierte Seiten
• Workflows
• Module (Dateigruppen)
• Listenvorlagen
• Listen- und Bibliotheksinstanzen
• Benutzerdefinierte Listenformulare und Ansichten
• Angepasste Inhaltstypen
• Webvorlagen
• Integrierte Spalten (keine benutzerdefinierten Spalten)
• Integrierte Webparts (keine benutzerdefinierten Webparts)
• JavaScript-Dateien
• Benutzerdefinierte Schaltflächen und Menüelemente für das Add-In-Web

All business logic in a SharePoint-hosted add-in uses JavaScript, either directly on a custom page or in a JavaScript file that is referenced from a custom page. A JavaScript version of the SharePoint object model (JSOM) is available to make it simple for the add-in to perform CRUD (create, read, update, and delete) operations on SharePoint data.

Custom pages in a SharePoint-hosted add-in are generally ASP.NET pages (ASPX), and they can declaratively reference ASP.NET and in-the-box SharePoint controls, but there can be no code behind. However, you can customize the SharePoint controls by using a client-side rendering option and custom JavaScript.

The JavaScript in SharePoint-hosted add-ins can access data and resources that are outside of the add-in web by using either of two techniques for safely working around the browser's same origin policy: a special JavaScript cross-domain library or a specific JavaScript WebProxy class. Using these techniques, a SharePoint-hosted add-in can work with data on the host web, its parent subscription, or anywhere on the Internet.

Vom Anbieter gehostete SharePoint-Add-Ins

Any SharePoint component that can be in a SharePoint-hosted add-in can also be in a provider-hosted add-in. But provider-hosted add-ins are distinguished from SharePoint-hosted add-ins because they include at least one remote component, such as a web application, service, or database, that is hosted externally from the SharePoint farm or SharePoint Online subscription. This could be a server in the same corporate network as a SharePoint farm or a cloud service. The external components can be hosted on any web hosting stack, including the Linux, Apache, MySQL, and PHP (LAMP) stack.

You have complete flexibility for the hosting framework that you use for the remote components. You don't have to use a Microsoft stack. Any web hosting framework can be used, including LAMP (Linux, Apache server, MySQL, PHP), MEAN (MongoDB, ExpressJS, AngularJS, Nodejs), Java, Python, and others, and you are welcome to use non-Microsoft development tools. In addition, the remote components can be hosted in non-Microsoft cloud services.

Remoteseiten im Add-In können mithilfe eines speziellen Chromsteuerelements das Erscheinungsbild und Verhalten von SharePoint-Seiten erhalten.

Remotedaten können unter anderem Blobs, Caches, Nachrichtenwarteschlangen, Netzwerke für die Inhaltsübermittlung (CDN) und Datenbanken sein. Datenbanken können einen beliebigen Typ haben, einschließliche relational und objektorientiert. Auf die Remotedaten kann auf verschiedene Weise zugegriffen werden. Sie können beispielsweise Business Connectivity Services (BCS) verwenden, um die Daten in einer SharePoint-Liste bereitzustellen. Eine weitere Option besteht darin, Daten in einem Raster auf einer Seite einer Remotewebanwendung darzustellen.

SharePoint-Add-Ins verwenden SharePoint-APIs für die Verbindung und Integration mit SharePoint -Funktionen wie Suche, Workflow, soziale Netzwerke, Taxonomie, Benutzerprofile, BCS und mehr. Damit können sie Dokumente lesen, Suchen durchführen, Benutzer verbinden und CRUD-Vorgänge ausführen. Es gibt verschiedene Sätze von APIs:

• Wenn die Remotekomponenten mit .NET implementiert werden, ist die Bibliothek des clientseitigen SharePoint-Objektmodells (CSOM) mit verwaltetem Code verfügbar.
• For remote components that are not based on .NET, a set of REST/OData APIs can be used to access SharePoint data. These can also be used from a .NET client if you prefer working with an OData interface.
• Die JSOM-Bibliothek, die weiter oben erwähnt wurde, kann nicht auf einer Remoteseite verwendet werden. Von einem Anbieter gehostete Add-Ins können jedoch benutzerdefinierte SharePoint-Seiten in einem Add-In-Web haben, und JavaScript auf diesen Seiten kann die JSOM-Bibliothek verwenden.

Von einem Anbieter gehostete Add-Ins, die auf SharePoint zugreifen, sind Sicherheitsprinzipale, ebenso wie Benutzer und Gruppen es sind. Der Add-In-Prinzipal muss ebenso wie der Benutzer authentifiziert und autorisiert werden. Das Add-In benötigt Berechtigungen, um Vorgänge an SharePoint-Daten im Hostweb durchzuführen. In den meisten Szenarien sind die effektiven Berechtigungen eines Benutzers, der mit SharePoint über eine SharePoint-Add-In arbeitet, die Schnittstelle der Berechtigungen des Benutzers und des Add-Ins, obwohl es einige Szenarien gibt, in denen ein Benutzer Aktionen mit einem Add-In ausführen kann, für das er andernfalls keine Berechtigung hätte.

Von einem Anbieter gehostete Add-Ins können eine Verbindung zu einem beliebigen internen oder öffentlichen Webdienst herstellen, und im Gegensatz zu von SharePoint gehosteten Add-Ins können sie SharePoint-Listen- und -Listenelementereignisse verarbeiten, z. B. das Hinzufügen eines Elements zu einer Dokumentbibliothek.

Auswählen des richtigen Weges für die SharePoint-Entwicklung

Sind Sie bereit zu beginnen?

• Wenn Sie ein erfahrener SharePoint-Entwickler sind, empfehlen wir, mit von SharePoint gehosteten Add-Ins zu beginnen. Sie sind den Arten von SharePoint-Erweiterungen, die Sie in der Vergangenheit entwickelt haben, am ähnlichsten.

  Erste Schritte beim Erstellen von von SharePoint gehosteten SharePoint-Add-Ins

• Wenn Sie ein erfahrener ASP.NET-Webanwendungsentwickler sind, empfehlen wir, mit von einem Anbieter gehosteten Add-Ins zu beginnen. Diese werden um Webanwendungen erstellt.

  Erste Schritte beim Erstellen von von einem Anbieter gehosteten SharePoint-Add-Ins

• Wenn Sie ein von einem Anbieter gehostetes Add-In auf einem Stapel eines anderen Anbieters als Microsoft entwickeln möchten, finden Sie im Folgenden Informationen zu den ersten Schritten:

  • Wenn Sie noch keine passenden Tools für Ihren Stapel haben, installieren Sie die Tools, die für Ihren Stapel geeignet sind.
  • Get a developer account on Office 365 for testing and debugging purposes. For details, go to Set up a development environment for SharePoint Add-ins on Office 365, or if you already have an Office 365 subscription, you just need to create a Developer Site on it.
  • Ihr Add-In verwendet SharePoint-REST-/OData-APIs, um CRUD-Vorgänge für SharePoint-Daten auszuführen:
    • Die erläuternde Dokumentation finden Sie im Artikel Einführung in den SharePoint-REST-Dienst und unter den darin enthaltenen Links zu anderen Artikeln.
    • Die Referenzdokumentation finden Sie unter REST-API-Referenz für SharePoint.
  • If you are not using Visual Studio, you have to create the add-in manifest file and the add-in package. For information, see Explore the app manifest structure and the package of a SharePoint Add-in. There are a lot of time-saving advantages to using Visual Studio and Microsoft Office Developer Tools for Visual Studio to make your manifest and package. We recommend that you consider them, even if you use another tool to create the remote web application itself. The Community edition of Visual Studio is free.
  • Es gibt Beispiele für von einem Anbieter gehostete Add-Ins für einige nicht von Microsoft stammende Sprachen und Plattformen im OfficeDev-Abschnitt auf GitHub, z. B. PHP-App-for-SharePoint.

Siehe auch

• SharePoint-Glossar