Continue Integratie / Continue Levering (CI/CD) is een softwareontwikkelingsmethodologie. Ik leen de term en pas deze toe op data, niet op software, specifiek data die voortdurend verandert in de tijd en die je continu in je registratiesystemen moet integreren!
Altijd geneigd om meteen diep te duiken, is mijn voorbeeld het nemen van een feed van openbaar vervoer voertuigposities (toegankelijk via een REST API) die elke 30 seconden ververst wordt en het doorsturen van de data naar een gehoste feature service in een ArcGIS Enterprise portal en ook naar een ruimtelijk ingeschakelde tabel in Snowflake. Ik zal een webtool gebruiken voor de verwerking omdat hoge beschikbaarheid uiteraard aan te raden is.
Hier zijn bus-, trein- en veerbootposities van een paar momenten geleden (vroeg op zaterdag lokale tijd) in Auckland, NZ.
Bus, trein & veerbootposities in Auckland
Ik werk waarschijnlijk aan het uiterste eind van continue bulkdata-integratiefrequentie, ik verwacht dat de overgrote meerderheid van integraties wordt uitgevoerd met intervallen van uren of dagen, maar tenminste weet je wat er bereikt kan worden.
Heb geduld terwijl ik plezier heb met mijn integratiescenario 😉.
Laten we zeggen dat ik werk bij Fako (een fictieve naam), die het first-mile/last-mile probleem van e-commerce hebben opgelost. Fako heeft vastgesteld dat forensennetwerken zeer efficiënt zijn om mensen en detailhandelsgoederen samen te brengen, kopen of verkopen, wanneer de reizigers de kopers en verkopers zijn. In samenwerking met vervoersbedrijven verwijderen we een paar rijen stoelen in elk voertuig, aan beide zijden van het gangpad, en vervangen deze door rasters van slimme opslagkluizen waar internetbestellingen door onze stevedores in onze magazijnen naast vervoersterminals kunnen worden 'afgeleverd'. Kopers bestellen vanaf elke website voor levering op een dag en route, verkopers verkopen op onze website en wij verplaatsen items naar routes overal op het netwerk. Wij zijn expediteurs. De mobiele app van Fako laat klanten hun telefoon gebruiken om de kluis te openen waarin hun item zich bevindt tijdens hun reis. Sommige kluizen zijn gekoeld, we hebben onze eigen maaltijdpakketlijn. Een zeer populaire functie van onze mobiele app laat reizigers bieden in veilingen voor achtergelaten items. Fako betaalt vervoersbedrijven het equivalent van een ritprijs per item, wat hun effectieve passagiersaantal aanzienlijk verhoogt. Fako hoeft geen wagenpark aan bezorgvoertuigen te kopen en de vervoerders krijgen meer inkomsten. Het bedrijf bloeit!
De backendsystemen van Fako draaien op Snowflake. Om alles te laten werken moet Fako de netwerkstatus continu bijhouden als ruimtelijk ingeschakelde Snowflake-objecten. Laten we kijken hoe!
Eerst de saaie manier, waarvoor ik mezelf heb gediskwalificeerd door een frequentie te kiezen die Windows geplande taken niet ondersteunen, zou zijn om een Spatial ETL workspace source fmw te kopiëren naar mijn Data Interoperability server en een geplande taak te configureren gebaseerd op de opdrachtregel gedocumenteerd in een logbestand van een handmatige run als de arcgis gebruiker:
Opdrachtregel om deze workspace uit te voeren:
"C:\Program Files\ESRI\Data Interoperability\Data Interoperability AO11\fme.exe" C:\Users\arcgis\Desktop\ContinuousIntegration\VehiclePositions2Snowflake.fmw
Je moet deze optie zorgvuldig overwegen voor jouw situatie, het is robuust en eenvoudig.
Nu voor de niet-saaie manier. Zoals ik zei, heb ik mezelf in deze richting geduwd door te werken met data die bulkgewijs met hoge frequentie wordt bijgewerkt. Ik maak een webtool die de integratie uitvoert en zichzelf aanroept nadat hij heeft gewacht tot de brondata is bijgewerkt.
Whoa een webtool die zichzelf aanroept, geen webhook en geen planning? Het is gek eenvoudig (mogelijk ook gewoon gek).
Ik maakte twee Spatial ETL tools, één echte en één dummy die niets doet, maar dezelfde naam en parameters heeft (geen in dit geval).
Ik heb een geschiedenisitem gedeeld van de dummyversie van VehiclePositions2Snowflake als webtool en de submitJob-URL opgenomen. Het is belangrijk dat de webtool asynchroon is zodat wanneer hij wordt aangeroepen hij de workspace niet blokkeert terwijl hij wacht op een reactie:
https://dev99999.esri.com/server/rest/services/VehiclePositions2Snowflake/GPServer/VehiclePositions2Snowflake/submitJob
Bewerk dan de echte ETL tool, in de laatste HTTP stap, om de submitJob-URL aan te roepen. Voer de tool uit en overschrijf vanuit het geschiedenisitem de dummy webtool.
Ik laat je zelf door de tool surfen maar in principe haalt de bovenste stroom de voertuigdata op en synchroniseert deze met het portal en Snowflake en wacht de onderste stroom hierop en tot 30 seconden verstreken zijn waarna hij de HTTP-aanroep doet.
De Zelfintegrerende ETL Tool
Draai dan gewoon één keer handmatig de webtool en je bent vertrokken, hij zal eindeloos herhalen. Ik zit hier mijn Pro-kaart te verversen (geen cache op de feature service-laag) en zie het transportvloot bewegen.
In Snowflake wordt mijn data ook ververst:
Snowflake console
Terug naar wat saaie details, vergeet niet dat wanneer je Spatial ETL tools publiceert als webtools Data Interoperability geïnstalleerd en gelicentieerd moet zijn op elke tool-hostingserver en wanneer je webverbinding of database-referenties gebruikt zoals ik hier doe, ga naar het menu Tools>FME Opties en exporteer de vereiste referenties (rechtermuisklik voor het menu) naar XML-bestanden, zet deze op je server en importeer ze in de Workbench-omgeving als arcgis service-eigenaar. Als je handmatig een workspace op de server uitvoert moet je mogelijk ook de Python-omgeving wijzigen. Ten slotte, hoewel het blogdownloadbestand een FMW-bestand bevat moet de tool die je publiceert naar je server een ingebedde bron hebben.
Dat was leuk!
