Edgar Maucourant - Expert / Formateur SharePoint

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 2 juin 2016

Un développeur SharePoint ça n’existe pas !

Ce billet est déjà paru sur Linkedin

« Alors là, tout le monde se dit, ça y est, il a craqué, il a trop fait de SharePoint, son cerveau a fondu... Bien-sûr qu’un développeur SharePoint ça existe, j’en connais même plein… ».

Et je vous répondrai : « Non ». Non, vous ne connaissez pas de développeurs SharePoint, mais des développeurs, voire des développeurs Web spécialisés sur SharePoint. Il s’agit de sémantique, mais la nuance est importante, comme j’espère vous en convaincre dans cet article. Voici donc un double coup de gueule sur base de sémantique : pour les développeurs et pour les SSII/recruteurs.

Mon premier coup de gueule concerne donc les développeurs eux-mêmes (et surtout ceux qui travaillent sur SharePoint On-Premise). Je rencontre de plus en plus de "développeurs SharePoint" qui ont oublié que SharePoint est avant tout une techno web, basée sur ASP.Net et donc sur .Net. Travailler avec une techno web implique d’en connaître les spécificités ET d’en accepter les conséquences : HTML, CSS, JavaScript. Car c’est bien de cela qu’il s’agit, dans les projets les développeurs rechignent quand il faut faire du CSS, sont rebutés à l’idée de claquer un bout de JS à droite à gauche, et considère que le HTML ce n’est pas assez bien pour eux… Cependant cela fait partie intégrante du développement sur SharePoint (notez que je n’ai pas parlé de « développement SharePoint »).

Tout développeur sur SharePoint sait qu’il existe des spécificités à cette plate-forme telles que les fonctionnalités (features), les gestionnaires d’évènements, les types de contenu, etc… Il faut bien évidemment maîtriser ces concepts, mais il faut également garder à l’esprit que faire du développement sur SharePoint c’est avant tout faire du développement ASP.Net, et donc faire du développement Web (certes avec un peu de retard sur ce qu’il se fait par ailleurs…). Il arrive parfois que l’on ait la chance d’avoir un intégrateur HTML/CSS dans une équipe, mais quand ce n’est pas le cas, il faut se rappeler que HTML/CSS/JS c’est AUSSI du développement SharePoint.

Nous avons tous envie de faire des trucs techno-hype-blingbling (+ digital, puisque c’est le mot à la mode en ce moment), et nous sommes tous enclins à vouloir déléguer les actions que l’on considère rébarbatives (comme la doc par exemple). Cependant, j’ai appris de mon premier employeur en informatique que pour qu’un projet arrive pleinement à son terme, tout le travail doit être fait, y compris les tâches les plus insignifiantes. Et il n’existe pas de « préposé aux tâches que personne ne veut faire » (non, un stagiaire ça ne sert pas à ça…).

Voici donc mon conseil aux développeurs qui officient sur SharePoint : n’oubliez pas que vous êtes avant tout des développeurs Web. D’ailleurs, avec Office 365, le modèle d’Apps et le SharePoint Framework, Microsoft a remis au centre du scope SharePoint les technos web : CSS / HTML / JavaScript. Il serait exagéré de dire que développer pour Office 365 se résume à gérer ces langages, cependant leur utilisation est dans ce cas bien plus importante qu’un langage comme C#.

Mon deuxième coup de gueule concerne les SSII et les recruteurs : être développeur SharePoint ce n’est pas une fin en soi ! Je comprends le besoin de staffer les projets, je comprends le besoin de répondre à l’urgence d’une demande, et je connais bien la difficulté de trouver des ressources compétentes sur SharePoint. Cependant, comme dit précédemment, un développeur sur SharePoint c’est avant tout un développeur, et s’il est probable que celui-ci ait eu une vie avant SharePoint, il est certain qu’il en aura une après.

D’ailleurs, ce que j’indique ici pour le développeur est valable pour tous les autres rôles liés à SharePoint : chef de projet, administrateur, architecte,... SharePoint est une plate-forme pleine de spécificités mais cela ne reste qu’un outil. Les démarches, les bases et les concepts peuvent tout aussi bien s’appliquer à d’autres outils ou d’autres domaines.

Il est tentant pour une SSII de cantonner ses collaborateurs dans un domaine particulier, d’autant plus que les développeurs sur SharePoint sont parfois « déconnectés » de la réalité de leur domaine (comme indiqué précédemment). Cependant il me semble important de ne pas oublier de maintenir leurs compétences à jour. L’arrivée du SharePoint Framework devrait être un bon moyen pour les développeurs de se remettre à niveau sur les frameworks et outils actuellement en vogue dans le développement Web.

