Choisir les motifs pour le développement et l’hébergement de votre complément SharePoint

Article
04/08/2023

Le modèle de complément SharePoint présente un large éventail de modèles d’hébergement et de développement. Certains de ces modèles peuvent être utilisés en combinaison les uns avec les autres. Par exemple, vos compléments peuvent associer des composants hébergés par SharePoint et des composants hébergés à distance. La façon la plus utile de déterminer les modèles que vous souhaitez utiliser consiste à commencer par vos propres exigences, technologies et objectifs et à les faire correspondre aux options et possibilités activées par les compléments SharePoint.

Éléments à considérer lors du choix de votre modèle de développement

Les Compléments SharePoint permettent d'élargir la gamme des langages de programmation et des piles technologiques que vous pouvez utiliser lorsque vous travaillez avec des ressources et des services SharePoint. Le nombre précis d'options à votre disposition dépend à la fois du type de complément et du modèle d'hébergement que vous choisissez. Il est également possible de combiner les modèles.

Compléments hébergés par SharePoint

Commencez par l’option la plus simple : les compléments hébergés par SharePoint ou les compléments dont tous les composants sont hébergés soit localement, soit sur une batterie de serveurs SharePoint Office 365. Les compléments hébergés par SharePoint sont installés sur un site web SharePoint, qu’on appelle le site web hôte. Leurs ressources sont hébergées sur un sous-site isolé d’un site web hôte, appelé le site web de complément. Il est important de connaître la différence entre sites web hôtes et sites web de complément.

La Figure 1 illustre l’architecture de base d’un complément SharePoint hébergé.

Figure 1. Architecture d’un complément hébergé par SharePoint

Les composants d’une application hébergée par SharePoint sont hébergés sur le serveur web d’applications d’une batterie SharePoint.

Vous pouvez combiner un complément hébergé par SharePoint avec des compléments dont les composants sont hébergés à distance. Ceci dit, tous les compléments ou portions de complément exécutés sur un site web de complément doivent répondre aux exigences suivantes concernant trois éléments clés : l'emplacement d'hébergement du complément, la méthode d'obtention d'autorisation pour le complément et le langage qu'il peut utiliser.

Composant	Exigences pour les compléments hébergés par SharePoint
Emplacement où sont hébergés les composants de compléments	Domaine de complément isolé de votre batterie de serveurs SharePoint
Méthode d'obtention d'autorisation du complément	Privilèges de l'utilisateur connecté
Langage pouvant être utilisé par le complément	JavaScript (avec la bibliothèque JSOM SharePoint) + HTML

Avantages offerts	Points à prendre en considération
Réutilisez les éléments SharePoint courants, tels que des listes et des composants WebPart.	Vous pouvez utiliser uniquement JavaScript dans le complément et aucun code côté serveur.
Ces compléments sont relativement faciles à créer et à déployer ; ils sont donc parfaits comme compléments de productivité pour les petites équipes et pour l'automatisation des processus d'entreprise impliquant des règles métiers peu complexes.	Votre complément dispose uniquement des privilèges d’autorisation de l’utilisateur connecté.

Commencer à créer des compléments SharePoint hébergés par SharePoint

Compléments hébergés par un fournisseur

Les compléments SharePoint hébergés par un fournisseur comprennent des composants qui sont déployés et hébergés en dehors de la batterie de serveurs SharePoint. Ils sont installés sur le site web hôte, mais leurs composants à distance sont hébergés sur un autre serveur qui ne doit pas faire partie de la batterie de serveurs SharePoint.

La Figure 2 illustre l’architecture de base d’un complément hébergé par un fournisseur.

Figure 2. Architecture d’un complément hébergé par un fournisseur

Les composants d’une application hébergée par un fournisseur sont hébergés sur n’importe quel serveur web ou service d’hébergement.

Le tableau suivant montre que les exigences concernant l'hébergement, les autorisations et les langages sont beaucoup plus souples pour les compléments hébergés par un fournisseur qu'elles ne le sont pour les compléments hébergés par SharePoint.

Composant	Exigences pour les compléments hébergés par un fournisseur
Emplacement où sont hébergés les composants de compléments	N'importe quel serveur web ou service d'hébergement
Méthode d'obtention d'autorisation du complément	OAuth ou la bibliothèque inter-domaines JavaScript
Langage pouvant être utilisé par le complément	N'importe quel langage pris en charge par votre serveur web ou votre service d'hébergement

Un complément hébergé par un fournisseur interagit avec un site SharePoint, mais utilise également les ressources et les services qui résident sur le site distant. Prenez en considération les éléments suivants avant de décider de créer un complément hébergé par un fournisseur.

