Migrer vos SharePoint Timer Jobs dans le cloud : Azure WebJobs est LA solution

Bonjour à tous,

Aujourd’hui, je vais reprendre un sujet que nous avons présenté avec l’excellent Gilles Pommier lors du non moins excellent yOS Day de Genève, lundi dernier.

Notre sujet concernait la migration des développement SharePoint On Premise vers SharePoint Online. Un sujet assez peu abordé, était la migration des timer jobs.

C’est quoi un timer job ?
Je lisais récemment sur le blog d’un développeur de ShareGate qui écrivait : « Les timer jobs, c’est ces trucs qui ont l’air vital, dont vos développeurs parlent tout le temps, mais auquel vous n’avez jamais rien compris ». Fort de ce constat pour le moins pessimiste, je me suis permis d’en rédiger une définition : c’est un programme dont le lancement est planifié, et peut être redondant, via la définition d’une fréquence. Il est exécuté par SharePoint. Sa planification s’effectue soit dans le code, soit dans l’interface d’administration de SharePoint. Etant déployé sur la ferme, il peut aisément réaliser des opérations à l’intérieur des collections de site SharePoint.

Quels en sont les usages ?
– Tâches fonctionnelles. Par exemple, dans le cadre de GED (archivages automatiques de documents à une date donnée, …).
– Tâches techniques. Envoi d’un email à l’administrateur d’une ferme lorsque certains quotas sont dépassés, …

Comment ça se migre sur un environnement cloud, en SaaS ?

MAL
(Ou plus exactement, pas facilement).

Vous imaginez que Microsoft ne va pas vous permettre d’accéder à leurs serveurs pour lancer vos tâches planifiées au niveau de leurs fermes. Le SDK ne permet pas ce genre de choses.

Dans tous les cas, il va falloir recoder vos traitements. Plusieurs options s’offrent à vous :

