Trois façons de réfléchir aux options de conception pour les compléments SharePoint
Vous devez d’abord vous familiariser avec l’article Compléments SharePoint.
Cet article étudie les choix d’architecture pour les compléments SharePoint de trois manières différentes. Dans la première, vous apprendrez les catégories les plus importantes pour faire vos choix de conception ; dans la deuxième, vous découvrirez l’architecture de complément en matière de niveau d’application ; enfin, dans la troisième, vous découvrirez un ensemble de facteurs à prendre en considération en faisant vos choix de conception.
La première décision à prendre réside dans le choix de votre extension SharePoint qui doit être un complément SharePoint ou une solution de batterie de serveurs SharePoint, ou encore une solution bac à sable. Certaines parties du modèle objet SharePoint, principalement connectées avec la personnalisation de l’administration et de la sécurité SharePoint, ne sont pas accessibles à partir des clients. Seul le code personnalisé exécuté sur le serveur SharePoint peut y accéder, et le code personnalisé côté serveur n’est pas autorisé dans un complément SharePoint. (Un riche ensemble de modèles objets clients et un service REST/OData permettent aux compléments SharePoint de créer n’importe quelle extension SharePoint orientée utilisateur final.)
Pour plus d’informations sur la décision entre les solutions classiques et les compléments, consultez la section Comparaison des compléments SharePoint et des solutions SharePoint. Pour vous aider également à prendre cette décision, consultez la section Choisir l’ensemble d’API approprié dans SharePoint.
Éléments clés dans la conception des compléments SharePoint
Il existe trois catégories majeures de choix à faire lors de la conception d’un complément SharePoint. Comme toujours, la conception d’un complément implique des compromis ; les choix que vous faites dans une catégorie peuvent limiter vos options dans une autre. Toutes les combinaisons de choix possibles ne sont pas nécessairement réalisables.
Hébergement : les compléments SharePoint peuvent être divisés en deux types principaux basés sur leur déploiement et leur hébergement.
Les compléments hébergés par un fournisseur nécessitent le déploiement et l’hébergement du stockage de données principal et de la logique de système par le développeur (vous), hors de SharePoint dans des serveurs ou sur un compte cloud que vous indiquez. Vous êtes responsable de l'application de l'isolation entre les comptes des divers clients qui achètent votre complément. De tels compléments peuvent avoir aussi des composants SharePoint. Ceux-ci sont hébergés dans la batterie de serveurs SharePoint du client. Ce type de complément vous offre un maximum de flexibilité dans les autres catégories de vos choix de conception. Il permet également d'utiliser des plateformes non Microsoft pour les données externes, la logique et l'interface utilisateur (IU) web. (Dans la catégorie des compléments hébergés par un fournisseur, vous devez également faire la distinction entre les compléments dont les composants distants se trouvent dans le même pare-feu d’entreprise que la batterie de serveurs SharePoint et ceux dont les composants distants se trouvent en dehors de ce pare-feu. Les systèmes d’autorisation pour ces deux scénarios sont différents, ce qui, à son tour, fait une différence dans le langage de programmation que vous utilisez pour accéder aux données SharePoint.)
Les compléments hébergés par SharePoint se composent entièrement de composants SharePoint, tels que des listes, des types de contenu, des flux de travail et des composants WebPart. Ils ne comprennent aucun composant externe. Pour plus d'informations sur les différents types de composant SharePoint pouvant être inclus dans les Compléments SharePoint, voir Héberger des sites web, des sites web de complément et des composants SharePoint dans SharePoint.
Pour plus d’informations sur les options d’hébergement des compléments SharePoint, consultez la section Choisir des motifs pour le développement et l’hébergement de votre complément SharePoint.
Connectivité : SharePoint prend en charge trois types d’accès sécurisé aux données pour la création/lecture/mise à jour/suppression (CRUD).
Les applications web externes dans un complément utilisent le protocole OAuth pour accéder aux données SharePoint. Pour plus d’informations, consultez la section Autorisation et authentification des compléments dans SharePoint.
JavaScript peut accéder aux données dans un site web de complément SharePoint, et aux données dans d’autres sites web dans la même location en utilisant une bibliothèque JavaScript spéciale qui permet les scripts sécurisés sur plusieurs domaines. Pour plus d’informations, voir Accéder à des données SharePoint à partir de compléments à l’aide de la bibliothèque inter-domaines.
Un complément SharePoint peut également accéder aux données externes via Business Connectivity Services (BCS) ou un proxy de service web. Pour plus d’informations, consultez la section Business Connectivity Services dans SharePoint et Interroger un service distant à l’aide du proxy web.
Pour plus d’informations sur le stockage et l’accès des données dans les compléments SharePoint, voir Stockage des données dans les compléments SharePoint, Accès aux données sécurisé et modèles objets clients pour les compléments SharePoint et Utiliser des données externes dans SharePoint.
UI: Il existe trois façons d’exposer un complément SharePoint dans SharePoint : au minimum, tous les compléments sont exposés dans une page web complète. Ensuite, ils peuvent être exposés de manière facultative via un composant du complément, et via un élément de menu ou un bouton du ruban. Pour plus d'informations, voir Conception de l'expérience utilisateur pour les compléments dans SharePoint.
Remarque
Les compléments SharePoint peuvent être installés par vos clients sur plusieurs collections de sites dans une location, ou en procédant site par site. Les premiers sont des compléments de location. Si vous souhaitez que vos clients puissent utiliser l’option pour les locations, vous ne devez pas inclure de bouton de ruban personnalisé ou de composant de complément. Pour plus d’informations, consultez la section Locations et étendues de déploiement des compléments SharePoint.
Niveaux architecturaux
Il existe une autre manière d'appréhender les options d'architecture de votre complément, en le percevant avec trois niveaux logiques : l'interface utilisateur, la logique du système et l'accès aux données. Chaque couche comprend plusieurs options d'implémentation ; de nouveau, les choix effectués pour une couche limitent les options pour d'autres. Les tableaux suivants décrivent certaines de ces options et leur utilisation pour les composants à distance d'un complément et les composants SharePoint.
Composants à distance dans les composants hébergés par un fournisseur : options pour chaque niveau
| Niveau | Options | S'applique à |
|---|---|---|
| Interface utilisateur | Pages ASP.NET dans un formulaire ASP.NET ou une application MVC hébergée dans un rôle Web Microsoft Azure | Optimisation des compétences du personnel de développement ASP.NET |
| Page HTML 5 avec JavaScript | Interface utilisateur enrichie | |
| PHP ou autre type de page web hébergée dans un service cloud non-Microsoft | Intégration d’applications non-Microsoft dans SharePoint | |
| Silverlight dans une application Windows Phone | Accès mobile aux données SharePoint et intégration aux données de géolocalisation et notifications Push | |
| Logique métier | JavaScript côté client | Logique de l’interface utilisateur et logique métier légère. Accès aux données SharePoint via le modèle objet client JavaScript |
| Un rôle de travail Microsoft Azure | Fonctionnalités d’utilisation intensive du processeur. Accès aux données SharePoint dans le modèle objet client .NET Framework | |
| Un service web distant | Fonctionnalités d’utilisation intensive du processeur. Accès aux données SharePoint dans le modèle objet client .NET Framework | |
| Données | SQL Azure | Données relationnelles complètes |
| Stockage de tableaux Microsoft Azure | Paramètres de l’application et autres métadonnées | |
| Stockage d’objets BLOB Microsoft Azure | Stockage de fichiers volumineux | |
| Service de nuage non-Microsoft | Exploitation des sources de données existantes basées sur les plateformes non-Microsoft | |
| Base de données sur le propre serveur du développeur | Contrôle du fournisseur d’hébergement et du développeur de l’isolation de la location |
Composants SharePoint : options pour chaque niveau
| Niveau | Options | S'applique à |
|---|---|---|
| Interface utilisateur | Vues personnalisées des listes et des bibliothèques SharePoint sur les pages web de complément | Optimisation de l’intégration avec l’apparence et le comportement de SharePoint |
| Application Silverlight hébergée dans un composant WebPart (ou dans <des balises d’objet> ) sur une page web de complément | Optimisation de l’expérience en développement du Silverlight existant. Interface utilisateur enrichie | |
| Logique métier | Flux de travail SharePoint | Implémentation du processus de l’entreprise |
| JavaScript côté client complété avec la bibliothèque inter-domaines de SharePoint | Accès aux données SharePoint dans le site web de complément. Accès aux données d’autres sites web au sein de la location | |
| Un gestionnaire d’événements distant | Gestion des événements CRUD dans des listes SharePoint et des bibliothèques à l’aide d’une logique hébergée à l’extérieur | |
| Données | Listes et bibliothèques SharePoint interrogées via le CAML (Collaborative Application Markup Language), ou requêtes LINQ avec un des modèles objets clients SharePoint | Exploitation de l’expérience de développement existante de SharePoint et .NET Framework |
| Listes et bibliothèques SharePoint interrogéess via le service Web REST/OData de SharePoint | Accès aux données SharePoint à partir de plateformes autres que Microsoft. Optimisation de l’expérience de requête existante OData | |
| Un modèle BCS | Exposition des données externes dans SharePoint comme liste SharePoint |
Facteurs à prendre en considération lors de l’élaboration de votre choix de conception
Le modèle de Complément SharePoint permet tellement de possibilités de conceptions qu'un simple arbre de décision n'est pas possible. Les facteurs suivants sont parmi les plus importants à considérer lors de la création d'une architecture pour un Complément SharePoint.
En particulier, bien sûr, vous devez tenir compte de la fonctionnalité que vous souhaitez mettre à la disposition des utilisateurs : ce sont les cas d’utilisation. Par exemple, si votre complément comprend des fonctions qui utilisent le processeur de manière intensive, telles que la conversion des fichiers vidéo dans un autre format, ce serait un argument pour la création d’un complément hébergé par un fournisseur dans lequel le traitement serait effectué sur l’un de vos serveurs ou sur un rôle de travail Microsoft Azure.
Comme un type de Complément SharePoint (les compléments hébergés par un fournisseur) nécessite que vous (ou votre client) hébergiez les composants non-SharePoint et que vous mettiez en application l'isolation du locataire, vous devez évaluer si vous avez le matériel et le personnel informatique suffisants pour le faire (ou si vos clients ciblés les ont).
Les clients que vous ciblez sont à prendre en considération de manière tout aussi importante. Si tous vos compléments doivent être utilisés en interne (c'est-à-dire, si vous n'avez pas de clients externes) ou utilisés par un seul client, il est bien plus aisé d'implémenter et de mettre à jour les compléments hébergés par un fournisseur que lorsque vous avez des clients externes ou que plusieurs clients sont susceptibles d'utiliser le complément. Si vous avez l'intention de vendre votre complément publiquement, vous devez également choisir si vous souhaitez le commercialiser à des entreprises qui ont des comptes SharePoint Online ou à celles qui ont leur propre batterie de serveurs SharePoint, ou les deux.
Vous devez également prendre en compte vos compétences ou les compétences de votre personnel de développement. Par exemple, si vous êtes un développeur ASP.NET expérimenté, c'est un argument supplémentaire pour la création d'une application web à distance et l'exposition des données de liste SharePoint sur une page ASP.NET. Par contre, si vous êtes un développeur SharePoint expérimenté, c'est un argument en faveur de l'utilisation d'une liste SharePoint personnalisée et d'une page de site, avec JavaScript pour effectuer le traitement.