Du développement d’add in Office 365/SPOL avec Azure

Bonjour à tous,

Dans le cadre de mes projets actuels, je suis de plus en plus amené à réaliser des Add In pour Office 365 (ou anciennement « Apps »). Cet état de fait est lié à différentes choses :
– Microsoft pousse en avant ce modèle, et sous-entend qu’il sera, à terme, le seul modèle de développement viable sur SharePoint.
– Privilégiant les clients sur Office 365 / Azure PaaS, mes projets On Premise se font de plus en plus rares.
– L’année 2016 sera l’année du Store de Microsoft Office (Word, Excel, …). Nous sommes clairement incentivés par Microsoft, via notamment la mise à disposition de ressources diverses, à développer pour Office.

Comme vous le savez surement, les capacités d’Office 365 en terme d’exécution de code côté serveur sont inexistantes, et ce pour des raisons de sécurité. Microsoft a donc mis à disposition un certain nombres d’API permettant d’attaquer de l’extérieur la plateforme SaaS.

Qu’est donc cet « extérieur » ? Pour certain c’est Azure, pour d’autres ce sont des serveurs On Premises sous Windows, pour d’autres c’est même des serveurs sous Linux… La seule réponse à cette question réside dans le choix de Microsoft pour ses APIs ; et ce choix est maintenant complètement acté : tout ce qui sait réaliser une requête REST constitue cet extérieur.

J’aimerai tordre le cou aux idées reçues : en dev, on peut faire 95% de ce qu’on faisait On Premise en Online. J’entends beaucoup trop souvent des gens dire le contraire. Ils disent qu’il est impossible de faire du dev Online, … Ne les écoutez pas, c’est faux. Appelez moi, et je vous le prouverai. Azure offre ce qu’il faut en PaaS, Office 365 ce qu’il faut en SDK, … Il n’y a pas de restrictions.
Ce qui est vrai, en revanche, c’est qu’il est impossible de migrer un dev On Prem dans Online, pour la simple raison que ce n’est pas le même SDK.
Pour le RESTe (petit jeu de mot), il s’agit juste d’une autre façon de développer, à laquelle il convient de se former, de s’adapter, mais ça se fait très bien. En quelques semaines, vous retrouverez vos réflexes de développeurs SharePoint / Office. J’ajouterai enfin que l’API est de plus en plus fournie, et qu’elle supplantera bientôt LARGEMENT ce qui existait en On Premise.

J’ai vu sur la toile des personnes interagir avec Office 365 via des techno complètement inattendues (Python, PHP sur Apache ou Lighttpd, …). Pour ma part, je le fais via Azure. La plateforme fournit des facilités de déploiement via Visual Studio et surtout la possibilité de développer en C#, que j’affectionne tout particulièrement. Microsoft a sorti un SDK pour SharePoint Online (90% de mes devs dans Azure) qui permet d’interagir avec l’API de manière plutôt pratique et sympa. 99% du temps, on ne se rend pas compte que c’est du REST qui permet l’échange entre O365 et son App.

Je vais un peu vite en besogne, et j’ai oublié de préciser qu’il existe un autre SDK, qui a l’immense avantage de pouvoir s’exécuter côté client, et donc d’être hébergé directement dans Office 365 : c’est un kit en Javascript (JSOM pour SharePoint). Avant de vous lancer dans le développement d’un Add In, demandez vous toujours s’il ne serait pas plus intéressant de développer votre App en JSOM.

Pour choisir entre JSOM et C#/autre techos serveur, en fin de compte, la chaine de décision d’un MOA/MOE devrait être la suivante :

J’ai un besoin sur Office 365 …
=> Ça existe en standard (même pour 90% de la couverture fonctionnelle attendue) ?
=> Si non, ça existe sous forme d’une App dans le Store (même pour 90% de la couverture fonctionnelle attendue) ?
=> Si non, peut-on le développer sans technologies serveur (JSOM, …) ?
=> Si non, ok… On va faire du Provider Hosted.

Pourquoi le Provider Hosted doit-il être le dernier choix ?
Parce que c’est la solution la plus longue et la plus couteuse. Elle nécessite de mettre en place de nouvelles plateformes (même si c’est assez rapide dans Azure, mais il faut ensuite payer l’hébergement), de faire intervenir des ressources spécialisées, et donc relativement coûteuse. L’avantage c’est que vous avez la main, vous faites ce que vous voulez avec les données récupérées dans Office 365, et vous les renvoyez via l’API (ou le SDK qui exploite l’API).

Le côté « technique » :
Pour le Provider Hosted, il y a un échange de Token qui permet à votre App de s’authentifier. Vous pouvez également authentifier votre application en saisissant en dur un nom d’utilisateur et un mot de passe dans votre code (je vous le déconseille quand même, sauf dans certain cas, comme pour des tâches planifiées).

Lorsque je parlais de s’adapter, je parlai non seulement d’apprendre les subtilités du nouveau SDK, mais également des nouvelles plateformes. Sur Azure, la mode est au micro service (modèle que je plébiscite d’ailleurs). Ça se manifeste d’ailleurs parfois de manière assez surprenante.

Exemple de situation vécue :
Vous développez tranquillement un Add In SharePoint Provider Hosted, tout va bien… Votre debug en local (VS debug la partie provider sur votre poste, sur un IIS Express) se passe bien et vous en voyez le bout : vous allez publier la partie serveur de votre application sur Azure. Et là, c’est le drame. Plus rien ne marche, vous devez livrer, votre client ne comprend pas pourquoi ça bug sur un écran alors que ça marchait deux minutes avant…
La réponse est dans les Session State qui ne sont pas supportées par Azure, pour des raisons techniques que je détaillerai surement un jour. Comme vos Token sont stockés dans des Session, ben ça marche plus… Dès que vous faites un Postback, tout bug.
Réponse : micro service. Il faut monter une plateforme Redis Cache (ou SQL) pour stocker les objets contenus dans vos Sessions entre les Postback, modifier votre web.config en conséquence
Pour info : j’ai mis en place le Reddis, changé mon web.config mais mes Session se vident quand même au Postback, mais j’ai vu des gens le faire ! J’ai donc stocké mon Token dans un champ hide avec un enableviewstate en attendant ; je ne désespère pas.

Ces cas arrivent souvent au début, mais une fois que vous aurez les bons automatismes, tout roulera !

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s