De la même façon il est tentant pour un recruteur de se cantonner à la demande initiale, mais il est important selon-moi de voir plus loin, et d’inclure pleinement les développeurs sur SharePoint dans l’écosystème des développeurs (et non pas comme un être à part qui ne pourrait pas faire autre chose que du SharePoint…).

Bien que SharePoint ne soit pas menacé à court-terme, il est probable qu’un jour ce produit soit remplacé par autre chose. Cet « autre chose » sera peut-être complètement différent de ce que nous connaissons aujourd’hui… Tout miser sur SharePoint est un risque important, sauf si l’on se souvient encore une fois que cette plate-forme repose sur des bases qui sont bien plus large que cet outil : le développement web et le framework .Net. En tant que recruteur ou « responsable de pôle » dans une SSII, ne pas imaginer ce futur est selon moi une faute importante, qui amènera inéluctablement à devoir gérer des profils « hors du marché du travail ».

En attendant ce changement, je retourne à mes projets, j’ai du CSS à finir. Oui on peut être architecte et mettre les mains dans le cambouis. Et en plus j’aime ça.

Edgar Maucourant - Architecte logiciel spécialisé sur SharePoint

A voir sur LinkedIn : https://www.linkedin.com/pulse/un-d%C3%A9veloppeur-sharepoint-%C3%A7a-nexiste-pas-edgar-maucourant?trk=pulse_spock-articles

mercredi 6 janvier 2016

Visual Studio Code : quel choc !

C’est sous ce titre volontairement ambigu et un brin racoleur que je souhaite vous faire part de ma première expérience avec Visual Studio Code. Autant le dire tout de suite, hormis une partie de leur nom, Visual Studio et Visual Studio Code n’ont rien en commun. Le premier est un EDI (Environnement de Développement Intégré, aussi appelé IDE) et l’autre est un éditeur de code enrichi avec la possibilité de déclencher des tâches automatisées.

Afin de simplifier la lecture de ce post je ferais référence à Visual Studio Code sous le nom VSCode et Visual Studio sous le nom VS2015.

Alors ? La voiture Ninjago ou le bateau pirate ?


La période de Noël étant encore proche, et heureux papa d’un petit garçon de 3 ans (oui je sais on n’est pas sur Facebook), un parallèle m’est venu assez rapidement : Playmobil et Lego. Deux univers bien distincts avec chacun leur fans et leur détracteurs. Et pourtant deux succès sans conteste. L’univers Lego centré sur la construction et les possibilités infinies de combinaisons s’apparenterait plutôt à VSCode, qui laisse le soin à l’utilisateur de définir les tâches à exécuter dans son projet grâce à des outils en ligne de commande tel que Gulp, Grunt, ou Yeoman. De son côté Playmobil est orienté sur l’expérience de jeu immédiate et serait donc plus dans l’esprit de VS2015 qui permet au travers des modèles de projets et des outils intégrés de se concentrer sur le code plutôt que sur la plomberie.

Le parallèle s’arrête cependant là, car si Playmobil et Lego sont en concurrence sur le marché du jouet, VSCode et VS2015 ne s’adressent pas aux mêmes cibles (sans être pour autant complémentaires). Précisons d’ailleurs tout de suite pour ceux qui n’auraient pas suivi qu’il ne sert à rien d’offrir un Visual Studio (Code) à votre enfant de 3 ans, il risque de ne pas apprécier…

Visual Studio est un environnement de développement complet et riche gérant tous les langages ou presque et toutes les typologies, mais disponible uniquement sur Windows. Visual Studio Code est un environnement léger et multiplateformes (Windows, Mac, Linux) plutôt orienté pour les développements sur des technos récentes (NodeJS, ASP.NET5 sur Mono/DNX, ou Unity).

VSCode est d’ailleurs toujours en Release Candidate (RC), ce qui signifie que le produit n’est pas encore finalisé. Cela explique le nombre restreint de langages et de typologies supportées. Ce côté non finalisé se fait parfois plus gênant, et il n’y a qu’à tester la création d’un projet ASP.NET 5 sur MacOSX pour s’en rendre compte. Mais VSCode évolue rapidement, et cette évolution est ancrée dans l’outil avec la possibilité d’ajouter des extensions, d’utiliser des outils en ligne de commande, et grâce également à un cycle de mises à jour plus rapides que Visual Studio. C’est donc un environnement jeune mais qui s’adaptera plus rapidement aux standards du marché et aux technos émergeantes.

Gulp, Grunt, Yeoman, Bower : Késako ?


