Archives des articles tagués javascript

Lors de ma dernière session de présentation à l’UGSF, et dans cet article sur la recherche SharePoint pour le marketing et la CRM, nous avions présenté plusieurs modes d’intégration possibles de la recherche SharePoint 2010 avec Twitter.
Je vais ici vous présenter de manière détaillée deux modes d’intégration et leurs implémentations respectives, mais avant, un petit rappel simple sur le fonctionnement de base du moteur de recherche de SharePoint.

L’indexation des sources de contenus

Il s’agit ici du mode de fonctionnement classique de SharePoint. Il est configurable depuis l’administration centrale :

Dans cet exemple, plusieurs sources de contenus sont définies :

  • Les sites SharePoint (C’est la moindre des choses !)
  • Un site Web
  • Une base de données métier (Ici une CRM)

En somme, à une fréquence définie (et configurable), le moteur de recherche SharePoint va lire l’ensemble de ces contenus (les crawler), les indexer (en extraire les informations, les formater…), puis les rendre accessibles au travers de ses écrans de recherche, par exemple ici une recherche sur un site Web :


Pour ce faire, SharePoint utilise des connecteurs paramétrables qui lui permettent d’accéder à différentes sources de données, notamment :

  • Sites SharePoint
  • Sites Web
  • Partages réseau
  • Dossiers publics Exchange
  • Applications métiers
  • Source personnalisée

Vous retrouvez ces options depuis le formulaire de création d’une nouvelle source de contenus :


On peut même développer ses propres connecteurs, qui seront alors accessibles depuis l’option « Custom Repository »… Mais alors pourquoi ne pas indexer directement Twitter avec un connecteur spécifique ?

  • D’abord parce que Twitter n’est pas en soit une source de données accessible pour l’indexation du fait de limitations techniques (nombre de requêtes…)
  • Surtout parceque votre index serait démesurément grand ! En général un index représente 30% de la taille du contenu original…

Il y a en réalité deux options viables pour intégrer ce type de média :

  • Par fédération
  • Par API

La fédération de moteurs de recherche

Cette première option consiste à utiliser le mécanisme de fédération présent dans le moteur de recherche SharePoint.

Pour être tout à fait complet, cette option est disponible nativement pour SharePoint Server (Standard et Enterprise) et par intégration de Search Server pour SharePoint Foundation.
En quelques mots, la fédération consiste à déléguer le travail de crawling et d’indexation à un moteur de recherche distant, puis à l’appeler pour récupérer les résultats lorsqu’une recherche est déclenchée par un utilisateur.

Voici un exemple de fédération du moteur de recherche Bing dans SharePoint :


Donc dans notre exemple, nous allons faire appeler le moteur de recherche de Twitter par celui de SharePoint.
Pour ce faire, naviguez jusqu’à l’écran de gestion du moteur de recherche SharePoint, sélectionnez « Federated location » dans le menu puis cliquez sur « New location » :

Renseignez les différents champs informatifs :

Puis renseignez ces valeurs dans les champs de la zone « Location information » :

  • Location type : OpenSearch 1.0/1.1
  • Query Template : http://search.twitter.com/search.atom?q={searchTerms}
  • « More results » link template : http://search.twitter.com/search?q={searchTerms}

Vous avez défini une fédération c’est bien… Mais afin de faire apparaître les résultats dans vos pages de recherche, vous allez devoir les configurer.

Pour ce faire, exécutez une recherche sur votre SharePoint, puis depuis la page de résultats, dans le menu « Actions du site », cliquez sur « Modifier la page » :

Cliquez dans une zone de la page sur « Ajouter un composant WebPart » :

Puis sélectionnez une Web Part « Résultats fédérés » dans la catégorie « Rechercher » :

Cliquez sur « Ajouter », puis utilisez la fontion « Modifier le composant WebPart » :

Dans la liste « Emplacement », sélectionnez « Twitter » puis cliquez sur « OK »

