Modèle ETL : Planification des outils Web

bharold

Souvent, l'ETL n'est pas ponctuel, une récurrence <\/STRONG> est nécessaire pour intégrer les changements de données au fil du temps.  Jusqu'aux versions ArcGIS Pro 3.4 et ArcGIS Enterprise 11.4, les modèles d'automatisation pris en charge<\/STRONG> pour cela incluaient ArcGIS Data Pipelines<\/STRONG> et des Notebooks <\/STRONG> ou outils programmés utilisant le planificateur de tâches REST API<\/A>, mais une nouvelle option sans code, planification d'outil web<\/A>, est livrée dans ArcGIS Pro 3.4 et ArcGIS Enterprise 11.4 !<\/STRONG><\/P>

Vous pouvez utiliser n'importe quel type d'outil de géotraitement pour créer votre outil web programmé - outil système principal, outil ModelBuilder, outil script Python ou outil Spatial ETL. <\/STRONG> Pour mon sujet de blog, j'utilise un outil Spatial ETL ArcGIS Data Interoperability, car il peut consommer ma source de données, un flux

RSS<\/A>, spécifiquement un flux Common Alerting Protocol<\/A> (CAP), tel que publié par de nombreuses agences dans le monde entier, y compris FEMA<\/A> aux États-Unis.  Mes données CAP sont des alertes météo en Nouvelle-Zélande<\/A>, actualisées deux fois par jour.  Le flux ne contiendra aucune entrée si le temps est bon 😉<\/span>.  CAP est basé sur XML, facilement géré par ArcGIS Data Interoperability<\/STRONG>.  Je souhaite refléter l'état du flux CAP dans une couche d'entités hébergée sur ArcGIS Online.<\/P>
Ci-dessous se trouve une carte d'état d'alerte exemple dans ArcGIS Pro, pour le 9 octobre 2024.  Le téléchargement du blog contient quelques documents XML d'alerte CAP, si vous souhaitez voir des données brutes.<\/P>
Alertes météo CAP<\/span><\/span><\/P>
Comme l'indique l'étiquetage, la zone jaune est une surveillance de vents forts, les lignes bleues (zoomées, polygones orange) sont des avertissements de neige pour les routes traversant certains cols montagneux.  Si nous zoomons sur la zone la plus au nord, nous pouvons l'inspecter.  C'est Lewis Pass, qui possède deux stations thermales géothermiques le long de la route, donc si vous êtes retardé par la neige, vous pouvez patienter confortablement !<\/P>
Alerte neige à travers Lewis Pass<\/span><\/span><\/P>
Quelques jours plus tard, il y a une surveillance de fortes pluies :<\/P>
Surveillance pluie Fiordland<\/span><\/span><\/P>
Pour cette région, la pluie ne vient que sous une forme - forte - donc il n'est pas surprenant que la prédiction d'une mise à niveau de l'alerte de surveillance à avertissement (orange) soit devenue vraie lors de la mise à jour suivante dans 12 heures, avec en plus quelques nouvelles alertes arrivées :<\/P>
Pluie côte ouest<\/span><\/span><\/P>
Et le lendemain - encore plus de météo !<\/P>
Encore plus de météo !<\/span><\/span><\/P>
Des mises à jour régulières comme celle-ci sont un cas classique pour un outil web programmé ; en fait c'est ainsi que les données ont été actualisées pour moi pendant la nuit.  À quoi ressemble cet ETL ?<\/P>
Mon flux de données maintient une couche d'entités hébergée dans ArcGIS Online à partir du statut CAP actuel.  Mon outil ETL est assez simple, le voici (également dans le téléchargement du blog, nécessite ArcGIS Data Interoperability pour Pro 3.4 et ArcGIS Enterprise 11.4 si partagé comme outil web).<\/P>
Outil ETL alerte CAP<\\/span><\\/span><\\/P>
D'abord un jeton est généré (en utilisant un EsriOnlineTokengetter<\\/A>, pour un portail local vous utiliseriez un EsriPortalTokenGetter<\\/A>), puis le flux supérieur lit le flux RSS et écrit une transaction upsert<\\/STRONG> vers la couche d'entités cible - toute nouvelle alerte devient une nouvelle entité et tout changement de données aux entités existantes est appliqué.  Le support upsert nécessite que les données aient un champ non nul indexé unique dans la couche, comme discuté dans un blog précédent<\\/A>.  Le flux inférieur teste les alertes expirées et les supprime.  Notez que l'outil ETL n'a pas de paramètres, car le flux RSS d'entrée et la couche d'entités de sortie ne changent pas et peuvent être définis comme non publiés au moment de la création. <\\/P>

Je montre ici un nouveau,<\\/STRONG> modèle ETL recommandé<\\/STRONG><\\/EM> pour la maintenance des couches d'entités hébergées, à savoir générer un jeton portail au sein de l'outil ETL plutôt que

partager des connexions web<\\/A> vers le serveur d'hébergement, ce qui est une étape gênante que nous pouvons éviter.  Le service d'entités cible est lu et écrit en utilisant le format Esri ArcGIS Server Feature Service<\\/STRONG> et un jeton fourni, avec l'option de vérifier les certificats SSL décochée<\\/STRONG>.  Si vos exigences de sécurité l'exigent, vous devrez fournir un certificat approuvé.<\\/P>
Ayant exécuté mon outil ETL localement dans ArcGIS Pro je peux partager le résultat historique comme outil web<\\/A> et le programmer.  Il faut faire quelques calculs mentaux lors de la planification.  Le flux CAP est mis à jour à 9h00 et 21h00 "heure locale", qui au moment de la rédaction est NZDT, ou UTC+13.  Ma machine Pro est actuellement en PDT, qui est UTC-7, donc pour démarrer mon planning au prochain créneau disponible toutes les 12 heures, 9h00 NZDT, je calcule que c'est 20h00 UTC ou 13h00 PDT.<\\/P>

Il n'y a maintenant rien qui vous empêche d'automatiser votre ETL !

 

bharold

@AdamRepsher_BentEar There is some problem with the token getting, if you copy the transformer into a new workspace and try out the Python it might give a clue. Once you establish generateToken isn't working you could open a support call.