SharePoint : Comment ? Pourquoi ?
Les différents métiers SharePoint
Quel que soit le point de vue, SharePoint est un produit d'une grande complexité :
- Les utilisateurs finaux peuvent avoir du mal à appréhender le produit de par sa richesse fonctionnelle (GED, recherche, synchronisations, BI, permission, création de pages, ...) et la philosophie du produit (architecture en collections de sites et sous-sites, listes et bibliothèques, permissions, Web parts, menus, navigation...).
- Les administrateurs doivent jongler avec un grand nombre de technologies : Windows Server, AD, IIS, SQL, DNS, UAG, et enfin SharePoint. Au sein même du produit, beaucoup de notions différentes peuvent nécessiter des compétences variées : backups, performances, BI, configuation de la recherche, publication Web, sécurité, diagnostics, etc.
- Enfin, les développeurs SharePoint doivent avoir une excellente connaissance fonctionnelle du produit (afin d'éviter les développements lorsque possible), connaître l'administration du produit (installation d'environnements, contraintes techniques pour les développements, interfaçage avec les modules avancés, etc.).
Et tout cela, sans même évoquer "SharePoint Designer", qui est un produit à la croisée des métiers SharePoint... et qui nécessite un bon approfondissement pour finalement comprendre comment l'on peut s'en passer !
Le développeur SharePoint
Une fois paré à affronter SharePoint grâce à ces connaissances périphériques (SharePoint fonctionnel et admin, IIS, AD, Windows), le développeur .NET peut aborder le coeur du sujet : le développement de solutions custom pour SharePoint. Bienvenue dans la jungle. Développer une solution SharePoint pour répondre à un besoin nécessite en effet la capacité de lister dans un premier temps toutes les approches possibles. Le produit est tellement tentaculaire, que très souvent plusieurs approches sont possibles. Une fois ces approches déterminées, il faut encore choisir la meilleure en fonction du contexte (reprise de l'existant, budget, évolutivité, généricité, facilité d'utilisation, contraintes techniques et sécuritaires diverses, ...)
Un exemple simple
Pour illustrer cette complexité, prenons un exemple classique et très simple : le développement d'un système de saisie et de gestion de congés.
Premier besoin : le stockage des données. La question semble triviale quand on aborde un projet SharePoint, mais elle peut en fait être capitale :
- Liste SharePoint "classique" (et encore faut-il aussi déterminer les types des colonne : texte, texte enrichi, choix, lookup, taxonomie...)
- Bibliothèque de documents avec méta-données
- Bibliothèque + liste
- Bibliothèque stockant des fichiers XML
- Base de données tierce (+ BCS ?)
Deuxième besoin : l'interface de saisie. Parmi toutes les options techniques possibles, citons, sans être exhaustif :
- Formulaire de liste standard SharePoint
- Formulaire de liste standard avec des types de champs custom
- Listes avec formulaires recréés en ASP.NET
- InfoPath
- Forms Server
- Document Word (avec ou sans extraction des données)
- Document Excel (avec ou sans extraction des données)
- Application riche
- Envoi d'emails à une bibliothèque de documents
Troisième besoin : le traitement des données après saisie. Là encore, les possibilités sont nombreuses :
- Traitement direct par la page de saisie
- Script PowerShell
- Job SharePoint
- Event receiver
- Workflow
- Traitement distant par système tiers
(et encore une fois, j'ai exclu les possibilités à base de SharePoint Designer : restons dans le cadre sérieux d'un développement sérieux).
On le voit, les possibilités sont très nombreuses à chaque fois. Toutes ne sont pas valables en fonction du besoin et des contraintes techniques.
Si l'on ne connait pas les tenants et aboutissants de chacune de ces approches, le choix risque bien d'être hasardeux... et les conséquences parfois catastrophiques.
Nombre de projets SharePoint sont voués à l'échec car les prestataires ont choisi une solution par défaut (i.e. ils n'en connaissaient qu'une, et la seule solution connue est de fait devenue la "meilleure" solution...). Et ce n'est que trop tard qu'un consultant expérimenté est contacté pour tâcher de remédier au problème. Bien souvent, la meilleure solution est alors de tout reprendre à zéro, sur des bases saines... mais ce n'est souvent pas politiquement possible, et l'on doit se contenter de rustines sur des fondations branlantes.
L'implémentation du code
Même lorsqu'une bonne architecture technique a été décidée, il faut encore implémenter le code selon les bonnes pratiques de développement SharePoint. Et là encore, les pièges sont nombreux.
Sans même évoquer les fameux objets SPWeb et SPSite historiquement responsables de nombreuses fuites mémoires (ou de crash intempestifs), la liste de ces pièges est longue :
- Absence de requêtage CAML (performances catastrophiques après le passage en production)
- Développement non-pensé pour les fermes SharePoint multi-frontaux
- Utilisation des "display names" plutôt que des "internal names" pour le référencement des colonnes
- Chemins hard-codés, accès direct au système de fichiers, etc.
- Déploiements "manuels"
- Mises à jour "manuelles"
- Elévations de contexte de sécurité intempestives (sécurité...)
- Scénarios de double-hop détectés uniquement après passage en production
- Tests réalisés uniquement en admin (plus d'accès après le passage en prod)
- Incorporation de composants tiers non-supportés, non-maintenus, non-maîtrisés
Etc.
Articles techniques (en construction)
Je propose dans cette section quelques articles techniques :
