Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Genereren zaakidentificatie ondersteunt gemeentecode niet in multitenant omgevingen (StUF-ZDS) #26

Open
rvanbeek opened this issue Dec 29, 2021 · 1 comment
Assignees

Comments

@rvanbeek
Copy link

In een multitenant omgeving is het van belang dat de gemeentecode bekend wordt gemaakt. Dit is momenteel alleen mogelijk via de stuurgegevens van het StUF-bericht door de 'administratie' te duiden. De documentatie stelt echter dat het zaaknummer vooraf moet worden gegaan door de vier karakters van de gemeentecode.

Dat is momenteel onmogelijk: bij aanroep van genereerZaakidentificatie bericht wordt geen context door de consumer meegegeven, waardoor de provider wel een uniek zaaknummer kan uitgeven, maar dat hier nooit de juiste gemeentecode in kan staan. Aanpassen van dit zaaknummer is volgens de standaard niet mogelijk.

We zijn dan ook op zoek naar de juiste werkwijze om de juiste gegevensverzameling te kunnen duiden in een keten. Dit komt onder meer voor bij samenwerkingsverbanden (vergunningen) en binnen een regionale sociale dienst waarbij één vakapplicatie op één zaaksysteem is gekoppeld.

@michielverhoef
Copy link
Contributor

michielverhoef commented Jan 14, 2022

Het klopt dat de Zaak- Documentservices standaard niet expliciet voorziet in multi-tennant omgevingen. Maar er zijn voor dit probleem meerdere oplossingen mogelijk. Ik ga er in onderstaande vanuit dat de consumer weet voor welke gemeente een zaak aangemaakt wordt. Als dat ook niet het geval is dan wordt het erg lastig.

In ieder geval is het niet verplicht voor de consumer om een zaakidentificatie gegenereerd door het zaaksysteem te gebruiken. Het staat de consumer vrij om een eigen zaakidentificatie te gebruiken. Wel moet deze zaakidentificatie uniek zijn.

Dit biedt de mogelijkheid om bijvoorheeld een zaakidentificatie zonder gemeentecode te laten genereren door het zaaksysteem en als consumer daar zelf een gemeentecode aan toe te voegen. Deze nieuwe zaakidentificatie wordt vervolgens gebruikt om de zaak aan te maken. Weliswaar is deze oplossing niet 100% conform de standaard (want de zaakidentificatie gegenereerd door het zaaksysteem bevat geen gemeentecode) maar voor het overige hoeven er geen aanpassingen aan de koppeling gedaan te worden. De consumer wordt dan wel verantwoordelijk voor het toevoegen van de gemeentecode en het voldoen aan het RGBZ. De provider, het zaaksysteem, moet dit controleren zoals beschreven in paragraaf 4.1.4.1 in de specificatie van de Zaak- Documentservices :

  • Het ZS controleert of toegestuurde zaakidentificaties uniek zijn en voldoen aan het RGBZ.

Een andere mogelijkheid is inderdaad de gemeentecode mee te geven in de stuurgegevens. Hierover is in de Zaak- Documentservices standaard niets beschreven maar in de StUF standaard staat op pagina 44 het volgende:

"Als hierover in het betreffende koppelvlak niets staat beschreven, dan bepaalt de ontvanger van een bericht welke
gegevens er in het element <ontvanger> worden gevuld en met welke waarde (het adres van de ontvanger). De
verzender van een bericht bepaalt zo ook zijn eigen adresgegevens en waarden in het <zender>-element (het adres
van de zender). Partijen mogen geen aanvullende voorwaarden stellen aan het adres van de andere partij, met als
enige uitzondering dat een ontvanger mag eisen van alle zenders waarvan het berichten ontvangt dat al hun adressen
(opgenomen in het <zender>-element) uniek zijn. Een zender moet daarbij altijd een andere combinatie van
organisatie, applicatie en administratie hebben dan een ontvanger. Deze eis geldt voor alle zenders/ontvangers
waarmee een partij te maken heeft.
"

Dit betekent dat het zaaksysteem, de ontvanger van het genereerZaakidentificatie bericht, mag bepalen dat de gemeentecode bijvoorbeeld opgenomen wordt in het stuurgegegeven administratie. De verzender van het bericht, de consumer, moet hier aan voldoen. Hoewel flexibel is dit toch een vorm van per koppeling/implementatie bepalen waar dit gegeven opgenomen wordt.

Daarom ben ik er wel voorstander van dit zoveel mogelijk te standaardiseren en de gemeentecode op te nemen in het stuurgegeven administratie van de ontvanger. Het zaaksysteem kan dan deze gemeentecode gebruiken bij het genereren van de zaakidentificatie. Dit toepassen is dus meer een best practice dan een verplichting, het opnemen in de stuurgegevens kan de ontavnger (het zaaksysteem) al afdwingen met de StUF standaard zoals hierboven beschreven staat.

Dat zou dan neer komen op iets als:

<genereerZaakidentificatie_Di02>
<ZKN:stuurgegevens>
<StUF:ontvanger>
<StUF:organisatie>Duckstad</StUF:organisatie>
<StUF:applicatie>ZaaksysteemXYZ</StUF:applicatie>
<StUF:administratie>9999</StUF:administratie>
</StUF:ontvanger>
...
</genereerZaakidentificatie_Di02>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants