DSO Viewer APIs — Presentatie¶

Documentatie in ontwikkeling

De Nederlandse vertaling van deze pagina is nog niet beschikbaar. Raadpleeg de Engelse versie voor de huidige inhoud. De dia's zelf zijn Engelstalig.

Een technische presentatie van dertien dia's over de manier waarop de DSO Viewer in LDE met het Digitaal Stelsel Omgevingswet communiceert: de proxylaag, de zes bovenliggende API's, welke aanroepen elk tabblad doet, hoe het dossier van een activiteit wordt samengesteld, en de openstaande punten. Zie DSO-integratie voor dezelfde stof in lopende tekst.

Downloaden

DSO Viewer APIs Deck (PDF, 184 KB)

De presentatie is ontworpen op basis van docs/dso-viewer-apis.md in de linked-data-explorer-repository en als dia's geëxporteerd. Deze versie is die van 24 september 2026, bij LDE v2026.09.6. Het is een momentopname, geen actuele weergave.

Architectuur¶

Dia 1 van 13, titeldia: DSO Viewer — API Reference, met onderaan drie kengetallen — 6 bovenliggende DSO-API's, 16 LDE-proxyendpoints, 2 omgevingen die met één header worden geschakeld — Zes API's, zestien proxyendpoints, twee omgevingen

Dia 2 van 13, het aanroeppad: DsoExplorer.tsx met vier tabbladen naar dsoService.ts naar de LDE-proxy op /v1/dso/* naar dso.service.ts naar het DSO, zes afzonderlijke publieke diensten — de frontend benadert het DSO nooit rechtstreeks — Elk verzoek loopt via de LDE-backend

Dia 3 van 13, wat de proxylaag oplevert: de API-sleutel blijft server-side, één header (X-Dso-Env) schakelt tussen pre-productie en productie, en HAL-antwoorden worden ongewijzigd doorgegeven binnen de success-data-envelop — Sleutel, omgeving en payload — de drie redenen voor de proxy

De zes bovenliggende API's¶

Dia 4 van 13, zes bovenliggende DSO-API's met hun paden, in een raster van drie bij twee: Stelselcatalogus, RTR Gegevens, Zoekinterface, Opvragen Werkzaamheden, Toepasbare Regels Uitvoeren Gegevens en Omgevingsdocumenten Presenteren (Ozon) voor regelingen zoeken, de annotatiegrafiek en documentonderdelen achter het activiteitendossier — De zes API's achter één `/v1/dso`-oppervlak — Ozon is de nieuwste

Dia 5 van 13, vier tabbladen en zes API's: Concepts gebruikt API 1, Werkzaamheden gebruikt API 3 voor zoeken en suggesties en API 4 voor versiedetail, Activities gebruikt API 2 voor lijst en detail en API 5 voor het regelpaneel, en Quality Profile gebruikt API 2, 5 en 6 in één aanroep

Welk tabblad welke API aanroept — het vierde bereikt er drie in één aanroep

Het dossier en het kwaliteitsprofiel¶

Eén aanroep verbindt drie API's; het profiel scoort op twee assen en houdt het daarbij

Activiteiten en de fan-out¶

Dia 7 van 13, activiteiten laden in twee modi: op datum (per 20 gepagineerd) of op bestuurslaag en bevoegd gezag, waarbij één aanroep de volledige set ophaalt zodat het naamfilter client-side werkt — 342 gemeenten, 12 provincies, 21 waterschappen en 12 ministeries. De RTR levert alleen een code zoals GM0995, dus de keuzelijst heeft een eigen namenlijst nodig; de RTR wil dd-MM-jjjj en Ozon JJJJ-MM-dd, dus de backend converteert per API — Twee laadmodi: op datum, of de hele set van één bevoegd gezag

Dia 8 van 13, een activiteit openen kost 1 + N verzoeken: de RTR levert onderliggende activiteiten als kale links zonder omschrijving, dus het paneel vraagt elke onderliggende activiteit apart op — 24 aanroepen voor Bedrijfsactiviteiten met 23 kinderen, nu vijf tegelijk, en het detail wordt vijf minuten gecachet zodat opnieuw openen binnen dat venster niets kost — De zwaarste interactie in de viewer — `1 + N` aanroepen, vijf tegelijk

Toepasbare regels¶

Dia 9 van 13, van regelbeheerobject naar regelbestand: geselecteerde activiteit, regelBeheerObjecten, functioneleStructuurRef en identifier — en daarna één upstream-endpoint met drie acties (STTR downloaden, DMN extraheren, formulierscaffold genereren) — Eén STTR-download, drie verschillende bewerkingen

Dia 10 van 13, vijf correcties maken STTR-uitvoer uitvoerbaar: DMN 1.2 naar 1.3, ontbrekende id's, FEEL-veilige variabelenamen, typeRef op ongetypeerde uitvoer en camunda:historyTimeToLive per beslissing — Wat `normalizeDmnForOperaton` aanpast

Dia 11 van 13, een DMN publiceren is een overdracht en geen opslag: LDE heeft geen eigen DMN-opslag, dus de deep link naar de CPSV Editor draagt alleen identificatoren en de CPSV Editor haalt de XML zelf op bij dezelfde backend — De deep link draagt identificatoren; de CPSV Editor haalt de XML zelf op

Status en vervolg¶

Dia 12 van 13, bekende losse eindjes: zoeken op geometrie is gebouwd maar niet ontsloten in de UI, geldigOp op begripzoeken heeft geen invoerveld, en de App Service-runtime is alleen op een hoofdversie vast te zetten, zodat die en de vastgelegde Node-versie met de hand en in de juiste volgorde moeten worden verzet — Drie bekende gaten: twee onbereikbare functies en één operationeel risico

Dia 13 van 13, vervolgstappen: kaart- en puntselectie, geldigheidsdatum in de UI, en een eigen timeout en defaults voor productie — Drie vervolgstappen — twee van de vijf uit augustus zijn in v2026.09.6 opgeleverd