Localisez vos Add In SharePoint !

Bonjour à tous,

Aujourd’hui je souhaite aborder un sujet souvent « remis à plus tard » dans le cadre des projets de développement que j’ai abordé : rendre son code « localizable compatible », et même le localiser.

Pourquoi et qu’entend-t-on par localiser une application ?
Tout simplement la traduire et gérer l’affichage de la bonne langue au bon utilisateur. Avec l’arrivée du store SharePoint et Office, et ma première application publiée, je me suis heurté à ce problème sans penser que cela me prendrait tant de temps de réaliser la traduction, implémenter les bouts de codes qui vont bien pour afficher la traduction, …
Vu que je souhaite que mes apps soient accessibles au plus grand nombre, je les traduis, au moins en anglais pour commencer.

Comment s’y prend-t-on ?
Comme souvent lorsqu’on développe, ça prend moins de temps de bien faire dès le début que de devoir le faire à la fin ^^
Donc, règle numéro une : ne mettez jamais jamais un bout de phrase, voir même un mot de l’UI dans une langue quelconque. Utilisez ce qui est prévu par Microsoft (si vous développez avec les bonnes vieilles techno .Net/C#, et même JS) : les fichiers de ressources.
Pour mes deux premiers add-in, je n’ai pas suivi cette règle, et je m’en suis mordu les doigts.

Si vous suivez un peu, vous savez que les add-in fonctionnent sur deux modèles : SharePoint Hosted et Provider Hosted. Et vous le savez, un add-in Provider Hosted est lui même composé d’une partie SharePoint (qui ressemble à un add-in SharePoint Hosted) et d’une partie réellement Provider Hosted. Vous savez enfin qu’on peut mettre du C# sur les parties Provider Hosted uniquement, mais du JS sur les deux types d’apps. Je ne vous ai même pas encore parlé des fichiers XML … … … … … … Je vous ai perdu…  C’est pourtant la stratégie de Microsoft ^^

Bref, je vous ai fait un petit tableau pour récapituler :

SharePoint Hosted
Add In
Provider hosted Add In
SharePoint Part Provider Part
XML (for SP stuff provisionning) YES YES NO
JS YES YES YES
ASP.Net/HTML Page YES YES YES
C# NO NO YES

Voilà les typologies de fichiers qu’on peut rencontrer dans des Add In, et à quels endroits.

Pour chacun de ces types de fichiers, vous allez trouver des éléments qui vont influer sur l’interface utilisateurs et notamment des textes, à mettre en plusieurs langues.
Le petit « plus Microsoft », c’est qu’en fonction du type de fichier dans lequel vous allez vouloir appeler votre texte, vous allez devoir vous y prendre (radicalement) différement.

Par exemple, pour nommer une liste, une bibliothèque ou une custom action, cela se fait via un fichier ressource .resx. Par contre, si vous souhaitez écrire du texte dans une page .aspx Add In SharePoint Hosted, cela se fait en JavasSript… Comme je ne veux pas à nouveau vous perdre, j’ai également fait un tableau :

SharePoint Hosted Add In Provider hosted Add In
SharePoint Part Provider Part
XML (for SP stuff provisionning) .resx file .resx file NO
JS .js file .js file .resx file
ASP.Net/HTML Page .js file .js file .resx file / .js file
C# / Other NO NO .resx file / other

How to ?
Cela dépend dans quelle case vous vous trouvez.
Pour la partie SharePoint Hosted et SharePoint Part, vous trouverez votre bonheur ici https://msdn.microsoft.com/fr-fr/library/office/FP179919.aspx

Pour la partie Provider Part, le lien ci-dessus ne donne que peu d’information. Il s’agit de « Localiser les composants distants dans une application pour SharePoint »…
Pour ma part, n’étant pas un pur développeur .Net, je tâtonne un tout petit peu sur cette partie, mais je vais trouver dans les jours qui viennent et ne manquerai pas de vous tenir au courant.

Quand même un petit « truc » qui m’a fait perdre pas mal de temps. Microsoft vous propose de charger la culture de SharePoint au moment du chargement de la page. La culture est passée (comme tout ce qui vient de SharePoint) en paramètre de l’URL.

Au PostBack, de manière automatique, le paramètre est doublé : de « fr-FR », il devient « fr-FR,fr-FR ». Les experts du .Net pourront surement nous expliquer ça. Mais le serveur n’aime pas beaucoup, du coup il faut faire un peu de ménage et passer de :

protected override void InitializeCulture()
{
    if (Request.QueryString["SPLanguage"] != null)
    {
        string selectedLanguage = Request.QueryString["SPLanguage"];
        
        // Override the page language.
        UICulture = selectedLanguage;
        Culture = selectedLanguage;

        // Reset the thread language.
        Thread.CurrentThread.CurrentCulture =
            CultureInfo.CreateSpecificCulture(selectedLanguage);
        Thread.CurrentThread.CurrentUICulture = new
            CultureInfo(selectedLanguage);
    }
    base.InitializeCulture();
}

à ça :

protected override void InitializeCulture()  
     {  
       if (Request.QueryString["SPLanguage"] != null)  
       {  
         string selectedLanguage = Request.QueryString["SPLanguage"];  
   
         if (selectedLanguage.Contains(","))  
         {  
           selectedLanguage = selectedLanguage.Split(',')[0];  
         }  
   
         // Override the page language.  
         UICulture = selectedLanguage;  
         Culture = selectedLanguage;  
   
         // Reset the thread language.  
         Thread.CurrentThread.CurrentCulture =  
           CultureInfo.CreateSpecificCulture(selectedLanguage);  
         Thread.CurrentThread.CurrentUICulture = new  
           CultureInfo(selectedLanguage);  
       }  
       base.InitializeCulture();  
     }  

D’ici là, n’hésitez pas si vous avez des questions !

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 !