Share via

Héberger des sites web, des sites web de complément et des composants SharePoint dans SharePoint

  • Article

Lorsqu’un complément qui comporte des composants SharePoint est installé sur un site web, il figure dans une liste sur la page Contenu du site à partir de laquelle il peut être lancé. Cette liste, qui constitue le point de lancement du complément, est le seul élément à ajouter obligatoirement au site web, bien que d’autres éléments puissent éventuellement être ajoutés, par exemple une action personnalisée ou un composant de complément. Pour plus d’informations sur ces options, consultez l’article décrivant comment accéder au complément à partir de l’interface utilisateur.

Sites web hôtes, sites web de complément et domaine isolé

À la différence des éléments d’interface utilisateur, les composants et le contenu d’un complément SharePoint, tels que les listes, les types de contenu, les flux de travail et les pages, sont déployés sur un autre site web dans un domaine isolé spécifique. Ceci est en grande partie invisible pour l’utilisateur. Le site web sur lequel le complément est déployé est nommé site web de complément. Le site web sur lequel le complément est installé est nommé site web hôte. Bien que le site web de complément possède son propre domaine isolé, il se trouve dans la même collection de sites que le site web hôte. (Une exception à cette règle est lorsque le complément est installé avec l’étendue du locataire. Dans ce scénario, le site web de complément se trouve dans la collection de sites du catalogue de compléments d’entreprise.)

La figure 1 représente un site web hôte avec deux compléments SharePoint installés. Le complément 1 est doté de composants distants, mais pas de composants SharePoint : il ne dispose donc pas de site web de complément. Le complément 2 n’est pas doté de composants distants, mais de deux listes SharePoint et d’un flux de travail. Ces éléments ont été déployés sur un sous-site isolé. (Un complément SharePoint peut être doté à la fois de composants distants et de composants hébergés sur SharePoint, ce qui n’est pas le cas pour les deux compléments représentés dans ce schéma.)

Figure 1 : site web hôte avec un complément hébergé par un fournisseur et un complément hébergé par SharePoint

Page web d’hôte, page web d’application et leurs composants

Supposons par exemple qu'un complément doté de composants SharePoint légèrement au-delà des éléments d'interface utilisateur pouvant être déployés sur un site web hôte soit installé sur un site web hôte à l'URL suivante :

https://www.fabrikam.com/sites/Marketing

Le Complément SharePoint sera déployé sur un nouveau site web avec une URL telle que :

http://add-in-bdf2016ea7dacb.fabrikamadd-ins.com/sites/Marketing/Scheduler

Notez que cette URL possède la structure suivante :

https://` _Add-in_Prefix_ `-` _Add-in_ID_ `.` _Add-in_Base_Domain_ `/` _Domain_Relative_URL_of_Host_Web_ `/` _Add-in_Name_

Les espaces réservés sont définis comme suit :

  • Préfixe_du_complément est une chaîne de caractères définie par l'administrateur de la batterie de serveurs au niveau de l'Administration centrale. La valeur par défaut est « default ». Dans cet exemple, l’administrateur a remplacé ce paramètre par « complément ».
  • ID_du_complément est un nombre hexadécimal généré en interne lorsque le complément est installé.
  • Domaine_de_base_du_complément est une chaîne de caractères définie par l’administrateur de la batterie de serveurs au niveau de l’administration centrale ou avec le SharePoint Management Shell. Cette valeur ne doit pas être définie sur un sous-domaine de l’application web SharePoint, car l’isolation de complément ne serait pas respectée. Dans cet exemple, l’administrateur a supprimé « www » et a ajouté « add-ins » au nom de la société. fabrikamadd-ins.com est donc le domaine de base du complément.
  • URL_relative_au_domaine_du_site_web_hôte est l’URL relative du site web hôte parent, dans ce cas sites/Marketing.
  • Nom_du_complément est la valeur de l'attribut Name de l'élément App dans le fichier appmanifest.xml.