Avantages offerts	Points à prendre en considération
Hébergez le complément sur Microsoft Azure ou sur une plateforme web distante, y compris des plateformes autres que celles de Microsoft.	Vous êtes responsable de la création de la logique d’installation, de mise à niveau et de désinstallation des composants distants.
Utilisez l’un des modèles objet client SharePoint, la bibliothèque inter-domaines JavaScript ou le service web SHAREPoint REST/OData pour interagir avec SharePoint.	Pour chaque façon d’interagir avec SharePoint, il existe des options correspondant aux différentes approches d’accès aux données.
Obtenir une autorisation d’accès à des données SharePoint à l’aide de l’un des trois systèmes d’autorisation.	Vous devez choisir entre OAuth et la bibliothèque inter-domaines pour autoriser l’accès de votre complément dans SharePoint.

Adapter votre modèle d’hébergement à vos objectifs de développement

En plus d'examiner les avantages et les contraintes techniques de chaque option, vous devez également réfléchir à vos objectifs de développement au moment de choisir un modèle d'hébergement. Le tableau suivant peut vous aider à déterminer le modèle d'hébergement qui correspond le mieux à vos besoins.

Vos besoins	Modèle d’hébergement recommandé	Exemple
Exclusivement utiliser et mettre en service de nouvelles entités SharePoint	Hébergé par SharePoint	Un complément qui comprend un contrôle de type sélecteur de personnes et stocke des informations sur les utilisateurs SharePoint dans une liste SharePoint
Utiliser les entités SharePoint existantes et interagir avec des services web externes (autres que SharePoint)	Hébergement par le fournisseur	Un complément qui récupère les adresses des clients dans une liste SharePoint figurant sur le site web hôte et utilise un service de géolocalisation dans une application web pour afficher l'endroit où ils se trouvent
Mettre en service de nouvelles entités SharePoint et interagir avec des services web externes	Combinaison d'une application hébergée sur SharePoint et d'une application hébergée par un fournisseur	Un complément de géolocalisation qui met en service une liste SharePoint sur le site web d'application afin de stocker les coordonnées de latitude et de longitude des adresses fournies par l'utilisateur ou tirées d'une liste SharePoint existante

Éléments à considérer lors du choix de votre modèle d’hébergement pour les compléments hébergés par un fournisseur

Les compléments hébergés par SharePoint présentent un modèle d’hébergement fixe, car ils sont hébergés sur le site web de complément. Les compléments hébergés par un fournisseur offrent plus de souplesse dans l’hébergement des différents composants de votre complément. Aussi, si vous choisissez d’en créer un, vous devrez sélectionner un modèle d’hébergement correspondant à vos objectifs et à vos exigences.

OAuth ou la bibliothèque inter-domaines

L'une des questions les plus importantes à vous poser si vous envisagez de créer un complément hébergé par un fournisseur est de savoir comment le complément obtient l'autorisation d'interagir avec SharePoint. Les compléments hébergés par un fournisseur vous donnent le choix entre deux possibilités : la bibliothèque inter-domaines JavaScript et OAuth.

La bibliothèque inter-domaines vous permet d’interagir avec plusieurs domaines à partir des composants à distance de votre complément via un proxy. Si le code côté client et les autorisations d’un utilisateur connecté à SharePoint sont suffisants, la bibliothèque inter-domaines constitue une bonne option. La bibliothèque inter-domaines peut également vous être utile chaque fois que vous effectuez des appels distants à travers un pare-feu.

OAuth est un protocole ouvert d’autorisation qui permet d’accorder des autorisations sécurisées à partir d’applications clientes (ordinateur de bureau, web et applications mobiles) d’une manière facile à gérer. Si vous envisagez de créer un complément SharePoint capable de s’exécuter dans une application web à distance et de communiquer des informations à SharePoint, vous devrez souvent vous servir d’OAuth. OAuth est requis chaque fois que vous effectuez un appel à SharePoint à partir d’une application web hébergée à distance qui ne peut pas utiliser exclusivement de code côté client (HTML + JavaScript). En savoir plus sur le fonctionnement d’OAuth dans les compléments SharePoint.

Les rubriques Accès aux données sécurisé et modèles d'objet client pour les compléments SharePoint et Trois systèmes d'autorisation pour les compléments SharePoint expliquent comment choisir entre OAuth et la bibliothèque inter-domaines de manière plus approfondie.

OAuth avec des batteries de serveurs SharePoint locales

Si vous utilisez un déploiement local de SharePoint, vous pouvez utiliser OAuth, mais vous devrez choisir entre la création de compléments à haut niveau de fiabilité et l’utilisation d’un client Office 365. Office 365 utilise Microsoft Azure Access Control Service (ACS) en tant que courtier de gestion de la confidentialité. Si vous n’avez pas accès à un client Office 365, utilisez Créer des compléments SharePoint à haut niveau de fiabilité, qui se sert de certificats pour établir la gestion de la confidentialité entre votre complément et SharePoint. Vous pouvez ajouter des compléments à haut niveau de fiabilité dans le catalogue de complément de votre batterie de serveurs SharePoint, mais vous ne pouvez pas les vendre dans Office Store. Si vous avez accès à un client Office 365, vous pouvez le lier à votre installation locale de SharePoint et utiliser ACS comme courtier de gestion de la confidentialité pour les compléments installés sur votre SharePoint local.