Nous voici donc au sujet qui a inspiré le titre de cet article. En tant qu’architecte SharePoint, j’ai l’habitude de travailler avec Visual Studio dans un cadre connu avec peu d’outils tierces, le .Net Framework étant bien assez riche pour traiter la plupart des cas et VS2015 incluant déjà beaucoup d’optimisations et de tâches automatisées. Cependant en tant qu’architecte applicatif je me dois de connaître ce qui se fait d’autre sur le marché, d’où mon intérêt pour VSCode. Et c’est là que la claque arrive… A peine arrivé sur le site de VSCode (http://code.visualstudio.com) on est bombardé de termes jusque-là vaguement entendu ou lu à droite à gauche : gulp, grunt, yeoman, bower,…

Très franchement au début on se demande bien à quoi cela peut servir. Puis en lisant les tutoriaux et la documentation de VSCode on se rend compte à quel point tout est à faire, et ô combien ces outils vont se révéler précieux. Loin de moi l’idée de décrire ceux-ci en détail (je vous laisse vous référer à leur site respectif) mais il me semble utile de préciser rapidement à quoi servent certains pour illustrer mon propos.

Gulp et Grunt sont deux « task runners », c’est-à-dire des outils permettant d’exécuter automatiquement des tâches, soit à la demande (par exemple pour préparer un déploiement), soit de manière automatique (par exemple à l’enregistrement d’un fichier). Dans VSCode on peut s’en servir par exemple pour transpiler des fichiers TypeScript en JS. Transpiler ? Oui vous avez bien lu, ça fait aussi partie de l’aventure : des nouveaux vocabulaires à utiliser. Transpiler c’est transformer un langage en un autre, il ne s’agit donc pas d’une vrai compilation mais plutôt d’une conversion. Ici un fichier TypeScript (qui est un superset de JS) est converti en JS pur pour permettre son interprétation par les interpréteurs JavaScript (Navigateurs, NodeJS,….).

Yeoman (Yo pour les intimes), est un outil de « Scaffolding » ou d’échafaudage en bon François de chez nous. Et vlan, un autre nouveau terme au passage. Pour ceux qui ne savent pas ce qu’est le « Scafffolding » : cela permet de créer des structures de dossiers et de fichiers à partir d’un template. On peut donc choisir dans une liste un template et Yo s’occupe de créer la structure de dossiers, copier les fichiers par défaut, et configurer certains fichiers (grunt ou gulp par exemple). Dans VS2015 cela s’apparenterait à la création d’un nouveau projet. Et c’est là une grande différence entre VS2015 et VSCode, quand le premier fourni un cadre de travail préconfiguré, avec un nombre de projet de base assez conséquent, le second n’offre de base qu’un éditeur de contenu. Tout est à faire vous dis-je !

La brique versus le préfabriqué


Vous vous souvenez de mon analogie Lego / Playmobil ? On est en plein dedans ! Par défaut VSCode ne va rien vous imposer, libre à vous d’utiliser Gulp, Grunt, Yeoman ou autres, c’est très flexible. Cela demande par contre un effort de mise en place non négligeable pour un développeur qui n’a pas baigné dans ces outils. Il n’y a pas de template tout fait dans VSCode (mais on peut en trouver sur le site de Yeoman). A l’inverse VS2105 guidera plus volontiers l’utilisateur avec des templates tout prêts, quitte à l’enfermer dans un certain cadre. Les deux possibilités ont avantages et inconvénients, comme pour les jouets : à chacun son choix.

La démarche mise en place par VSCode a cependant ses limites car il n’est pas possible actuellement de traiter toutes les typologies de projets : exit ASP.Net MVC, exit Azure, etc… Pour le moment VSCode gère le Web nouvelle génération (comprendre NodeJS / ASP.NET 5), des framework multiplateformes (Mono, Unity), les outils front office (AngularJS, React, SASS, LESS,….) et quelques langages annexes type Markdown pour la description de projet dans Git.

Ca y est le mot est prononcé : Git. Car il faut bien l’avouer lorsque l’on prend en main VSCode pour la première fois on ne peut s’empêcher de penser qu’il a été conçus pour les projets hébergés via Git (et plus particulièrement GitHub). Même organisation en dossiers, même convention, support du Markdown,…

Microsoft s’adresse donc avec cet éditeur, non pas aux utilisateurs Visual Studio standard mais plutôt à tous les autres développeurs, qui ont l’habitude de travailler sur d’autre éditeurs. Nul doute que pour ceux-là : Gulp, Grunt, ou Yeoman n’ont rien d’inconnu.

Et c’est pas fini…

(Tout ressemblance avec une publicité récente est bien évidemment fortuite…)

Avec tous ces outils à installer (et bien d’autres), il vaut mieux un bon outil de gestion de package, car VSCode ne le fera pas pour vous. N’y voyez aucune malveillance, il s’agit là encore de ne pas vous imposer d’outil, et de ne pas réinventer la roue. Il existe en effet pléthore de gestionnaires de packages : npm, bower, homebrew,…

Pour ma part, le choix a été vite fait : NPM (Node Package Manager), le gestionnaire de package de NodeJS sera selon moi votre plus fidèle ami. Il est simple, largement utilisé, supporte un grand nombre de packages (et d’autres sont ajoutés quotidiennement) et est disponible sur toutes les plateformes.

Si la démarche d’utiliser les outils existants est louable, il faut bien avouer que garder un terminal ouvert en permanence et jongler entre NPM et VSCode est un peu casse pied. Un accès à ces lignes de commandes depuis VSCode aurait amélioré l’expérience utilisateur (surtout sur un Mac ou basculer d’une fenêtre à l’autre est plus pénible que sur Windows).

Fort heureusement NPM est facile d’usage, et les outils précités également. Il n’y donc rien d’insurmontable pour un développeur prêt à se retrousser les manches.

Alors ? Heureux ?


J’avoue que sur Windows je garderais très volontiers mon VS2015 (ou à défaut un Visual Studio Community). Par contre ayant fait l’acquisition d’un Mac récemment et développant sur Linux depuis déjà quelques temps, l’option VSCode est plus qu’intéressante. Cela permet d’avoir un éditeur commun sur les trois environnements pour faire du C# et / ou du NodeJS.

Reste que pour un développeur habitué à un Visual Studio standard, la claque est bien ressentie. Mais soyons honnête, malgré les problèmes de jeunesse et la courbe d’apprentissage un peu rude au départ pour maîtriser tous les petits outils annexes, VSCode est convivial, et bien pensé. Et puis comme indiqué, la cible est plutôt les développeurs utilisant des solutions similaires et qui n’auront pas à apprendre l’usage des outils tierces qu’ils connaissent déjà en général.

En définitive, peut-être que Microsoft aurait dû utiliser un nom différent pour cet outil très convainquant afin de ne pas entretenir une fausse filiation avec Visual Studio qui reste tout de même mon IDE préféré.

Article aussi disponible via LinkedIn : https://www.linkedin.com/pulse/visual-studio-code-quel-choc-edgar-maucourant?trk=prof-post

dimanche 23 mars 2014

De mystérieuses extensions serveurs 16 dans la ruche... SharePoint 2014/2015 ?

Bonjour à tous,

Bien que n'ayant pas mis à jour mon blog depuis très longtemps faute de temps, je ne résiste pas à l'envie de vous faire part de cette information.

En mettant à jour mon Visual Studio 2013 (Update 1), je me suis aperçu qu'en plus de la ruche 15, j'avais à présent une ruche 16...

hive16.png

Le contenu de la ruche est pour le moment assez simple mais nous livre déjà beaucoup d'informations :

hive16_content.png

Tout d'abord le dossier le plus intéressant est le dossier ISAPI, où l'on peut voir que Microsoft travaille d'arrache pied sur le modèle objet client de la future version de SharePoint (d'autres DLL suivront sûrement évidemment) :

