Série d'exemples : Requêtes Http-Client

Ce que nous allons montrer

Dans cet article, nous allons montrer comment configurer rapidement un workflow layline.io pour interroger une REST-API en utilisant l'API Yahoo Finance comme exemple. Nous créerons un workflow qui interroge Yahoo pour obtenir des cotations boursières à intervalles fréquents.

Configuration du Http-Service

Tout d'abord, nous lançons l'interface web et créons un nouveau projet "sample-http-client-yahoo". Nous créons ensuite un Http-Service Asset "Yahoo-Finance-Source".

Qu'est-ce que les Services ?

Les services dans layline.io représentent des Assets spécifiques qui encapsulent des définitions d'interfaces complexes et les exposent ensuite à d'autres Assets sous forme d'appels de fonctions nommées simples pour une invocation facile. Les définitions REST-API correspondent à ce modèle, tout comme, par exemple, les instructions de base de données. À cette fin, layline.io fournit un certain nombre de Service Assets qui sont orientés vers les types d'interfaces spécifiques, tels que Http, JDBC, Aerospike, et plus encore. Dans notre exemple, nous utiliserons le Http-Service Asset pour accéder à l'API Yahoo Finance.

L'API REST des cotations boursières de Yahoo

Yahoo Finance fournit une API très complète pour accéder aux informations financières des entreprises cotées en bourse. Pour cette démonstration, nous passons par Rapid-API qui agit comme un service proxy. Si vous ne connaissez pas Rapid-API, vous devriez le découvrir. C'est vraiment cool.

Vous pouvez consulter l'URL exacte du service et sa description ici, puis vérifier le chemin "market/v2/get-quotes".

Configuration du Http-Service

En utilisant le Configuration Center, nous créons un Http-Service Asset :

Hôte

Ensuite, nous définissons l'adresse générique de l'hôte à laquelle les données peuvent être accessibles. Cela ne nécessite pas d'identifiants, mais des clés API que nous définirons plus tard.

Requêtes

