Au moment de l'écriture, c'est la semaine suivant la conférence internationale des utilisateurs Esri 2025, et en mettant en avant les sujets ArcGIS Data Interoperability et ETL Patterns dans le showcase Esri toute la semaine, je peux rapporter que l'intérêt principal pour le flux de données entrant concernait le maintien des hosted feature services à partir de données externes. Ce post vous montrera une technique dont j'ai déjà parlé sur mon blog mais avec une mise à jour importante, comment faire la détection de changement en masse de manière la plus efficace possible, alors continuez votre lecture.<\/P>
Voici mes données sujet, les adresses de rues pour la ville de Los Angeles, qui mettent aimablement les données disponibles sur leur site open data. Les données d'adresses sont mises à jour quotidiennement.<\/P>
Beverly Hills n'est pas dans Los Angeles<\/span><\/span><\/P>Les stratégies d'intégration des données incluent une variété d'approches, et il y a généralement plusieurs "bonnes réponses", un bon aperçu peut être obtenu en regardant une présentation par mes collègues Esri plus tôt cette année. Dans le cas de mes données sujet, toutes les options discutées dans la présentation (ArcGIS ModelBuilder, scripts python, notebooks python, ArcGIS Data Pipelines et ArcGIS Data Interoperability) sont toutes des approches valides.<\/P>Mais ceci est l'espace communauté Data Interoperability, donc avec un focus sur cette option j'ai un conseil de traitement pour vous. Vous entendrez dans la présentation liée ci-dessus que maintenir un hosted feature service est très courant, et minimiser le temps d'arrêt pendant ce processus est important. Une façon est de maintenir deux feature services, éditer un à la fois et faire un échange de source entre eux. Cependant, si vous utilisez ArcGIS Data Interoperability, vous avez une autre option disponible, le transformateur ChangeDetector, qui peut très rapidement dériver une transaction qui inclut seulement les enregistrements ajoutés, mis à jour ou supprimés, presque toujours une transaction très efficace.<\/P>Le truc cependant est d'amener les données existantes et nouvelles en masse au transformateur afin qu'il puisse calculer la transaction delta ! Voici comment je recommande de faire cela :<\/P>
Utiliser une connexion web pour piloter le changement<\/span><\/span><\/P>La source du workspace ETL FMW est dans le téléchargement du post.<\/P>Il n'y a pas moyen d'échapper à la récupération des nouvelles données entrantes par téléchargement, mais vous pouvez éviter le streaming dans l'état actuel du hosted feature service cible (ce qui est comparativement lent) en demandant au portail de générer une exportation file geodatabase, puis en téléchargeant cela. L'appel au job d'exportation nécessite un token, ce qui est difficile à générer si votre organisation est comme la mienne et applique l'authentification multi-facteurs (MFA). Le truc est d'utiliser l'authentification web service dans les transformateurs HTTPCaller qui initient le job d'exportation et vérifient le statut du job dans le transformateur personnalisé en boucle qui attend la fin du job d'exportation. L'authentification web service fournit un token en coulisses donc vous n'avez pas à le fournir comme paramètre URL HTTP. C'est l'astuce centrale derrière cette approche.<\/STRONG><\/P>Vous verrez sur l'image du workspace ci-dessus qu'une transaction quotidienne de changement pour les adresses de Los Angeles est une petite transaction à la fin de quelques minutes prises pour lire les données. Le fichier log (non montré) m'indique que 67 entités ont participé à la transaction, qui a pris 0.5s.<\/P>