hive16_isapi.png

Ce qui frappe au premier abord c'est l'apparition de DLL "Portable", qui comme leur nom l'indique sont destinées à un des .NET Framework Portable. Un coup de ILSPY nous révèle le profile utilisé (78) :

ilspy_portable.png

Une petite recherche sur internet nous révèle que ce profile est à destination de Window Store et Windows Phone 8... Microsoft serait donc en passe de permettre de créer des applications Windows 8 et Windows Phone interagissant avec SharePoint de manière plus native qu'avec SharePoint 2013. Soupçons qui se confirme lorsque l'on regarde la liste des DLL dans ISAPI, puisque 3 dll liées à Windows, WindowsStore et WindowsPhone font leur apparition :

hive16_windows.png

Ensuite une fois ces nouveautés écartées, on peut s'apercevoir que certaines DLL ont pris du poids, et que cela augure sûrement de nouvelles possibilités dans le CSOM de SharePoint 16 :

Les dlls de SharePoint 15 : hive15_dll_size.png

Les dlls de SharePoint 16 : hive16_dll_size.png

J'avoue que je n'ai pas pris le temps de détailler les changements entre les DLLs, si quelqu'un se sent l'envie de faire de la SPéléologie, il(elle) est le(la) bienvenu(e) ;)

Le dossier Template sous la ruche 16 est intéressant également, bien qu'il y ait peu de fichiers présents (relativement à ceux présent dans le Template 15) :

