Guide pratique pour utiliser le kit SDK Node.js pour Azure Mobile Apps

Cet article fournit des informations détaillées ainsi que des exemples qui illustrent comment utiliser un back-end NodeJS pour Azure Mobile Apps.

Présentation

Azure Mobile Apps offre la possibilité d’ajouter une API web d’accès aux données optimisée pour les appareils mobiles à une application web. Le SDK Azure Mobile Apps est fourni pour les applications web Node.js et ASP.NET Framework. Le Kit offre les opérations suivantes :

  • Opérations de table (read, insert, update, delete) pour l’accès aux données
  • Opérations d’API personnalisées

Ces deux types d’opérations fournissent l’authentification sur l’ensemble des fournisseurs d’identité qu’Azure App Service autorise. Ces fournisseurs incluent des fournisseurs d’identité sociale tels que Facebook, Twitter, Google et Microsoft et Microsoft Entra ID pour l’identité d’entreprise.

Plateformes prises en charge

Le SDK Node.js Azure Mobile Apps prend en charge Node 6.x et versions ultérieures, et il a été testé jusqu’à Node 12.x. Les autres versions de Node peuvent fonctionner, mais elles ne sont pas prises en charge.

Le SDK Node.js Azure Mobile Apps prend en charge deux pilotes de base de données :

  • Le pilote node-mssql prend en charge Azure SQL Database et les instances SQL Server locales.
  • Le pilote sqlite3 prend en charge les bases de données SQLite sur une seule instance.

Créer un back-end Node simple à l’aide de la ligne de commande

Chaque back-end Azure Mobile Apps Node.js débute en tant qu’application Express. Express est le framework de service web le plus populaire pour Node.js. Vous pouvez créer une application Express de base de la manière suivante :

  1. Dans une commande ou une fenêtre PowerShell, créez un répertoire pour votre projet :

    $ mkdir basicapp
    
  2. Exécutez npm init pour initialiser la structure du package :

    $ cd basicapp
    $ npm init
    

    La commande npm init pose une série de questions pour initialiser le projet. Consultez l’exemple pour voir le résultat obtenu :

    The npm init output

  3. Installez les bibliothèques express et azure-mobile-apps à partir du référentiel npm :

    npm install --save express azure-mobile-apps
    
  4. Créez un fichier app.js pour implémenter le serveur mobile de base :

    var express = require('express'),
        azureMobileApps = require('azure-mobile-apps');
    
    var app = express(),
        mobile = azureMobileApps();
    
    // Define a TodoItem table.
    mobile.tables.add('TodoItem');
    
    // Add the Mobile API so it is accessible as a Web API.
    app.use(mobile);
    
    // Start listening on HTTP.
    app.listen(process.env.PORT || 3000);
    

Cette application crée une API Web optimisée pour les applications mobiles avec un seul point de terminaison (/tables/TodoItem) qui fournit un accès non authentifié à un magasin de données SQL sous-jacent à l’aide d’un schéma dynamique. Cette API est adaptée pour les démarrages rapides de bibliothèques de client suivants :

Vous trouverez le code pour cette application de base dans la zone d’exemples sur GitHub.

Activer une page d’accueil pour votre application

De nombreuses applications sont une combinaison d’applications Web et mobiles. Vous pouvez utiliser le framework Express pour combiner les deux facettes. Néanmoins, il peut être parfois préférable d’implémenter uniquement une interface mobile. Il est utile de fournir une page d’accueil pour obtenir la garantie que le service d’application fonctionne correctement. Vous pouvez soit fournir votre propre page d’accueil, soit activer une page d’accueil temporaire. Pour activer une page d’accueil temporaire, utilisez le code suivant pour instancier Azure Mobile Apps :

var mobile = azureMobileApps({ homePage: true });

Si vous voulez que cette option soit disponible uniquement pour un développement local, vous pouvez ajouter ce paramètre au fichier de configuration azureMobile.js :