Enregistrez et publiez vos modifications (Menu Actions du site \ Publier ) :

Relancez une recherche et admirez le résultat 😉

A noter que le présentation des résultats (Layout, styles…) est personnalisable via XSL.

Comme vous l’avez constaté pendant la configuration, cette méthode repose sur le protocole OpenSearch, vous trouverez des informations détaillées et les dernières spécifications à cette adresse :

http://www.opensearch.org

D’autres moteurs sont accessibles au travers de ce protocole, et Microsoft propose en téléchargement les fichiers de configuration de plusieurs médias à cette adresse :

http://technet.microsoft.com/en-us/sharepoint/ff727944/

Une fois téléchargés, vous pouvez les importer depuis l’écran de gestion des fédérations en utilisant la fonction :

L’intégration applicative par API

Cette seconde option consiste à utiliser les API Search de Twitter pour effectuer les requêtes et afficher les résultats dans vos pages.

La manière « lourde »

La manière « lourde » consisterait à effectuer une intégration serveur complète entre SharePoint et Twitter (Identification via oAuth, utilisation d’une query de recherche, formatage des résultats via un template…). Cette option est tout à fait réalisable, et vous trouverez des exemples pratiques pour différentes plateformes et langages en consultant le SDK à cette adresse :
https://dev.twitter.com/docs/using-search

Bien que très souple, cette solution et aussi assez complexe et réservée aux développeurs. Je vous propose donc une solution alternative plus accessible.

La manière « légère »

Ce que je vous propose ici est blen plus léger, et consiste à intégrer dans vos pages un widget fourni par Twitter, et à le configurer pour afficher les résultats souhaités.
Les plus pointilleux me feront remarquer qu’il ne s’agira pas d’une recherche sur les tweets du passé, mais d’un filtre sur les messages en temps réel. C’est vrai, mais l’idée de l’usage de ce widget est justement d’obtenir un instantané des conversations en cours, pas d’obtenir un cliché du passé.

Cette méthode se décompose en 3 étapes :

  1. Obtenir et configurer le widget original Twitter
  2. Modifier le widget pour lui transférer les paramètres de recherche SharePoint
  3. Intégrer le widget modifié à vos pages de recherche SharePoint

1. Obtenir et configurer le widget original Twitter

Commencez par configurer votre widget depuis cette adresse :
https://twitter.com/about/resources/widgets/widget_search

Depuis cet écran, pensez surtout à personnaliser les couleurs des bordures et du texte afin qu’elles correspondent à la charte graphique de votre plateforme SharePoint :


Et ne vous occupez pas de la zone « Search query » pour l’instant, nous définirons plus tard sa valeur.

Une fois vos personnalisations réalisées, cliquez sur « Finish & Grab code », puis copiez le code généré.

Observons ce code :

On constate qu’il est composé de deux blocs :

  • La première ligne ne fait que charger dans la page le script « Widget.js » depuis les serveurs de Twitter.
  • Le reste du code crée une instance d’un objet « Widget » du namespace « TWTR » avec certains paramètres.

2. Modifier le widget pour lui transférer les paramètres de recherche SharePoint

Si vous observez vos pages de recherche SharePoint, vous constaterez que les paramètres de recherche sont transmis via l’URL sous cette forme :

http://monserveur/sites/search/Pages/results.aspx?k=MARECHERCHE

Voici donc une légère modification du script original, qui va simplement, au chargement de la page de résultats de recherche, lire la valeur « MARECHERCHE » du paramètre « k » dans l’URL, puis la passer à l’attribut « search » du widget :

Pour aller plus loin, vous pouvez aussi configurer le widget pour qu’il utilise des opérateurs de recherche avancés.

Consultez le SDK Twitter au besoin :
https://support.twitter.com/articles/71577

3. Intégrer le widget modifié à vos pages de recherche SharePoint

Maintenant que vous avez configuré et modifié votre widget, vous allez pouvoir l’intégrer à votre page de recherche.