hive16_template.png

Ce qui est intéressant dans ce dossier Template c'est le sous-dossier ClientBin qui contient toutes les DLLs pour le modèle objet client de Silverlight. Microsoft semble donc continuer le support des interactions entre Silverlight et SharePoint pour cette prochaine version (cela reste évidemment à confirmer, d'ici la première béta les choses auront sûrement bien évoluées...) :

hive16_clientbin.png

Le reste du dossier Template est moins intéressant (à mon goût), on peut y voir que les Activités de Workflow ont légèrement pris de poids :

hive16_wfactivities.png

Et que les schémas XML n'ont quasiment pas bougé en terme de taille (le contenu a peut-être évolué, mais je ne sais pas pourquoi, je n'ai pas très envie de vérifier...) :

hive16_xml.png

Voila pour la primeur sur la future version de SharePoint. Je précise qu'évidemment il est probable que Microsoft ne souhaitait voir ces informations divulguées, mais je précise également que je n'ai enfreints aucun "agreement", hormis la récupération du profile78 via ILSpy je n'ai fait aucun "retro engeneering", pas plus que je n'ai cherché à trouver des informations cachées. Ces fichiers se sont trouvés sur mon disque à la suite d'une mise à jour Visual Studio.

Espérons que Microsoft nous annoncera bientôt des news !

D'ici là, Bon code à tous, Edgar Maucourant

mardi 4 décembre 2012

NFTInside lance les pack Fiches Actions SharePoint 2010 !

Bonjour à tous,

Depuis la création de cette société, j'ai toujours tenté de mettre l'éducation, la formation et l'amélioration des connaissances au centre de notre démarche. Dans cette optique, j'ai depuis longtemps pensé à réaliser des fiches "actions" qui permettrait d'avoir en quelques étapes la réalisation des actions les plus courantes sur SharePoint. Lancé en 2010 puis abandonné par faute de temps, le projet est à nouveau opérationnel, et je suis heureux de pouvoir annoncer la sortie des Pack "Fiches Actions".

Ces packs comprenent plus d'une centaines de fiches au format PDF, qui regroupent les étapes pour mettre en oeuvre différentes actions sur SharePoint (ex : ajouter un document, créer un affichage, gérer les autorisations, activer l'historique de versions...). Les actions sont pour cette version ciblées en grande partie sur l'utilisation d'un site d'équipe SharePoint, mais d'autres fiches sont déjà prévues pour les autres usages de SharePoint...

