Les différentes typologies de développements SharePoint

La plateforme SharePoint, outre ses capacités bien connues à créer des solutions collaboratives par paramétrage, se révèle aussi être une plateforme de développement d’applications extrèmement performante.

SharePoint est désormais parfaitement integré à Visual Studio, et bien qu’imparfaits sur certains points, ses API et services offrent une large palette de possibilités permettant de concevoir des applications extrêmement variées :

  • Réseaux sociaux d’entreprise (RSE)
  • Extranets Clients et Fournisseurs
  • Sites Web
  • Applications collaboratives
  • Recherche d’entreprise fédérée
  • Solutions d’intégration avec des applications métier, ERP, CRM…

Sans trop entrer dans les détails de l’architecture applicative de SharePoint et de ses nombreux services, voici une représentation synthétique des interactions possibles avec le système :

On remarquera que ces intéractions sont autorisées à de nombreux niveaux, à l’exception notable des appels directs sur la base de données, ce qui est formellement proscrit par Microsoft sous peine de perte de support. En effet, le schéma de la base peut être mis à jour par n’importe quel update, même mineur, les développements spécifiques faisant appel directement à la base sont donc par nature très risqués.

Pour revenir au schéma, on observe deux grandes typologies de solutions, les solutions server-side, exécutées sur les serveurs de la ferme SharePoint, par exemple :

  • Des pages d’application aspx
  • Des contrôles ou web parts
  • Des actions planifiées  (SPTimers)…
Dans ce mode, le code (quasi exclusivement .NET) est executé côté serveur par ASP.NET, les écrans générés depuis le serveur, puis transmis en HTML au navigateur :
C’est un mode assez traditionnel de développement de solutions Web avec ASP.NET finalement, reposant sur des appels au modèle objet serveur de SharePoint.

D’autre part, nous trouvons les solutions dites « client-side », avec notamment :

  • Des extensions JavaScript dans le navigateur
  • Des applications ou web parts Silverlight (ou Flash !) « In » ou « Out »-of-browser
  • Des applications intégrées à la suite Office (Document Information Panel par exemple)
  • Des scripts de gestion ou d’administration écrits en PowerShell (vous trouverez à cette adresse un article particulièrement réussi sur ce sujet précis)
  • Des applications spécifiques comme des passerelles de numérisation, ou d’autres applications tierces…
En somme, il s’agit de l’ensemble des applications clientes qui utilisent SharePoint sans passer par le modèle objet serveur.
Dans ce mode, de multiples types de clients (RIA, Office…) vont intéragir avec SharePoint :

Comme le montre le précédent schéma, afin de répondre aux différentes demandes et types d’applications clientes (Branche de gauche: UX), Microsoft a integré différentes solutions pour réaliser des applications client-side.

En fait, on peut catégoriser les applications client-side en trois groupes, selon la « profondeur » d’intégration avec SharePoint :

  • Les clients BCS : Applications serveur distantes (CRM, ERP…), SharePoint Workspace dans une certaine mesure
  • Les clients des services Web : Applications riches desktop et mobiles, Apps mobiles développées avec des frameworks web comme PhoneGap ou CellSDK
  • Les clients OM (Object Model) : Applications HTML/JS, RIA avec Silverlight, Applications desktop

Les clients BCS

BCS (pour Business Connectivity Services) est une solution permettant d’intégrer simplement des applications tierces à SharePoint.
BCS fournit ainsi aux applications externes plusieurs points d’intégration avec SharePoint :
  • Affichage et édition de données du système externe directement depuis SharePoint en utilisant des Web Parts (Par exemple les fiches Clients de votre CRM)
  • Intégration avec des Workflows de systèmes tiers (Par exemple lancement de processus SAP)
  • Indexation des données externes et affichage par le moteur de recherche SharePoint (Par exemple recherche depuis SharePoint de vos documents comptables SAP)
  • Gestion de données exposées par BCS dans des applications en mode déconnecté (Par exemple un accès en mode déconnecté au catalogue produit de votre CRM)
Un très bon exemple d’utilisation de BCS est la solution SAP Duet, qui permet d’intégrer SAP et SharePoint. Je vous conseille vivement cet article sur le sujet.
Du point de vue architectural, le point fort de BCS est d’exposer les données des applications ainsi integrées au travers de web services, qui pourront être consommés par n’importe quelle application distante.
Un bon exemple d’application client-side utilisant les services BCS pour rendre accessible des données d’applications métiers en mode déconnecté est SharePoint WorkSpace. Vous pouvez consulter mon précédent article sur SharePoint Workspace qui, j’espère, vous en démontrera la puissance.

Les clients des services Web

