Compléments SharePoint par rapport aux solutions SharePoint

Cet article conserve une comparaison antérieure des compléments SharePoint, des solutions de batterie de serveurs et des solutions bac à sable sans code. Il ne s’agit pas d’une recommandation pour créer des compléments SharePoint Online. Pour les nouvelles extensions de l’interface utilisateur de SharePoint Online, utilisez SharePoint Framework (SPFx) ; pour les compléments existants, consultez les conseils en matière de migration.

Cet article compare les cas d'utilisation des Compléments SharePoint, solutions de batterie de serveurs et des solutions bac à sable sans code (NCSS).

• Les compléments SharePoint sont des extensions autonomes qui peuvent inclure une logique et des données hébergées en externe, des composants SharePoint et des scripts côté client, mais pas de code managé personnalisé qui s’exécute sur les serveurs SharePoint. Historiquement, ils pouvaient être installés sur SharePoint Online et SharePoint Server. Après le retrait de SharePoint Online, seuls les déploiements SharePoint Server applicables via un catalogue d’applications sur site restent en dehors de ce retrait. Pour obtenir une vue d’ensemble, voir Compléments SharePoint.
• Les solutions de batterie de serveurs SharePoint sont des packages de composants SharePoint qui sont chargés vers une galerie au niveau de la batterie de serveurs d’où ils peuvent être installés. Ils ne peuvent pas être distribués via Office Store et ne peuvent pas être installés sur SharePoint Online. Ils peuvent inclure du code managé personnalisé qui s’exécute sur les serveurs de batterie de serveurs SharePoint. Pour plus d’informations sur les principes de base des solutions de batterie de serveurs, voir Vue d’ensemble des solutions et Solutions de batterie de serveurs dans SharePoint 2010.
• Les NCSS sont également des packages de composants SharePoint ; Mais elles sont chargées dans une galerie de collections de sites à partir de laquelle elles peuvent être installées. Ils peuvent être installés dans des batteries de serveurs sur site ou dans SharePoint Online, mais ils ne peuvent pas être distribués via Office Store. Ils peuvent inclure presque les mêmes types de composants descriptifs que les compléments SharePoint et, comme les compléments, ils peuvent avoir JavaScript, mais ils ne contiennent pas de code managé personnalisé qui s’exécute sur les serveurs SharePoint. Les différences dans les systèmes de déploiement des compléments et des NCSS font des NCSS une meilleure option de développement pour une liste courte de scénarios. Pour plus d’informations sur les solutions bac à sable, consultez Solutions bac à sable dans SharePoint 2010.

Les sections suivantes décrivent les compromis historiques de conception des compléments. Les recommandations d’utilisation du modèle de complément au lieu de solutions de batterie de serveurs ou de bac à sable ne s’appliquent plus à SharePoint Online après le retrait. Le retrait ne met pas hors service les API clientes SharePoint utilisées par ces solutions.

Développez un complément chaque fois que vous pouvez

Traditionnellement, les conseils étaient de préférer un complément SharePoint à une solution de batterie de serveurs ou NCSS lorsque cela était possible. La liste suivante indique la justification initiale, y compris les capacités du marché qui ne sont plus disponibles ; il ne s’agit pas de conseils de développement SharePoint Online actuels :

• Elles fournissent aux utilisateurs les processus les plus simples en matière de découverte, d'achat et d'installation.
• Elles offrent aux administrateurs les extensions SharePoint les plus sûres.
• Elles vous fournissent le système de vente et de marketing le plus simple, basé sur un magasin de compléments en ligne de Microsoft.
• Elles maximisent votre flexibilité pour le développement de futures mises à niveau.
• Elles optimisent votre capacité à tirer parti de vos compétences existantes en matière de programmation d'applications autres que SharePoint.
• Elles intègrent les ressources informatiques de manière plus fluide et plus souple.
• Elles activent votre extension pour obtenir des autorisations qui sont distinctes des autorisations de l'utilisateur qui exécute le complément.
• Elles vous permettent d'utiliser des normes interplateformes, notamment HTML, REST, OData, JavaScript et OAuth.
• Elles vous permettent de tirer parti de la bibliothèque SharePoint inter-domaines JavaScript pour accéder aux données SharePoint. Vous pouvez également utiliser un service de jeton sécurisé fourni par Microsoft compatible avec OAuth ou utiliser des certificats numériques pour obtenir l'autorisation pour les données SharePoint.

Concevoir des compléments ou des NCSS pour les utilisateurs finaux et des solutions de batterie de serveurs pour les administrateurs

