Ik neem even StUF019 als voorbeeld, dit is de volgende controle:
TijdstipBericht niet groter dan voorgaand TijdstipBericht van zender
Deze vraag gaat niet over een specifiek koppelvlak, dat gebruik ik slechts als voorbeeld:
Vanuit onze BGT applicatie hebben we twee endpoints waar we naartoe (uitgaand) zenden:
- Mutatielevering Bronhouder: https://k-webservices.stichtingsvbbgt.nl/svbontvanger0111/OntvangAsynchroon
- Vooraankondiging: https://k-webservices.stichtingsvbbgt.nl/svbontvanger0120/OntvangAsynchroon
Nu is de vraag, omdat het twee losse endpoints zijn, moet het tijdstipbericht opvolgend zijn? M.a.w. mag dit:
- Volgnummer: 1, Bericht: Mutatielevering Bronhouder, Zender: Wij, Ontvanger: Bravo, TijdstipBericht: 2018-01-01
-
Volgnummer: 2, Bericht: Vooraankondiging, Zender: Wij, Ontvanger: Bravo, TijdstipBericht: 2018-01-02
- Volgnummer: 3, Bericht: Mutatielevering Bronhouder, Zender: Wij, Ontvanger: Bravo, TijdstipBericht: 2018-01-04
- Volgnummer: 4, Bericht: Vooraankondiging, Zender: Wij, Ontvanger: Bravo, TijdstipBericht: 2018-01-03
Moet volgens de StUF standaarden bericht met volgnummer 4 afgekeurd worden met een StUF019?
Of mag ie door omdat ie op een ander endpoint praat, het is immers wel dezelfde zender en ontvanger?
De standaard noemt geen endpoints, maar definieert zender als de combinatie van organisatie, applicatie en administratie. Ik werk voor het Kadaster, en daar gebruiken we voor de organisatie ons OIN (00000001802327497000), voor applicatie de dienst (bijvoorbeeld LVWOZ) en voor het onderscheiden van verschillende systemen binnen een dienst gebruiken we de administratie.
Als de twee endpoints van verschillende applicaties zijn ligt het voor de hand de applicatie-tag te gebruiken. Gaat het om verschillende administratieve eenheden binnen een applicatie dan is het logischer gebruik te maken van de administratie-tag.
Zelfs als er maar 1 applicatie en/of 1 administratie is kan het een goede keus zijn om organisatie, applicatie en administratie altijd in te vullen, zodat het later makkelijker is nieuwe applicaties en/of administraties te introduceren.
De controles op tijdstipBericht (StUF019) en referentienummer (StUF016) gelden per unieke combinatie van organisatie, applicatie en administratie (zie ook StUF010 en StUF013).
Rijk, dus als ik het goed begrijp is jouw antwoord: Ja, het bericht moet afgekeurd worden met StUF019?
Zo waren de checks ook ingebouwd in onze software, maar wij zien dat Bravo zich hier niet aan houdt.
Op pagina 44 van de StUF standaard staat:
"StUF-berichten worden uitgewisseld tussen geautomatiseerde systemen. Zo’n geautomatiseerd systeem wordt beheerd door een organisatie."
en
"... is er in StUF voor gekozen om een systeem te identificeren met behulp van twee stuurgegevens: de applicatie en de administratie."
Rijk heeft dus gelijk als hij stelt dat de standaard een zender definieert als de combinatie van organisatie, applicatie en administratie. Een endpoint is dus geen onderdeel van de identificatie van een systeem.
De regel die je zelf aanhaalt staat op pagina 45 en verwijst naar deze definitie van systeem en luidt volledig:
"StUF stelt wel als randvoorwaarde dat het tijdstipBericht van een bericht groter is dan het tijdstipBericht van alle eerder door een systeem aangemaakte berichten."
De conclusie van Rijk is dus correct en ja het bericht zou dus afgekeurd moeten worden.
@Robert: Thanks! Zo hadden we het ook geïmplementeerd, maar Bravo houdt zich hier niet aan, dus aan onze kant de StUF019-check optioneel gemaakt om verder te kunnen. Ik zal het verder adresseren bij SVB-BGT.
@Lennart: Volgnummer is geen veld wat over het lijntje gaat. Maar heb ik alleen toegevoegd ter verduidelijking in deze discussie.
@Frank Ja, ok. Dan lijkt het dat je met dat volgnummer bedoeld dat dit de functionele volgorde is, waarin mutaties doorgevoerd moeten worden. Dan is het bijbehorende antwoord (wat mij betreft) dat je dus geen StUF fout mag geven als berichten technisch in een andere volgorde binnenkomen dan wat de functionele volgorde aangeeft. Immers, de transport laag (http, ebms, wus) garandeert geen volgorde. Voor de functionele volgorde zal je de binnengekomen berichten dus eerst in functioneel goede volgorde moeten zetten, voordat je ze verwerkt.
Het tijdstipBericht klinkt mij niet in de oren als de functionele volgorde, omdat die al bepaald is voordat een bericht aangemaakt wordt. Wellicht dat het in sommige gevallen wel werkt, als de functionele volgorde gehandhaafd blijft bij het aanmaken van berichten. In algemeenheid lijkt tijdstipBericht mij niet de meest geschikte kandidaat, maar eerder tijdstipRegistratie.
Goed, so far voor 2 cents. Succes!
@Lennart, tja, als je op tijdstipBericht moet checken volgens de StUF019 check, dan dwingt dat dus de functionele en "aankomstvolgorde" af. Om dit te laten werken moet de verzender de Bv03/Fo03 afwachten voordat hij de volgende stuurt. Zelf zaken op volgorde zetten staat haaks op de StUF019 check. tijdstipRegistratie wordt door Bravo (en ons) niet gestuurd en eerlijk gezegd ben ik die nog niet tegengekomen.
Dus ik houd vast aan deze uit de specs:
"StUF stelt wel als randvoorwaarde dat het tijdstipBericht van een bericht groter is dan het tijdstipBericht van alle eerder door een systeem aangemaakte berichten."