Accueil Nos publications Blog Nouveautés sur Windows Azure Mobile Services

Nouveautés sur Windows Azure Mobile Services

Lors d’un précédent article qui vous présentait Windows Azure Mobile Service, nous avions vu que ce service était disponible en preview fin août, et je vous en avais fait un tour d’horizon de ses fonctionnalités.

Pour résumer, il fournit facilement et rapidement un système de CRUD simplifié au sein d’Azure, ainsi que des capacités d’authentification au sein de vos applications, et la possibilité d’envoyer des notifications à vos utilisateurs.

Je vais donc vous présenter dans cet article les nouveautés qu’a annoncé Microsoft sur le sujet.

Gestion de plusieurs modules d’identification

La dernière fois je vous avais montré la manière de s’authentifier avec un compte de type Microsoft Account, (ou Live), et je suppose que comme moi vous étiez déçus de vous en contenter. Et bien, sachez que maintenant c’est fini ! Il est possible de choisir entre Facebook, Google, Twitter, et bien entendu Microsoft Account.

Pour cela, il faut vous rendre sur le provider d’identification que vous souhaitez, et configurer une nouvelle application afin d’obtenir une combinaison de AppId / AppSecret. Afin de créer ces applications, il vous faut aller sur ces différents portails :

Le processus par la suite est assez simple, il suffit de créer un compte, et de récupérer les clés afin de les mettre dans la partie Identité de votre application Mobile Service, afin d’obtenir quelque chose similaire à ce que vous pouvez retrouver ci-contre.

Au niveau du code, c’est encore plus simple : vous n’avez plus besoin d’utiliser des SDK, tel que le Live SDK, ou Facebook SDK, il vous suffit de définir le provider que vous souhaitez utiliser et notre service s’occupe de la mécanique de traitement.
Pour résumer, pour pouvoir utiliser un provider spécifique, vous n’avez qu’à ajouter cette ligne :


        MobileServiceAuthenticationProvider provider = MobileServiceAuthenticationProvider.Facebook;
        MobileServiceUser user = await _serviceClient.LoginAsync(provider);
        

L’avantage de plus, c’est qu’il se charge de l’ouverture de la popup et de la partie connexion afin de ne vous renvoyer qu’un utilisateur qui se définit par le type de provider et l’identifiant de l’utilisateur.
Pour ce qui concerne l’authentification, il est à noter que ce n’est pas Access Control Service qui s’en occupe, donc vous ne pouvez pour l’instant ajouter vos propres modules d’identification. En espérant que Microsoft le permette dans une prochaine mise à jour.

Stocker vos données dans le Table Storage

Dans la première version, nous étions obligés d’utiliser SQL Azure pour stocker nos données. Pour ma part, j’utilise énormément le Table Storage car pour moi, une approche NoSQL correspond plus à un système scalable.
Pour utiliser le Table Storage, il faut cependant grandement modifier vos scripts côté Node.js afin qu’ils utilisent le Table Storage à la place de SQL Azure.

