Ketenprotocol VMS
De beschrijving van de technische systeem interfaces voor matrixsignaalgevers wordt gebruikt is vastgelegd in het, in de onderliggende paragrafev beschreven, ketenprotocol-VMS. Dit protocol is bedoeld om een beschrijving te geven hoe systemen DATEX II gegevens met een payload van het type Vms- of VmsTablepublication (zie hiervoor hoofdstuk 7) dienen uit te wisselen.
Binnen het ketenprotocol-VMS worden er twee methodes voor data afname beschreven. De Push Methode en de Pull Methode.
Push Methode
Systemen binnen de VMS keten hebben een interface beschikbaar om data te "pushen" naar een afnemende partij. Het systeem van deze partij moet gebouwd zijn volgens de "DATEX II Push WSDL omschrijving"
De push methode bevat een aantal onderdelen die hier onder beschreven worden. Het gaat om:
- Administratie
- Klaar voor levering
- Onderhouden verbinding
- Weigeren van data
Administratie
De leverende partij houdt een (offline) administratie bij. Hierin staat geregistreerd:
- End Point waarop het afnemende systeem de data wil ontvangen.
Zodra een afnemer administratief is geregistreerd wordt de afnemer geactiveerd. Het leverende systeem gaat dan naar Klaar voor levering.
Klaar voor levering
Het aanleverende systeem maakt kenbaar dat het klaar is om de levering te starten door een DATEX II Keep-Alive bericht te sturen naar het afnemende systeem. Indien het afnemend systeem niet reageert, zal het leverend systeem dit bericht iedere minuut blijven herhalen tot het ontvangende systeem reageert. Het exchange element van dit Keep-Alive bericht bevat de volgende waarden:
| Elementen binnen exchange | waarde |
|---|---|
| keepAlive | true |
| --- | --- |
Zodra het afnemende systeem het Keep-Alive bericht correct bevestigd met een DATEX II acknowledge bericht, gaat het leverende systeem over tot het onderhouden van de verbinding.
Het acknowledge bericht van het afnemende systeem moet de volgende waardes bevatten:
| Elementen binnen exchange | waarde |
|---|---|
| response | acknowledge |
| --- | --- |
Onderhouden verbinding
De verbinding tussen het aanleverend systeem en het afnemend systeem zal worden onderhouden door het aanleverend systeem.
De push methode maakt gebruik van het mechanisme SupplierPushOnOccurrence. De "occurrence" kan tweeërlei zijn:
- het beschikbaar zijn van een (volledige) bijgewerkte gegevens set,
- het verstrijken van het tijdstip waarop gegevens gepubliceerd dienen te worden, conform de actualiteitseisen.
Tijdens het onderhouden van de verbinding zal het leverende systeem, zodra er sprake is van het optreden van een van deze voorwaarden, de gegevens naar het afnemend systeem gaan versturen. Dit gebeurt door de "DATEX II Client Push Service" aan te roepen die beschikbaar is op het systeem van de afnemer.
Indien het afnemend systeem niet reageert, zal het leverend systeem direct een DATEX II Keep-Alive bericht sturen, en dit bericht iedere 20 seconden blijven herhalen tot het ontvangende systeem reageert. Reageert het afnemende systeem niet (met een DATEX II acknowledge bericht) op drie achtereenvolgende Keep-Alive berichten, dan wordt een escalatieprocedure in gang gezet, en gaat het leverende systeem over naar Klaar voor levering.
Indien de data incorrect is of de push niet succesvol was, dan zal het teruggezonden DATEX II bericht dienovereenkomstig gevuld worden. Zie hiervoor ook Weigeren van data.
Om een haperende verbinding te kunnen detecteren wordt de escalatieprocedure ook in werking gezet, als het vijf keer niet lukt om data te verzenden, maar het ontvangende systeem wel steeds binnen drie keer op een DATEX II Keep-Alive bericht reageert.
Het exchange element van het DATEX II Keep-Alive bericht bevat de volgende waarden:
| Elementen binnen exchange | waarde |
|---|---|
| keepAlive | true |
| --- | --- |
Het DATEX II acknowledge bericht van het afnemende systeem moet de volgende waardes bevatten:
| Elementen binnen exchange | waarde |
|---|---|
| response | acknowledge |
| --- | --- |
Weigeren van data
Het afnemend systeem kan een data levering weigeren. Binnen het Nederlandse profiel zijn er twee manieren om een weigering van data op te nemen. Via de elementen denyReason en ExtendedDenyReason.
Bij het weigeren van data moet het element denyReason altijd gevuld zijn. Indien het element ExtendedDenyReason gebruikt wordt dient het element denyReason gevuld te worden met "unkownReason". Zie voor de invulling van de elementen de uitleg van exchange.
Pull
Een aanleverend systeem kan tevens uitgerust zijn met functionaliteit om gegevens, op verzoek van het afnemend systeem te publiceren. Het zijn altijd de meest actuele gegevens die worden gepubliceerd.
De pull methode is geïmplementeerd op basis van het "simple http server-profile", wat betekent dat de afnemer een HTTP-request doet en in de body van de response de gegevens krijgt.
Deze gegevens worden in hetzelfde formaat aangeboden als bij de push methode. Om interoperabiliteit te behouden tussen deze twee methoden wordt de data bij de pull methode ook in een SOAP enveloppe verpakt.
Current=true
Configuratiebestanden worden ook via de pull methode aangeboden. 24 uur voor het live gaan van een nieuwe versie is deze beschikbaar via de pull methode. De parameter 'current=true' kan worden om altijd het huidige (actieve) configuratie bestand op te halen, ook al is een wisseling naar de volgende versie aangekondigd en de nieuwe versie beschikbaar.
Push afnemers dienen, wanneer zij een configuratiebestand gemist hebben, ook altijd via de pull methode de configuratiebestanden op te kunnen halen.
1 WSDL omschrijvingen zijn hier te vinden.
2 De inhoud van een escalatie procedure valt niet binnen de scope van het Nederlands profiel DATEX II.