Les Logic Apps ont récemment fait peau neuve, comme nous vous l’avions annoncé dans un précédent article sur « Logic Apps Standard :...
4 août 2015
Prise en main des Azure API Apps au coeur de l’architecture Microservices
Les discussions récentes sur les architectures microservices ont pour vertu d’apporter aux développeurs et aux architectes de nouvelles logiques d’implémentation et d’intégration de solutions pour les systèmes d’information d’entreprise. Ces réflexions s’inscrivent totalement dans le courant des dernières technologies porté par le Cloud, la mobilité ou le Big Data. Si vous souhaitez profiter de ces outils, le défi d’intégration est le suivant : pouvoir mettre en place des APIs qui
- se créent facilement,
- se déploient rapidement,
- interopérables entre les plateformes,
- maintenables par les équipes,
- scalables au besoin.
Et tout cela en tenant compte de la complexité du système existant bien sûr!
Les avantages des architectures microservices sont présentés par Radoine Douhou lors d’un précédent blog post (que je vous recommande fortement en lecture préalable 🙂 ). Les services proposés par le Cloud Microsoft Azure ont pour vocation de soutenir cette approche d’architecture microservices afin de répondre aux problématiques que j’ai évoquées. Une des clés de réussite dans l’adoption de ce pattern est la capacité à créer ces microservices. Ce sont les « atomes » qui vont constituer la matière. Pour cet article, je me pencherai plus précisément sur les questions techniques concernant l’implémentation de microservices portés par Azure API Apps. L’objectif est de les combiner avec Azure Logic Apps, workflow qui va assembler les différents microservices.
Pourquoi Azure API App ?
Tout d’abord, que représentent les API App Azure ? Il s’agit d’un modèle de développement qui accélère l’implémentation de web services ou d’APIs basés sur l’architecture REST et le protocole HTTP. Cette caractéristique présente son importance : plutôt que de partir de concepts totalement nouveaux, il est plus pertinent de s’appuyer sur des architectures qui se sont imposées comme standards, et ainsi proposer des APIs promptes à être appelées « naturellement ». De plus, le format JSON est nativement pris en charge par ces APIs Azure, et permet une facilité d’intégration dans les pages web et la garantie d’un transfert de données sous un format léger, adapté notamment à la mobilité. Le protocole HTTP, quant à lui, permet de profiter des codes retour HTTP existants et qui sont connus dans le monde du web. C’est mieux que d’imposer une nomenclature différente pour chaque API à élaborer.
En REST, les APIs sont mises à disposition sous formes de ressources et présentent une logique à la fois simple et rigoureuse qui contribue au succès de vos services. Par exemple, si je crée des APIs pour une plateforme de e-commerce, voici un modèle valable :
- j’accède à la commande n°26 via l’url suivante : http://monservice.com/api/orders/26
- pour obtenir des informations sur le client n°14 : http://monservice.com/api/customers/14
Par extension, via cette simplicité peut s’ouvrir une opportunité « business » pour la monétisation de vos APIs. Grâce à Azure API App, vous pouvez facilement rajouter une couche de facturation de votre APIs sans avoir à entrer dans un processus de développement complexe. On se projette alors dans une logique B2B où vos APIs sont proposées via le catalogue de services Microsoft Azure Marketplace. Vous pourrez alors mettre en place des processus qui s’appuient sur vos propres microservices mais aussi ceux proposés par vos partenaires, par exemple un service de livraison dans le cadre de ma plateforme e-commerce. Plus d’informations sur Azure Marketplace ici.
Développement sous Visual Studio
Afin d’illustrer l’implémentation d’un microservice, je vais montrer comment simplement créer une API App via Visual Studio. Nous allons, pour exemple, mettre en place une API qui exécute des créations de clients sur Dynamics CRM Online pour l’exploiter dans Azure App Services.
Au préalable, il faut disposer de la version 2.5.1 du SDK Azure qui ajoute les fonctionnalités de développement des App Service. La dernière version du SDK est disponible via le lien suivant.
Pour créer un nouveau projet, il faut se rendre sur Visual Studio dans la section Templates > Visual C# > ASP.Net Web Application.
Dans le cadre de notre exemple, nous allons partir de la configuration par défaut Azure API App (Preview).
Le projet de base Api Apps est alors créé avec notamment les dossiers suivants :
- App_Start : gère des configurations comme WebApiConfig.cs, afin de modifier le comportement des Web APIs, et SwaggerConfig.cs, pour personnaliser la découverte des APIs via Swagger,
- Controllers : contient les Controllers pour implémenter les opérations des APIs,
- Models : contient les classes portant les modèles employés dans les APIs.
Nous pouvons ouvrir le Controller créé par défaut, ValuesController. Ce dernier expose cinq méthodes : Get, GetById, Post, Put, Delete. Par défaut, les noms des méthodes font référence aux opérations HTTP (comme GET, POST, PUT ou DELETE) pour l’API disponible à l’adresse api/values.
Pour notre exemple, nous allons créer une classe adaptée : Customer.cs. C’est cet objet que nous passerons en paramètres de notre appel API afin de le faire apparaître dans Dynamics CRM Online.
public class Customer
{
public string name { get; set; }
public string city { get; set; }
public string telephone { get; set; }
}
A présent, nous allons créer un nouveau Controller qui va manipuler la classe Customer. Pour ce faire, il faut cliquer droit sur le dossier Controllers, sélectionner Add > Controller, de type Web API 2 Controller – Empty et l’appeler CustomersController. Attention car le nom a son importance, c’est à partir de celui-ci que le framework va définir l’uri de l’API, qui sera alors api/Customers. Ces règles définies par le Framework ne doivent pas être perçues comme des contraintes mais ont plutôt pour objectif d’apporter de la rigueur et de la cohérence afin que le code soit maintenable.
Nous l’enrichissons d’une méthode Post que l’on nommera Post. Grâce à ce nom de méthode, le framework va automatiquement faire correspondre cette méthode à une requête Post exécutée sur notre API. L’argument est de type Customer et nous exécutons une requête de création sur Dynamics CRM que nous avons préparée au préalable. Je n’entre pas dans les détails de l’appel à Dynamics, le but est de vous montrer qu’un code existant peut être facilement intégré à une API App :).
public IHttpActionResult Post(Customer customer)
{
// Get the configuration for Dynamics CRM
Configuration config = new Configuration();
try
{
Task.WaitAll(Task.Run(async () => await CreateCustomer(config, customer.name, customer.city, customer.telephone)));
return Ok();
}
catch (Exception e)
{
return BadRequest(e.Message);
}
}
La méthode implémentée, nous pouvons passer au test. Des utilitaires comme Fiddler ou Postman permettent de lancer des requêtes REST et de vérifier notre développement mais nous allons opter pour une autre solution. Swagger est une extension incluse nativement dans les Api Apps qui facilite l’appel des APIs REST en exposant les requêtes disponibles sur une page web. Nous pouvons le comparer au wsdl qui est utilisé dans le cadre du développement des web services SOAP. Pour activer cette interface graphique, il suffit de modifier le code de SwaggerConfig.cs en décommentant l’option EnableSwaggerUI.
// ***** Uncomment the following to enable the swagger UI *****
})
.EnableSwaggerUi(c =>
{
A présent, il est possible de tester son développement. Lorsque l’API est déployée, par exemple via exécution sous Visual Studio, il est possible d’accéder à l’interface de swagger directement à partir du navigateur web, en rajoutant /swagger à l’url, par exemple http://localhost:%5Bport%5D/swagger L’extension Swagger répertorie alors automatiquement la liste des APIs et met à disposition un formulaire de test rapide. Je peux alors l’utiliser pour soumettre ma requête.
L’exécution de ce test nous permet de vérifier le fonctionnement correct de la création dans Dynamics CRM Online. Le nouveau compte/client apparaît dans la liste.
Déploiement de l’API App
Jusqu’à présent, nous n’avons exploité que des fonctionnalités proposés par le framework des Web API. Cependant, puisque nous avons sélectionné le template Azure API Apps, notre projet comporte des métadonnées apiapp.json qui vont permettre à Azure de reconnaître cette Web API comme une API Apps utilisable dans App Service, via Logic App en particulier.
Visual Studio intègre le Cloud Microsoft Azure de manière efficace et permet en quelques clics de procéder au déploiement des API Apps. Il suffit de faire un clic droit sur le projet et de choisir « Publish ».
Il faut ensuite sélectionner Microsoft Azure API Apps (Preview) et cliquer sur le bouton Publish. S’ensuit une phase d’authentication avec votre compte Azure. Enfin l’utilitaire permet de créer une API Apps sur Azure en spécifiant les options désirées (on peut en particulier déterminer le niveau d’accès pour limiter les autorisations sur les APIs).
Une fois le déploiement effectué, l’API App apparaît sur le portail Azure dans la section correspondante et est prête à l’emploi dans mon groupe de ressources.
Il est alors possible d’intégrer notre API app dans une Azure Logic App, ce qui nous permet par exemple de combiner un connecteur Twitter et notre microservice/connecteur Dynamics CRM Online. Ma Logic App Azure peut, en fonction des événements qui se déroulent sur Twitter, déclencher automatiquement des actions sur Dynamics (dans mon cas créer des comptes, mais on peut facilement imaginer d’autres opérations possibles).
Cette API profite alors des avantages du Cloud et peut apporter de nouvelles opportunités lorsque l’on souhaite se lancer dans des projets qui intègrent les dernières solutions innovantes.
En conclusion
Les concepts fondamentaux des microservices ne sont pas inconnus dans le monde de la SOA. La nouveauté réellement apportée est la simplification dans leur implémentation et l’adéquation des Azure API Apps avec l’écosystème existant. Nous pouvons alors mettre en place des APIs qui n’ont pas une durée limitée dans le temps mais qui se veulent fonctionnelles sur le long terme.
