-
Notifications
You must be signed in to change notification settings - Fork 3
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
Comments
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 :
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 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:
|
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.
The text was updated successfully, but these errors were encountered: