Het lijkt geen overbodige luxe om het Best Practices document van StUF uit te breiden met een paar efficiënte richtlijnen rondom het gebruik van dienstberichten (persoonlijk vind ik dat een betere naam dan vrije berichten). De vraag is wanneer gebruiken we dienstberichten (Di, Du) en wanneer de standaard berichtsoorten (Lk, La, Sa, Sh) van StUF zoals:
- kennisgevingen
- samengestelde kennisgevingen
- synchronistatieberichten
- vraag/antwoordberichten
Als gekozen is voor dienstberichten dan is er een nog een belangrijke vraag: Maak je in het dienstbericht wel of niet hergebruik van de bovengenoemde standaardberichten? Als we hierover geen best practices hebben afgesproken moeten we dezelfde discussie elke keer opnieuw voeren bij bijvoorbeeld de nog door operatie NUP op te leveren koppelvlakken. Als startpunt kunnen we analyseren waarom dienstberichten zijn gebruikt in (bestaande) sectormodellen/koppelvlakken zoals
- Prefill eFormulieren,
- Invorderingen & Betalen,
- Zaakdocument services,
- StUF-WOZ
- StUF-HR
- Etc.
en van daaruit algemene regels destilleren. Dit onderwerp staat op de agenda van de aankomende StUF Expertgroep van 19 februari. Bij deze nodig ik iedereen uit om alvast hier op het forum te reageren. Dus schroom niet om op deze post te reageren als je een best practice hebt voor het wel of niet gebruiken van dienstberichten...
Ik ben van mening dat er geprobeerd moet worden om zoveel mogelijk met 1 berichtendefinitie gecommuniceerd moet worden. Daarmee bedoel ik dus dat het StUF berichten verkeer een container moet zijn om sector specifieke gegevens te transporteren, en dat de berichtdefinitie zoveel mogelijk herbruikbaar moet zijn, zonder allerlei nieuwe webservices of definities voor elk denkbaar functioneel scenario te maken. Belangrijkste hierbij is om de syntax en objectstructuur van deze gegevens correct te definieren via schema's. De inhoudelijke vulling van deze gegevens wordt echter bepaald door een bepaald scenario, en zou in mijn beleving niet door het schema (dus xsd) afgedwongen moeten worden, omdat hierdoor een enorme overhead aan documentatie, versies en incompatibiliteitsproblemen ontstaat, terwijl in essentie dezelfde objecten gecommuniceerd worden. Het herkennen van het gebruik van de gegevens en daarmee context geven van de vulling in het bericht, en welke elementen wel of niet verplicht of mogelijk gevuld zijn, afhankelijk het gebruik, zou heel eenvoudig kunnen worden gespecificeerd door het element 'functie' in de stuurgegevens te vullen. De omschrijving van verschillende functie-namen en de bijbehorende eisen aan de vulling van een bericht kan beschreven worden in specifieke koppelvlakken die gebruik maken van StUF berichten.
Dit zal in de huidige StUF-sector modellen niet lukken omdat Functie standaard niet meegestuurd mag worden in kennisgevings- of vraagberichten. Dit betekent dat er voor nieuwe koppelvlakken die bestaande object-berichtdefinities zouden willen hergebruiken, toch dienstberichten gemaakt moeten worden omdat dit de enige manier is om de functie van berichten, en de bijbehorende vulling-validatie te kunnen communiceren.
Ik ben namens Roxit dus voorstander om de herbruikbaarheid van StUF Sector modellen te vergroten door minder restricties in de generieke bericht-definities op te nemen, maar deze uitsluitend te verscherpen in documentatie, en hiernaar te verwijzen in het bericht met 1 element (voorstel: functie). Hierdoor wordt veel documentatie herbruikbaar, evenals allerlei onderdelen van de software. Ook wordt hiermee de noodzaak van Dienstberichten beperkt tot uitsluitend gebruik wanneer er nieuwe object-types gecommuniceerd dienen te worden.
Vanuit Centric zijn wij van mening dat vrije berichten moeten worden ingezet voor de berichtdefinitie van services waarin andere functionaliteit wordt geboden dan het doorgeven van toevoegingen, wijzigingen en verwijderingen van gegevens en het opvragen ervan op basis van een informatiemodel. Deze zienswijze is ook vastgelegd in de inleiding van hoofdstuk 7 van de beschrijving van StUF (stuf0301.pdf). Aangezien de prefill services in de huidige opzet niets meer zijn dan het opvragen van RSGB-data, kunnen die ons inziens zonder problemen worden gerealiseerd met StUF-BG 0310 vraagberichten. Net zoals de ZDS-specificaties waar mogelijk worden ingevuld met StUF-ZKN 0310 vraagberichten. Wat dat aan gaat zouden wij willen stellen dat het niet alleen toegestaan moet zijn deze vraagberichten te gebruiken, maar dat tevens de reeds gedefinieerde vrije berichten niet in de standaard worden opgenomen. De StUF-EF berichtdefinities zijn nu opgezet als kennisgevingen. Dat zouden volgens ons dus eigenlijk vrije berichten moeten zijn. Daarbij willen wij stellen dat als in koppelvlakken gebruik gemaakt wordt van een deel van de functionaliteit van bestaande berichtdefinities (bijvoorbeeld een vraag-/antwoordspel waarbij in ieder geval een gegeven set aan criteria moet kunnen worden gebruikt en een minimaal aantal gegevens in het antwoord moet worden opgenomen), dit zoveel mogelijk zo wordt gedaan dat hiervoor geen nieuwe berichten hoeven te worden gedefinieerd. Met andere woorden: een systeem dat de standaardberichtenset zover heeft geïmplementeerd dat minstens de gevraagde functionaliteit wordt geleverd, kan onveranderd worden ingezet voor invulling van het koppelvlak. Een voorbeeld: als een koppelvlak stelt dat er minstens een NPS moet kunnen worden bevraagd op BSN, waarbij minimaal de NAW-gegevens worden teruggeleverd, dan moet een systeem dat alle NPS-vragen ondersteunt en daarbij mogelijk ook nog de geboortegegevens terug kan geven niet te hoeven worden aangepast om aan (dat deel van) het koppelvlak te kunnen voldoen.