module.exports = {
    homePage: true,
};

Vous pouvez ajouter d’autres paramètres au fichier azureMobile.js, en fonction des besoins.

Opérations de tables

Le kit SDK Node.js Server azure-mobile-apps fournit des mécanismes permettant d’exposer les tables de données stockées dans Azure SQL Database sous la forme d’une API Web. Il fournit cinq opérations :

Operation Description
GET /tables/tablename Extraire tous les enregistrements de la table.
GET /tables/tablename/:id Extraire un enregistrement spécifique de la table.
POST /tables/tablename Créer un enregistrement dans la table.
PATCH /tables/tablename/:id Mettre à jour un enregistrement dans la table.
DELETE /tables/tablename/:id Supprimer un enregistrement de la table.

Cette API web prend en charge OData v3 et étend le schéma de table pour prendre en charge la synchronisation des données hors connexion.

Définir des tables à l’aide d’un schéma dynamique

Avant de pouvoir utiliser une table, vous devez la définir. Vous pouvez définir les tables avec un schéma statique (dans lequel vous définissez les colonnes du schéma) ou dynamique (dans lequel le Kit de développement logiciel (SDK) contrôle le schéma en fonction des demandes entrantes). En outre, vous pouvez contrôler des aspects spécifiques de l’API Web en ajoutant du code Javascript à la définition.

Il est recommandé de définir chaque table dans un fichier Javascript du répertoire tables, puis d’utiliser la méthode tables.import() pour importer les tables. En étendant l’exemple d’application de base, vous pourrez ajuster le fichier app.js :

var express = require('express'),
    azureMobileApps = require('azure-mobile-apps');

var app = express(),
    mobile = azureMobileApps();

// Define the database schema that is exposed.
mobile.tables.import('./tables');

// Provide initialization of any tables that are statically defined.
mobile.tables.initialize().then(function () {
    // Add the Mobile API so it is accessible as a Web API.
    app.use(mobile);

    // Start listening on HTTP.
    app.listen(process.env.PORT || 3000);
});

Définissez la table dans ./tables/TodoItem.js :

var azureMobileApps = require('azure-mobile-apps');

var table = azureMobileApps.table();

// Additional configuration for the table goes here.

module.exports = table;

Par défaut, les tables utilisent un schéma dynamique.

Définir des tables à l’aide d’un schéma statique

Vous pouvez définir explicitement les colonnes à exposer via l’API Web. Le Kit de développement logiciel (SDK) Node.js azure-mobile-apps ajoute automatiquement à la liste que vous fournissez toutes les colonnes supplémentaires requises pour la synchronisation des données hors connexion. Par exemple, les applications clientes de démarrage rapide requièrent une table à deux colonnes : une colonne text (une chaîne) et une colonne complete (une valeur booléenne). Vous pouvez définir ces colonnes dans le fichier JavaScript de définition de table (situé dans le répertoire tables) comme suit :

var azureMobileApps = require('azure-mobile-apps');

var table = azureMobileApps.table();

// Define the columns within the table.
table.columns = {
    "text": "string",
    "complete": "boolean"
};

// Turn off the dynamic schema.
table.dynamicSchema = false;

module.exports = table;

Si vous définissez des tables de manière statique, vous devez également appeler la méthode tables.initialize() pour créer le schéma de base de données au démarrage. La méthode tables.initialize() renvoie un objet promise qui permet de s’assurer que le service web ne traite pas les requêtes avant l’initialisation de la base de données.

Utiliser SQL Server Express comme magasin de données de développement sur votre ordinateur local

Le SDK Node.js Azure Mobile Apps fournit trois options pour traiter immédiatement des données :

  • Utilisez le pilote memory pour fournir un exemple de magasin non persistant.
  • Utilisez le pilote mssql pour fournir un magasin de données SQL Express utilisé pour le développement.
  • Utilisez le pilote mssql pour fournir un magasin de données Azure SQL Database utilisé pour la production.

