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

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 se produit lorsque le complément est installé avec une étendue de location. Dans ce cas, le site web de complément se trouve dans la collection de sites du catalogue de compléments d’entreprise.)

La figure 1 montre un site web hôte avec deux compléments SharePoint installés. Le complément 1 a des composants distants, mais aucun composant SharePoint. Il n’a donc pas de site web de complément. Le complément 2 n’a aucun composant distant, mais il a deux listes SharePoint et un flux de travail. Ceux-ci ont été déployés sur un sous-site isolé (un complément SharePoint peut avoir à la fois des composants distants et hébergés par SharePoint, bien qu’aucun complément de ce diagramme n’ait les deux).

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. Sa valeur par défaut est « default ». Dans cet exemple, l'administrateur l'a remplacée par « add-in ».
  • ID_du_complément est un nombre hexadécimal généré en interne lorsque le complément est installé.
  • Complément in_Base_Domain est une chaîne définie par l’administrateur de batterie de serveurs dans l’Administration centrale ou avec SharePoint Management Shell. Cela ne doit pas être défini sur un sous-domaine de l’application web SharePoint ou l’objectif de l’isolation du complément est largement rejeté. Dans cet exemple, l’administrateur a supprimé le « www » et ajouté des « compléments » au nom de la société. Par conséquent, fabrikamadd-ins.com est 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.

Il existe deux raisons principales expliquant le déploiement des composants SharePoint sur des sites web de compléments, plutôt que sur des sites web hôte. 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 offre également un moyen de contourner en toute sécurité les limites de la stratégie. Entre autres choses, cela permet aux composants distants d’un complément SharePoint d’interroger des données à partir de n’importe quel site web dans la location parente commune de l’hôte et des sites web de complément. Pour plus d’informations, consultez Accéder aux 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

En général, un complément SharePoint peut contenir un ou plusieurs des composants de la liste suivante. À certaines exceptions près, ces composants doivent être déployés dans fonctionnalités étendues au web qui se trouvent dans un fichier de package de solution SharePoint (.wsp).

Notes

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 (y compris les éléments de menu contextuel et les personnalisations du ruban)*
  • Récepteurs d’événements distants*
  • Balisage référençant les composants WebPart (notamment les composants de complément) qui sont 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 restrictions relatives à ce qui peut être inclus dans un complément SharePoint, consultez Compléments SharePoint par rapport aux 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 : vous pouvez ajouter des actions personnalisées dans le site web de complément, mais également dans le site web hôte. Pour ajouter une action personnalisée dans le site web de complément, vous devez l'inclure dans une fonctionnalité d'étendue Web contenue dans un fichier .wsp, de la même manière que pour tout composant à insérer dans le site web de complément. 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. Les composants d'une telle fonctionnalité isolée s'appliquent au site web hôte et non au site web de complément. Ce type de fonctionnalité s'appelle donc unefonctionnalité de site web hôte .

  • Composants WebPart : un seul type de composant WebPart (le composant de complément) peut être déployé dans un complément. Les composants de complément peuvent être déployés sur le site web de complément comme sur le site web hôte. Tous les autres types de composant WebPart peuvent être référencés dans les compléments, mais ils ne peuvent pas être déployés par ceux-ci. 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éments. Il existe deux étapes principales à ce sujet :

    • Incluez un élément WebTemplate personnalisé (modèle web), un fichier onet.xml et éventuellement d’autres fichiers associés, dans la fonctionnalité web du complément pour votre complément. Déployez le modèle web dans la fonctionnalité web dans un fichier .wsp à l’intérieur du package de complément comme d’habitude.

    • 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" />
      

    Notes

    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 de site et des définitions.

Voir aussi