J’ai eu à faire un développement dans lequel il fallait que j’appelle un service web distant. Jusque là, rien de bien sorcier. On ajoute une référence web dans sa solution Visual Studio, et cet outil se charge de créer un proxy pour l’utiliser dans notre code, et se charge d’ajouter les bons bindings et endpoints dans un fichier de configuration. Il nous reste plus qu’a scripter tout ça, pour pouvoir déployer de façon propre ce code sur notre plateforme SharePoint. L’idée étant d’utiliser la classe SPWebConfigModification pour s’assurer que tous les web.config des serveurs de la ferme auront la modification de configuration pour l’appel des services.

Cependant, je ne suis pas particulièrement fan de l’édition de web.config dans SharePoint. Si je veux utiliser mon service dans plusieurs applications web, il va falloir que je modifie tous les web.config. Quelle serait-donc une alternative propre?

On pourrait bien entendu s’affranchir d’une configuration XML et de tout coder dans notre solution. Pourquoi pas … Etant donné que je cherche une solution plus propre, je ne suis pas certain qu’écrire en dur dans du code une URL, des comptes d’accès etc. soit très bien.

En étudiant l’architecture de SharePoint 2010, et plus particulièrement le dossier root, on remarque un dossier WebClients, qui contient des sous-dossiers avec des noms de services d’application, et dans ces dossiers, un fichier client.config contenant des informations d’appel de services.

Du coup, pourquoi ne pas utiliser ce modèle ….

Partons d’un exemple. Je veux créer une web part qui doit afficher des informations qui proviennent d’un service imaginaire :
http://www.sharepointofview.fr/ResultsWorldCup2010.asmx.

Je crée une nouvelle solution SharePoint 2010 de type Visual Web Part et j’ajoute une référence vers ce service. Un fichier app.config est généré. Ce fichier contiendra la configuration d’appel de notre service :

Ci-dessous, le contenu du fichier app.config (avec le binding, ici un basic http, et le endpoint contenant l’URL de notre service):

Ces informations sont donc à reporter dans le web.config de SharePoint. Plutôt que de développer un FeatureReceiver qui ajouterait ces données dans le web.config, ajoutons un lien virtuel vers le dossier WebClients du root depuis Visual Studio:

Dans le lien WebClients, ajoutons un nouveau dossier WorldCupService, et déplaçons le fichier app.config dans ce dossier.

Lors du déploiement de la solution, ce fichier sera déposé sur tous les serveurs de la ferme SharePoint.

Il ne nous reste plus qu’à appeler ce service depuis notre code.

   1:  string path = SPUtility.GetGenericSetupPath(@"WebClients\WorldCupService");

   2:  ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();

   3:  fileMap.ExeConfigFilename = System.IO.Path.Combine(path, "app.config");

   4:  Configuration cfg = ConfigurationManager.OpenMappedExeConfiguration              

                   (fileMap, ConfigurationUserLevel.None);

   5:   

   6:  ChannelFactory<WorldCupService.Service1Client> channel =

   7:          new ConfigurationChannelFactory<WorldCupService.Service1Client>

   8:          ("BasicHttpBinding_IService1",

   9:           cfg,

  10:           null);

  11:   

  12:  WorldCupService.Service1Client sc = channel.CreateChannel();

  13:  Team fr = sc.GetTeam("France");

Ligne 1, je récupère le chemin vers le dossier WorldCupService sur le serveur.

Dans les lignes qui suivent, je charge le fichier app.config dans une instance de la classe System.Configuration.Configuration.

Ligne 6, je crée un channel (un canal de communication) en injectant ce fichier de config et le nom du binding que je veux utiliser.

Ligne 12 et 13 j’appelle les méthodes de mon service.

Et voilà, en quelques lignes nous avons une solution efficace qui se déploiera proprement dans un environnement SharePoint.