Le SDK Node.js Azure Mobile Apps utilise le package mssql Node.js pour établir et utiliser une connexion à SQL Server Express et à SQL Database. Ce package nécessite l’activation de connexions TCP sur votre instance SQL Server Express.

Conseil

Le pilote memory ne fournit pas un ensemble complet de fonctionnalités à des fins de test. Si vous souhaitez tester localement votre serveur principal, nous vous recommandons d’utiliser un magasin de données SQL Server Express et le pilote mssql.

  1. Téléchargez et installez Microsoft SQL Server 2019 Developer.

  2. Exécutez le Gestionnaire de configuration :

    • Développez le nœud Configuration du réseau SQL Server dans le menu de l’arborescence.
    • Sélectionnez Protocoles pour nom_instance.
    • Cliquez avec le bouton droit sur TCP/IP, puis sélectionnez Enable. Sélectionnez OK dans la boîte de dialogue contextuelle.
    • Sélectionnez SQL Server Services dans le menu de l’arborescence.
    • Cliquez avec le bouton droit sur SQL Server (nom_instance) et sélectionnez Redémarrer.
    • Fermez le Gestionnaire de configuration.

Vous devez également créer un nom d’utilisateur et un mot de passe qu’Azure Mobile Apps peut utiliser pour se connecter à la base de données. Vérifiez que l’utilisateur que vous créez détient le rôle serveur dbcreator. Pour plus d’informations sur la configuration des utilisateurs, consultez la documentation SQL Server.

Veillez à enregistrer les nom d’utilisateur et mot de passe que vous avez sélectionnés. Vous devrez peut-être affecter des rôles serveur ou autorisations supplémentaires, en fonction des besoins de votre base de données.

L’application Node.js lit la variable d’environnement SQLCONNSTR_MS_TableConnectionString pour la chaîne de connexion de cette base de données. Vous pouvez définir cette variable dans votre environnement. Par exemple, vous pouvez utiliser PowerShell pour définir cette variable d’environnement :

$env:SQLCONNSTR_MS_TableConnectionString = "Server=127.0.0.1; Database=mytestdatabase; User Id=azuremobile; Password=T3stPa55word;"

Accédez à la base de données via une connexion TCP/IP. Fournissez un nom d’utilisateur et un mot de passe pour la connexion.

Configurer votre projet pour un développement local

Azure Mobile Apps lit un fichier JavaScript appelé azureMobile.js à partir du système de fichiers local. N’utilisez pas ce fichier pour configurer le SDK Azure Mobile Apps en production. Utilisez plutôt Paramètres de l’application dans le portail Azure.

Le fichier azureMobile.js doit exporter un objet de configuration. Les paramètres les plus courants sont les suivants :

  • Paramètres de base de données
  • Paramètres de journalisation des diagnostics
  • Paramètres CORS de remplacement

Cet exemple de fichier azureMobile.js implémente les paramètres de base de données précédents :

module.exports = {
    cors: {
        origins: [ 'localhost' ]
    },
    data: {
        provider: 'mssql',
        server: '127.0.0.1',
        database: 'mytestdatabase',
        user: 'azuremobile',
        password: 'T3stPa55word'
    },
    logging: {
        level: 'verbose'
    }
};

Nous vous recommandons d’ajouter azureMobile.js à votre fichier .gitignore (ou un autre fichier ignore de contrôle du code source) pour éviter que les mots de passe soient stockés dans le cloud.

Configurer des paramètres d’application pour votre application mobile

La plupart des paramètres du fichier azureMobile.js ont un paramètre d’application équivalent dans le portail Azure. Utilisez la liste suivante pour configurer votre application dans Paramètres de l’application :

Paramètre d’application Paramètre azureMobile.js Description Valeurs valides
MS_MobileAppName name Le nom de l’application string
MS_MobileLoggingLevel logging.level Niveau minimal de journal pour les messages à consigner error, warning, info, verbose, debug, silly
MS_DebugMode debug Active ou désactive le mode de débogage true, false
MS_TableSchema data.schema Nom de schéma par défaut pour les tables SQL string (valeur par défaut : dbo)
MS_DynamicSchema data.dynamicSchema Active ou désactive le mode de débogage true, false
MS_DisableVersionHeader version (sur Undefined) Désactive l'en-tête X-ZUMO-Server-Version true, false
MS_SkipVersionCheck skipversioncheck Désactive la vérification de la version de l’API client true, false

La modification de la plupart des paramètres requiert le redémarrage du service.

Utiliser Azure SQL en tant que magasin de données de production

L’utilisation d’Azure SQL Database en tant que datastore est identique pour tous les types d’applications Azure App Service. Si ce n’est déjà fait, suivez ces étapes pour créer un back-end Azure App Service. Créez une instance d’Azure SQL, puis définissez le paramètre d’application SQLCONNSTR_MS_TableConnectionString sur la chaîne de connexion de l’instance d’Azure SQL que vous souhaitez utiliser. Vérifiez que l’Azure App Service qui exécute votre back-end peut communiquer avec votre instance d’Azure SQL.

Exiger une authentification pour l’accès aux tables

Si vous souhaitez utiliser l’authentification App Service avec le point de terminaison tables, vous devez d’abord configurer l’authentification App Service dans le portail Azure. Pour plus d’informations, consultez le guide de configuration correspondant au fournisseur d’identité que vous souhaitez utiliser :

Chaque table possède une propriété d’accès que vous pouvez utiliser pour contrôler l’accès à la table. L’exemple suivant illustre une table définie de façon statique avec l’authentification requise.

var azureMobileApps = require('azure-mobile-apps');

var table = azureMobileApps.table();

// Define the columns within the table.
table.columns = {
    "text": "string",
    "complete": "boolean"
};

// Turn off the dynamic schema.
table.dynamicSchema = false;

// Require authentication to access the table.
table.access = 'authenticated';

module.exports = table;

La propriété d’accès peut prendre trois valeurs :

  • anonymous indique que l’application cliente est autorisée à lire les données sans authentification.
  • authenticated indique que l’application cliente doit envoyer un jeton d’authentification valide avec la requête.
  • disabled indique que cette table est actuellement désactivée.

Si la propriété d’accès n’est pas définie, l’accès non authentifié est autorisé.

Utiliser des revendications d’authentification avec vos tables

Vous pouvez configurer différentes revendications qui sont demandées lors de la configuration de l'authentification. Ces revendications ne sont normalement pas disponibles via l’objet context.user . Toutefois, vous pouvez les récupérer à l’aide de la méthode context.user.getIdentity(). La méthode getIdentity() renvoie une promesse qui correspond à un objet. L’objet est indexé par la méthode d’authentification (facebook, google, twitter, microsoftaccount ou aad).

Remarque

Si vous utilisez l’authentification Microsoft via l’ID Microsoft Entra, la méthode d’authentification n’est aadpas microsoftaccount.

Par exemple, si vous configurez l’authentification Microsoft Entra et demandez la revendication d’adresses e-mail, vous pouvez ajouter l’adresse e-mail à l’enregistrement avec le contrôleur de tableau suivant :

var azureMobileApps = require('azure-mobile-apps');

// Create a new table definition.
var table = azureMobileApps.table();

table.columns = {
    "emailAddress": "string",
    "text": "string",
    "complete": "boolean"
};
table.dynamicSchema = false;
table.access = 'authenticated';

/**
* Limit the context query to those records with the authenticated user email address
* @param {Context} context the operation context
* @returns {Promise} context execution Promise
*/
function queryContextForEmail(context) {
    return context.user.getIdentity().then((data) => {
        context.query.where({ emailAddress: data.aad.claims.emailaddress });
        return context.execute();
    });
}

