Thema Totaal 3D/T3D Pilots/Den Haag/orkestratie
Inhoud
Orkestratie[bewerken]
In Den Haag is na een pakketkeuze in jaar twee, het derde jaar vooral gefocust op workflow automation en orkestratie. In Den Haag is ADF (Azure Data Framework) hiervoor als tooling gebruikt. De ervaringen daarmee en met workflow automation in het algemeen worden hier beschreven.
Voor meer informatie over de keuze voor ADF, zie Thema Totaal 3D/T3D Pilots/Den Haag/orkestratie/pakketkeuze
Werkwijze[bewerken]
ADF is uiteindelijk vooral gebruikt als data orkestratie (workflow automation) tooling, en minder als ETL tooling. Een Azure Blob is gebruikt als opslag en ADF dient ook als middel om de data te benaderen en op te slaan. In de praktijk is er veel gebruik gemaakt van Azure functions om andere componenten aan te roepen wegens een beperking in ADF.
Ervaringen[bewerken]
De ervaringen van Den Haag met Azure ADF zijn wisselend. Er is heel veel in mogelijk, en het biedt goede mogelijkheden om de orkestratie van het proces in goede banen te leiden en te automatiseren. Tegelijkertijd was het vaak best lastig om dingen voor elkaar te krijgen. Dit kan ook met een gebrek aan ervaring te maken hebben (in de loop van het project ging het wel steeds iets gemakkelijker), maar duidelijk is dat er vrij steile leercurve is voor ADF en dat training niet overbodig is. Documenteren binnen ADF is niet altijd even eenvoudig.
Omdat de ETL functie van ADF beperkt tot niet gebruikt is zijn hier geen ervaringen mee opgedaan.
Hieronder is de centrale rol van ADF als workflow automation tool afgebeeld:
Interface[bewerken]
ADF is een tool voor ontwikkelaars. Er is geen gebruiksvriendelijke interface voor de operator. Een aparte interface voor eindgebruikers zal dus nog gemaakt moeten worden. Dat is nu in Den Haag niet gedaan. Dit betekent dat de tool zeker niet voor alle gemeenten geschikt zal zijn. Wel kan het interessant zijn voor marktpartijen om deze tooling te gebruiken in een oplossing.
Autorisatie[bewerken]
In een workflow voor verwerking van 3D gegevens zijn vermoedelijk externe services of externe partijen betrokken. Dat betekent dat er externe toegang nodig is via ADF. Bij inrichting van ADF (of een vergelijkbare tool) moet hier goed over worden nagedacht. Externe toegang is vaak niet meer vanzelfsprekend. ADF kan vanzelfsprekend worden gekoppeld aan AzureAD of vergelijkbare identity providers, maar dat maakt het niet perse eenvoudiger om extern gehoste componenten toegang te geven tot de applicatie.
Opslag van gegevens[bewerken]
Gegevens die vanuit een ander business proces worden ingewonnen, worden vanuit de bijbehorende applicaties ergens opgeslagen. Als deze gegevens in het beheerproces voor 3D registraties gebruikt gaan worden, dan is de vraag of ze gekopieerd gaan worden naar een centrale opslag, of dat ze op de oorspronkelijke locatie blijven staan. Het heeft de voorkeur om bestanden op de oorspronkelijke locatie te laten staan. Duplicatie van gegevens is onwenselijk, en alleen noodzakelijk als er geen garanties omtrent beschikbaarheid van de gegevens op de gewenste bewaartermijn kunnen worden gegeven. Vanuit het beheerproces (en dan vooral de orkestratie daarvan), wordt dan alleen een verwijzing, aangevuld met eventuele metadata opgeslagen in de eigen opslag. Voor bestanden die speciaal worden ingewonnen voor het beheren van 3D gegevens ligt het eenvoudiger. Deze zullen te allen tijde in een daarvoor bestemde speciale database worden opgeslagen (in het proefproject is dit een Azure Blob storage). Om vanuit de orkestratie een eenduidige werkwijze te kunnen hanteren, zal van deze bestanden ook een verwijzing inclusief metadata opgeslagen. Onderstaande figuur geeft dit kort weer.
In Den Haag is voor het proefproject vooral met de tweede methode gewerkt.
Meta-informatie en procesgegevens[bewerken]
Een 3D object registratie dient om bedrijfsprocessen te ondersteunen. Daaruit komen beslissingen, die traceerbaar moeten zijn. Daarom is het van belang om gegevens vast te leggen over de oorsprong en kwaliteit van de data, maar ook over de wijze van verwerking van de data. Is er tijdens de transformatie geen lijntje of vlak verdwenen, heeft de validatie nog rare zaken opgeleverd, etc. Maar ook wanneer is de data ingewonnen, wat is de nauwkeurigheid, wie heeft het ingewonnen, waarvoor is het ingewonnen. Het is dus een combinatie van meta-informatie over de data zelf en proces informatie over de verwerking van de data. In Den Haag worden deze gegevens opgeslagen in de Azure Blob, en zijn ze gekoppeld aan het invoerbestand (net als dat de gecreëerde CityGML). Op die manier is eventueel ook vanuit de uiteindelijke 3D objectregistratie altijd de koppeling naar deze gegevens terug te vinden. Er is ook overwogen om deze informatie te kopieren naar de 3D objectregistratie, maar dat is op dit moment niet het voorkeursscenario. Redenen hiervoor zijn: • Kopiëren van data is in het algemeen onwenselijk als het niet noodzakelijk is • 1 3D object kan in de loop der jaren meerdere bronnen hebben (originele inwinning in 2022, achterkant pand gewijzigd door een uitbouw in 2023, voorkant gewijzigd door een dakkapel in 2024). Overzichtelijk houden wat dan de kwaliteit van het object is, is lastig. Een terugverwijzing naar alle bronnen kan dan bij discussie in ieder geval duidelijk maken welk deel van het pand wanneer is ingewonnen. Afhankelijk van de keuze voor en 3D objectregistratie tool en de mogelijkheden daarvan kan deze keuze nog wijzigen.
Dat betekent dat een koppeling tussen een ingewonnen bestand en een geregistreerd object moet kunnen worden gelegd. Als dat een BIM bestand is van 1 pand, dan is dat overzichtelijk. Als een ingewonnen bestand veel objecten bevat, dan moet daar nog beter naar gekeken worden. Dat is in Den Haag nog niet gedaan.