In het StUF testplatform, bij Zaak- en Documentservices 1.2 bij volgnummer 5 van updateZaak_ZakLk01 (P) wordt de relatie-entiteit 'leidtTot' opgegeven, maar in het ZDS 1.2 staat deze relatie-entiteit niet gespecificeerd. Is dit een fout in de test?
do, 3-08-2017 - 14.21u
#1
leidtTot in updateZaak_ZakLk01
Dit is een lastige want in de specificaties staat op pagina 24 onderaan:
Volledige RGBZ-ondersteuning
Indien het ZS het RGBZ 1.0 volledig ondersteunt, geldt dat alle RGBZ-attributen en relaties die niet genoemd zijn in de tabellen, maar volgens StUF-ZKN wel in een zakLv01/ zakLa01 voor mogen komen, geretourneerd moeten worden indien een ZSC hierom vraagt.
Voor vraag-/antwoordberichten geldt dat de ZSC niet naar andere elementen/attributen mag vragen dan gespecificeerd in het antwoordbericht, tenzij het ZS het RGBZ volledig ondersteunt.
Elementen die niet zijn opgenomen in de tabellen, mogen wel voorkomen in een kennisgevingsbericht zolang dat bericht voldoet aan de StUF-ZKN-schema’s. Echter, de verwerking van deze elementen wordt niet door deze specificatie afgedwongen.
Jullie bouwen momenteel RGBZ 2 in, hierover wordt niets gezegd in de ZDS 1.2 specificatie. Technisch gesproken zou je dat als ontsnappingsclausule kunnen zien maar zoals het laatste deel aangeeft, zolang het bericht voldoet aan de StUF ZKN schema's, waarop de berichten van de Zaak- Documentservices gebaseerd zijn, mag het. Alleen is een zaaksysteem niet verplicht die gegevens ook te verwerken.
Hallo Michiel, deze teststap is specifiek bedoeld om de "Volledige RGBZ ondersteuning" te testen. Dus zijn de volgende relaties opgenomen:
• heeftAlsDeelzaak
• heeftBetrekkingOpAndere
• leidtTot
Het ontvangende systeem hoeft deze gegevens niet te verwerken, maar moet er wel tegen kunnen dat het StUF Testplatform deze stuurt.
Ik begrijp je opmerking "Jullie bouwen momenteel RGBZ 2 in" niet. In de testset van het Testplatform wordt toch niks gedaan met RGBZ 2? Of wie bedoel je anders met "jullie"?
Excuses, ik vergat even dat ik voorheen al contact had gehad met Alexander en wist dat hij momenteel bezig is met het maken van een zaaksysteem op basis van RGBZ2. "Jullie" is dus in dit geval Alexander en zijn collega's, niet het StUF test platform.
In het geval dat het ontvangende systeem een van deze relaties niet verwerkt, hoe wordt het verzendende systeem hierover bericht? Mijn vraag is eigenlijk, hoe wordt de situatie voorkomen dat het verzendende systeem denkt dat een van deze relaties is opgeslagen, maar dat dit in werkelijkheid niet is gebeurd?
Het afhandelen van fouten staat beschreven in de StUF standaard paragraaf 4.4 pagina 45 en verder.
In de WSDLs staan het Fo01 foutbericht dan ook opgenomen voor de asynchrone services en het Fo02 foutbericht voor de synchrone services.
Dus als het verwerken van een kennisgeving niet lukt moet het ontvangende systeem een Fo01 of Fo02 foutbericht terugsturen.
Edit: collega Frank wees me er net op dat bovenstaande natuurlijk niet afdekt hoe een ZS aan moet geven dat bepaalde gegevens uit een kennisgeving niet verwerkt zijn omdat ze weliswaar wel toegestaan maar niet op genomen zjin in de Zaak- Documentservices. Hier kom ik nog op terug.
Het is niet mogelijk om dynamisch te controleren of een ZS gegevens die niet in de standaard staan ondersteunt.
In principe hoeft dat ook niet, bij de inrichting is bekend wat de betrokken systemen wel/niet ondersteunen en wordt het berichten verkeer ingericht. Het is geen dynamische omgeving waarbij een applicatie eerst uitvraagt wat wel/niet verwerkt kan worden en op basis daarvan een bericht stuurt.
Een ZS hoeft volgens de standaard dus ook geen services te ondersteunen om deze informatie te kunnen geven. Wat wel/niet uitgewisseld wordt bepaal je bij de inrichting.