/**
* Adds the email address from the claims to the context item - used for
* insert operations
* @param {Context} context the operation context
* @returns {Promise} context execution Promise
*/
function addEmailToContext(context) {
    return context.user.getIdentity().then((data) => {
        context.item.emailAddress = data.aad.claims.emailaddress;
        return context.execute();
    });
}

// Configure specific code when the client does a request.
// READ: only return records that belong to the authenticated user.
table.read(queryContextForEmail);

// CREATE: add or overwrite the userId based on the authenticated user.
table.insert(addEmailToContext);

// UPDATE: only allow updating of records that belong to the authenticated user.
table.update(queryContextForEmail);

// DELETE: only allow deletion of records that belong to the authenticated user.
table.delete(queryContextForEmail);

module.exports = table;

Pour voir les revendications disponibles, utilisez un navigateur web pour afficher le point de terminaison /.auth/me de votre site.

Désactiver l’accès à des opérations de table spécifiques

En plus d’apparaître sur la table, la propriété d’accès peut être utilisée pour contrôler des opérations spécifiques. Il existe quatre opérations :

  • read est l’opération GET RESTful sur la table.
  • insert est l’opération POST RESTful sur la table.
  • update est l’opération PATCH RESTful sur la table.
  • delete est l’opération DELETE RESTful sur la table.

Vous pouvez, par exemple, souhaiter fournir une table non authentifiée en lecture seule :

var azureMobileApps = require('azure-mobile-apps');

var table = azureMobileApps.table();

// Read-only table. Only allow READ operations.
table.read.access = 'anonymous';
table.insert.access = 'disabled';
table.update.access = 'disabled';
table.delete.access = 'disabled';

module.exports = table;

Ajuster la requête utilisée avec les opérations de table

On attend souvent des opérations de table qu’elles soient capables de fournir une vue restreinte des données. Par exemple, vous pouvez fournir une table marquée avec l’ID de l’utilisateur authentifié, vous permettant uniquement de lire ou de mettre à jour vos propres enregistrements. La définition de table suivante offre cette fonctionnalité :

var azureMobileApps = require('azure-mobile-apps');

var table = azureMobileApps.table();

// Define a static schema for the table.
table.columns = {
    "userId": "string",
    "text": "string",
    "complete": "boolean"
};
table.dynamicSchema = false;

// Require authentication for this table.
table.access = 'authenticated';

// Ensure that only records for the authenticated user are retrieved.
table.read(function (context) {
    context.query.where({ userId: context.user.id });
    return context.execute();
});

// When adding records, add or overwrite the userId with the authenticated user.
table.insert(function (context) {
    context.item.userId = context.user.id;
    return context.execute();
});

module.exports = table;

Les opérations qui exécutent normalement une requête ont une propriété de requête que vous pouvez ajuster avec une clause where. La propriété de requête est un objet QueryJS utilisé pour convertir une requête OData en un élément que le serveur principal pourra traiter. Pour les cas d’égalité simple (comme dans l’exemple précédent), vous pouvez utiliser un mappage. Vous pouvez également ajouter des clauses SQL spécifiques :

context.query.where('myfield eq ?', 'value');

Configurer une suppression réversible sur une table

Une suppression réversible ne supprime pas réellement les enregistrements. Elle les marque comme étant supprimés dans la base de données en définissant la colonne supprimée sur true. Le SDK Azure Mobile Apps supprime automatiquement des résultats les enregistrements supprimés de manière réversible, sauf si le SDK Mobile Client utilise includeDeleted(). Pour configurer une table pour une suppression réversible, définissez la propriété softDelete dans le fichier de définition de table :

var azureMobileApps = require('azure-mobile-apps');

var table = azureMobileApps.table();

// Define the columns within the table.
table.columns = {
    "text": "string",
    "complete": "boolean"
};

// Turn off the dynamic schema.
table.dynamicSchema = false;

// Turn on soft delete.
table.softDelete = true;

