Vragen over ZS-DMS koppelvlak 1.1 - Update Zaakdocument

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

6 reacties / 0 nieuw
John Rooijakkers
Vragen over ZS-DMS koppelvlak 1.1 - Update Zaakdocument

Ik heb twee vragen over de service (operatie) "Update Zaakdocument" in ZS-DMS koppelvlak versie 1.1:

1. Er is opgenomen dat de documentinhoud (object.inhoud) verplicht moet worden opgenomen. Is dit ook van toepassing als alleen metaggevens van het document worden gewijzigd en de inhoud niet wordt gewijzigd?

2. Er is opgenomen dat de parameter checkedOutId alleen verplicht is indien het document eerder is opgevraagd via de ‘Geef Zaakdocument bewerken’ service (operatie). Dit suggereert dat een update van een zaakdocument is toegestaan zonder dat het eerst is opgevraagd via de ‘Geef Zaakdocument bewerken’ service (operatie). Is dit inderdaad het geval?

John Rooijakkers

Aanvulling op vraag 1: In versie1.2 van het koppelvlak zie ik dat de inhoud optioneel is gemaakt. Daarmee verwacht ik dat dit ook voor versie 1.1 zou moeten gelden. Wordt dit alsnog als een erratum verwerkt binnen versie 1.1?

Vraag 2 blijft los hiervan open staan.

Issue Manager

Van deze vragen is issue #490059 aangemaakt.

Michiel Verhoef

Alleereerst excuses voor het late beantwoorden van de vragen.

1/ Het is inderdaad niet altijd nodig om de inhoud mee te sturen, wanneer deze niet gewijzigd is is het onnodig. Daarom is issue #490060 aangemaakt om deze wijziging door te voeren in een patch op ZDS 1.1.

2/ Deze vraag lijkt verwant aan deze vraag . Zoals ik daar heb aangegeven is het technisch gesproken (nog) mogelijk om via updateZaakdocument een document aan te passen zonder dat dit uitgechecked is. Als ik heel eerlijk ben heb ik moeite met bedenken wanneer dit zo gedaan gaat worden. Al was het maar omdat je toch zeker wilt weten dat jouw wijzigingen op de laatste versie zijn gemaakt en het onwenselijk is dat iemand er even snel tussendoor een versie in het DMS opslaat.

ERRATUM #490000 is daarom aangemaakt om gebruik van geefZaakdocumentBewerken verplicht te stellen voordat een document via updateZaakdocument gewijzigd wordt.

Het voorstel van ERR #490000 is:

Voorgesteld wordt de standaard (zowel versies 1.1 als 1.2 ) aan te passen door gebruik van updateZaakdocument alleen toe te staan nadat het document via geefZaakdocumentBewerken is opgevraagd en uitgecheckt.

Tenzij er geldige bezwaren en/of goede redenen zijn dit niet door te voeren zal dit ERRATUM met de volgende patch (1 juli 2018) op zowel ZDS 1.1 als ZDS 1.2 doorgevoerd worden.

 

Maarten Rutten

Als ik het goed inschat wordt het lastig om berichten ZKN 3.10 te transformeren naar ZSDMS 1.1 / 1.2 op het moment dat 'geef ZaakdocumentBewerken' verplicht wordt. 

Via ZKN 3.10 is het mogelijk om direct de inhoud van een document te wijzigen. De servicebus die dit verzoek moet transformeren naar ZSDMS wordt door de verplichting van 'geefZaakdocumentBewerken' gedwongen om dit verzoek toe te voegen aan de transformatie.

In mijn ogen is het niet bezwaarlijk om de verantwoordelijkheid voor het toepassen van 'geefZaakDocumentBewerken' bij de applicatie te leggen en deze niet via de standaard af te dwingen.  

 

Michiel Verhoef

Berichten transformeren is iets anders dan een valide proces afdwingen. De berichten logica zou in de applicatie moeten zitten en niet in de servicebus. Zelfs al voeg je een geefZaakdocumentBewerken aanroep toe in de servicebus wanneer een applicatie via een StUF ZKN bericht een document wil wijzigen ben je eigenlijk gewoon te laat. Een document moet eerst uitgechecked worden voordat het gewijzigd wordt, niet pas wanneer een gewijzigd document aangeboden wordt. Want dan weet je nog steeds niet of er intussen andere wijzigingen zijn geweest die weer overschreven worden.

Mocht een applicatie eerst het document opvragen via een StUF ZKN bericht voordat er gewijzigd wordt zie ik geen problemen: De servicebus kan dat bericht gewoon omzetten naar een geefZaakdocumentBewerken bericht en de checkin/checkout informatie ofwel ergens tijdelijk opslaan of meegeven in extraElementen of wat voor creatieve oplossing er ook maar verzonnen kan worden.

Juist het correct laten verlopen van een proces is iets wat je in een standaard gaat afdwingen. Dat een aanpassing in de standaard een stukje werk in een applicatie betekent mag geen reden zijn om de standaard daarom maar niet te verbeteren als dat nodig is. Helemaal niet wanneer het bezwaar zou zijn dat een servicebus een bericht van een sectormodel (in dit geval StUF ZKN) moet transformeren naar een ZDS bericht. De Zaak- Documentservices zijn juist opgezet om het zaakgericht werken scherper te ondersteunen.

Een vakapplicatie zou dan ook gebruik moeten maken van Zaak- Documentservices en niet van StUF ZKN. In ieder geval daar waar de ZDS standaard berichten voor heeft.

In mijn ogen is het juist heel erg bezwaarlijk om een applicatie toe te staan niet "netjes" te werken en bijvoorbeeld een document te kunnen wijzigen zonder dat het eerst uitgechecked is in het DMS. Vaak gaat het goed, en die keer dat het toevallig fout gaat heeft de gebruiker gewoon pech?

Ik ben er dus ook voor om de verantwoordelijkheid voor het toepassen van een correct proces bij de applicatie te leggen maar ook om dit af te dwingen door een procesmatig correcte standaard, in ieder geval voor zover dit mogelijk is. En in dit geval is het mogelijk.