Mais vu que je suis d’un naturel gentil, altruiste et généreux (oui pas tout le temps je sais ;-)), voici de quoi intégrer twitter plus rapidement…

J’ai simplement packagé le widget avec les modifications nécessaires pour qu’il puisse être importé directement dans vos pages de recherche SharePoint.

Commence  par télécharger ce fichier : Twitter Widget for SharePoint Search (DWP)
Il contient une Web Part déjà configurée avec tout le code nécessaire.

Vous n’avez plus qu’à ouvrir votre page de résultats de recherche puis passer en mode édition par le menu « Actions du site » :

Ouvrir le menu d’ajout d’une Web Part :

Importer le fichier précédemment téléchargé :

Cliquez sur télécharger puis sélectionnez la Web Part importée :

Sauvegardez et publiez vos modifications :

Et oh miracle ! Votre page de résultats de recherche SharePoint et Twitter fonctionne !

Bilan

La solution du fichier DWP est pratique pour tester le fonctionnement finalisé, mais vous devrez utiliser une autre méthode plus industrialisée pour passer en production. En quelques mots :

  1. Enregistrer le script JS dans un fichier dédié
  2. Publier ce fichier sur une URL accessible (SharePoint ou non), par exemple dans une bibliothèque SharePoint, le dossier « Layout »…
  3. Référencer ce script dans une « Content Editor Web Part » (CEWP) et la positionner sur la page de recherche (Déploiement par script…)
Si vous m’en faites la demande, je pourrai publier une procédure détaillée de mise en production à l’occasion.

J’espère que cet article vous a intéressé, n’hésitez pas à me solliciter si vous rencontrez des problèmes dans la mise en oeuvre de cette solution !

Petite astuce pour utiliser le CSOM SharePoint sur des sites Web anonymes.

Yann GARIT

L’utilisation du modèle objet client de SharePoint 2010 permet de facilement récupérer des données, cependant, vous avez peut-être remarqué que son utilisation en mode anonyme ne fonctionne pas.
Vous obtiendrez en effet un message d’erreur comme quoi la méthode “GetItems” a été désactivé par l’administrateur :

"ErrorMessage":"The method \"GetItems\" of the type \"List\" with id \"{xxxxxxx-xxxxxxx-xxx-xxx}\" is blocked by the administrator on the server."

Pour désactiver cette restriction, il faut aller voir du coté de SPClientCallableSettings.AnonymousRestrictedTypes.

Cette propriété référence toutes les méthodes qui sont restreintes dans le cas d’un accès par un utilisateur anonyme.

image

Nous pouvons voir, en y accédant en PowerShell, que la méthode “GetItems” est bien présente dans les méthodes restreintes.

 

View original post 47 mots de plus

Pourquoi JavaScript ?

Dans mon précédent article, « Développer des applications client-side avec SharePoint« , je tentais de dresser un panorama des solutions de développement client-side pour SharePoint :

  • BCS
  • .NET
  • Silverlight
  • JavaScript

Parmi les solutions étudiées, j’ai choisi ici de me concentrer sur JavaScript. Pourquoi ? Parce que ce serait la meilleure solution de manière absolue ? Naturellement non.

Pour vous présenter mon argumentation, je vais tout d’abord simplement exposer certaines des limitations et contraintes des autres solutions, puis vous donner mon point de vue sur les points positifs et négatifs de JavaScript pour SharePoint.

Les contraintes des autres solutions

Les solutions server-side

Bon, je coupe court aux remarques avant même qu’elles ne surviennent, oui c’est « puissant » de développer sur SharePoint côté serveur avec .NET et Visual Studio.

Oui :

  • On peut tout faire et intervenir sur l’ensemble des artefacts SharePoint (Web Parts, Services applications, Timers, Solutions Farm-level…)
  • Depuis Visual Studio, c’est confortable un IDE complet
  • Microsoft promeut cette option, et la préconise dans ses best practices par exemple pour la création de templates de sites

