Op het moment van schrijven is het de week na de 2025 Esri International User Conference, en door de ArcGIS Data Interoperability en ETL Patterns onderwerpen de hele week in de Esri showcase te presenteren, kan ik melden dat de meeste interesse voor inkomende datastromen lag bij het onderhouden van hosted feature services vanuit externe data. Deze post laat je een techniek zien waar ik eerder over heb geblogd maar met een belangrijke update, hoe bulk wijzigingsdetectie het meest efficiënt uit te voeren, dus lees verder.<\/P>
Hier is mijn onderwerpdata, straatadressen voor de stad Los Angeles, die vriendelijk de data beschikbaar stellen op hun open data site. De adresdata wordt dagelijks bijgewerkt.<\/P>
Beverly Hills is niet in Los Angeles<\/span><\/span><\/P>Strategieën voor dataintegratie omvatten verschillende benaderingen, en er zijn over het algemeen meerdere "juiste antwoorden", een goed overzicht is te krijgen door een presentatie van mijn Esri-collega's eerder dit jaar te bekijken. In het geval van mijn onderwerpdata zijn alle opties die in de presentatie worden besproken (ArcGIS ModelBuilder, python scripts python notebooks, ArcGIS Data Pipelines en ArcGIS Data Interoperability) allemaal geldige benaderingen.<\/P>Maar dit is de Data Interoperability community ruimte, dus met focus op die optie heb ik een verwerkingstip voor je. Je hoort in de bovenstaande presentatie dat het onderhouden van een hosted feature service heel gebruikelijk is, en het minimaliseren van downtime daarbij belangrijk is. Een manier is om twee feature services te onderhouden, er één tegelijk te bewerken en een bronwissel tussen hen te doen. Als je echter ArcGIS Data Interoperability gebruikt, heb je nog een andere optie beschikbaar, de ChangeDetector transformer, die zeer snel een transactie kan afleiden die alleen toegevoegde, bijgewerkte of verwijderde records bevat, bijna altijd een zeer efficiënte transactie.<\/P>De truc is echter om de bestaande en nieuwe bulkdata naar de transformer te krijgen zodat deze de delta-transactie kan berekenen! Dit is hoe ik aanbeveel dat te doen:<\/P>
Een webverbinding gebruiken om verandering aan te sturen<\/span><\/span><\/P>De ETL workspace FMW-bron staat in de post download.<\/P>Er valt niet aan te ontkomen nieuwe binnenkomende data via download op te halen, maar je kunt streaming van de huidige staat van de doel-feature service vermijden (wat relatief traag is) door het portal te vragen een file geodatabase export te genereren en die te downloaden. De export job-aanroep vereist een token, wat moeilijk te genereren is als jouw organisatie net als de mijne multi-factor authenticatie (MFA) afdwingt. De truc is om webservice-authenticatie te gebruiken in de HTTPCaller-transformers die de exportjob starten en jobstatus controleren in de aangepaste looping transformer die wacht op voltooiing van de exportjob. Webservice-authenticatie levert achter de schermen een token zodat je deze niet als HTTP URL-parameter hoeft mee te geven. Dat is de centrale truc achter deze aanpak.<\/STRONG><\/P>Je ziet aan de hand van het workspace-afbeelding hierboven dat een dagelijkse wijzigingstransactie voor Los Angeles' adressen een kleine transactie is aan het einde van enkele minuten dat lezen van data kost. Het logbestand (niet getoond) vertelt me dat 67 features deelnamen aan de transactie, die 0,5s duurde.<\/P>