SharePoint expose ses données et fonctions au travers de services web. Ces services sont exposés selon REST pour les accès standardisés aux données, et SOAP pour les appels de fonctions et requêtes.
Cette solution d’intéraction avec SharePoint offre l’avantage d’être relativement souple et surtout générique, dans le sens où globalement toute application pourra l’utiliser (Application desktop, mobile, web…).
L’inconvénient majeur provient justement de la qualité « générique » de ces services, à savoir que les développeurs devront travailler à un relativement bas niveau d’abstraction, en tenant compte du protocole utilisé (enveloppes SOAP, sérialisations XML…). De plus, on ne manipulera ici que des flux XML et pas des objets SharePoint fortement typés, contrairement à ce qui se passe avec les développement sur le modèle objet serveur de SharePoint.

Les clients OM

Afin de palier à ces difficultés d’implémentation des clients de services Web, Microsoft a conçu différentes couches d’abstraction, les CSOM (Client Side Object Model).

SharePoint 2010 propose trois CSOM similaires pour trois implémentation distinctes :

  • .NET pour les Clients .NET (Windows, WPF…)
  • Silverlight
  • JavaScript (ECMAScript dans la terminologie Microsoft)

En fournissant ainsi plusieurs CSOM similaires, SharePoint propose une expérience de développement cohérente, reposant sur des objets fortement typés, et consistante entre les différentes plateformes (.NET, ECMAScript, Silverlight)

Attention cependant, ces abstractions ont un prix, notamment celui de ne pas avoir une couverture fonctionnelle aussi complete qu’en passant directement pas les services Web.

Voici un comparatif des fonctionnalités et capacités d’accès aux données des CSOM vis à vis des services Web  :

CSOM

REST interface

Web services

List queries YES YES YES
List join queries YES YES*
External list queries YES
View projections YES YES YES
Request batching YES YES
Synchronous operations YES (except ECMA) YES
Asynchronous operations YES YES YES
SharePoint Foundation object model access YES
Access to SharePoint Server functionality (beyond SharePoint Foundation) YES
Support non-Windows clients YES (ECMA only) YES YES
Support strongly-typed LINQ queries YES (objects only, no list queries) YES (with proxy, lists only)

Comme le montre ce tableau, et mis à part certaines fonctionnalités particulières, les trois CSOM offrent globalement les mêmes possibilités.

Cette similarité va plus loin puisque les modèles objets sont équivalents et globalement proches, tant sur le serveur que sur les clients. Le tableau suivant montre l’équivalence des objets entre le modèle serveur et les CSOM :

Server .NET Managed and Silverlight JavaScript
Microsoft.SharePoint.SPContext Microsoft.SharePoint.Client.ClientContext SP.ClientContext
Microsoft.SharePoint.SPSite Microsoft.SharePoint.Client.Site SP.Site
Microsoft.SharePoint.SPWeb Microsoft.SharePoint.Client.Web SP.Web
Microsoft.SharePoint.SPList Microsoft.SharePoint.Client.List SP.List
Microsoft.SharePoint.SPListItem Microsoft.SharePoint.Client.ListItem SP.ListItem
Microsoft.SharePoint.SPField (including major derived classes) Microsoft.SharePoint.Client.Field SP.Field
Microsoft.SharePoint.WebPartPages.SPLimitedWebPartManager Microsoft.SharePoint.Client.WebParts.LimitedWebPartManager SP.WebParts.LimitedWebPartManager

Comme vous pouvez le constater, les objets sont donc similaires mais sont exposés dans des namespaces différents :

  • Microsoft.SharePoint sur le serveur
  • Microsoft.SharePoint.Client sur les desktop et Silverlight
  • SP dans le navigateur

En fait, du point de vue strictement fonctionnel, la réelle différence entre les API serveur et client réside dans le scope exposé puisque, contrairement aux API serveur, les API client ne peuvent pas accéder aux objets d’un scope plus « haut » que la collection de sites (SPSite). Ce scope est d’ailleurs équivalent à celui appliqué pour les solutions sandbox, et exclut de fait les opérations d’administration à distance sur les application web et sur la ferme de serveurs.

Présentation des trois CSOM, .NET, Silverlight et Javascript

Principes communs

Les CSOM réalisent deux grands types d’opérations :

  • Ils masquent ou simplifient les communications et appels vers les services Web
  • Ils gèrent les sérialisations / désérialisations XML et JSON vers des objets typés

Principes de communication

Autre particularité, pour communiquer, les CSOM fonctionnent de manière totalement asynchrone :

  1. Le client créer et paramètre une suite de commandes (Créer une liste, ajouter un item, etc…)
  2. Le client demande l’exécution de son lot de commandes
  3. Le CSOM transmets aux services web les commandes au format XML
  4. Le serveur exécute séquentiellement les commandes
  5. Une fonction de callback (une en cas de succès de l’opération, une autre en cas d’échec) est appelée côté client lorsque les opérations ont été traitées côté serveur
  6. Cet appel à la fonction de callback est porteur des informations retournées par le serveur au format JSON
  7. Le client peut alors traiter ces données et poursuivre l’exécution du programme

