J'en avais parlé il y a quelque temps avec notamment la publication d'un projet sur CodePlex, mais voici un point un peu plus complet sur ce qu'on appelle les extensions stsadm, ou le moyen d'étendre l'utilitaire stsadm - le super outil d'administration en ligne de commande - avec vos propres commandes.
Bien sûr, "stsadm" ça reste une bonne vieille ligne de commande, une application console plutôt austère. Seulement, c'est aussi le parfait outil pour les scripteurs fous et ceux qui ont besoin de pouvoir lancer des tâches planifiées avec tout plein de paramètres. De plus, il arrive parfois que l'interface web ne soit pas disponible (plantage ou autre), et on garde ainsi toujours la possibilité de gérer sa plateforme. Petite note : pour l'écriture de jobs, un autre moyen est l'utilisation des Job definitions, cf le billet de Phil dessus : http://blogs.developpeur.org/phil/archive/2007/11/26/sharepoint-taches-planifiees-et-spjobdefinition.aspx
Combien de fois avez-vous développé une petite application console au départ pour simplement tester 2/3 choses sur votre ferme, puis de vous dire plus tard : "tiens, avec quelques paramètres bien placés, je pourrais le réutiliser" ? Aussi, pourquoi créer ses applications console de manière indépendante alors que vous pourriez bénéficier d'une "interface" commune (on ne parlera pas d'interface graphique ici, mais plutôt d'un point d'entrée connu et homogène).
Grâce aux extensions pour stsadm, vous pourrez proposer de nouvelles opérations et ainsi étoffer votre boîte à outils pour :
- les développeurs, avec des commandes de test, de log, de remplissage de sites, ...
- les administrateurs, avec des commandes d'administration pour sauvegarder, déployer, gérer sa plateforme...
Les gains :
- la même logique pour toutes ses commandes
- un endroit bien défini pour le déploiement
- un code "dans les clous" (implémentation d'une interface)
Allons un peu plus loin et rentrons dans le vif du sujet : comment développer son extension pour stsadm ?
Tout d'abord, sachez que le SDK propose un "How To : Extend the STSADM utility" : parfait pour débuter et avoir un exemple de code. Voici un peu plus de détail sur la marche à suivre :
- tout d'abord créer un projet de type bibliothèque de classes (et oui, pas de projet extension stsadm avec les extensions pour VS - ça fait beaucoup d'extensions dans la même phrase :p)
- y ajouter les références à la DLL de base SharePoint tout d'abord (Microsoft.SharePoint.dll), mais aussi (et surtout) Microsoft.SharePoint.StsAdmin.ddl qui contient l'interface ISPStsadmCommand, la clé de voute de notre projet. J'en profite pour rappeler une chose important : il n'est pas obligatoire de développer sous Win2K3 avec SharePoint !!! J'ai développé régulièrement sur mon poste sous XP sans aucun problème, il suffit de récupérer les dll
- ensuite créez votre classe implémentant l'interface ISPSAdminCommand (pensez aux using qui vont bien). Vous devrez écrire 2 méthodes : GetHelpMessage et Run.
- GetHelpMessage affiche le message d'aide expliquant les paramètres à fournir pour lancer votre opération. Cette méthode prend une chaîne de caractères en paramètres représentant l'opération demandée. On pourra ainsi avoir plusieurs opérations au sein de la même classe et ainsi dispatcher le bon message d'aide selon l'opération demandée.
- La méthode Run, elle, permet d'exécuter la commande à proprement parler. Elle prend le nom de la commande demandée, un ensemble de clés/valeurs représentant les paramètres additionnels, et fournit une chaîne de caractères en sortie qui sera affichée à la fin de l'exécution si tout s'est bien passé. Il vous faudra aussi retourner un entier représentant le résultat de l'opération : 0 si tout s'est bien passé, -1 pour une erreur générique, -2 si c'est une erreur de syntaxe. Dans ce dernier cas, ce sera le résultat de la méthode GetHelpMessage qui sera affiché.
- il vous restera ensuite encore une étape importante : créer un fichier XML permettant de faire le lien entre les opérations disponibles et le code. Il faudra ainsi indiquer le nom de la commande et le nom de la classe + l'assembly de cette manière :
<commands>
<command name="command_name" class="fully_qualified_class_name, assembly_name, Version=1.0.0.0, Culture=neutral, PublicKeyToken=value"/>
</commands>
Vous pouvez bien sûr déclarer plusieurs commandes dans le même fichier XML. Ce fichier devra respecter un nom particulier : stsadmcommands.[nom_unique].xml, où nom_unique correspond à un identifiant unique que vous donnerez à votre fichier (aucun lien outre mesure avec le nom de la classe, de la dll, ...)
Et voilà ! Bien sûr, il reste une étape très importante : le déploiement !
Pour que la commande soit prise en compte, il suffit de copier le fichier XML dans le répertoire ...\12\CONFIG (le fameux Hive de SharePoint) et mettre la DLL dans le GAC.
On peut bien sûr se dire qu'on déploiera les fichiers avec un MSI ou avec un petit batch, mais pourquoi ne pas profiter des solutions SharePoint ? Vous pourrez ainsi déployer automatiquement vos fichiers sur vos serveurs SharePoint, les gérer depuis l'interface web de l'administration centrale (déployer, retirer, supprimer), et puis c'est quand même LE mode de déploiement SharePoint, autant l'utiliser ! Vous pourrez ainsi utiliser WSPBuilder avec un répertoire possédant la structure finale : un répertoire 12 et sous répertoire CONFIG qui contiendra le(s) fichier(s) XML, un répertoire GAC avec votre DLL, et le tour est joué.
Pour finir, voici quelques bons pointeurs :
Et si le mode console vous rebute toujours, regardez du côté de l'interface graphique pour Stsadm : http://blogs.msdn.com/ronalus/archive/2007/01/04/stsadmwin-has-an-2007-version.aspx.
J'espère que vous aurez toutes les billes en main pour enrichir votre environnement SharePoint (hé oui, le développement SharePoint est vraiment très varié avec la version 2007).
Gat, SPStsadment vôtre