FME - Esri integratie

Momenteel wordt onder elke FME Flow Engine Service node een ArcGIS Server licentie gebruikt. Met de hoeveelheid FME omgevingen, lab en OTAP, is dit best een grote investering. In dit document worden toekomstige alternatieven beschreven maar deze alternatieven zijn op het moment van schrijven nog niet haalbaar aangezien > 90% van de workflows afhankelijk is van SDE databases. Het probleem zit het dus vooral in de datalaag van RWS.

Op de FME website is vrij duidelijk aangegeven voor welke functionaliteit een ArcGIS Server licentie benodigd is. In zijn algemeenheid kan je zeggen dat er 2 functionaliteiten zijn die dit nodig hebben:

•  om verbindingen te maken met Esri binaire geodatabase opslag
• om ArcPy scripts te kunnen inzetten

Grofweg zijn er 2 alternatieven te benoemen:

1. middels queue control slechts een deel van de nodes uitrusten met Esri integratie, grofweg zou dit potentieel een besparing van de helft van de ArcGIS Server licenties kunnen opleveren
2. helemaal geen tight integration meer hebben tussen FME and ArcGIS, maar werken op basis van services

In het verleden was er ook wat onduidelijkheid of ArcGIS Pro ingezet mocht worden onder FME Flow, maar inmiddels is duidelijk dat dit niet toegestaan is.

Scenario 1: queue control

Middels queue control kunnen jobs die de Esri integratie benodigen worden doorgeleid naar de specifieke node welke de tight coupling met Esri tot zijn beschikking heeft. De andere node kan dan alle jobs opvangen die niet afhankelijk zijn van ArcPy of Esri binaire formaten. Het probleem is dat we momenteel geen inzicht hebben in welk percentage van de jobs, of welk percentage van de job duur, afhankelijk is van Esri integratie. Dit zouden we eigenlijk wel tot onze beschikking moeten hebben om hierop een juiste afweging te kunnen maken. Wat ook mee speelt is dat de Esri drivers alleen op Windows beschikbaar zijn, dus wanneer we naar OpenShift toe gaan dan is queue control in principe sowieso benodigd om de Esri specifieke jobs naar Windows VMs toe te leiden. Tenzij Safe op tijd de Linux ondersteuning gereed heeft. Je zou ook kunnen overwegen om queue control op bepaalde omgevingen in te zetten die wat minder intensief gebruikt worden, zoals de lab omgeving en de OTA, maar dit heeft als nadeel dat deze omgevingen dan weer geen exacte afspiegeling van de productie omgeving meer zijn.

Scenario 2: geen tight integration

Dit scenario heeft best veel invloed op de gebruikers van het FME platform. In de huidige situatie waarin de datalaag bij RWS nog veel geometrieën worden opgeslagen in binaire Esri formaten (ST_GEOMETRY) is het misschien geen haalbare kaart. Maar het is wel iets om over na te denken. Het zou betekenen dat je bijvoorbeeld ArcGIS FeatureServices aanroept in plaats van directe calls op de database. En dat je bijvoorbeeld geoprocessing services aanroept op ArcGIS Enterprise om bewerkingen te doen die je normaal gesproken in ArcPy zou doen. Het aanroepen van services heeft wel wat latency tot gevolg, en gevoeligheid voor netwerk storingen. Maar als je bijvoorbeeld kijkt naar waar Esri naar toe beweegt met branch versioning, waarbij de interactie altijd via een service moet lopen is dit misschien wel de meest toekomstvaste optie en zou het een grote besparing van Esri licenties kunnen opleveren, en zou het FME platform zonder WIndows VMs op OpenShift kunnen draaien. Probleem is wel dat we niet genoeg inzicht hebben in hoe de huidige gebruikers van het FME platform de Esri integratie inzetten en hoe zij er tegenover zouden staan. In het verleden zijn er ook problemen geweest met 32-bit/64-bit compatibility tussen FME en ArcPy, waar de services integratie optie ook niet gevoelig voor is. Het zou misschien wel betekenen dat de huidige licenties van ArcGIS Enterprise een zwaardere belasting te verwerken zouden krijgen, waardoor potentieel het licentie gebruik aan die kant juist weer uitgebreid zou moeten worden, dus dit is een lastig vraagstuk om te concretiseren.

Een alternatief voor ArcPy kan naast het aanroepen van geoprocessing services ook het gebruik van open source tooling zoals shapely, rasterio, Fiona, GeoPandas of GDAL e.d. in FME zijn. Maar dit vergt ook inzicht in waar afnemers van het FME platform nu ArcPy voor inzetten, wat naar mijn weten ontbreekt.

Ook zouden we Notebook Server voor ArcGIS in kunnen zetten om de ArcPy workloads zonder tight integration te kunnen draaien.