Intégration Continue / Livraison Continue (CI/CD) est une méthodologie de développement logiciel. J'emprunte ce terme et l'applique aux données, pas au logiciel, spécifiquement aux données qui changent sans cesse au fil du temps et que vous devez intégrer dans vos systèmes d'enregistrement, eh bien, en continu !
Toujours prêt à plonger dans le grand bain, mon exemple consiste à prendre un flux de positions de véhicules de transport public (accessible via une API REST) qui se rafraîchit toutes les 30 secondes et à pousser les données vers un service d'entités hébergé dans un portail ArcGIS Enterprise et aussi dans une table spatialisée dans Snowflake. J'utiliserai un outil web pour le traitement car une haute disponibilité est évidemment recommandée.
Voici les positions des bus, trains et ferries il y a quelques instants (samedi matin heure locale) à Auckland, NZ.<\/STRONG><\/P>
Positions des bus, trains & ferries à Auckland
Je travaille probablement à l'extrême fréquence d'intégration continue de données en masse, je m'attends à ce que la grande majorité des intégrations soient effectuées à des intervalles de plusieurs heures ou jours, mais au moins vous saurez ce qui peut être réalisé.
Portez-moi patience pendant que je m'amuse avec mon scénario d'intégration 😉.
Disons que je travaille chez Fako (un nom fictif), qui a résolu le problème du premier kilomètre / dernier kilomètre du commerce électronique. Fako a identifié que les réseaux de navetteurs sont très efficaces pour rapprocher les personnes et les biens de détail, achat ou vente, lorsque les passagers sont acheteurs et vendeurs. En partenariat avec les opérateurs de transport, nous retirons quelques rangées de sièges dans chaque véhicule, des deux côtés de l'allée, et les remplaçons par des grilles de casiers intelligents auxquels les achats en ligne peuvent être « livrés » par nos dockers dans nos entrepôts situés à proximité des terminaux de transport. Les acheteurs commandent depuis n'importe quel site web pour une livraison un jour et sur un itinéraire donné, les vendeurs vendent sur notre site web et nous transférons les articles vers des itinéraires partout sur le réseau. Nous sommes des transitaires. L'application mobile de Fako permet aux clients d'utiliser leur téléphone pour déverrouiller le casier contenant leur article à tout moment pendant leur trajet. Certains casiers sont réfrigérés, nous avons notre propre gamme de kits repas. Une fonctionnalité très populaire de notre application mobile permet aux passagers d'enchérir lors d'enchères pour des articles abandonnés. Fako paie aux opérateurs de transport l'équivalent d'un tarif passager par article, augmentant considérablement leur fréquentation effective. Fako n'a pas besoin d'acheter une flotte de véhicules de livraison et les opérateurs de transport voient leurs revenus augmenter. Les affaires prospèrent !
Les systèmes back-end de Fako fonctionnent sur Snowflake. Pour que tout fonctionne, Fako doit maintenir en continu l'état du réseau sous forme d'objets spatialisés Snowflake. Voyons comment !
D'abord la méthode ennuyeuse, pour laquelle je me suis disqualifié en choisissant une fréquence non supportée par les tâches planifiées Windows, serait de copier un espace de travail Spatial ETL source fmw sur mon serveur Data Interoperability et configurer une tâche planifiée basée sur la ligne de commande documentée dans un fichier journal d'une exécution manuelle en tant qu'utilisateur arcgis :
Ligne de commande pour exécuter cet espace de travail :
"C:\Program Files\ESRI\Data Interoperability\Data Interoperability AO11\fme.exe" C:\Users\arcgis\Desktop\ContinuousIntegration\VehiclePositions2Snowflake.fmw
Vous devriez considérer attentivement cette option selon votre situation, elle est robuste et simple.
Maintenant la méthode non ennuyeuse. Comme je l'ai dit, je me suis orienté vers cette approche en travaillant avec des données qui se mettent à jour en masse à haute fréquence. Je crée un outil web qui effectue l'intégration puis s'appelle lui-même après avoir attendu la mise à jour des données source.<\/STRONG>
Whoa un outil web qui s'appelle lui-même, pas de webhook et pas de planification ? C'est incroyablement simple (peut-être aussi juste fou).
J'ai créé deux outils Spatial ETL, un réel et un factice qui ne fait rien mais porte le même nom et paramètres (aucun dans ce cas).<\/P>
<\/P>
J'ai partagé un élément historique de la version factice de VehiclePositions2Snowflake comme outil web et enregistré l'URL submitJob. Il est important que l'outil web soit asynchrone afin que lorsqu'il est appelé il ne bloque pas l'espace de travail en attendant une réponse :
https://dev99999.esri.com/server/rest/services/VehiclePositions2Snowflake/GPServer/VehiclePositions2Snowflake/submitJob
Puis modifiez l'outil ETL réel, dans l'étape HTTP finale, pour appeler l'URL submitJob. Exécutez l'outil et depuis son élément historique surchargez l'outil web factice.
Je vous laisse explorer l'outil vous-même mais essentiellement le flux supérieur récupère les données des véhicules et les synchronise avec le portail et Snowflake tandis que le flux inférieur attend cela ainsi que 30 secondes écoulées puis effectue l'appel HTTP.
L'Outil ETL Auto-Intégrant
Puis lancez simplement l'outil web une fois manuellement et vous êtes parti pour la course, il se répétera sans fin. Je suis ici en train d'actualiser ma carte Pro (pas de cache sur la couche du service d'entités) et je vois la flotte de transport se déplacer.
Dans Snowflake mes données se rafraîchissent aussi :
Console Snowflake
Revenons à quelques détails ennuyeux, n'oubliez pas qu'en publiant des outils Spatial ETL comme outils web Data Interoperability doit être installé et licencié sur chaque serveur hébergeant ces outils et lorsque vous utilisez des identifiants web ou base de données comme je le fais ici, allez dans Outils>Options FME et exportez les identifiants requis (clic droit pour le menu) vers des fichiers XML, placez-les sur votre serveur et importez-les dans l'environnement Workbench en tant que propriétaire du service arcgis. Si vous exécutez manuellement un espace de travail sur le serveur vous devrez peut-être aussi changer l'environnement Python. Enfin, bien que le téléchargement du blog contienne un fichier FMW l'outil que vous publiez sur votre serveur devrait avoir une source intégrée.
C'était amusant !