Les Compléments SharePoint et les NCSS utilisent l'un des modèles objet client SharePoint ou l'un des points de terminaison REST pour accéder au contenu et aux composants SharePoint. Ces API clientes activent les extensions SharePoint qui sont conçues pour les utilisateurs finaux. (Les « utilisateurs finaux » dans ce contexte sont les administrateurs de collection de sites, les propriétaires de site web et les membres de site web.) Le modèle objet de serveur a des API supplémentaires qui autorisent des extensions de programmation pour la gestion, la configuration et la sécurité de SharePoint. Cela comprend les extensions de l'Administration centrale, les commandes Windows PowerShell personnalisées, les travaux du minuteur et les sauvegardes personnalisées. Pour plus d’informations sur les types d’extensions administratives que vous pouvez développer, voir Administration de Windows SharePoint Services. Ces extensions d'administration sont déployées dans les fonctionnalités SharePoint concernant la batterie de serveurs, l'application web ou la collection de sites. Les solutions de batterie de serveursSharePoint sont également installées par les administrateurs de batterie de serveurs, même si les compléments et les NCSS peuvent être installés par le client et les administrateurs de collections de sites.

Le modèle d’objet serveur comporte également des API pour les opérations de création, de lecture, de mise à jour et de suppression (CRUD) sur les listes, les bibliothèques et les sites web, ainsi que pour les opérations sur d’autres composants SharePoint. Cela signifie que le modèle objet serveur peut être utilisé pour les extensions destinées aux utilisateurs finaux, mais pour les raisons indiquées dans la section précédente, les solutions de batterie de serveurs ne sont généralement pas le meilleur choix pour de telles extensions. Par conséquent, il n’est pas surprenant que les solutions de batterie de serveurs ne puissent pas être installées sur Microsoft Office SharePoint Online. Étant donné que Microsoft gère toute la gestion de SharePoint Online, il n’est pas nécessaire de recourir à des extensions administratives. Pour plus d’informations sur les différents ensembles d’API dans SharePoint et sur leurs chevauchements, consultez Choisir le bon ensemble d’API dans SharePoint.

Les modèles objet client et les points de terminaison REST ne dupliquent pas les API orientées administration du modèle objet serveur. En outre, étant donné que ni une Complément SharePoint ni une NCSS ne peuvent contenir du code personnalisé qui fonctionne sur les serveurs SharePoint, elles ne peuvent pas appeler ces API d'administration. De plus, toutes les fonctionnalités des Compléments SharePoint doivent avoir une étendue de site web, et les fonctionnalités des NCSS doivent avoir une étendue de collection de sites ou de site web. Ainsi, une extension SharePoint orientée administration n'est pas vraiment possible avec une Complément SharePoint ou une NCSS. Par conséquent, selon le deuxième principe, qui n'est pas une règle absolue, les compléments et les NCSS sont faits pour les utilisateurs finaux et les solutions de batterie de serveurs sont faites pour les administrateurs.

Concevoir des NCSS pour des extensions de type modèle et de personnalisation

Vous pouvez rencontrer l'un des quelques scénarios de développement SharePoint pour lesquels le modèle de complément n'est pas adapté, mais que vous ne pouvez pas implémenter avec une solution de batterie de serveurs, peut-être parce que la solution doit être installée sur SharePoint Online ou doit être installée par un administrateur de collection de sites. Il existe deux catégories générales, et qui se chevauchent, de tels scénarios.

• Personnalisation : les utilisateurs SharePoint souhaitent souvent donner à leurs sites SharePoint (et à leurs sites SharePoint Online) une apparence personnalisée avec leurs propres couleurs, styles, dispositions et logos. Cela est généralement plus facile à faire avec des solutions bac à sable (sandbox) sans code qu’avec des compléments SharePoint. Un complément SharePoint a un contrôle déclaratif sur l’apparence du site web de son complément uniquement. Pour le site web hôte, il peut ajouter uniquement des éléments de menu et des boutons du ruban de manière déclarative (et des parties de complément). Les autres modifications apportées à un site web hôte ou à sa location, collection de sites parent ou application web SharePoint locale doivent être effectuées avec un code ou un script qui utilise l’un des modèles objet client de SharePoint. Par exemple, les nouvelles icônes ou les nouveaux fichiers CSS doivent être déployés par programme. Ce code peut être exécuté à partir du complément après son installation ou dans le gestionnaire d’événements d’installation du complément. Néanmoins, la création de ce code nécessite une quantité considérable de travail. En outre, le complément doit disposer d’autorisations limitées à la collection de sites pour modifier tous les sites web se trouvant en dehors du site web de son complément et du site web hôte, et il doit disposer d’autorisations limitées au client pour modifier plus que sa collection de sites parent. Une solution bac à sable (sandbox) de personnalisation peut toutefois être déployée et activée sur n’importe quelle collection de sites ; et elle peut se composer de quelques composants purement déclaratifs uniquement.

  Remarque

  Les solutions de batterie de serveurs SharePoint sont potentiellement plus puissantes que des NCSS ou des compléments SharePoint pour la personnalisation, mais elles ne constituent pas une option envisageable sur SharePoint Online.