// Require authentication to access the table.
table.access = 'authenticated';

module.exports = table;

Établissez un mécanisme pour supprimer définitivement les enregistrements tels qu’une application cliente, un WebJob, une fonction Azure ou une API personnalisée.

Alimenter votre base de données

Lorsque vous créez une application, vous souhaiterez sans doute alimenter une table avec des données. Vous pouvez amorcer les données dans le fichier JavaScript de définition de table comme suit :

var azureMobileApps = require('azure-mobile-apps');

var table = azureMobileApps.table();

// Define the columns within the table.
table.columns = {
    "text": "string",
    "complete": "boolean"
};
table.seed = [
    { text: 'Example 1', complete: false },
    { text: 'Example 2', complete: true }
];

// Turn off the dynamic schema.
table.dynamicSchema = false;

// Require authentication to access the table.
table.access = 'authenticated';

module.exports = table;

L’amorçage des données se produit uniquement lorsque vous avez utilisé le SDK Azure Mobile Apps pour créer la table. Si la table existe déjà dans la base de données, aucune donnée ne sera injectée dans la table. Si le schéma dynamique est activé, alors le schéma est déduit des données alimentées.

Nous vous recommandons d’appeler explicitement la méthode tables.initialize() pour créer la table au début de l’exécution du service.

Activer la prise en charge de Swagger

Azure Mobile Apps offre une prise en charge intégrée de Swagger. Pour activer la prise en charge de Swagger, commencez par installer l’interface utilisateur Swagger en tant que dépendance :

npm install --save swagger-ui

Vous pouvez ensuite activer la prise en charge de Swagger dans le constructeur Azure Mobile Apps :

var mobile = azureMobileApps({ swagger: true });

Vous préférerez probablement activer la prise en charge de Swagger uniquement dans les éditions de développement. Vous pouvez activer la prise en charge de Swagger lors du développement à l’aide du paramètre d’application NODE_ENV :

var mobile = azureMobileApps({ swagger: process.env.NODE_ENV !== 'production' });

Le point de terminaison swagger se trouve à l’adresse http://VotreSite.azurewebsites.net/swagger. Vous pouvez accéder à l’interface utilisateur Swagger via le point de terminaison /swagger/ui. Si vous décidez de demander une authentification sur l’ensemble de votre application, Swagger génère une erreur. Pour obtenir de meilleurs résultats, autorisez les requêtes non authentifiées via les paramètres d’authentification et d’autorisation d’Azure App Service. Vous pouvez ensuite contrôler l’authentification en utilisant la propriété table.access.

Vous pouvez également ajouter l’option Swagger à votre fichier azureMobile.js si vous voulez activer la prise en charge de Swagger uniquement dans le cadre du développement local.

API personnalisées

Outre l’API d’accès aux données via le point de terminaison /tables, Azure Mobile Apps peut fournir une couverture d’API personnalisée. Les API personnalisées sont définies de manière similaire aux définitions de table et sont accessibles à toutes les mêmes fonctionnalités, y compris l’authentification.

Définir une API personnalisée

La définition des API personnalisées est largement similaire à celle des API de tables :

  1. Créez un répertoire api.
  2. Créez un fichier JavaScript de définition d’API dans le répertoire api.
  3. Utilisez la méthode import pour importer le répertoire api.

Voici le prototype de définition d’API dérivé de l’exemple d’application de base utilisé précédemment :

var express = require('express'),
    azureMobileApps = require('azure-mobile-apps');

var app = express(),
    mobile = azureMobileApps();

// Import the custom API.
mobile.api.import('./api');

// Add the Mobile API so it is accessible as a Web API.
app.use(mobile);

// Start listening on HTTP
app.listen(process.env.PORT || 3000);

Prenons un exemple d’API qui renvoie la date du serveur à l’aide de la méthode Date.now(). Voici le fichier api/date.js :

var api = {
    get: function (req, res, next) {
        var date = { currentTime: Date.now() };
        res.status(200).type('application/json').send(date);
    });
};

