BUG: Opnemen kerngegevens in synchronisatieberichten

17 reacties / 0 nieuw
Maarten van den...
BUG: Opnemen kerngegevens in synchronisatieberichten

Probleem

De StUF0301-standaard stelt op p. 68 onder punt 6: "6.De kennisgevingen binnen een synchronisatiebericht bevatten niet verplicht de kerngegevens, omdat er bij een synchronisatiebericht geen twijfel is over de identiteit van het object." Dit voorschrift is dubbelzinnig. Zo moet het bijvoorbeeld in de toevoegkennisgeving binnen een synchronisatie actueel of binnen oudste in een synchronisatie historisch wel degelijk verplicht zijn om de kerngegevens op te nemen. Binnen de wijzigkennisgevingen in een synchronisatie historisch geeft de huidige formulering de vrijheid om de kerngegevens al dan niet op te nemen. Dit leidt tot diverse implementaties en daarmee tot problemen.

Oplossing

Vervang punt 6 door:

'6. In toevoegkennisgevingen binnen synchronisatieberichten is het opnemen van kerngegevens altijd verplicht (ook als sleutelOntvangend wordt meegegeven). In wijzigkennisgevingen binnen synchronisatieberichten zijn de kerngegevens niet verplicht en mogen uitsluitend elementen worden opgenomen met een andere waarde in "oud" en "nieuw". De kerngegevens zijn in de wijzigingen niet nodig, omdat er binnen een synchronisatiebericht geen twijfel is over de identiteit van het te synchroniseren object.'

Mark Paanakker

Ik vind deze omschrijving nu iets te vrij. De kerngegevens mogen worden weggelaten in de hoofdentiteit bij een wijzigingsbericht in een synchronisatie, Dit geld niet voor de kerngegevens van relaties en gerelateerde entiteiten.

Sid Brouwer

Naar aanleiding van de vraag van Robert in het overzicht met de errata stel ik voor de tekst iets aan te scherpen (als reactie op de opmerking van Mark Paanakker):
"In wijzigkennisgevingen binnen synchronisatieberichten zijn de kerngegevens niet verplicht in de topfundamenteel en mogen ..."

Daarnaast heb ik zelf ook nog een vraag/voorstel. In dezelfde zin staat "en mogen uitsluitend elementen worden opgenomen met een andere waarde in "oud" en "nieuw"". Deze opmerking kan als beperking worden gezien of als een verruiming: alleen de elementen die zijn gewijzigd mogen worden opgenomen of het is toegestaan om het bericht te beperken tot de gewijzigde elementen.

Ik kan mij voorstellen dat het laatste correct is. Daarom zou ik de zin formuleren als " en is het ook toegestaan om uitsluitend elementen op te nemen met een andere waarde in "oud" en "nieuw"".

Ton Timmermans

Ik zou ook graag willen zien dat kerngegevens wel opgenomen mogen worden zelfs als deze niet wijzigen.

Als een systeem de berichten binnen een synchronisatie nu als losse berichten afhandelt, zal het ontbreken van kerngegevens tot problemen leiden.

Henri Korver

Ik begrijp de gedachte van Ton maar er moet een keuze gemaakt worden over het wel of niet verplicht zijn van kerngegevens in synchronisatieberichten anders bereiken we nooit interoperabilitiet. Mijn voorkeur is om geen kerngegevens toe te staan in de wijzigingkennisgevingen binnen het synchronisatiebericht tenzij de kerngegevens zelf wijzigen. Anders worden de synchronisatieberichten onnodig groot. Ik stel voor om punt 6 te vervangen door de volgende tekst:

In toevoegkennisgevingen binnen synchronisatieberichten is het opnemen van kerngegevens altijd verplicht (ook als sleutelOntvangend wordt meegegeven). In wijzigkennisgevingen binnen synchronisatieberichten zijn de kerngegevens niet toegestaan in de topfundamenteel behalve als de kerngegevens zelf wijzigen. De kerngegevens zijn in de wijzigingen niet nodig voor identificatie omdat er binnen een synchronisatiebericht geen twijfel is over de identiteit van het te synchroniseren object.

Ter info: dit erratum staat bekend als ERR242 in de onderhoudsverzoeken.

Robert Melskens

In de StUF Expertgroep van 20 maart 2013 is er voor gekozen de kerngegevens nu nog niet te gaan verplichten. De StUF Expertgroep stelt voor dat een systeem er tegen moet kunnen als de kerngegevens er niet in zitten. Zij wil echter wel zo snel mogelijk voor een groeipad gaan waarin het wel verplicht is. In de StUF standaard gaan we dan ook een waarschuwing opnemen dat we in de toekomst zullen gaan verplichten dat de kerngegevens opgenomen moeten worden. Er is hiervoor inmiddels dan ook al een RFC opgevoerd (RFC0146).

