ZRC 1.5/DRC 1.4 Expand op lijst documenten bij de zaak

[johannesbattjes]

@HenriKorver
Het komt heel vaak voor dat een lijst met documenten bij een zaak wordt getoond.
Daarbij moet ook het documenttype getoond worden.
Dit zou te bereiken zijn met een bevraging op zaken met als filter expand=zaakinformatieobjecten.informatieobject.informatieobjecttype

Dit lijkt niet te mogen door de regel "Er mogen alleen resources uit de eigen registratie opgenomen worden in de expand. Voor Zaken zijn dit de resources die in de Zaken API specificatie beschikbaar zijn, voor Documenten/Informatieobjecten de resources uit de Documenten API specificatie en voor Besluiten die uit de Besluiten API. Daarnaast mogen de relevante typen uit de Catalogi API opgehaald worden."

Het alternatief zou dan zijn een expand te gebruiken op de DRC objectinformatieobject.
Deze expand bestaat echter niet.

De referentieapplicatie staat zaakinformatieobjecten.informatieobject.informatieobjecttype wel toe.

Graag een oplossing en duidelijkheid. Onze voorkeur gaat er naar uit zaakinformatieobjecten.informatieobject.informatieobjecttype toe te staan zodat je met één call alle relevante zaakinfo hebt.
Onze ervaring - en die van de referentie implementatie - is dat het geen probleem is informatie uit drie registraties te halen.

[HenriKorver]

Het alternatief zou dan zijn een expand te gebruiken op de DRC objectinformatieobject.

Dit voorstel is uitgewerkt in pull request #2371 (naar aanleiding van issues #2370 en #1891). Zie de redoc van deze uitwerking.

[johannesbattjes]

Hoi Henri, mooi. Wat is de status van 1.4.4? (Wanneer wordt die gepubliceerd?)
Blijft over ons verzoek om de volgende expand op zaken ook mogelijk te laten blijven:
expand=zaakinformatieobjecten.informatieobject.informatieobjecttype

[joeribekker]

Voordat dit er snel doorheen komt: De regel dat je enkel kan expanden binnen de eigen registratie en naar de Catalogi API toe is er wel met een reden. We moeten niet alle regels overboord gooien zodra het uitkomt.

Daarnaast denk ik dat je onder de streep precies 1 call bespaard hierdoor maar wel veel meer onnodige en onwenselijke verwevenheid krijgt. We hebben ons al eerder afgevraagd: Waar stopt het? Straks komt de vraag om ook de betrokkene uit de BRP te expanden.

De expand naar de Catalogi API was op zich prima. Dit kan uiteindelijk ook doorwerken zodat de "typen" worden overgeheveld naar de relevante APIs zodat een Catalogi API eigenlijk overbodig wordt en de Zaken, Documenten en Besluiten API echt op zichzelf kunnen bestaan.

[johannesbattjes]

@joeribekker Het klopt dat 1 call bespaard wordt: dat is juist mijn verzoek. Ik vind het onterecht dat mijn verzoek nu geassocieerd wordt aan het doorvragen op de BRP want dat is niet mijn voorstel. Ik zou dat ook niet willen om twee redenen: de BRP ligt buiten de ZGW-standaard. En wat ons betreft mogen persoonsgegevens niet zonder meer meegeleverd worden met zaakbevragingen. Om grootschalige datalekken te voorkomen zouden voor de bevraging van BRP andere regels moeten gelden dan voor het bevragen van zaken, bijvoorbeeld qua autorisatie en qua aantallen gegevens die tegelijk geleverd worden.

Waarom vind ik het besparen van die ene call belangrijk? In de eerste plaats: onze ontwikkelteams en die van patners/concurrentie de op Fundament aansluiten vragen er om. Daarnaast heb ik zelf zitten testen met de expands in Fundament. Met de expands kun je ontzettend handig in één request allerlei bevragingen doen waar je vroeger veel requests voor nodig had. Deze regel (alleen binnen registratie en ZTC, maar niet bv DRC en ZRC) voelt als een blokkade om de potentie optimaal te benutten. Ik snap wel dat je rekening moet houden met diepte en performance en dergelijke maar de praktijk leert dat dit nog geen probleem is (in de referentieimplementatie blijkbaar niet en in ons Fundament ook niet). Het is onterecht dat we de potentie van expands niet volledig benutten vanwege een een hypothetisch probleem dat in de praktijk niet blijkt te bestaan.

[joeribekker]

Het is onterecht dat we de potentie van expands niet volledig benutten vanwege een een hypothetisch probleem dat in de praktijk niet blijkt te bestaan.

Ze zijn met reden gesplitst. Ik vind dat je dit te makkelijk bestempeld als theoretisch probleem en heel erg vanuit jullie product beredeneerd.

Ik ben niet perse tegen maar je kan dit niet met hetzelfde gemak doorvoeren als een attribuutje toevoegen.

[EduardWitteveen]

Vanuit het open-webconcept heeft het vinden van een functionele oplossing voor dit probleem prioriteit.

De snelheid serieus probleem is bij de mijnzaken omgeving, waarbij gelukkig de expand op de zaken(zrc) het al een stuk sneller heeft gemaakt.

Het ophalen van de documenten ophalen blijft (te) traag. Onduidelijkheid over de aanpak hierin heeft meteen gevolgen voor het live kunnen zetten van functionaliteiten (het tonen van documenten bij een zaak) bij gemeenten, zelfs voor het afgeven van een goede planning hiervoor.

Meer inhoudelijkheid #2469