• Extensions de type modèle : supposons que vous devez créer une extension de gestion de crise pour SharePoint, pour une analyse collaborative et une solution de crises d'entreprise. Votre extension comprend plusieurs types de liste personnalisée, des flux de travail sans code et d'autres composants SharePoint, tous combinés en un élément WebTemplate personnalisé. Supposons que vous créez un package et déployez l'extension sous forme de NCSS. Une fois la fonctionnalité de la solution activée, les utilisateurs peuvent créer un sous-site web de gestion de crise de leur site SharePoint à chaque fois qu'une crise se produit. Ils peuvent remplir le site web avec des données propres à la crise. En revanche, vous pouvez implémenter la même extension qu'une Complément SharePoint à l'aide du même ensemble de composants SharePoint. Lorsque le complément est installé sur le site d'équipe, le sous-site web (appelé « site web de complément ») est immédiatement créé. Là encore, les utilisateurs remplissent le site web avec des données pertinentes.

  Maintenant, que se passe-t-il en cas de deuxième crise ? Si vous avez implémenté l'extension sous forme de NCSS, vos utilisateurs peuvent simplement créer un autre sous-site web à partir de votre élément WebTemplate personnalisé. Cependant, si vous avez implémenté l'extension sous forme d'Complément SharePoint, un problème se pose pour vos utilisateurs. Ils ne peuvent pas installer une deuxième instance du même complément sur leur site web parent. Une seule instance d'un complément peut être installée sur un site web hôte. Tout ce que vous pouvez faire consiste à créer un sous-site du site web parent pour servir d'emplacement pour une autre instance du complément à installer. Lorsque le complément est installé, un nouveau site web de complément, qui est un sous-site du site web parent, est créé pour les composants de complément. Cette comparaison démontre un principe général, mais pas absolu : les extensions SharePoint qui ont un caractère de type modèle, c'est-à-dire, une collection de composants réutilisable qui doit être configurée pour chaque cas d'utilisation spécifique, mais qui a naturellement plusieurs instances associées au même site web SharePoint, sont plus adaptées au modèle de développement NCSS qu'au modèle de complément. Dans cet exemple, l'élément variable est la crise, mais il est facile d'imaginer des extensions SharePoint de type modèle dans lesquelles les instances varient par région, date ou de nombreuses autres caractéristiques.

Pour plus d’informations sur comment étendre les possibilités des compléments SharePoint, consultez Utiliser les gestionnaires d’événements des compléments de manière conservatrice et Compléments qui créent des extensions.

Activer des fonctionnalités comme dans un complément

Comme indiqué précédemment, le code personnalisé qui s’exécute sur les serveurs SharePoint n’est pas autorisé dans les compléments SharePoint. Il ne s’agit pas d’une limitation importante. Cela signifie simplement que votre logique métier personnalisée est soit « hors service » sur le périphérique client, soit « en service » dans le cloud. Dans les deux cas, vous pouvez utiliser le service SharePoint REST/OData pour accéder aux sites, listes et autres données SharePoint. Vous pouvez également accéder à distance aux données SharePoint via les modèles d’objets clients SharePoint JavaScript, Silverlight ou .NET Framework. Enfin, sur les Windows Phone, vous pouvez accéder à SharePoint via le modèle d’objet SharePointWindows Phone. Pour plus d’informations sur les différents ensembles d’API dans SharePoint, consultez Choisir le bon jeu d’API dans SharePoint.

De même, les fonctionnalités des Compléments SharePoint ne peuvent pas disposer d'une étendue de collection de sites, d'application web ou de batterie de serveurs. Toutefois, il est inutile d'abandonner des fonctionnalités ou des éléments de l'interface utilisateur. Cela signifie que l’implémentation du composant passe de SharePoint à un client, une application web distante ou une base de données distante.

Le tableau suivant répertorie les composants SharePoint qui ne peuvent pas être déployés dans une Complément SharePoint et décrit comment obtenir ces mêmes fonctionnalités à la manière d'un complément.

Certains composants SharePoint, répertoriés ci-dessous, sont utilisés dans des scénarios d’utilisateur final, mais n’ont pas d’équivalent dans le modèle de complément SharePoint et ne peuvent pas être déployés dans des NCSS. Dans ce cas, vous devez utiliser des solutions de batterie de serveurs.