Ces packs sont plutôt déstinés aux entreprises, avec une bonne nouvelle : le tarif est unique ! Ici pas de licence complexe à l'utilisateur ou au nombre de serveurs ou que sais-je... Tout est simple : vous payez une fois et on vous envoie l'ensemble des fiches au format PDF que vous pouvez mettre sur votre intranet à destination des utilisateurs de l'entreprise sans limite de temps ou de nombre d'utilisateurs (à condition que ceux-ci soient des collaborateurs de l'entreprise). Une option permet également de recevoir toutes les nouvelles fiches qui seront ajoutées au fur et à mesure, cette option prend la forme d'un abonnement annuel.

Si vous êtes intéressé(e)s, je vous invite à consulter notre page dédiée sur le site NFTInside : http://www.nftinside.com/fr/packsfiches/fichesactions2010.aspx

N'hésitez pas à nous faire un retour sur ce blog ou par e-mail !

Bonne lecture à tous, Edgar

samedi 3 novembre 2012

[Màj : 04/11/2012] Site www.nftinside.com en maintenance [Terminée]

Bonjour à tous,

Pour des raisons de migration sur la solution d'hébergement le site www.nftinside.com sera indisponible du Samedi 03 Novembre 20h30 au Dimanche 04 Novembre 20h30. Désolé pour le désagrément occasionné.

MàJ 04/11@13h50 : Maintenance terminée le site est de nouveau opérationnel.

Bon W.E. à tous, Edgar

samedi 19 mai 2012

Erreur lors de la création d'une connexion pour la synchro des profiles

Bonjour à tous,

Imaginons que vous souhaitiez synchroniser votre magasin de profils (User Profile Application ou UPA) avec votre Active Directory (AD), vous allez alors recourir à la création d'une connexion pour synchroniser vos annuaires dans SharePoint via FIM (ForeFront Identity Manager). Cependant au moment de la création de votre connexion vous recevez le message suivant :

err_synch_conn.png

Et le message donné dans les Logs ne vous aidera pas beaucoup plus.

Il existe un nombre important de raisons pour lesquelles vous recevez ce message, en voici quelques unes :

  • Le compte utilisé pour la synchro n'a pas les bons droits
  • Certains affirment que le compte de synchro doit être administrateur de la machine qui fait la synchro (je n'ai pas constaté ce point)
  • Vous n'avez pas appliqué les patchs : KB 2475880 et 2475878
  • Des objets non-conformes sont présents dans votre A.D.

Dans mon cas rien de tout ça n'a fonctionné, heureusement il existe une autre raison bien plus simple : le nom de votre connexion ne respecte pas la convention de nommage !

En effet, après avoir cherché sur le net et testé de nombreuses "solutions" différentes, je me suis rendu compte que le nom de ma connexion contenait un accent et une apostrophe qui sont tous les deux interdits dans le nom de la connexion.

Evidemment, c'est toujours après avoir trouvé la solution que l'on trouve des posts s'y rapportant, comme celui-ci : http://danmyhre.wordpress.com/2011/02/12/error-unable-to-process-create-message/

Bref avant de vous lancer dans des modifications (parfois farfelues) de votre ferme, vérifiez que vos noms de connexion soient simples !

Bon code à tous, Edgar

vendredi 11 mai 2012

Les 3 règles d'or pour toutes personnes travaillant avec SharePoint

Bonjour à tous,

Cela fait quelques mois maintenant que je souhaite écrire ce post, le temps m'a manqué, mais aujourd'hui je me lance !

De mes pérégrinations dans le monde magique de SharePoint, j'ai pu au fil du temps établir 3 règles qui me semblent indispensables pour chaque personne travaillant sur cet outil. Il s'agit là bien évidemment d'un sentiment personnel lié à ma propre histoire avec ce produit, cependant j'ai expérimenté ces règles sur plusieurs types de profils lors de mes formations, coaching, etc... et je dois dire qu'elles se révèlent très souvent efficaces !

Ces règles sont valables pour tous profils : expert, consultant, architecte, développeur, administrateur, gestionnaire de sites, commercial, chef de projet, et même l'utilisateur occasionnel ! J'espère qu'elle pourront vous permettre de mieux appréhender cette plate-forme.

Les règles sont classées par ordre d'importance, les explications sont données en suivant :

  • Règle n°1 : Avec SharePoint, ne jamais présumer.
  • Règle n°2 : Avec SharePoint, Google (ou Bing) n'est pas toujours ton ami, ni la MSDN ni le Technet.
  • Règle n°3 : Avec SharePoint, se méfier de ses expériences passées

Voici à présent pour chaque règle, une explication plus détaillée de mon propos.

Règle n°1 : Avec SharePoint, ne jamais présumer

Lorsque l'on débute avec SharePoint, ou lorsque l'on aborde un sujet nouveau (il y en a toujours, même pour les experts), on est tenté de ce dire que telle ou telle action ou fonctionnalité doit agir comme ceci ou comme cela. De mon expérience la plupart des fois où j'ai raisonné ainsi mes présomptions se sont révélées fausses ou partiellement fausses. Je pourrais mettre en cause ma manière de raisonner ou mes capacités intellectuelles, mais d'autres ont eu le même résultat que moi, peut-être sommes-nous tous nuls, mais j'en doute :) Toute personne ayant déjà travaillé avec cet outil sait à quel point la logique utilisée dans SharePoint est... floue. Parfois cela est dû à l'organisation interne du produit et en creusant on comprend le pourquoi du problème en surface, parfois on se demande si le produit n'a tout simplement pas été codé avec les pieds... (Au moins en partie).

Règle n°2 : Avec SharePoint, Google (ou Bing) n'est pas toujours ton ami, ni la MSDN ni le Technet.

Internet est une révolution, personne ne le niera, c'est une mine d'or incroyable d'expériences échangées, de bugs remontés, d'explications et d'entraide. Cela a révolutionné notre manière de travailler. Ainsi aujourd'hui n'importe quel informaticien qui rencontre un problème et qui dispose d'Internet à proximité va faire une recherche sur Google (ou Bing) pour trouver une réponse ou au moins un peu d'aide. Sauf que dans le cas de SharePoint ce n'est pas forcément la meilleure idée. On trouve en effet beaucoup de bêtises à son sujet sur Internet, des informations fausses, des informations partielles où l'on a omis la partie problématique de la solution, des méthodes qui relèvent franchement de la bidouille et d'autres qui s'appuient sur des mauvaises pratiques... Même des sources d'information supposées "sûres" ne le sont pas, ainsi la MSDN et le Technet, bien qu'améliorés, ont encore des pages de documentation fausses, ou ambiguës. Il est par exemple possible de rencontrer des articles contradictoires où l'un préconise telle action alors que l'autre indique de ne surtout pas le faire. Ou bien encore, des articles dans lequel les tournures de phrases masquent une difficulté du produit (ex : quid de la sauvegarde à chaude de la base de configuration ?)

Règle n°3 : Avec SharePoint, se méfier de ses expériences passées

SharePoint est un outil complexe, parce que vaste, il couvre un nombre important de fonctionnalités et de cas d'usage. De cette richesse survient un soucis : la multiplicité des cas "similaires" mais pas identiques. Ainsi lorsque l'on réfléchis à un problème sur cet outil, il faut se méfier de ses expériences passées, car ce qui a fonctionné dans tel cas ne fonctionnera pas forcément dans tel autre. Par exemple des fonctions disponibles dans le site de publication, ne le sont pas dans le site d'équipe, pire les comportements diffèrent entre le site vide et le site d'équipe qui sont pourtant basés sur la même définition. De même ce qui fonctionnait en SharePoint 2007, n'est peut être plus valable en SharePoint 2010 ou seulement en partie. Ainsi quand vous développez, ce qui fonctionne sur un site racine peut ne pas fonctionner dans un sous-site, ou dans un site contenu sous un chemin managé. Avant de vous aventurez sur les chemins tortueux du chiffrage SharePoint gardez cela à l'esprit...

J'espère que ces règles pourront vous aider dans votre travail avec cette plate-forme. Il n'existe à mon sens qu'un moyen de pouvoir contourner les problèmes suggérés par ces règles : Tester, tester et retester. Cela peut paraître simpliste et "puriste" mais si vous vous aventurez à parler d'un sujet que vous ne connaissez pas dans SharePoint sans avoir ces règles à l'esprit, vous risque au mieux de vous planter, au pire de vous planter ET de passer pour un vaniteux incompétent ;)

Bon code à tous
Edgar

dimanche 4 mars 2012

SharePoint 2007 (et 2010 ?) : suppression d'un serveur de BDD impossible

Bonjour à tous,

Imaginons que vous n'ayez pas installé votre ferme SharePoint selon les bonnes pratiques, et qu'au lieu d'utiliser un alias SQL Server vous ayez directement saisi le nom du serveur pour la création des services (c'est ballot mais c'est courant...).

Imaginons maintenant que vous souhaitiez refaire les choses bien et que vous recréiez les services avec un alias (c'est un bon consultant ça ! oh oui un bon consultant...).

Il est probable qu'ensuite vous souhaitiez supprimer le serveur de BDD référencé dans la section "Servers in farm".

Sage décision, le ménage ça fait toujours du bien (ma femme m'a obligé à mettre cette phrase...), cependant lorsque vous cliquez pour supprimer le serveur vous obtenez le message suivant :


An object in the SharePoint administrative framework, "SPDatabaseServiceInstance Name=NOMINSTANCE Parent=SPServer Name=NOMSERVEUR", could not be deleted because other objects depend on it. Update all of these dependants to point to null or different objects and retry this operation. The dependant objects are as follows :

Grosso modo, il existe des objets dépendant de celui-ci, et SharePoint ne peut pas le supprimer. Cependant la section listant les objets concernée est vide !! (Bizarre ça ne m'étonne même plus, je dois être trop habitué à SharePoint...)

Après un rapide tour sur Internet, vous trouvez un certain nombre de posts qui vous encouragent à aller faire une requête sur la base de données pour voir les objets dépendants et à les supprimer, par exemple : http://www.mylifeinaminute.com/2008/07/23/manually-removing-servers-in-moss-2007/

Pas de chance, cette requête ne retourne rien... On aurait pu s'en douter puisque c'est sûrement la même requête qui a été utilisée dans le message d'erreur ci-dessus.

En allant un peu plus loin vous pourriez tomber sur un post comme celui-ci : http://www.jeremytaylor.net/2010/01/09/sharepoint-moss-shared-services-ssp-delete-unprovisioning/ qui vous encourage à supprimer directement les objets par l'utilisation de STSADM, ce qui semble plus propre mais revient au même : la suppression d'une ligne directement dans la base. Pas de chance là également car l'exécution de cette commande vous renvoie exactement le même message que précédemment...

Dans votre quête de connaissance, vous continuez à chercher et tombez sur ce post : http://sharepointwillem.blogspot.com/2010_06_01_archive.html. Cette fois-ci on va encore plus loin dans le risque pour modifier temporairement la structure de la base de données SharePoint....(L'aaaaaamour du risque, Jonathan et Jennifer... tout ça, tout ça)


STOP !!!!


Bon honnêtement, là j'ai pas pu, je me suis dit qu'il devait y avoir un autre moyen... Et en regardant les contraintes de clés étrangères que le post précédent expliquait comment faire sauter (tout en disant qu'il ne faut pas le faire :o/), je me suis rendu compte qu'il y avait une autre forme de dépendance plus implicite (parce que non indiquée dans la table "dependencies") : la relation Parent / Enfant. En effet les tables des Objets SharePoint donne pour chaque objet quel est l'id de son parent (dont il dépend donc).

J'ai donc fait une recherche rapide sur les objets dont le parent est mon instance SQL Server (après avoir récupéré son Id), et j'ai trouvé le problème : la base de données du service de recherche d'aide WSS était encore stockée sur cette instance... Après avoir redéployée ma base de données du service de recherche d'aide via mon alias, j'ai pu supprimer ma référence de serveur sans soucis...

Ce cas illustre encore une fois le risque de suivre les actions données sur Internet, surtout si celles-ci vont à l'encontre des bonnes pratiques : on ne doit pas toucher aux bases SharePoint !!! Microsoft ne supporte même pas les requêtes SELECT sur ces bases, il ne s'agit donc pas juste de modifier la base, mais rien que lire les données de cette base en dehors des API SharePoint n'est pas supporté... Notez que pour SharePoint 2010 il me semble avoir lu que MS supporte la lecture, mais toujours pas évidemment l'écriture en direct dans les bases (sauf peut-être celle de logging, à vérifier)


Bon code à tous,
Edgar


Note : les plus perspicaces d'entre-vous se seront rendu compte que ma requête pour retrouver les objets parent n'est donc pas supportée... Gardez cela à l'esprit si vous suivez cette démarche (bon en même temps je ne pense pas que cela gêne quoi que ce soit sur la table Objects...).

mardi 21 février 2012

SharePoint, PowerPivot, Datafeed & erreur 401

Bonjour à tous,

Dans PowerPivot, vous pouvez utiliser un flux Atom en tant que source de données pour une table. Si vous souhaitez exposer votre fichier PowerPivot dans SharePoint, il est nécessaire de disposer d'un ficheir ".atomsvc" accessible au travers d'un répertoie partagé ou d'une url accessible (par exemple une bibliothèque SharePoint). Si ce fichier n'est pas accessible au service PowerPivot il ne sera alors pas possible de rafraîchir les données du cube PowerPivot.

Le Problème

C'est ici que votre erreur 401 intervient. En effet il est possible que lors du rafraîchissement programmé du cube, l'erreur suivante apparaisse :


Errors in the high-level relational engine. The following exception occurred while the managed IDbConnection interface was being used: The remote server returned an error: (401) Unauthorized.. A connection could not be made to the data source with the DataSourceID of '48ffbe38-adeb-48ae-a20d-b32a99b03ebb', Name of 'List_Name'. An error occurred while processing the 'TableName' table. The operation has been cancelled.

Après avoir vérifié que vous avez accès à la liste indiquée, que votre compte de rafraîchissement (PowerPivotDataRefresh) a accès à la liste, que le compte PowerPivotDataRefresh et vous avez accès aux fichiers ".atomsvc" concernés, vous êtes sur le point de menacer votre serveur de le priver de courant s'il n'optempère pas sur le champ...

La solution

Mais il y a toujours une solution plus douce... En effet si vous avez installé votre instance PowerPivot selon les recommandations Microsoft, vous devriez avoir séparé les comptes de services pour chaque service (hormis l'application de service PowerPivot sur SharePoint qu'il est recommandé de faire tourner avec le compte système de la ferme). Vous devriez donc avoir en plus de votre compte de rafraîchissement des données, un compte pour le moteur "analysis service vertipaq". Un rapide coup d'oeil avec NetMon vous indiquera que c'est le compte de ce service qui nécessite l'accès aux fichier ".atomsvc" et vous envoie une erreur 401 s'il n'a pas les autorisations pour cela.

Donc pour que cette erreur "401" disparaisse n'oubliez pas de donner accès aux fichiers ".atomsvc" au compte exécutant le moteur AS de PowerPivot. Et rebranchez-moi cette prise....

Bon code à tous,
Edgar

mardi 31 janvier 2012

SharePoint 15 arrive... Enfin le SDK pour le moment

Bonjour à tous,

Tous les SharePointeurs de la planète s'attendent à une sortie de la prochaine version de SharePoint dans le courant de cette année (au moins en CTP ou Beta). Et Microsoft semble confirmer ceci car ils viennent de mettre en ligne le SDK de la Tech preview de SharePoint 15, vous pourrez le télécharger ici :

http://www.microsoft.com/download/en/details.aspx?id=28768&

Bon code à tous, Edgar

- page 1 de 6