Le tableau suivant énumère tous les modèles possibles pour l'hébergement des composants SharePoint et des composants distants de votre complément, ainsi que les services Broker d'approbation disponibles si vous utilisez OAuth. Notez que vous aurez besoin d'un accès à un client Office 365 afin de pouvoir utiliser ACS pour établir la relation d'approbation entre SharePoint et un Complément SharePoint installé sur une installation sur site de SharePoint.

Emplacement du composant SharePoint	Emplacement du composant distant	Service Broker d’approbation
Sur site	Dans le nuage	ACS, certificat
Sur site	Sur site	ACS, certificat
Site SharePoint Office 365	Dans le nuage	ACS
Site SharePoint Office 365	Sur site	ACS

Combiner l’hébergement par un fournisseur et l’hébergement par SharePoint

Vous pouvez également créer des compléments qui incluent à la fois des composants hébergés par SharePoint et des composants hébergés sur le cloud. Par exemple, vous pouvez créer un complément hébergé sur le cloud qui contient un type de liste et de contenu SharePoint personnalisé. Si vous choisissez d’utiliser cette architecture, votre conception et votre approche doivent tenir compte des limitations de sécurité intégrées dans le modèle. Vous pouvez utiliser uniquement JavaScript dans les composants de code hébergés par SharePoint. Les composants hébergés à distance, quant à eux, doivent utiliser OAuth ou la bibliothèque inter-domaines pour interagir avec le site web SharePoint. Lorsque vous envisagez cette approche, veillez à comprendre le fonctionnement de l’autorisation de complément dans SharePoint.

La Figure 3 vous montre comment fonctionne cette architecture si vous utilisez Azure pour héberger les composants à distance de votre complément, et si vous utilisez OAuth.

Figure 3. Communication de serveur à serveur pour un complément SharePoint avec OAuth et Windows Azure

Restrictions des communications entre serveurs

Découvrez comment créer un complément qui combine l’hébergement cloud et l’hébergement par SharePoint.

Voici quelques éléments à considérer lorsque vous envisagez une combinaison de l’hébergement par un fournisseur et de l’hébergement par SharePoint.

Avantages offerts	Points à prendre en considération
Tous les avantages des deux approches.	L’architecture est plus complexe et nécessite une planification soignée de la communication de serveur à serveur et des restrictions de scripts intersites.

Compléments hébergés par un fournisseur dans des rôles web Azure

Si l’application web est un environnement local ou un site web Azure, vous pouvez héberger un complément SharePoint hébergé par un fournisseur sur un rôle web Azure au lieu d’une application web. Grosso modo, un rôle web Azure est un site web hébergé sur Azure et qui s’appuie sur Internet Information Services (IIS). Vous pouvez tirer parti des services d’hébergement et de l’extensibilité des rôles web Azure. Vous pouvez également améliorer les performances et la facilité d’utilisation de votre complément SharePoint, en particulier si le complément est soumis à une utilisation intensive ou exige d’être modifié au fil du temps. Si le complément SharePoint requiert davantage de ressources serveur, Azure peut lui en allouer dynamiquement.

Consultez les liens suivants pour plus d’informations sur les rôles web Azure.

Dans le cadre des conditions préalables, vous avez besoin du kit de développement logiciel (SDK) Microsoft Azure pour .NET (Visual Studio 2012) 1.8.1, que vous pouvez installer à l’aide de Web Platform Installer.

La façon dont vous créez le projet dans vsnv varie selon que vous démarrez avec un projet de complément SharePoint puis ajoutez le projet de rôle web Azure, ou que vous démarrez avec le projet Azure et ajoutez ensuite le projet SharePoint.

Ajouter un service cloud à un complément existant

Si vous avez déjà un complément SharePoint hébergé par un fournisseur et que vous souhaitez l’héberger sur Azure, choisissez le projet d’application web dans la solution pour le complément SharePoint. Dans la barre de menus, sélectionnez Projet>Ajouter Projet Microsoft Azure Cloud Service. Un projet Azure appelé NomDuProjetDeComplément.Azure est ajouté à la solution pour votre complément SharePoint. Un rôle web pour le projet web est également ajouté au projet pour Azure Cloud Service. Les outils de développement Office pour Visual Studio 2012 définissent les propriétés de projet requises pour que le rôle web puisse fonctionner avec le complément SharePoint.

Ajouter un complément à un rôle web existant

Si vous avez déjà un rôle web dans un Azure Cloud Service et que vous souhaitez l’utiliser en tant qu’hôte pour un complément SharePoint hébergé par un fournisseur, ouvrez le projet Azure Cloud dans Visual Studio. Puis, dans l’Explorateur de solutions, choisissez le projet du rôle web. Dans la barre de menus, sélectionnez Projet>Ajouter complément pour projet SharePoint. Un projet pour un complément SharePoint hébergé par un fournisseur est créé, appelé NomDuProjetDeComplémentWeb.Azure, et ajouté à la solution. Visual Studio référence le rôle web Azure en tant qu’hôte du projet web pour le complément SharePoint.