• Définitions de site personnalisées Toutefois, les éléments WebTemplate personnalisés, qui sont fonctionnellement semblables à des définitions de site, sont disponibles à la fois dans les NCSS et les Compléments SharePoint. Pour plus d'informations, consultez Utilisation des modèles et des définitions.
• Contrôles de délégation Pour plus d'informations, consultez Contrôle de délégation (modélisation des contrôles).
• Thèmes personnalisés
• Groupes d'actions personnalisées et masquage d'actions personnalisées
• Contrôles utilisateur (fichiers *.ascx) Aucun scénario ne les requiert réellement.

Utiliser des gestionnaires d'événements de complément de manière conventionnelle

Vous pouvez contourner certaines des limitations des Compléments SharePoint en créant des gestionnaires pour les événements d'installation, de mise à jour et de désinstallation du complément. Ces gestionnaires sont des services web hébergés sur des serveurs web en dehors de la batterie de serveurs SharePoint, éventuellement dans le cloud. Ils peuvent utiliser le modèle objet client SharePoint ou les API REST pour effectuer des opérations CRUD sur les composants SharePoint, y compris les composants du site web hôte. En théorie, vous pouvez utiliser ces gestionnaires pour contourner certaines restrictions de déploiement dans les éléments de personnalisation et d' extensions de type modèle évoqués précédemment. Toutefois, nous vous recommandons d'utiliser ces gestionnaires uniquement en dernier ressort, lorsqu'il est impossible de fournir aux clients la fonctionnalité nécessaire. Lorsque vous décidez de créer un gestionnaire, prenez en compte les informations suivantes :

• Le déploiement de programmation pour le site web hôte exige que le complément demande l'autorisation Contrôle total au site web hôte. Les compléments qui requièrent ce niveau d'autorisation ne peuvent pas être vendus via le Office Store.
• Le déploiement de composants vers le site web hôte tend à compromettre les avantages de sécurité consistant à placer les composants SharePoint dans un complément web avec son propre domaine.
• La création et le débogage du code de déploiement complet représentent un travail énorme par rapport au balisage de déploiement descriptif qui peut être utilisé pour les composants web de complément et dans les NCSS.
• Certaines meilleures pratiques indispensables doivent être suivies pour la création de gestionnaires d'événements de complément. Votre code doit inclure une logique de restauration pour annuler tout ce qu'il a créé en cas d'erreur. Il doit également alerter l'infrastructure SharePoint de l'erreur, afin que l'infrastructure puisse annuler tout ce qui a été effectué.
• Les gestionnaires d'événements de complément ne peuvent pas exister avec le type d'Complément SharePoint appelé « hébergée sur SharePoint ».

Pour plus d’informations sur les gestionnaires d’événements de complément, consultez le nœud SDK Gérez les événements dans les compléments SharePoint. Pour plus d’informations sur la logique de restauration, consultez la section Ajouter une logique de restauration au gestionnaire de la rubrique Créer un gestionnaire pour l’événement de mise à jour dans SharePoint Compléments Cette dernière rubrique est écrite dans le contexte de l’événement de mise à jour du complément, mais les principes de base s’appliquent à tous les gestionnaires d’événements de complément.

Les compléments qui créent des extensions

Une autre façon d'utiliser le modèle objet client SharePoint, ou ses API REST, pour résoudre les problèmes de déploiement des composants avec les Compléments SharePoint, consiste à disposer d'un code CRUD dans le complément lui-même, plutôt que dans un gestionnaire d'événements de complément. Le complément devient alors un type de fabrique pour un type d'extension personnalisée. Par exemple, un complément hébergé par SharePoint peut utiliser le modèle objet JavaScriptSharePoint pour effectuer le déploiement et d'autres opérations CRUD sur le site web hôte ou ailleurs dans la location ou l'application web. Pour obtenir un autre exemple, consultez la rubrique Brève introduction à la mise en service à distance de l'article Techniques de mise en service de site et mise en service à distance dans SharePoint, qui décrit comment une Complément SharePoint hébergée par un fournisseur est utilisée pour la mise en service d'un sous-site de manière parfaitement identique à la mise en service d'un sous-site web de SharePoint. Il existe, cependant, un grand nombre de méthodes réinventées, et donc la création d'une fabrique d'Complément SharePoint représente un travail énorme. En outre, ce type complément ne peut pas être vendu via le Office Store, car le complément nécessite le contrôle total du site web hôte.

Voir aussi

• Modèles de programmation dans SharePoint
• Utilisation de solutions