Avant de définir des fonctions, nous nous assurons que layline.io comprend les requêtes et les réponses correspondantes. Vous pouvez définir un nombre quelconque de requêtes. Ici, nous définissons seulement "GetQuotes" qui devrait récupérer les cotations boursières et les données associées pour un certain nombre de symboles boursiers. C'est également là que le chemin de la requête est défini. De plus, nous configurons les paramètres nécessaires pour invoquer l'API (région et symboles, ainsi que la clé et l'hôte RapidAPI). Nous fournissons les valeurs lorsque nous définissons le Source Asset dans une étape suivante.

Si nous voulions utiliser d'autres requêtes, nous pourrions simplement les ajouter ici.

Réponse

Ensuite, nous définissons les réponses possibles à notre requête. Nous attendons un document JSON que nous avons défini dans "Quotes". layline.io est fortement typé. Dans notre cas, nous mappons simplement la réponse au type interne "AnyMap". Des réponses supplémentaires pourraient être des échecs 3xx à 5xx qui nous intéressent également.

Fonctions

Maintenant que nous avons défini la requête et les réponses, nous pouvons créer les fonctions abstraites que nous voulons exposer en interne.

Nous créons une fonction nommée "GetQuotes". Elle référence la requête du même nom que nous avons créée ci-dessus et assigne des réponses possibles à cette requête ("Quotes").

Nous pouvons maintenant accéder à l'API Yahoo Finance en invoquant simplement la fonction "GetQuotes" et en lui passant les paramètres requis. Nous verrons un exemple de cela lorsque nous définirons la Source de Service ci-dessous.

Hélas, pas mal de choses à configurer pour un premier Http-Service. Mais notez que des requêtes supplémentaires vers le même hôte peuvent être ajoutées très rapidement.

Configuration de la Source de Service

Nous prévoyons de constamment interroger l'API pour les dernières données boursières et nous voudrons la traiter comme une source de données régulière dans le workflow. Nous devons définir un Service-Source Asset pour cela. Un Service-Source Asset est un type spécial de Source qui utilise les fonctions définies dans les Service Assets, tout comme celui que nous avons défini ci-dessus.

Nous lions le Http-Service que nous avons défini à cette Source :

Enfin, nous configurons la fréquence de sondage de l'API et les paramètres d'appel de l'API réels.

Via un paramètre de type cron-table, nous définissons un intervalle de requête de 10 secondes. Object name désigne le nom de l'objet qui sera retourné par chaque requête. Notez que nous ajoutons la date et l'heure au nom de l'objet pour distinguer chaque objet de réponse. Nous utilisons un paramètre constant pour le sondage, ce qui signifie rien d'autre que nous voulons passer des paramètres codés en dur à la fonction de service au lieu de paramètres dynamiques. Ainsi, nous invoquons toujours la fonction pour les mêmes symboles boursiers dans notre exemple. Le Constant Type décrit le chemin vers la fonction de service réelle que nous voulons appeler et son objet de requête. Pour l'instant, cela doit être saisi manuellement, mais sera bientôt guidé par l'utilisateur. Nous entrons Yahoo.Finance.Functions.GetQuotes.Request ici.

Enfin, nous fournissons les paramètres que nous voulons passer à la fonction GetQuotes au format JSON. Rappelez-vous que nous les avons définis lorsque nous avons créé le Http-Service Asset.

C'est tout, nous pouvons maintenant créer le workflow réel.

Création du Workflow

Nous nous dirigeons vers l'interface utilisateur du Workflow et configurons un simple Workflow avec une entrée de flux et un processeur JavaScript.

Dans les paramètres du Service-Input Asset, nous le lions à la source Http que nous venons de créer.

Pour le processeur Javascript, nous ajoutons un script très simple qui envoie le message reçu au journal de flux. C'est ainsi que nous pouvons inspecter les résultats via l'Audit Trail dans l'interface utilisateur. Bien sûr, vous ne sortiriez normalement pas les résultats dans le journal, mais vous les traiteriez en aval dans le Workflow.

Déployer sur le Cluster et exécuter

Nous sommes prêts à tester le Workflow. Pour ce faire, nous devons le déployer sur un cluster Reactive Engine. Vous pouvez simplement utiliser celui sur votre ordinateur portable (nœud unique). Ou si vous avez un cluster layline.io plus grand ailleurs, vous pouvez le déployer là-bas. Pour déployer, nous passons à l'onglet DEPLOYMENT du projet :

Nous créons une configuration d'Engine pour déployer le projet. Cela définit les parties du projet que nous souhaitons déployer. Dans notre exemple, ce serait le seul Workflow que nous avons défini, ainsi que l'Environment Asset qui l'accompagne.

Puisque nous voulons déployer sur le cluster local, nous choisissons "Deploy to Cluster" puis notre configuration "Local Cluster" prédéfinie. Chaque déploiement nécessite un Tag. Nous utilisons "yahoo-quotes-" suivi d'une macro "${build-timestamp}" pour identifier le déploiement. La macro sera remplacée par un horodatage lors du transfert de déploiement. Cela garantit que nous obtenons toujours un tag différent avec chaque déploiement.

Nous sélectionnons de déployer tous les Workflows que nous avons créés (un seul). Enfin, nous lançons le transfert du déploiement en cliquant sur "TRANSFER DEPLOYMENT TO CLUSTER" (Assurez-vous que le cluster sur lequel vous déployez est en marche).

Si le déploiement s'est bien passé, vous devriez voir ceci :

Sinon, un message d'erreur s'affichera, vous guidant sur la façon de résoudre le problème.

Activation du Déploiement

Nous devrions maintenant être prêts à activer le déploiement. Pour cela, nous passons à l'onglet "CLUSTER". Cela nous donne une vue de tout ce qui concerne le "cluster". Dans le cas où vous gérez plus d'un cluster, assurez-vous d'avoir sélectionné le bon dans la boîte déroulante en haut à gauche.

En faire le déploiement par défaut

Sélectionnez "Deployment Storage" dans l'arborescence à gauche. C'est là que nous trouvons tous les déploiements actuellement connus du cluster sélectionné. Dans notre capture d'écran d'exemple, dans la section "Deployment Configuration", nous voyons 1 "DeploymentRoot" : C'est le déploiement par défaut vide de base qui est toujours présent. 2 "yahoo-quotes-20221011093550" : C'est le déploiement que nous venons de transférer au cluster. Pour activer maintenant le nouveau déploiement sur le cluster, sélectionnez-le puis cochez la case "is the cluster's default deployment".

Planification

Maintenant que le déploiement est actif sur le cluster, nous devons vérifier s'il exécute réellement des instances du Workflow. Si c'est la première fois que vous déployez ce Workflow, la réponse est probablement "non". Vérifions :

• Sélectionnez l'onglet "Cluster"
• Sélectionnez l'entrée "Scheduler Master" dans l'arborescence à gauche

• Dans la boîte de paramètres du planificateur, sélectionnez le nœud du planificateur dans l'arborescence
• Ensuite, assurez-vous que le nombre cible d'instances est réglé sur au moins 1. Le régler sur un nombre plus élevé lancera plus d'instances du même Workflow. En quelques secondes, vous devriez voir l'instance démarrée. Vous n'avez besoin de faire cela qu'une seule fois. La prochaine fois que vous déploierez le Workflow, le Reactive Engine se souviendra du nombre d'instances que vous souhaitez exécuter à partir de ce Workflow. Vous pouvez également définir les paramètres du planificateur que vous souhaitez dans le cadre d'un déploiement. Mais c'est pour une autre démonstration.

Statut de l'Engine

Passez à l'onglet "Engine". Assurez-vous que toutes les catégories d'Engine sont en vert. Vérifiez également le statut des Assets individuels dans l'arborescence à gauche.

Vérification des résultats

Dès que vous avez planifié le Workflow (ci-dessus), il commence à interroger l'interface Yahoo Finance pour obtenir des résultats toutes les quelques secondes.

Rendez-vous sur l'onglet Audit Trail pour voir les résultats apparaître dans le journal de flux au format JSON :

Bien sûr, cette sortie est uniquement à des fins de démonstration. Dans un environnement de travail réel, vous traiteriez ces données en aval dans le Workflow.

Résumé

Cette démonstration met en évidence comment vous pouvez créer un Http-Client-Workflow à la volée sans trop de tracas. Et vous obtenez beaucoup plus avec cela prêt à l'emploi :

• Réactif — Adopte le paradigme de traitement réactif. Entièrement construit sur la gestion des flux réactifs au cœur
• Haute évolutivité — S'étend au sein d'une instance de moteur et au-delà à travers plusieurs moteurs et nœuds distribués
• Résilience — Sûr en cas de panne dans des environnements distribués. Opération 24/7 complète et évolutivité
• Déploiement automatique — Déployez les configurations modifiées en un clic
• Temps réel et batch — Exécutez à la fois des intégrations de données en temps réel et par lots en utilisant la même plateforme
• Métriques — Génération automatique de métriques à utiliser dans votre outil de surveillance et d'alerte préféré (par exemple, Prometheus)

Il y a trop de fonctionnalités à expliquer ici. Pour plus d'informations, veuillez consulter la documentation ou simplement nous contacter à hello@layline.io. Merci de votre lecture !

Ressources

• En savoir plus sur layline.io ici.
• Contactez-nous à hello@layline.io.