Le fait que les composants SharePoint soient déployés sur des sites web de complément plutôt que sur le site web hôte tient à deux raisons principales. Les deux sont liées à la sécurité.

  • Application des autorisations de complément : dans le modèle de complément SharePoint, un complément possède sa propre identité et il est doté d'autorisations qui ne correspondent pas nécessairement aux autorisations de l'utilisateur qui l'exécute. Ces autorisations sont demandées lorsque le complément est installé et elles sont accordées par l'installateur du complément, tant que celui-ci dispose de toutes les autorisations demandées par le complément. (Un l'utilisateur qui tente d'installer le complément sans disposer de toutes les autorisations demandées par celui-ci ne pourra pas mener à bien cette installation.) En attribuant à chaque complément son propre domaine, SharePoint peut identifier de manière fiable les demandes effectuées par le complément et vérifier les autorisations de celui-ci. Pour plus d'informations sur les autorisations de complément, voir Autorisations de complément.

  • Sécurité des scripts à domaines multiples : les navigateurs actuels pratiquent la « stratégie d'origine identique » en ce qui concerne les appels de méthodes JavaScript. En déployant chaque Complément SharePoint sur son propre domaine, SharePoint tire parti de cette stratégie pour s'assurer que le code JavaScript du Complément SharePoint ne peut exécuter aucun code JavaScript d'un autre domaine, y compris du domaine dans lequel est installé le complément, du point de vue de l'utilisateur final.

    SharePoint propose également un moyen de s'affranchir en toute sécurité des limites de cette stratégie. Entre autres aspects, les composants distants d’un complément SharePoint peuvent interroger des données de tout site web qui dépend à la fois des sites web hôtes et des sites web de complément. Pour plus d’informations, voir Accéder à des données SharePoint à partir de compléments à l’aide de la bibliothèque inter-domaines.

Types de composants SharePoint pouvant figurer dans un complément SharePoint

Un complément SharePoint peut généralement contenir un ou plusieurs des composants de la liste ci-dessous. Sauf exception, ces composants doivent être déployés dans des fonctionnalités d’étendue Web, contenues dans un fichier de type .wsp (package de solution SharePoint).

Remarque

Les composants marqués d’un astérisque (*) sont présentés de manière plus détaillée dans la section Points à observer lors du déploiement des composants SharePoint plus loin dans cet article.

  • Fonctionnalités (étendue web uniquement)
  • Actions personnalisées (notamment les éléments des menus contextuels et les personnalisations du ruban)*
  • Récepteurs d'événements distants*
  • Balisage qui fait référence aux composants WebPart, y compris les composants de complément, inclus dans SharePoint (mais pas les composants WebPart personnalisés)*
  • Fichiers de feuilles de style en cascade personnalisées (CSS) utilisés par les pages SharePoint
  • Fichiers JavaScript personnalisés utilisés par les pages SharePoint
  • Modules (ensembles de fichiers)
  • Pages
  • Modèles de listes
  • Instances de liste et de bibliothèque (expérience classique uniquement)
  • Formulaires de liste personnalisés
  • Listes d'affichage personnalisées
  • Types de contenu personnalisés
  • Champs (de types de champs intégrés dans SharePoint)
  • Modèles Microsoft Business Connectivity Services (BCS) (étendue web uniquement), types de contenu externe basés sur le modèle et listes externes qui utilisent les types de contenu*
  • Flux de travail*
  • Conteneurs de propriétés
  • Modèles Web (mais pas les définitions de site)*

Aucun autre type de composant SharePoint ne peut être déployé dans un complément SharePoint. Pour plus d’informations sur les éléments qui peuvent être inclus dans un complément SharePoint, reportez-vous à Comparaison des compléments SharePoint et des solutions SharePoint.

Restrictions liées au déploiement de composants SharePoint

