Implémentation d’une solution fondée sur les Azure App Services : Consommation du service de recherche par une application Web

Voici donc le troisième d’une série d’articles consacrée à l'implémentation d’une solution fondée sur les Azure App Services et qui sera organisée de la façon suivante :
•Solution et choix d’implémentation
•Mise en œuvre d’un service de recherche
•Consommation du service de recherche par une application Web
•Exposition du service de recherche
•Consommation du service de recherche par une application Universelle
•Gestion d’identité
•Code et configuration de l’application

L’objectif est de développer une application Web utilisant directement le service de recherche exposé par Azure Search ainsi que le service Azure Storage.

Description fonctionnelle de l’application Web

Sur le plan fonctionnel, l’application doit permettre de naviguer entre les fonctions Stockage et Recherche.

Stockage

La page « Stockage » doit permettre d’afficher la liste des documents présents dans un container du stockage Azure et d’uploader de nouveaux documents.

Recherche

La page « Recherche » offre la possibilité de saisir une chaîne de caractères pour lancer une requête sur l’ensemble des attributs « searchable » (susceptibles de faire l’objet d’une requête) de l’index d’« Azure Search ».
L’attribut « Compteur » correspond au nombre de demandes de téléchargement du document sélectionné.

Azure Web Apps

L’implémentation de cette application utilise l’une des composantes d’« Azure App Services » : les « Web Apps ».
« Azure Web Apps » est une plateforme entièrement gérée qui permet de générer et rapidement déployer des applications web, en déléguant à Azure la prise en charge de l'infrastructure pour la mise à l'échelle automatique,  la haute disponibilité, l'analyse des performances, l’authentification et les connexions hybrides. « Web Apps » supporte l’utilisation de multiples langages (NET, Java, Node.js, PHP ou Python) et offre des fonctions de contrôle de version, de mise à jour, d'intégration et de déploiement en continu (avec des services comme Visual Studio Online, GitHub, BitBucket,…). La productivité de développement est augmentée par la mise à disposition de modèles d’applications web Open Source et la possibilité de réutiliser les connecteurs « API Apps ». « Web Apps » propose de multiples environnements de déploiement, ce qui facilite la mise en production et permet d’effectuer du test en production. Enfin, « Web Apps » supporte l’exécution tâches à la demande, en continu ou planifiées grâce aux « WebJobs ».

Implémentation de l’Application Web

L’application Web est une simple application MVC qui propose deux contrôleurs, l’un pour accéder au service de recherche « Azure Search », l’autre pour consulter le service « Azure Storage ». La page de recherche utilise jQuery + Ajax pour solliciter l’« action Search » sur le contrôleur. L’action correspondante utilise le SDK .NET pour interroger le service « Azure Search » et relaie le résultat JSON de l’appel vers le code JavaScript de la vue « Index.cshtml ». Le moteur de templates client « underscore.js » analyse alors cette réponse et affiche le résultat sur la page.
« underscore.js » est une librairie JavaScript qui fournit de nombreuses fonctions complémentaires (map, filter, invoke) et quelques accélérateurs comme les templates javascript. Pour la référencer, on peut utiliser le mécanisme « bundles » qui permet de minimiser et de combiner plusieurs fichiers de script et de style en un seul fichier.
Pour ce faire, il suffit de mettre à jour deux fichiers.
• Le premier de ces fichiers est le fichier « BundleConfig.cs ».
• Le second de ces fichiers est le fichier « _Layout.cshtml ». 

La fonction « search » déclaré dans le script « index.js » exploite donc le mécanisme de template inclus dans « underscore.js ». 
  Le comportement par défaut du framework Ajax inclus dans jQuery est de mettre le résultat des requêtes effectuées en cache, si la requête est identique. Dans notre contexte ce fonctionnement par défaut est problématique (entre deux recherches, l’index peut avoir été modifié). Pour désactiver ce comportement, il suffit d’ajouter un paramètre qui modifie la requête à chaque appel (« Math.random() »).
La fonction « search » précédemment présentée interagit avec le script « search-results-template » déclaré dans la vue « index.cshtml ».

On notera la façon de remettre en forme les dates lorsqu’elles sont véhiculées au format JSON.
Pour mettre à jour l’index sur le nombre de demande de downloads par document, il suffit de déclarer et implémenter un gestionnaire d’évènement sur les boutons générés dynamiquement par le template « search-results-template ». Il faut veiller à inclure le script dans la section dans laquelle est déjà déclaré le script « index.js », afin de s’assurer de l’ordre de déclaration de ce script. Il doit déjà exister au moment où le template va créer les boutons qui y font référence…. 
La fonction « ViewsCounterIncrement » réalise un appel Ajax sur l’action « Update » du « SearchController.cs ». Celle-ci utilise le mode batch proposé dans le SDK .Net et qui permet d’indexer un lot de documents. Dans notre contexte, cela se limite à un et un seul document.

Afin d’offrir le maximum de souplesse en terme de saisie de critères de recherche, l’application « Doc.Search.Portal » accepte l’utilisation optionnelle du caractère « * » (il sera ajouté s’il n’est pas présent). La recherche sur l’extension « docx » est explicitement remplacée par une recherche filtrée sur le « content_type » correspondant. Le code C# permettant d’exécuter une requête sur l’index est donc extrêmement simple, comme l’illustre la fonction suivante, extraite de la classe  « SearchController.cs ».

Vous retrouverez ces éléments et bien d’autres dans le code que je publierai prochainement sur GitHub. Mais d’ici là, dans le prochain article, nous verrons comment ajouter un autre mode d’accès au service « Azure Search » avec une « API App ».