En voici une représentation schématique :

Pour être tout à fait complet et précis, les CSOM .NET et Silverlight utilisent un OM “managé”, c’est à dire exécuté par un moteur .NET, alors que l’OM Javascript est lui naturellement non managé (en tout cas au sens .NET, car selon le navigateur, on pourra éventuellement parler de moteur JavaScript managé…) :

Gestion des objets fortement typés

Les CSOM exposent un grand nombre d’objets SharePoint avec leurs propriétés associées :

  • Collections de sites et sites
  • Listes, items, vues, et schémas
  • Fichiers et dossiers
  • Property Bags des sites, listes, et items
  • Web Parts
  • Sécurité
  • Content Types
  • Templates de sites

Comme vous pouvez le constater, un grand nombre des objets utilisables dans les solutions côté serveur sont aussi accessibles depuis les OM clients.

Regardons maintenant plus en détail chacun des OM.

.NET Client Object Model

Le CSOM .NET est destiné à l’ensemble des applications développées sur la plateforme .NET :

  • Winforms
  • WPF
  • Lignes de commande
  • CommandLets PowerShell
  • Applications Web ASP.NET

La communication avec le serveur repose sur les mêmes paradygmes que les autres CSOM, à l’exception notable de la prise en compte d’un mode de communication synchrone (Pour les puristes, L’OM .NET « simule » un appel synchrone aux services, l’appel réel se faisant toujours de manière asynchrone) :

Pour l’utiliser depuis vos clients .NET, vous devrez référencer ces assemblies :

  • Microsoft.SharePoint.Client.dll (282KB)
  • Microsoft.SharePoint.Client.Runtime.dll (146 KB)

Présentes dans le dossier :

  • C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI

Notez que ces assemblies sont d’une taille bien plus réduite que leur équivalent serveur (Microsoft.SharePoint.dll de 16.2 MB), ce qui est naturel.

Attention : Lorsque vous utiliserez cette API, pensez aux performances !

En effet, par défaut, toutes les propriétés des objets sont chargées, donc pensez à spécifier celles dont vous avez réellement besoin, par exemple si vous n’avez besoin que de la propriété « Title » d’un objet « Web » :

ctx.Load(web, w=>w.Title);
ctx.Load(list,l=>l.Title, l=>l.ItemCount);
ctx.ExecuteQuery();

Silverlight Client Object Model

Le CSOM Silverlight est destiné aux applications RIA:

  • In browser
  • Out of browser

La communication avec le serveur repose sur les mêmes paradygmes que les autres CSOM, et est exclusivement aynchrone :

Pour l’utiliser depuis vos clients Silverlight, vous devrez référencer ces assemblies :

  • Microsoft.SharePoint.Client.Silverlight.dll (266K)
  • Microsoft.SharePoint.Client.Silverlight.Runtime.dll (142K)

Présentes dans le dossier :

  • C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\ClientBin

Javascript (ECMAScript) Client Object Model

Le CSOM JavaScript est destiné aux applications Web.

La communication avec le serveur repose sur les mêmes paradygmes que les autres CSOM (surtout Silverlight), et est exclusivement aynchrone :

Le CSOM JavaScript peut être ajouté simplement à une page SharePoint, par une simple référence à la bibliothèque : sp.js

A noter pour les curieux (regardez la source du script sp.js depuis votre browser) que cette API est en partie générée par les développeurs de Microsoft par une conversion automatisée de code C# vers JavaScript à l’aide d’un excellent outil appelé Script# :

Pour l’utiliser depuis vos clients Web, vous devrez référencer une de ces deux bibliothèques :

  • SP.js (381 KB)
  • Debug version : SP.debug (561 KB)

Présentes dans le dossier :

  • C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS

Différentes solutions existent pour référencer cette bibliothèque et autres dépendances (par exemple par l’utilisation de contrôles ScriptLink), mais c’est un tout autre sujet et j’y reviendrai dans un prochain article.

Pour aller plus loin

Les CSOM de SharePoint offrent de nombreuses possibilités, et malgré un certain nombre de limitations, offrent un cadre de développement performant.

J’ai pour ma part mis en oeuvre les CSOM .NET, Silverlight et JavaScript dans le cadre de plusieurs projets, mais celles et ceux qui me connaissent savent que je suis particulièrement intéressé par le CSOM EcmaScript. J’y reviendrai donc plus en détail dans un prochain article, avec notamment :

  • Solutions d’accès aux données avec REST
  • Utilisation de frameworks JS complémentaires : JQuery, LabJS, SPServices
  • Exploiter les nouvelles API HTML5 depuis SharePoint
  • Les contraintes liées à la sécurité
  • La gestion des traces et logs côté client
Publicités