Zum Zeitpunkt des Schreibens ist es die Woche nach der Esri International User Conference 2025, und nachdem ich die ArcGIS Data Interoperability und ETL Patterns Themen die ganze Woche über im Esri Showcase präsentiert habe, kann ich berichten, dass das größte Interesse am eingehenden Datenfluss darin bestand, gehostete Feature Services aus externen Daten zu pflegen. Dieser Beitrag zeigt Ihnen eine Technik, über die ich bereits gebloggt habe, aber mit einem wichtigen Update, wie man Bulk-Change-Detection am effizientesten durchführt, also lesen Sie weiter.<\/P>
Hier sind meine Fachbereichsdaten, Straßenadressen für die Stadt Los Angeles, die freundlicherweise die Daten auf ihrer Open Data Site verfügbar machen. Die Adressdaten werden täglich gepflegt.<\/P>
Beverly Hills ist nicht in Los Angeles<\/span><\/span><\/P>Datenintegrationsstrategien umfassen eine Vielzahl von Ansätzen, und es gibt im Allgemeinen mehrere „richtige Antworten“. Einen guten Überblick erhält man durch das Ansehen einer Präsentation meiner Esri-Kollegen Anfang dieses Jahres. Im Fall meiner Fachbereichsdaten sind alle in der Präsentation besprochenen Optionen (ArcGIS ModelBuilder, Python-Skripte, Python-Notebooks, ArcGIS Data Pipelines und ArcGIS Data Interoperability) gültige Ansätze.<\/P>Da dies jedoch der Data Interoperability Community-Bereich ist, konzentriere ich mich auf diese Option und habe einen Verarbeitungstipp für Sie. In der oben verlinkten Präsentation hören Sie, dass die Pflege eines gehosteten Feature Service sehr üblich ist und es wichtig ist, Ausfallzeiten dabei zu minimieren. Eine Möglichkeit besteht darin, zwei Feature Services zu pflegen, jeweils einen zu bearbeiten und dann einen Quellentausch zwischen ihnen vorzunehmen. Wenn Sie jedoch ArcGIS Data Interoperability verwenden, steht Ihnen eine weitere Option zur Verfügung: der ChangeDetector-Transformer, der sehr schnell eine Transaktion ableiten kann, die nur hinzugefügte, aktualisierte oder gelöschte Datensätze enthält, was fast immer eine sehr effiziente Transaktion ist.<\/P>Der Trick besteht jedoch darin, die vorhandenen und neuen Bulk-Daten zum Transformer zu bringen, damit er die Delta-Transaktion berechnen kann! So empfehle ich das zu tun:<\/P>
Verwendung einer Webverbindung zur Steuerung der Änderung<\/span><\/span><\/P>Die ETL-Arbeitsbereichsquelle FMW befindet sich im Beitrag zum Download.<\/P>Es gibt kein Entkommen davor, neue eingehende Daten per Download abzurufen, aber Sie können vermeiden, den aktuellen Zustand des Ziel-Feature Service streaming abzurufen (was vergleichsweise langsam ist), indem Sie das Portal bitten, einen File-Geodatabase-Export zu erstellen und diesen herunterzuladen. Der Exportjob-Aufruf erfordert ein Token, das schwer zu generieren ist, wenn Ihre Organisation wie meine Multi-Faktor-Authentifizierung (MFA) erzwingt. Der Trick besteht darin, Webservice-Authentifizierung in den HTTPCaller-Transformern zu verwenden, die den Exportjob initiieren und den Jobstatus im benutzerdefinierten Looping-Transformer überprüfen, der auf den Abschluss des Exportjobs wartet. Die Webservice-Authentifizierung liefert hinter den Kulissen ein Token, sodass Sie es nicht als HTTP-URL-Parameter angeben müssen. Das ist der zentrale Trick dieses Ansatzes.<\/STRONG><\/P>Sie sehen auf dem obigen Arbeitsbereichsbild, dass eine tägliche Änderungs-Transaktion für die Adressen von Los Angeles eine winzige Transaktion am Ende von wenigen Minuten Lesezeit der Daten ist. Die Protokolldatei (nicht gezeigt) sagt mir, dass 67 Features an der Transaktion beteiligt waren, die 0,5 s dauerte.<\/P>