Afin de vous donner un aperçu, voici le script d’insertion :


        var azure = require('azure');
        var tableService = azure.createTableService("MyAccountName", "MyAccountKey");

        function insert(item, user, request) {
        console.log(item);
        tableService.createTableIfNotExists('Messages', function(error) {
        console.log(error);
        if (!error) {
        // Table exists or created

        var message = {
        PartitionKey : 'Messages',
        RowKey : item.myid,
        Message : item.message,
        CreationDate : new Date()
};

        tableService.insertEntity('Messages', message, function(error) {
        console.log(error);
        if (!error){
        // Entity inserted
request.respond(200);
}
       });
        }
        });
        

Alors, pour traduire, on dit que notre script requiert Azure pour fonctionner, puis on référence le table storage que l’on souhaite utiliser.

Ensuite lors du script, il nous suffit de créer notre table, et d’y ajouter nos entités. Il est important de noter, qu’il faut que notre service réponde, car là par exemple dans ce script, s’il y a un échec, premièrement je ne sais pas pourquoi, et deuxièmement, au niveau de mon application Windows 8, je vais avoir un timeout au niveau de mon appel.

Maintenant, passons à la récupération de nos messages, puisqu’effectivement nous ne les avons plus dans SQL Azure, mais dans le Table Storage, il faut donc que nous modifions aussi le script associé, cela nous donne donc ceci :


        var azure = require('azure');
        var tableService = azure.createTableService("MyAccountName", "MyAccountKey");

        function read(query, user, request) {
        tableService.createTableIfNotExists('Messages', function(error) {
        console.log(error);
        if (!error) {
        // Table exists or created
        var query = azure.TableQuery
        .select()
        .from('Messages');
        tableService.queryEntities(query, function(error, entities) {
        if (!error){
        console.log(entities);
        var result = new Array();
        console.log(entities.length);
        for (var i = 0; i < entities.length; i++){
        console.log(i);
        console.log(entities[i]);
        result.push({
        myid : entities[i].RowKey,
        message : entities[i].Message
        });
        }

        console.log(result);
        request.respond(200, result);
        }
        });
        }
        });
        }
        

Ici, je lis donc ma table, sans prendre en compte le champ query fourni par mon application Windows 8, ce qu’il faudrait faire car il contient des filtres. Ensuite je génère un tableau comprenant mes entités Messages, avec le schéma attendu au niveau de mon client, afin de pouvoir les récupérer, et les afficher dans mon application.

On remarquera qu’utiliser le Table Storage avec un service Mobile Service est certes plus fastidieux en terme de développement au niveau serveur, cependant si l’on connait bien la partie Table Storage cela peut engendrer un gain de performance non négligeable.

A noter que lorsqu’on utilise ce type de stockage, nous ne pouvons voir depuis le portail les différentes entités présentes dans notre base, il nous faut un logiciel tierce, ou Visual Studio avec le SDK Windows Azure installé.

Envoi d’email depuis Azure

Il est dorénavant possible d’envoyer des emails depuis Windows Azure Mobile Service, cependant la plateforme de Microsoft n’est pas dotée d’une plateforme d’envoi de mail, il faut passer par un prestataire tierce. Il conseille pour cela le service SendGrid qui permet d’envoyer des emails au format HTML.

Il vous faut donc utiliser ce code afin d’envoyer un email :


        var SendGrid = require('sendgrid').SendGrid;
        var sendgrid = new SendGrid('user', 'key');
        sendgrid.send({
        to: 'example@example.com',
        from: 'other@example.com',
        subject: 'Hello World',
        text: 'My first email through SendGrid'
        }, function(success, message) {
        if (!success) {
        console.log(message);
        }
        });
        

A noter que SendGrid est un prestataire payant, et donc que l’envoi de mail est à rajouter dans la facturation finale. Cependant, on va utiliser les mêmes principes que pour la gestion du Table Storage, nous allons inclure un nouveau module dans notre Node.js, et l’utiliser selon nos besoins.

De plus, SendGrid a une documentation très complète pour l’utiliser avec Node.js, ce qui est un plus si vous voulez utiliser cette fonctionnalité.

Envoi de SMS depuis Windows Azure Mobile Service

Il est aussi possible d’envoyer des SMS depuis Windows Azure, cependant au même titre que pour les mails il faut passer par un prestataire externe, cette fois-ci il s’agit de Twilio.

Au niveau du code, on a donc ceci :


        var httpRequest = require('request');
        var account_sid = "<< account SID >>";
        var auth_token = "<< auth token >>";

        // Create the request body
        var body = "From=" + from + "&To=" + to + "&Body=" + message;

        // Make the HTTP request to Twilio
        httpRequest.post({
        url: "https://" + account_sid + ":" + auth_token +
        "@api.twilio.com/2010-04-01/Accounts/" + account_sid + "/SMS/Messages.json",
        headers: { 'content-type': 'application/x-www-form-urlencoded' },
        body: body
        }, function (err, resp, body) {
        console.log(body);
        });
        

On peut remarquer que Twilio n’est pas supporté par Node.js, mais qu’on fait appel à un service Web pour envoyer notre SMS, ce qui ouvre des possibilités infinies puisqu’il est donc possible d’appeler nos propres services Web à partir de Windows Azure Mobile Services.

Support de iOS

Et comme dernière nouveauté, voici le support de iOS pour Windows Azure Mobile Services, n’ayant jamais développé dans ce langage, je vous laisse vous référer à la documentation qui se trouve sur le centre de développement de Windows Azure

Mon avis sur cette nouvelle version

En résumé, je trouve que cette nouvelle version de Windows Azure Mobile Services apporte de la maturité au produit du fait qu’elle permet d’utiliser beaucoup plus les composants d’Azure comme le Table Storage. Et je pense que comme fournisseur d’identité il est à prendre en compte pour les applications Windows 8, car il abstrait totalement les fournisseurs les plus utilisés à ce jour, tout en étant relativement transparent au niveau de l’application.