Robert Melskens

In de StUF Expertgroep van 19-6-2013 is besloten dit erratum niet mee te nemen in patch 16. Volgens Maarten van de Broek zou het verplicht maken van kerngegevens ertoe leiden dat bepaalde synchronisaties niet meer uitgevoerd kunnen worden. De gekozen richting is strijdig met het uitvoeren van correcties binnen historie. Besloten is om de oplossingswijze verder te bediscussieren.

Robert Melskens

Het erratum ERR242 is doorgevoerd in patch 20 (1 juli 2014).

In de StUF standaard is geëxpliciteerd dat kerngegevens in synchronisatie op precies dezelfde wijze worden behandeld als de overige gegevens. Ze worden binnen wijzigingen/correcties uitsluitend opgenomen, als dit functioneel vereist is en nooit alleen omdat ze kerngegeven zijn.

Maarten van den...

Inmiddels is bij de wijzigingen ten behoeve van de sleutelSynchronisatie de heldere tekst voorgesteld door Henri in reactie 5 weer gesneuveld. Het lijkt me daarom goed de onderstaande tekst onder het kopje 5.4.3:

"Omdat het te wijzigen of te corrigeren object binnen een Sh01/02-bericht wordt geïdentificeerd met behulp van
StUF:sleutelSynchronisatie zijn de kerngegevens niet verplicht en moet voor alle elementen in 'oud' in
plaats van voor minstens één element gelden dat de waarde van dat element in de registratie voorkomt met het
tijdvakGeldigheid in 'oud'."

te vervangen door

"Omdat het te wijzigen of te corrigeren object binnen een Sh01/02-bericht wordt geïdentificeerd met behulp van
StUF:sleutelSynchronisatie zijn de kerngegevens niet verplicht. Een kerngegeven mag net als de andere gegevens alleen worden opgenomen als het kerngegeven wijzigt of als het kerngegeven één van de gegevens is waarvoor het tijdvakGeldigheid wijzigt. In een wijzigkennisgeving in een Sh01-bericht moet voor alle elementen in 'oud' in
plaats van voor minstens één element gelden dat de waarde van dat element in de registratie voorkomt met het
tijdvakGeldigheid in 'oud'."

Sid Brouwer

De laatste zin in het voorstel vind ik nog niet helemaal duidelijk. Dit komt vooral door de toevoeging "in plaats van voor minstens één element". Waarschijnlijk verwijst deze toevoeging naar de stelling dat in reguliere kennisgevingen de beginGeldigheid gelijk is aan de grootste beginGeldigheid van alle gewijzigde gegevens.

Duidelijker lijkt het mij dit expliciet te maken (als mijn veronderstelling juist is):
In een wijzigkennisgeving in een Sh01-bericht moet voor alle elementen in 'oud' gelden dat de waarde van dat element in de registratie voorkomt met het tijdvakGeldigheid in 'oud'. Dit in tegenstelling tot kennisgevingsberichten, waarin dit voor minstens één element moet gelden.

Robert Melskens

Aangezien het eerder in deze discussie genoemde onderhoudsverzoek ERR242 al is gesloten heb ik een nieuw onderhoudsverzoek opgevoerd in de onderhoudsverzoeken, nl. ONV0398.
De lijst met onderhoudsverzoeken vind je op: 
www.gemmaonline.nl/index.php/StUF-Expertgroep#Documenten

Maarten van den...

Wat Sid voorstelt is inderdaad beter.

Robert Melskens

Op basis van de bovenstaande voorstellen heb ik de bewuste pagina als voorstel uitgewerkt. Zie de bijlage.

Bijlage

stuf0301-ONV0398.zip
Maarten van den...

De verbetering is wat mij betreft correct doorgevoerd.

Robert Melskens

Tijdens de StUF Expertgroep van 16-9-2015 is de in deze discussie voorgestelde oplossing goedgekeurd. Het onderhoudsverzoek is omgezet naar erratum ERR0398.

Robert Melskens

Tijdens de StUF Expertgroep van 16 september 2015 is besloten RFC0146 af te voeren.

Robert Melskens

Tijdens de StUF Expertgroep van 16-9-2015 is de voorgestelde oplossing m.b.t. ERR0398 in de gerelateerde discussie goedgekeurd. Het onderhoudsverzoek is omgezet naar een erratum en is meegenomen in pre-patch 23.