Solution 1 : Une tâche planifiée sur un serveur
En gros, vous lancez votre script distant depuis un serveur (distant) et il interagit avec SharePoint. L’avantage de cette solution, c’est que vous pouvez utiliser un grand nombre de technologies CSOM (le C# qui fonctionne avec SharePoint Online, et qui peut s’exécuter depuis l’extérieur), du PowerShell ou encore l’API REST. On note que REST étant standardisé, vous pouvez même l’exécuter depuis un serveur LINUX avec CRON (par exemple). Le gros inconvénients, c’est que vous devez payer et maintenir un serveur… Et ça, ça casse un peu le côté SaaS de la chose ; ça vous pousse à héberger vous même ce serveur, ou encore à faire du IaaS. Ce qu’Azure fait très bien au demeurant.

Solution 2 : les prestataires externes
Je passe assez vite sur ce point. Lors de mes recherches je me suis rendu compte que des gens se proposaient d’héberger vos scripts et de les lancer. Ces « gens » ne sont pas de grands acteurs, et je me vois mal proposer à un client d’héberger une partie de ses scripts chez quelqu’un d’assez peu connu, … Bref, c’est une option que je ne considèrerai pas tant que je n’aurai pas de solides garanties quant à la solidité technique et financière du prestataire. On ne parle même pas de la confidentialité des données qui pourraient transiter par son service.

Solution 3 : les Azure WebJobs
Vous vous en douterez, c’est la solution que je préfère. Azure propose en effet, via ses « app web » (anciennement Azure Websites) un service nommé Azure WebJobs permettant de planifier l’exécution de son code ; préalablement hébergé dans Azure.
Plusieurs avantages à cette solution :
– Selon le nombre de traitement mensuels, c’est souvent gratuit.
– Vous êtes hébergés par Microsoft, donc, a priori, vous avez confiance en eux, puisque vous avez un Office 365.
– L’interface de déploiement des scripts et complètement intégrée dans Visual Studio, et ça, ce n’est pas rien.

Comment fait-on ?
Je vous conseille d’avoir Visual Studio 2015, ça facilite grandement les choses. Même si on est (encore) en preview, la dernière realease est stabilisée.

Dans Visual Studio, créez un nouveau projet et trouvez le template « Azure WebJob ». Donnez lui un nom, et créez le projet.

Capture d’écran 2015-04-20 à 12.46.26

Référencez les assemblies nécessaires à votre dev :
– Microsoft.Sharepoint.Client
– Microsoft.Sharepoint.Client.Runtime
– Eventuellement d’autres, si vous vous amusez avec de la taxonomie, ou ce genre de joyeusetés…

Capture d’écran 2015-04-20 à 12.49.27

Capture d’écran 2015-04-20 à 12.49.56

L’important, c’est de savoir qu’Azure Webjobs n’ayant rien à voir avec SharePoint, il n’a pas ces DLL installées. Il va donc falloir indiquer à Visual Studio de déployer les DLL en même temps que votre code. Pour chaque assemblie, vous devez donc paramétrer le paramètre « Copy Local » sur la valeur « True ».

Capture d’écran 2015-04-20 à 12.50.33

Dans la foulée, je vous invite également à commenter ces lignes :
var host = new JobHost();
// The following code ensures that the WebJob will be running continuously
host.RunAndBlock();

Une fois que c’est fait, vous pouvez, dans la méthode Main(), lancer le traitement que vous souhaitez. Je me suis ici authentifié « en dur », mais il existe d’autres méthodes. Je ferai un post là dessus un peu plus tard.

Ici, on utilise donc le CSOM pour interagir avec SharePoint.

Capture d’écran 2015-04-20 à 13.54.34

Ensuite, afin de publier dans Azure, rien de plus simple. Un clic droit sur le projet et « Publish as Azure Webjob ».

Capture d’écran 2015-04-20 à 13.55.49

Visual Studio vous propose alors de définir le type de WebJob que vous souhaitez publier (continu, sur demande ou programmé). Ici nous choisirons « programmé » et définirons notre paramétrage de programmation.

Capture d’écran 2015-04-20 à 13.57.48

Sélectionnez ensuite « Azure Websites » pour publier dans Azure.

Capture d’écran 2015-04-20 à 13.59.42

Si vous êtes déjà connecté avec vos credentials Azure dans Visual Studio 2015, vous pouvez créer un nouveau website, comme ci-dessous.

Capture d’écran 2015-04-20 à 14.06.50

Capture d’écran 2015-04-20 à 14.07.24

VS s’occupe de tout, il créé le profil de connexion pour vous, et vous n’avez plus qu’à cliquer sur « Publier » (éventuellement après avoir validé la connexion pour vérifier que tout se passe bien).

Voici ce à quoi doivent ressembler vos logs lors du déploiement.

Capture d’écran 2015-04-20 à 14.09.53

Rendez-vous ensuite dans l’explorateur de serveur de Visual Studio. Développez le chemin suivant :
Azure > Websites > votre nom de site > Webjobs > A la demande et planifié, et vous voyez votre Webjob publié ! Félicitations ! Vous pouvez le lancer via un clic droit sur le nom de votre Webjob et « Exécuter ».

Capture d’écran 2015-04-20 à 14.13.05

Une fois que vous avez lancé l’exécution, pour voir des erreurs, savoir si cela a fonctionné, … Vous pouvez à nouveau réaliser un clic droit et cliquer sur « Voir le tableau de bord ». Vous accédez alors à l’interface web vous indiquant l’issue du traitement et les éventuelles erreurs.

Capture d’écran 2015-04-20 à 14.16.02

D’autres usages des Azure Webjobs ?
Les event receivers ont été remplacé dans SharePoint Online par les Remote Event Receivers ; qui semblent être compliqués à utiliser et assez peu fiables. Les Azure Webjobs continus sont donc vraisemblablement une solution à ces problèmes, en tout cas pour remplacer les Event Receivers asynchrones.

Pour le pricing (modeste) : http://azure.microsoft.com/fr-fr/pricing/details/scheduler/

Bonne journée !

yOS Tour : une façon innovante de s’informer sur les technos cloud de Microsoft

Bonjour à tous,

Aujourd’hui, le sujet ne sera pas technique, mais plutôt orienté « promo » ; on ne va pas se cacher.

Je souhaite vous parler du yOS Tour, une succession de journées, au cours de l’année, à travers les pays francophones, dédiées à Yammer, Office 365, SharePoint et les technologies cloud Microsoft de manière générale, dont Azure fait partie.

yos-tour-N

C’est Patrick Guimmonet et Yoan Topenot, tous deux MVPs Office 365, qui m’ont présenté ce projet. Il s’agit de proposer une alternative aux évènements habituels de la communauté Microsoft.

L’alternative se caractérise tout d’abord par le format des sessions : elles sont dynamiques, au nombre de huit. Finies les sessions d’une heure et demi, on passe sur cinquante minutes, avec souvent, deux speakers.
On notera également le fait que, même si les yOS Days sont sponsorisés, les sponsors en question ne réalisent pas  de présentation technico-commerciale de leurs outils. Ce sont des consultants, des développeurs, des MVPs, des « teks » qui vous présentent les produits de Microsoft. Ils le font au travers de leur expérience technique et fonctionnelle : retours d’expériences, best pratices, …
Au titre des nouveautés : la plénière de quatrevingt-dix minutes est réalisée en fin d’après-midi, après les sessions, par un intervenant étranger au pays organisateur, afin d’offrir un point de vue sensiblement différent ; et éclairé par les sessions de la journée.
Enfin, une table ronde entre quatre interlocuteurs techniques et les participants est proposée en fin de journée.
Et surtout, le plus important, les repas sont offerts par les sponsors !

2600_AZURE-BAR_REST_LOGO.jpg

Même si tout n’est pas nouveau, le fait de concentrer ces formats inhabituels rend le concept attrayant. Le fait que des utilisateurs (techniques ou fonctionnels) puissent s’adresser à des experts et interagir entre eux, le nombre élevé de sessions, … Tout cela permet un élargissement des thèmes abordés. De plus, le format rend l’organisation assez simplifiée : deux salles d’une trentaine de personne sont suffisantes. Avis aux amateurs qui ont envi de s’investir un peu dans la communauté !

Inutile de dire que j’ai été séduit, et que je me suis donc avancé comme speaker pour certain des yOS Days, et que j’ai proposé de co organiser le yOS Paris à la fin de l’année. Me voilà donc dans le joyeux bateau.

D’ici là, l’actualité est brulante. Yoan Topenot propose le premier yOS Day à Genève, où je serai co-speaker avec Gilles Pommier. Il s’agira d’une session sur les best pratices de migration des Apps dans SharePoint Online. Je ferai notamment un focus sur la migration des timer jobs (grâce aux Azure Web Jobs of course), sujet souvent rencontré en clientèle, mais assez peu dans les événements communautaires. Cette présentation sera reprise sur ce blog dès la fin de la semaine prochaine (pour ceux qui n’auraient pas pu venir).

11046512_1431800717132007_6969127108322213358_o

D’autres dates sont d’ores et déjà confirmées, en plus de Genève dès demain :
– 12 juin à Montpellier
– Fin d’année à Paris
D’autres lieux et dates sont également sur le feu, nous attendons des confirmations !

C’est donc demain le grand lancement, je souhaite à Yoan que tout se passe bien, et je n’en doute pas.

Si vous êtes intéressés par le concept, que vous souhaitez organiser, être speaker, ou tout simplement participer, n’hésitez pas à joindre l’organisation du yOS Tour :
– via le site Internet : http://www.yos-tour.com/
– via FaceBook : https://www.facebook.com/pages/yOS-Tour/1569101103333128
– sur mon Twitter, mon FaceBook, mon LinkedIn, bref, tout est ouvert !

See you on the yOS Tour !