Bij het valideren van onze berichten kom ik een tweetal fouten tegen in testregel BGWZ000004. Als ik kijk in de implementatie van deze regel dan wordt het sorteren op rootelement (bij gelijke tijdstipregistratie en tijdvakgeldigheid) gedaan op basis van de onderstaande elementen: gemLk01, wplLk01, oprLk01, pndLk01, aoaLk01, vboLk01, ligstaLk01, ogoLk01, otrLk01.
De eerste fout lijkt te zijn dat ligplaatsen en standplaatsen zijn samengevoegd tot het element 'ligstaLk01', maar dit element wordt niet in alle procesberichten gebruikt. Als ik een bgrBSLSP_Lk03-bericht stuur, dan bevat deze een aoaLk01 en een staLk01 (volgens specificatie), echter dit bericht wordt afgekeurd met de volgende foutmelding in de rapportage: 'Lk01 messages have the wrong order in Lk03 message. Lk01 compared by root name. Incorrectly ordered Lk01 messages are 1, 2'.
De andere fout heeft ook met het sorteren op rootelement te maken. Neem bijvoorbeeld het bgrVBI_Lk03-bericht. Hierin kunnen de volgende kennisgevingen voorkomen: aoaLk01-toevoegen, aoaLk01-afvoeren, pndLk01, ogoLk01, vboLk01-wijzigen, vboLk01-toevoegen, vboLk01-afvoeren. Als ik een bgrVBI_Lk03-bericht stuur met daarin een pndLk01, een aoaLk01-afvoeren en een vboLk01-afvoeren, dan wordt dit bericht afgekeurd. Dit lijkt te komen doordat de rootelementen 'aoaLk01-afvoeren' en 'vboLk01-afvoeren' niet in de sorteerroutine worden meegenomen. Kunnen jullie deze fout bevestigen?
Dag Rob,
Zou je de berichten waar je het over hebt aan deze discussie willen toevoegen?
Groet,
Robert Melskens
Ik heb een bgrBSLSP_Lk03 en een bgrVBI_Lk03 als bijlage toegevoegd. Deze berichten valideren nu wel, maar dat komt omdat ik de tijdstipregistraties kunstmatig heb opgehoogd, zodat hier op wordt gesorteerd i.p.v. op rootelement.
Bijlage
Tweede bericht...
Bijlage
Een ander probleem wat ik ben tegengekomen heeft te maken met testregel STV0000096 in combinatie met de procesberichten bagBN_Lk03 en bagIN_Lk03. Volgens het schema mogen de vboLk01's hierin geen tijdstipregistratie of tijdvakgeldigheid bevatten. Daardoor faalt regel STV0000096 en krijg ik het bericht dus nooit goedgekeurd. Zie ook de bijlagen.
Bijlage
bagIN_Lk03 bijlage...
Bijlage
Ik heb het probleem betreffende de sorteervolgorde bij berichten die een 'staLk01' of 'ligLk01' element hebben eens bekeken.
Ik zie dat er samengestelde berichten zijn waarin i.p.v. het element 'ligstaLk01' het element 'staLk01' of 'ligLk01' wordt gebruikt.
De voorgeschreven sorteervolgorde houdt daar inderdaad geen rekening mee. Ik ga dit punt dan ook als erratum op de BAG berichtencatalogus aanmelden.
Het is mij op dit moment niet duidelijk of het probleem zit in de documentatie dan wel de schema's. Dat zal daarom eerst bepaald moeten worden. De testregel in het StUF Testplatform doet n.m.m. precies wat beschreven is in de documentatie maar moet wellicht aangepast worden indien de documentatie wordt aangepast.
Ook wat betreft het bgrVBI_Lk03-bericht en de elementen aoaLk01-afvoeren en vboLk01-afvoeren lijkt mij sprake te zijn van een fout in vermoedelijk de documentatie. Dit neem ik dan ook mee in het erratum.
Tenslotte de foutmelding bij testregel STV0000096 bij het testen van de berichten bagBN_Lk03 en bagIN_Lk03. Het betreft hier geen foutmelding maar een aandachtspunt, vandaar het uitroepteken. De handleiding zegt hierover:
De testregel is op basis van het berichttype relevant maar:
a. het StUF testplatform kan niet met zekerheid zeggen of het bericht aan de regel voldoet of
b. de regel is nog niet geïmplementeerd (er is alleen een beschrijving toegevoegd). In de omschrijving van de testregel staat: Let op: regel wel van toepassing maar nog niet geïmplementeerd.
Ik begrijp de verwarring en ik ga dit zeker even bespreken.
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ONV0328.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
In het antwoord op de vraag over foutregel STV0000096 heb ik ook aangegeven dat de STP niets fout doet maar dat het alleen een waarschuwing genereert.
Inmiddels heb ik wat extra informatie ontvangen die me leert dat er ook geen waarschuwing gegenereerd had mogen worden. TijdstipRegistratie mag volgens het schema gewoon niet aanwezig zijn in de enkelvoudige berichten ligStaLk01 en vboLk01 binnen het bericht bagBN_Lk03. Dit ga ik alsnog aanmelden bij JNET. Zij zullen dit moeten corrigeren.
Met betrekking tot het probleem van hetbepalen van de sorteervolgorde in samengestelde berichten is tijdens de StUF Expertgroep van 18 juni 2014 het voorstel van Sid Brouwer aangenomen. Hij stelde voor om in klein comité een voorstel te doen en daarbij mensen te betrekken die indertijd ook betrokken zijn geweest bij het opstellen van de huidige versie van het koppelvlak.
Na onderzoek ben ik tot de volgende conclusie gekomen: Er lijkt sprake van een "afkorting/shortcut" in de bericht definities: ligsta01 komt voor in berichten als bagIO_LK03 (in onderzoek plaatsen object). Een ligsta01 is of een ligplaats of een staplaats.
Indien er meerdere ligsta01 elementen voorkomen hebben die een unieke identificatie en maakt de volgorde van verwerken niet uit. Is de identificatie niet uniek maar zijn het verschillende typen (ligplaats of staanplaats, te vinden in element bg:typering) dient er een foutmelding gegeven te worden omdat hetzelfde unieke nummer door twee verschillende typen object is gebruikt.
De constructie ligsta01 is mogelijk gekozen om nog een extra choice tussen ofwel een sta01 of een lig01 te voorkomen.
In de standaard staat beschreven op pagina 9: "Bij gelijk tijdstipRegistratie, gelijk tijdvakGeldigheid/beginGeldigheid en gelijk berichtsoort staan de berichten in de volgorde: - F (correcties) - T (toevoeging) - W (beëindiging) - W (overige wijzigingen). "
Voor de berichten vboLk01-gedeeltelijkVerdwijnen en vboLk01-afvoeren in bgrVOCDEEL_Lk03 geldt dan eerst correcties (vboLk01-gedeeltelijkVerdwijnen) en vervolgens beëindiging (vboLk01-afvoeren). Het zou onlogisch zijn het andersom te doen aangezien een object niet eerst afgevoerd kan worden om vervolgens gedeeltelijk te verdwijnen Ik vraag uw commentaar op deze analyse.
In een poging dit onderhoudsverzoek op te lossen heb ik in het bijgaande voorstel de sorteerregel in die zin aangepast dat er niet meer wordt gesorteerd op de berichtsoort maar op de combinatie van de waarde van de elementen 'berichtcode' en 'entiteittype' in de stuurgegevens van de enkelvoudige berichten. Daarmee is de sortering eenduidiger en onafhankelijk van de namen van de enkelvoudige berichten binnen de Lk03/Lk04 berichten.
Ik hoop dat dit ieders goedkeuring heeft zodat we dit onderhoudsverzoek kunnen afsluiten.
Bijlage
Een aantal opmerkingen bij het voorstel:
Ik zou het netter vinden als hier een lijstje komt met in BG bekende berichttypes, of dat de zin boven het lijstje wordt aangepast.
Ten eerste is het berichttype niet relevant: het gaat altijd om Lk01-berichten
Daarmee kan wellicht worden volstaan met het entiteittype. Daarbij moeten we opletten: de entiteitcode voor ligplaatsen, standplaatsen, etc. is altijd TGO. Mocht hier onderscheid nodig zijn, dan moet de sorteervolgorde toch anders worden gedefinieerd. Anders kan het lijstje een stuk korter worden omdat een aantal varianten in het huidige lijstje worden samengevoegd onder één entiteittype.
Er is eerder in de expertgroep gesteld dat dit issue in een kleiner comité moet worden bekeken om te kunnen bepalen of afwijken van de huidige oplossing geen problemen geeft (er is destijds over nagedacht en het was niet meer duidelijk waarom de huidige oplossing zo is gekozen). Is dit nu gebeurd? Met andere woorden: kunnen we er nu op vertrouwen dat de argumente van toen zijn meegenomen in het huidige voorstel? Of weten we inmiddels dat dit niet meer noodzakelijk is? (zie ook de post van 8-9-2014)
Sid,
Mijn voorstel was een poging om tot een oplossing voor dit probleem te komen. Het was niet mijn bedoeling om hiermee voorbij te gaan aan het comité. Het lijkt me goed dat dat comité mijn voorstel beoordeelt. Wel ben ik iets te snel door de bocht gegaan door dit voorstel ook al op te nemen in de lijst met de voor de volgende patch (24) goed te keuren onderhoudsverzoeken. Dat kan natuurlijk pas als het voorstel is goedgekeurd door het comité.
De lijst onderaan pagina 7 en bovenaan pagina 8 is overigens geen lijst met complexTypes maar een lijst met binnen de berichtencatalogus BAG gebruikte enkelvoudige berichtnamen. Voor de duidelijkheid lijkt het mij goed om de zin boven het lijstje als volgt aan te passen:
De berichtcodes hebben in mijn voorstel inderdaad geen toegevoegde waarde, het gaat inderdaad altijd om Lk01 of Lk02 berichten. De berichtcode hoef je dus inderdaad niet te betrekken in het bepalen van de volgorde. In het lijstje in mijn voorstel onderaan pagina 9 heb ik de entiteittype overigens niet goed verwerkt want daarin komen de termen vbo, lig, sta, ogo en otr nog steeds terug terwijl dit dan eigenlijk TGO zou moeten zijn.
Het is echter inderdaad de vraag, zoals jij stelt, of er bij het bepalen van de volgordelijkheid nog onderscheid gemaakt moet worden tussen het ene TGO bericht en het andere. Zo niet dan zou je dat lijstje kunnen vervangen door het kortere lijstje:
Het is overigens niet zozeer de bedoeling om een andere oplossing aan te bieden maar om de onduidelijkheid in de huidige oplossing op te heffen.
Hallo Robert,
Waar ik mbt het lijstje op pagina 7/8 moeite mee heb, is dat er namen staan die niet gedefinieerd zijn als berichten.
Ik heb in eerste instantie niet helemaal goed opgelet en het types genoemd, maar ik zie nu dat een naam als ligstaLk01 alleen voorkomt als een elementnaam binnen definities van Lk03-berichten. Uiteindelijk worden binnen de Lk03-berichten in mijn ogen alleen maar enkelvoudige StUF-BG-kennisgevingen gebruikt. Binnen StUF-BG zijn die gedefinieerd als tgoLk01, pndLk01, etc. Daarin komt geen ligLk01 voor of ligstaLk01.
Tijdens de StUF Expertgroep van 17 februari 2016 is afgesproken de enkelvoudige kennisgevingsberichten in de samengestelde berichten van de BAG berichtencatalogus niet als berichten te beschouwen. We noemen ze dus enkelvoudige kennisgevingen. Verder is afgesproken dat we gaan proberen het voorstel eerst in het kleine comité, bestaande uit leden van de werkgroep die oorspronkelijk de BAG berichtencatalogus heeft opgesteld, te laten checken. Is dat niet mogelijk dan zal de StUF Expertgroep het voorstel moeten keuren.
Het voorstel dat ik in reactie 12 heb gepost heb ik voorgelegd aan Ruud Kathmann (Waarderingskamer). Deze zegt daar over:
Naar aanleiding van deze reactie maar ook de afspraken tijdens de laatste StUF Expertgroep (17 februari 2016) heb ik de volgende dooe Ruud goedgekeurde tekst in het document geplaatst (de aangepaste passage t.o.v. de huidige versie staan in vet):
Het aangepaste document heb ik tevens bijgevoegd.
Bijlage
Ik realiseerde me dat enige tijd geleden Lk04 berichten aan het koppelvlak zijn toegevoegd en dat de sorteerspecificatie daar natuurlijk ook rekening mee moet houden. In de bijgaande nieuwe versie van het document heb ik dan ook de zin:
toegevoegd.
Bijlage
Hoi Robert,
Ik ben het niet eens met deze toevoeging. Hoewel er inderdaad Lk04-berichten in de xsd's zijn opgenomen, worden deze nergens genoemd in het document van de berichtencatalogus. Hierin is alleen sprake van Lk01- en Lk03-berichten. Volgens de documentatie worden de Lk04-berichten dus niet gebruikt in het koppelvlak.
Door nu alleen in de door jouw genoemde alinea wél Lk04-berichten te benoemen, wordt het er niet duidelijker op. "Mogen ze nu wel of niet worden gebruikt?" Mijn mening is dat ze niet (zonder meer) mogen worden gebruikt: de huidige implementaties van het koppelvlak zijn op basis van asynchrone berichten. Als een partij nu opeens synchrone berichten zou gaan sturen, gaat dat niet werken. We moeten dat dus voorkomen. Eenduidigheid in het koppelvlak staat wat mij betreft voorop; daarbij hoort ook de keuze voor synchroon of asynchroon.
Mijn voorstel is dus om jouw laatste toevoeging toch weer weg te halen. De Lk04-berichten worden in geen enkel (standaard) koppelvlak gebruikt. Zou dat wel het geval (gaan) zijn, dan kan dat koppelvlak alsnog de toevoeging op de sorteerregel vastleggen.
Met vriendelijke groet,
Sid Brouwer
Wij denken dat Sid gelijk heeft.
Tijdens de StUF Expertgroep van 16 maart 2016 is de voorgestelde oplossing goedgekeurd onder voorbehoud dat de in het laatste voorstel toegevoegde alinea weer wordt verwijderd. In feite betreft de goedkeuring het voorstel uit reactie #17.
Het onderhoudsverzoek wordt meegenomen in patch 24.