In de ZSDMS specificatie staat het volgende opgenomen:
Volledige RGBZ-ondersteuning
Indien het ZS het RGBZ volledig ondersteunt, geldt dat alle RGBZ-attributen en relaties die niet genoemd zijn in bovenstaande tabellen, maar volgens de StUF-ZKN wel in een zakLk01 voor mogen komen, verwerkt moeten worden door het ZS indien deze aanwezig zijn in het bericht.
Bij een klant is nu het volgende issue ontstaan:
- de ZS consumer levert de relatie ZAKBSL mee in een updateZaak bericht
- Het ZS (provider) keurt dit bericht af omdat het versie 1.1 van de specificatie ondersteunt.
Naar onze mening mag de ZS consumer de genoemde relatie meesturen. Het ZS (provider) hoeft deze niet te verwerken als zij aangeven niet het volledige RGBZ te ondersteunen. Het ZS (provide) mag het bericht naar onze mening NIET afkeuren.
Graag horen wij de mening van KING op deze discussie.
In Zaak- Documentservices 1.1 is het toegestaan een relatie ZAKBSL mee te sturen in een zakLk01 bericht in de functie van updateZaak (zie pagain 39 en 40 van de specificaties van Zaak- Documentservices 1.1). Het updateZaak bericht zoals gespecificeerd in Zaak- Documentservices 1.2 (met als rootnode "updateZaak_ZakLk01") is niet geldig volgens de ZDS 1.1 schema's (die nog uitgaan van de reguliere StUF ZKN berichten zoals zakLk01 etc.)
Tot slot staat in ZDS 1.1 op pagina 42 bovenaan bij de beschrijving van de service updateZaak het volgende:
Volledige RGBZ-ondersteuning
Indien het ZS het RGBZ volledig ondersteunt, geldt dat alle RGBZ-attributen en relaties die niet genoemd zijn in bovenstaande tabellen, maar volgens de StUF-ZKN wel in een zakLk01 voor mogen komen, verwerkt moeten worden door het ZS indien deze aanwezig zijn in het bericht.
De relatie ZAKBSL is toegestaan in het schema van zakLk01 (StUF ZKN 03.10) dus zolang het bericht volgens dat schema goedgekeurd (en correct is volgens de StUF regels) wordt lijkt mij dat de aanwezigheid van een ZAKBSL relatie geen reden moet zijn om het bericht af te keuren.
Hebben jullie die bericht al getest ten opzichte van het StUF Test Platform? Ik ben wel benieuwd wat daar uit komt.
De vraag over het STP zal ik voorleggen aan mijn collega's maar die heeft momenteel vakantie.
Ik heb het volgende geconstateerd bij het verifiëren van de standaarden:
In RGBZ 1.0 worden de besluitidentificatie, de besluitdatum en de ingangsdatum verplicht gesteld (volgens https://www.gemmaonline.nl/index.php/Rgbz_1.0/doc/objecttype/besluit). In ZS-DMS 1.1 (oftewel StUF-ZKN 3.10 in dit geval) valt de ingangsdatum echter buiten de XSD restrictie (zie XSD type "BSL-kerngegevensKennisgeving").
Hiermee is het volgens de standaarden onmogelijk om een besluit bij een zaak op de juiste manier te verwerken via ZS-DMS 1.1. Versie 1.2 van de Zaak- en Documentservices standaard lost dit op door een ander XSD type ("VoegBesluitToe-BSL-kennisgeving") te gebruiken in een ander bericht "voegBesluitToe_Di01".
Als het bovenstaande inderdaad klopt en als een afkeuring door de ontvangende applicatie niet mag, dan impliceert het bovenstaande dat besluiten die met ZS-DMS 1.1 via een updateZaak bericht binnenkomen, genegeerd moeten worden om een afkeuring te voorkomen. Kunnen jullie je hierin vinden?
Overigens, het bericht "voegBesluitToe_Di01" is een vrij bericht dat opgenomen is in de WSDL van "OntvangAsynchroon" i.p.v. die van "VrijeBerichten". Is dat een bewuste keuze geweest?
Beste Laurens,
Helaas kloppen je aannames en conclusies niet. Het complexType BSL-kerngegevensKennisgeving bevat de kerngegevens die dienen ter identificatie van een besluit. Dat besluit is al eerder in een Besluit-kennisgeving (bslLk01 of bslLk02) aangemaakt.
Immers, in een kennisgeving kunnen gerelateerden nooit worden aangemaakt, alleen relaties gelegd (of verbroken) worden.
In een zakLk01 (zaak kennisgeving, basis voor updateZaak) kunnen dus geen besluiten aangemaakt worden, alleen de relatie tussen een zaak en een besluit gelegd worden.
In de ZDS 1.1 zijn nog geen services beschreven voor het werken met besluiten. Dit zou dan volgens de reguliere StUF ZKN berichten moeten. Omdat het nogal bewerkelijk is om eerst een besluit toe te voegen in een bslLk01 en dat vervolgens aan een zaak te koppelen met een zakLk01 is besloten in ZDS 1.2 een vrij bericht te maken waarin zowel een besluit opgevoerd kan worden als de relatie met de zaak gelegd kan worden. Maar dit is een vrij bericht, geen standaard StUF ZKN bericht.
Het opnemen van het voegBesluitToe_Di01 bericht in de WSDL OntvangAsynchroon komt doordat het een asynchroon bericht is. In de vrijeberichten WSDL wordt gebruik gemaakt van de service VerwerkSynchroonVrijBericht en dat zou niet correct zijn. In de StUF protocolbindingen staat bij het portType ontvangAsynchroon (pagina 9):
OntvangAsynchroon
Het element <portType> heeft als waarde voor het name attribute 'OntvangAsynchroon'. Binnen dit <portType> worden <operation> elementen gedefinieerd voor alle asynchrone berichten, die het systeem kan ontvangen.
Het bericht staat dus in de correcte WSDL.
Beste Michiel,
De tweede alinea in jouw reactie hierboven klopt niet. Binnen StUF is het wel degelijk toegestaan een gerelateerde op te voeren. Daarom is in de gerelateerde de verwerkingssoort opgenomen en mag deze I, T of (in uitzonderingsgevallen) W zijn.
Wijzigen is in principe niet wenselijk en mag dus alleen maar en enkele relaties (te benoemen in het sectormodel), maar toevoegen is dus geen probleem. Uiteraard geldt hierbij duidelijk de beperking dat alleen kerngegevens van het besluit kunnen worden opgenomen. Andere gegevens moeten met een besluit-kennisgeving worden doorgegeven.
Michiel en Sid, hartelijk dank voor jullie uitleg. Ik had niet goed gezien dat de mogelijkheid tot het toevoegen van een gerelateerde entiteit inderdaad kan afwijken in een sectormodel t.o.v. de StUF-standaard (in dit geval met besluiten, zie paragraaf 5.2.7 van "StUF 03.01: In Gebruik" en paragraaf 2.1 van "Ontwerpkeuzen bij het verStUFfen van het RGBZ").
Het zendende systeem verwacht dus dat het ontvangende systeem deze BSL entiteit al kent. Deze moet van tevoren apart toegevoegd zijn, zoals Michiel beschreven heeft. We zullen dit samen verder bekijken. Nogmaals dank voor de informatie!
@Sid: I stand corrected, ik heb de tekst van keuzenVerStUFfing RGBZ als algemeen geldend geïnterpreteerd en dat klopte niet.
@Laurens: mochten er nog onduidelijkheden zijn hoor ik het graag.