module.exports = api;

Chaque paramètre correspond à l’un des verbes RESTful standard : GET, POST, PATCH ou DELETE. La méthode est une fonction ExpressJS middleware standard qui envoie la sortie requise.

Exiger une authentification pour l’accès à une API personnalisée

Le SDK Azure Mobile Apps implémente l’authentification de la même façon pour le point de terminaison tables et pour les API personnalisées. Pour ajouter l’authentification à l’API développée dans la section précédente, ajoutez une propriété access :

var api = {
    get: function (req, res, next) {
        var date = { currentTime: Date.now() };
        res.status(200).type('application/json').send(date);
    });
};
// All methods must be authenticated.
api.access = 'authenticated';

module.exports = api;

Vous pouvez également spécifier l’authentification sur des opérations spécifiques :

var api = {
    get: function (req, res, next) {
        var date = { currentTime: Date.now() };
        res.status(200).type('application/json').send(date);
    }
};
// The GET methods must be authenticated.
api.get.access = 'authenticated';

module.exports = api;

Pour les API personnalisées qui requièrent une authentification, vous devez utiliser le même jeton que celui utilisé pour le point de terminaison tables.

Gérer des chargements de fichiers volumineux

Le SDK Azure Mobile Apps utilise l’intergiciel body-parser pour accepter et décoder le contenu du corps de votre requête. Vous pouvez préconfigurer body-parser pour accepter les chargements de fichiers plus volumineux :

var express = require('express'),
    bodyParser = require('body-parser'),
    azureMobileApps = require('azure-mobile-apps');

var app = express(),
    mobile = azureMobileApps();

// Set up large body content handling.
app.use(bodyParser.json({ limit: '50mb' }));
app.use(bodyParser.urlencoded({ limit: '50mb', extended: true }));

// Import the custom API.
mobile.api.import('./api');

// Add the Mobile API so it is accessible as a Web API.
app.use(mobile);

// Start listening on HTTP.
app.listen(process.env.PORT || 3000);

Le fichier est codé en base 64 avant la transmission. Cet encodage augmente la taille du chargement réel (ainsi que la taille dont vous devez tenir compte).

Exécuter des instructions SQL personnalisées

Le SDK Azure Mobile Apps autorise l’accès à l’ensemble du contexte par le biais de l’objet de requête. Vous pouvez facilement exécuter des instructions SQL paramétrées pour le fournisseur de données défini :

var api = {
    get: function (request, response, next) {
        // Check for parameters. If not there, pass on to a later API call.
        if (typeof request.params.completed === 'undefined')
            return next();

        // Define the query. Anything that the mssql
        // driver can handle is allowed.
        var query = {
            sql: 'UPDATE TodoItem SET complete=@completed',
            parameters: [{
                completed: request.params.completed
            }]
        };

        // Execute the query. The context for Azure Mobile Apps is available through
        // request.azureMobile. The data object contains the configured data provider.
        request.azureMobile.data.execute(query)
        .then(function (results) {
            response.json(results);
        });
    }
};

api.get.access = 'authenticated';
module.exports = api;

Débogage

Déboguer, diagnostiquer et résoudre les problèmes liés à Azure Mobile Apps

Azure App Service fournit plusieurs techniques de débogage et de résolution des problèmes pour les applications Node.js. Pour bien démarrer avec la résolution des problèmes liés à votre back-end Node.js Azure Mobile Apps, consultez les articles suivants :

Les applications Node.js ont accès à un large éventail d’outils de journaux de diagnostic. En interne, le SDK Node.js Azure Mobile Apps utilise [Winston] pour la journalisation des diagnostics. La journalisation est activée automatiquement lorsque vous activez le mode de débogage ou affectez la valeur true au paramètre d’application MS_DebugMode dans le portail Azure. Les journaux d’activité générés s’affichent dans les journaux de diagnostic sur le portail Azure.