StUF versionering

6 reacties / 0 nieuw
Niek Palm
StUF versionering

Het systeem dat wij ontwikkelen ontvangt diverse soorten StUF berichten en is in staat dynamisch te bepalen welke bericht ontvangen wordt. Voor deze dynamische bepaling, bepalen wij de root element namespace van het ontvangen xml bericht. Vervolgens kunnen wij het bijbehorende schema ophalen op basis van de target namespace die dan gelijk is aan de root element namespace. Hierna weten wij of we b.v. een StUF BG 0204 of willekeurig ander bericht in handen hebben. Bij deze keuze zijn wij ervan uitgegaan dat er slechts 1 versie van StUF BG 0204 bestaat. En wanneer deze gewijzigd wordt, de namespace ook zou wijzigen. Echter nu blijkt dat diverse varianten van een schema met dezelfde target namespace in omloop zijn. Zo kan het voorkomen dat diverse partijen berichten sturen die volgens de namespace StUF BG 0204 zijn maar bij analyse allemaal een net ander schema blijken te gebruiken. In het schema is wel een versie opgenomen (bijvoorbeeld 020401 of 0204.02) maar in het verstuurde bericht is hier geen notie meer van. Op deze manier is het onmogelijk om voor een systeem dat meerdere soorten berichten ontvangt te bepalen aan welk schema (variant van StUF) deze voldoet. Ondanks dat er dus een standaard is, is het niet voorspelbaar wat de structuur van een bericht is dat ontvangen wordt. Een robuuste manier van communicatie tussen systemen wordt zo erg lastig. Ik ben benieuwd of andere partijen ook tegen deze problematiek aanlopen? Is er al eens nagedacht voor een oplossing of is deze er al? Wellicht is het het overwegen waard om de versie en patch revisie onderdeel uit te laten maken van de namespace.

Met vriendelijke groet, Niek Palm (Atos Origin)

Henri Korver

Hallo Niek,

De laatste patch van een sectormodel is de enige versie die geldig is. Alle voorgaande versies van het schema zijn bij het uitkomen van een nieuwe patch verouderd en mogen niet meer worden gebruikt. Wanneer een binnenkomend StUF-bericht voldoet aan het schema van de laatste patch dan is het een geldig bericht en anders niet. De namespace hoeft dus niet veranderd te worden. Voordelen:

Minder aanpassingen in de software omdat de namespace niet wordt veranderd.
Men wordt gedwongen om over te gaan op de nieuwe patch ipv te blijven kleven aan oude versies/patches

Mvg,
Henri Korver

Niek Palm

In de praktijk blijkt helaas dat er diverse versies van applicties in veld staan (van verschillende leveranciers). Het kan zo zijn dat deze applicateis niet altijd dezelfde patch van StUF024 gebruiken. Van een applicatie zal niet altijd een versie beschikbaar zijn met de laatste versie van StUF. Tevens is het ook niet mogelijk om elke applicatie op hetzelfde moment te upgraden naar de laatste patch. Er zijn dus diverse redenen waarom applicaties niet altijd de laatste versie van StUF zullen spreken. Ook bij een groeiend appliactie landschap zal het zeer ingewikkeld zijn om er altijd voor te zorgen dat de elke applicatie de laatste (juiste) versie van StUF spreekt.
Wanneer een applicatie met diverse andere applicatie berichten uitwisselt (b.v. een distributie system of een gegevensmagazijn). Is het voor deze applicaties niet te voorspellen wat het precieze StUF0204 dialect is. Integratie van applicaties wordt op deze manier wel zeer ingewikkeld. Automatisch berichtenverkeer wordt zo erg ingewikkeld omdat niet te voorspellen is aan welke schema een inkomend bericht voldoet. In de praktijk zal dit dus niet altijd de laatste versie zijn.
Vanuit dit standpunt denk ik dat het wenselijk / noodzakelijk is om toch een oplossing voor dit probleem te zoeken, bijvoorbeeld door het aanpassen van de namespace. Waardoor aan het bericht direct herkenbaar is aan welke patch deze voldoet.

John Rooijakkers

Beste bezoeker,

Het is belangrijk om in deze discussie onderscheid te maken tussen een nieuwe versie en een patch van een sectormodel. Bij een nieuwe versie wordt functionaliteit toegevoegd, gewijzigd of verwijderd en hierbij wordt ook een nieuwe namespace gebruikt. Bij een patch wordt een fout hersteld zonder dat daar de oorspronkelijk BEOOGDE functionaliteit gewijzigd wordt. Een patch is het gevolg van de constatering dat de oorspronkelijk beoogde functionaliteit foutief of onvolledig ge√Įmplementeerd was en daarmee feitelijk ook niet praktisch werkbaar was.
Indien je bij patches ook gaat werken met verschillende namespaces, betekent dat enerzijds dat ieder systeem ook het patch level moet kunnen verwerken van het systeem waarmee gecommuniceerd wordt. Voor verschillende versies van een sectormodel is dit al een hele opgave, voor patches lijkt me dat praktisch niet werkbaar (en betaalbaar).
Overigens is dit een onderwerp dat al eens vaker in de StUF expertgroep besproken is. Wellicht is het een goed idee indien een StUF deskundige vanuit jullie bedrijf in deze groep aansluit. We komen maandelijk (derde woensdagochtend)bijeen in Utrecht. Nadere info is te verkrijgen bij Henri Korver.

Met vriendelijke groet,
John Rooijakkers
PinkRoccade Local Government.

Niek Palm

Ik kom toch nog even graag terug op de discussie. Ten eerste ben ik erg benieuwd of de discussie mbt. tot versionering die reeds eerder schijnt gevoerd te zijn nog ergens na te lezen is. Zo ja hoor ik graag waar.

De discussie mbt tot versionering richt zich wat mij betreft alleen tot patches aangezien bij een release de namespace al aangepast wordt. Ten eerste wordt aangegeven dat het aanpassen van namespaces veel impact heeft op huidige applicaties, dit begrijk ik wel, echter het standpunt dat elke applicatie zo spoedig mogelijk op het laatste patchlevel moet zitten heeft uiteraard ook veel impact en brengt kosten met zicht mee. Voor mij is het niet duidelijk of ik van een patch mag verwachten of deze backwards compatible is met de vorige patches en de bijbehordende release. Wanneer dit niet het geval is betekent dit weer dat applicaties robust moeten zijn voor wijzigingen in het schema. En er niet op vertrouwd kan worden dat een bericht voldoen aan het schema wat de applciatie kent. Want in de praktijk zullen echter niet alle applicaties altijd het laatste patch level kennen.

Een ander knelpunt dat wij tegenkomen is de hoek van versie / namespaces is dat er ook leveranciersspecifieke varianten van StUF bestaan die dezelfde namespace gebruiken als b.v. StUF0204. Hierdoor idoor een andere systeem niet te herkennen dat het om een afwijkend van de standaardbericht gaat. Automatische verwerking wordt hierdoor ook lastiger.

Verder ga ik bekijken of wij ook aan de Expert groep kunnen deelnemen.

Met vriendelijke groet, Niek Palm (Atos Origin).

Anoniem

Dit onderwerp staat voor morgen (21 okt) op de agenda in de StUF expertgroep. Zie ook de onderstaande memo:

https://www.surfgroepen.nl/sites/stuf/Shared%20Documents/1_StUF_Expertgr...