Oui… mais :

  • Il faut Visual Studio et ce n’est pas gratuit
  • Cela impose de développer en .NET ce qui n’est pas dans les cordes de tout le monde
  • Cela implique une grosse montée en compétences spécifique à SharePoint, tant sur les API serveur que sur les problématiques de packaging, features, feature stappler…

Les solutions Silverlight

Les solutions Silverlight offrent un grand nombre de possibilités et présentent de bons arguments pour créer des applications RIA dans SharePoint :

  • Développement .NET et forte intégration avec Visual Studio
  • Richesse des composants graphiques, notamment d’éditeurs tiers
  • Un CSOM dédié très proche du modèle serveur
  • Possibilité de créer des applications out-of-browser

Mais cette option présente aussi un grand nombre de contraintes :

  • Déploiement d’un plug-in spécifique
  • Des différences notables de fonctionnement et de support entre les navigateurs
  • Pas de support des terminaux mobiles, même pas Windows Phone !

Un dernier point tout de même, l’avenir de Silverlight est pour le moins incertain… Alors que Silverlight 5 est tout juste arrivé, il n’est pas sûr qu’une version 6 verra le jour… quel avenir pour Silverlight ?

Mais n’ouvrons pas ce débat ici…

L’heure du bilan

Le sourcing

Voilà un vrai problème. Trouver des compétences réellement qualifiées en développement SharePoint est particulièrement délicat. En effet, on trouvera relativement peu d’écoles informatique qui traitent de ce sujet en profondeur, et par ailleurs, bon nombre de développeurs SharePoint (sans trop vouloir généraliser naturellement 😉 n’ont pour seule connaissance du produit que :
  • Ce qu’ils connaissent de la version « légère », SharePoint Foundation, généralement en tant qu’end-user
  • Ce qu’ils ont retenu des 5 jours de formation standard au développement SharePoint avec pour seul prérequis de savoir développer en .NET
On trouve donc beaucoup de développeurs capables de produire très correctement des fonctionnalités unitaires, mais qui ne maîtrisent pas du tout l’ensemble de la plateforme. Ce manque de vision globale conduit à d’inévitables difficultés :
  • Travail parcellaire et moins valorisant / valorisable
  • Manque d’anticipation des difficultés de packaging, d’intégration et déploiement
  • Parfois même le développement spécifique de fonctionnalités qui existent déjà nativement

L’agilité et le time to market

C’est un des points les plus délicats des projets SharePoint, l’ALM (Application Licecycle Management).

Schématiquement, l’ALM consiste à maîtriser votre projet dans l’ensemble des évènements du cycle de vie de l’application :

  • Packaging
  • Gestion des environnements
  • Déploiements automatisés
  • Mise à jour entre versions mineures et majeures
  • Distribution à la demande…

De ce point de vue, SharePoint propose un certain nombre de solutions, plus ou moins adaptées, et plus ou moins délicates à mettre en oeuvre.

Car si les évolutions de Visual Studio ont simplifié un certain nombre d’opérations, comme le packaging ou le déploiement vers un environnement debug, l’industrialisation complète de la chaine de production logicielle reste une question complexe, délicate et surtout longue à mettre en oeuvre.

De plus, ce qui fonctionne relativement simplement pour la V1 de votre projet, comme les déclarations de modèles de sites en mode déclaratif XML, se révèle particulièrement délicat à manier lorsqu’il s’agit de mise à jour vers une version ultérieure.

Ces problématiques de change management, contrôle de version et de versionning de schéma (si l’on admet le parallèle entre les typologies de contenus SharePoint et un modèle SQL) est désormais bien outillée dans les environnements SQL (Par exemple avec RedGate SQL Compare), mais encore peu sur SharePoint, sauf à utiliser des solutions complètes de type AvePoint Replicator ou Quest Deployment Manager.

JavaScript, la troisième voie

Naturellement, tout ne peut être réalisé en JavaScript, ou tout du moins pas simplement. Ceci étant, l’idée d’utiliser JavaScript avec SharePoint vise à répondre à une particularité de cette plateforme, à savoir comment repousser le moment de l’écriture de la première ligne de code .NET.

En effet, un des points forts de la plateforme SharePoint réside dans sa capacité de configuration avancée, sans développement. Mais cette grande souplesse s’accompagne d’un inconvénient majeur, un très fort effet de seuil sur les coûts lors de la production de la première ligne de code.

Un exemple, si vous souhaitez afficher un message de bienvenue personnalisé à l’utilisateur en lieu et place de la traditionnelle zone :

Pour ce faire, en développement .NET classique, vous devrez :

  1. Créer une nouvelle solution SharePoint dans Visual Studio
  2. Définir la solution et les features
  3. Comprendre le système de « delegate »
  4. Développer le contrôle qui va « remplacer » le rendu original
  5. Builder
  6. Créer le package WSP
  7. Lancer quelques lignes de commande pour installer, déployer puis activer votre solution
  8. Vous assurer que cela fonctionne

C’est donc assez lourd, et je ne compte pas ici la moindre étape de mise à jour et l’ensemble des opérations liées à l’AML et l’industrialisation !

En conclusion, JavaScript offre une alternative pertinente pour bon nombre de situations, entre la configuration à la souris et le développement lourd.

C’est ce que certains auteurs tel Marc Anderson (créateur de l’excellente librairie SPServices), appellent le développement « middle-tier ».

Voici les points faibles et les points forts de cette option.

Les points faibles

Oui je sais, JavaScript c’est mal ! JavaScript ça tue des bébés phoques !
  • JavaScript est un langage non typé
  • C’est juste fait pour développer des animations de flocons de neige dans une page web (enfin si vous avez été enlevé par des Farcs depuis 20 ans et que vous n’avez pas suivi l’actualité)
Non plus sérieusement, développer avec Javascript pour SharePoint présente certaines limitations :
  • Si vous n’utilisez que le CSOM SharePoint (SP.JS), vous ne pourrez accéder qu’aux artefacts internes à la collection de sites (Site, Web, List…)
  • Si vous souhaitez accéder à d’autres objets, vous devrez faire des appels aux web service
  • Si vous développez en .NET habituellement, c’est une transition non négligeable et bon nombre de paradigmes de développement seront à revoir…

Les points forts

Certes la transition pour les développeurs .NET n’est pas neutre, mais pourrez-vous y échapper ?
Comme le laissent à penser les analyses du SDK (avec un renforcement du CSOM) et les leaks de SharePoint 15 (regardez ci-dessus le label « Drag files… »), la prochaine version de SharePoint reposera sur HTML5 et donc très fortement sur JavaScript… (Je précise que je ne suis pas soumis à la NDA et que le screenshot ci-dessus est public)
Outre cet investissement sur l’avenir, parier sur JavaScript vous permettra aussi de :
  • Simplifier vos process de déploiements
  • Réduire certains coûts initiaux de développement
  • Intégrer à vos équipes des profils orientés IHM
  • Utiliser des frameworks MVC puissants et légers
Par ailleurs, la maturité de ce langage n’est plus à démontrer, et l’écosystème JS propose désormais une large palette d’outils d’ingénierie et d’industrialisation pour les tâches traditionnelles de développement :
  • Audit de code
  • Qualimétrie
  • Automatisation des tests TDD et BDD
  • Intégration continue

Des perspectives passionnantes

Aujourd’hui j’ai tenté de vous convaincre en vous exposant « Pourquoi développer avec JavaScript pour SharePoint ». Dans mon prochain article nous verrons ensemble « Comment développer avec JavaScript pour SharePoint », en abordant notamment :

  • Best practice de déploiement des scripts et des dépendances
  • Comment choisir son framework : sp.js ou SPServices ?
  • Exécuter son code JavaScript à distance (Mobile, Node.js sur Azure…)

Alors à très bientôt pour la suite !

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