Als leverancier wil ik de extra gegevens die ik nu kwijt in extraElementen ook kunnen gebruiken in de ZGW Api's

[michielverhoef]

...zodat ik mijn bestaande koppelingen correct kan ombouwen.

Toelichting:
In de huidige StUF ZKN en Zaak- Documentservices koppelingen kunnen met behulp van extraElementen gegevens die niet in het RGBZ staan meegestuurd worden. Dit kan zonder dat de standaard aangepast hoeft te worden. Door het construct extraElementen was het ook mogelijk dat providers die het gegeven niet kennen dit zonder fouten te laten negeren.

Met REST is dit lastiger, een resource en attributen moeten wel bestaan bij de provider voordat ze gebruikt kunnen worden in een aanroep. Met andere woorden, je kunt niet zomaar attributen toevoegen, dan wijk je af van de standaard.

De reden voor extraElementen zal ongetwijfeld nog bestaan dus de vraag is hoe daarmee om te gaan in de nieuwe ZGW API's.

NB. Dit hangt ook samen met de vraag in hoeverre de nieuwe ZGW API's hetzelfde kunnen als de huidige StUF ZKN en Zaak- Documentservices. #631.

Bepaling prioriteit door PO

• verbreding of verdieping API's
• stimuleert gebruik door gemeenten
• stimuleert gebruik door leveranciers

... eventueel nog toelichting door PO

Definition of ready

• Iedereen in het team begrijpt de user story
• de gewenste (aanvulling op de) functionaliteit van de API's duidelijk en beschreven is.
• Is klein genoeg (maximaal 1/5 van sprint)
• Product Owner akkoord en voorzien van prioriteit (mag alleen afgevinkt worden door PO)
• Idee hebben van hoe deze user story kan worden gedemonstreerd.
• Globale oplossingsrichting bekend
• Vastgelegd in Github en geplaatst in kolom ready

Definition of done

• Er is een OAS 3.0 specificatie
• Er is een referentieimplementatie
• Er zijn tests aanwezig die de wijziging aantonen en waarmee de user story getest kan worden.
• De technische specificatie (standaard.md) is gepubliceerd leesbaar
• Gebruikte gegevensmodel is na iedere iedere sprint bijgewerkt.

Acceptatiecriteria

• De DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
• Er zijn geen bekende GEMMA tegenstrijdigheden of afwijkingen zijn vastgelegd.

Taken

• Implementeren in referentie-implementatie [verantwoordelijke]
• Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]
• Documentatie bijwerken
• Gegevensmodel bijwerken

[Hugo-ter-Doest]

ExtraElementen zijn een oplossing voor een probleem dat we niet meer zullen hebben met de nieuwe opzet op basis van micro services. Het idee is dat gegevens die buiten de generieke gegevens van ZGW (vroeger RGBZ en imZTC) vallen met gestandaardiseerde objecten worden gerepresenteerd. Dus liever niet met extra attributen in de ZGW API's, maar nieuwe objecten die door andere REST API's worden aangeboden.

[michielverhoef]

Hoewel ik het volledig eens ben met de theorie heropen ik dit issue toch.

Er is nl. (voor zover ik weet) nog niet gekeken naar de gegevens die nu in de extraElementen gebruikt worden en in hoeverre die wel in de ZGW API's zouden passen. Gegevens die nu ontbreken in het RGBZ.

Om een volwaardige release candidate te zijn waar leveranciers mee aan de slag kunnen om hun huidige StUF koppelingen te vervangen zal daar iets voor bedacht moeten worden. Desnoods een patroon waarmee de oplossing gebouwd kan worden maar alleen zeggen dat we het probleem niet meer zullen hebben is iets te optimistisch in mijn ogen. In ieder geval bieden de ZGW API's dan niet alles wat de huidige StUF ZKN en Zaak- Documentservices kunnen.

NB. Dit is ook van belang voor de migratie strategie: Hoe komen we van StUF naar REST?

[Hugo-ter-Doest]

Michiel, dit is niet conform visie van CG en ZGW API's. Graag een nieuwe user story openen zonder referentie aan ExtraElementen en vanuit gemeente geformuleerd. Het gaat erom dat je gegevens die niet in ZGW zitten wilt kunnen registreren gekoppeld aan een van de ZGW resources (wsch. zaak). In de user story de extra benodigde gegevens ook benoemen. Ik sluit hem weer en zie je nieuwe user story graag tegemoet.

[michielverhoef]

Dat is eigenlijk wat ik de leveranciers ook gevraagd heb op de VNG API Community Slack en het StUF Discussieplatform.

[Hugo-ter-Doest]

Dit soort gegevens komen terecht in andere resources (objecten) waar een zaak betrekking op kan hebben (ander zaakobject) ofwel in eigenschappen die bij een zaaktype worden gedefinieerd en die vervolgens als eigenschappen bij een zaak kunnen worden geregistreerd.