Voici quelques restrictions et informations concernant le déploiement de certains types de composants SharePoint dans un complément :

  • Actions personnalisées : En plus d’ajouter des actions personnalisées au site web de complément, vous pouvez également les ajouter au site web hôte. Pour ajouter une action personnalisée dans le site web hôte, vous pouvez inclure (même dans un complément externe) le balisage CustomAction dans une fonctionnalité contenue dans le package de complément mais en dehors de tout fichier .wsp. Pour ajouter une action personnalisée au site web hôte, vous pouvez inclure (même dans un complément basé en externe) le balisage CustomAction dans une fonctionnalité qui se trouve dans le package de complément, mais en dehors de tout fichier .wsp. Les composants d’une fonctionnalité « libre » s’appliquent au site web hôte, et non au site web de complément. Par conséquent, ce type de fonctionnalité est appelé fonctionnalité web hôte.

  • Composants WebPart : Un type de composant WebPart, un composant de complément, peut être déployé dans un complément, et un composant de complément peut accéder au site web de complément ou au site web hôte. Tous les autres types de composants WebPart peuvent être référencés dans les compléments, mais pas déployés par eux. Si un composant de complément est déployé sur le site web hôte, il doit être inclus dans une fonctionnalité de site web hôte.

  • Récepteurs d'événements distants : il s'agit d'une nouveauté de SharePoint. Les récepteurs d'événements distants sont semblables à des récepteurs d'événements SharePoint classiques, à ceci près que le code s'exécute dans le cloud. Ils ne sont pas disponibles dans les compléments hébergés sur SharePoint.

  • Flux de travail : Les flux de travail de SharePoint utilisent le moteur runtime de flux de travail hébergé dans Microsoft Azure, qui est une nouveauté de SharePoint. Les flux de travail codés qui utilisent le moteur runtime de flux de travail hébergé dans SharePoint ne peuvent pas être inclus dans un Complément SharePoint. Seuls les flux de travail déclaratifs ou les flux de travail qui utilisent ce nouveau moteur runtime sont autorisés.

  • Modèles Microsoft Business Connectivity Services (BCS), types de contenu externe et listes externes : les modèles Service Business Data Connectivity (BDC) ont habituellement une étendue plus large qu’une collection de sites. Toutefois, lorsqu’un modèle Service Business Data Connectivity (BDC) est déployé dans un complément, son étendue est limitée au site web de complément. Lorsqu’un modèle Service Business Data Connectivity (BDC) est inclus dans un complément, il n’est pas stocké dans le magasin de service partagé Service Business Data Connectivity (BDC). En revanche, il est stocké sous forme de fichier dans le site web de complément.

  • Modèles web : dans la plupart des cas, il est recommandé que le site web de complément instancie la nouvelle configuration de définition de site intégrée APP#0, optimisée pour les sites web de complément. Pour plus d’informations à ce sujet, consultez Accéder au complément à partir de l’interface utilisateur. SharePoint utilise automatiquement APP#0 lorsque le package de complément ne contient pas d’élément WebTemplate.

    Vous pouvez également définir un type de site personnalisé pour le site web de complément. Pour ce faire, il faut effectuer les deux étapes principales suivantes :

    • Intégrez un élément WebTemplate (modèle web) personnalisé, un fichier one.xml, et si possible d’autres fichiers associés dans la fonctionnalité de site web de complément pour votre complément. Déployez de la manière habituelle le modèle web de la fonctionnalité d’étendue web dans un fichier .wsp au sein du package de complément.

    • Ajoutez un élément WebTemplate (PropertiesDefinition, complexType) (manifeste de complément SharePoint) dans le manifeste de complément en tant qu’enfant de l’élément Properties. Définissez son attribut Id sur le GUID de la fonctionnalité de site web de complément et la valeur de l’attribut Name de l’élément WebTemplate (modèle web). Le GUID doit être séparé par des tirets et encadré par des accolades « {} », et le GUID et le nom de modèle doivent être séparés par le caractère « # », Voici un exemple :

      <WebTemplate Id="{81dd4ae5-873b-4759-9838-4ad9c3dd2952}#NewSiteType" />

    Remarque

    Le nouvel élément WebTemplate pour les manifestes de complément n’a pas le même balisage que l’élément WebTemplate qui peut être inclus dans les fonctionnalités. L’élément WebTemplate qui peut être inclus dans les fonctionnalités définit un type de site, mais l’élément WebTemplate pour les manifestes de complément détermine simplement le type de site à utiliser. Pour plus d’informations sur le manifeste de complément d’un complément Sharepoint, reportez-vous à la structure du package de complément.

    Attention

    N’utilisez pas l’élément WebTemplate dans le manifeste de complément pour désigner l’une des configurations de définition de site SharePoint intégrées en tant que type de site web de complément. Nous ne prenons pas en charge les configurations de définition de site intégrées autres que APP#0 pour les sites web de complément.

    Pour plus d’informations sur les configurations de définition de site et les modèles web, consultez Utilisation des modèles et définitions de site.

Voir aussi