Ketenprotocol SB Datex-II V3

De beschrijving van de technische interface voor Situatieberichten is vastgelegd in het, in de onderliggende paragrafen beschreven, ketenprotocol-SB. Dit protocol is bedoeld om een beschrijving te geven hoe systemen voor de uitwisseling van DATEX II v3.x met elkaar verbinden en data met payload van het type situationPublication dienen uit te wisselen. Voor de uitwisseling wordt gebruik maakt van Exchange 2020. Alle berichten worden in een messageContainer verstuurd met daarin optioneel drie secties: payload, exchangeInformation en informationManagement.

Payload

De payload bevat het daadwerkelijke DATEX II bericht met de situatie-informatie.

Exchange Information

De exchangeInformation gaat over de uitwisseling tussen de Supplier en de Client. Met behulp van informationManagement kunnen situaties beëindigd of geannuleerd worden. In de onderstaande paragrafen staan tabellen met verwijzingen als sd x.x.x. Dit verwijst zowel naar de onderdelen in de sequence diagrammen als naar de meegeleverde XML-voorbeelden.

Push Methode

Systemen binnen de SB keten hebben een interface beschikbaar om data te "pushen" naar een afnemende partij. Het systeem van deze partij moet gebouwd zijn om te werken met "Exchange 2020 Ketenprotocol WSDL".

De push methode bevat een aantal onderdelen die hier onder beschreven worden. Het gaat om:

• Administratie;
• Start Connection and Deliver Data
• Maintain Connection
• Close Connection or Fail
• Request Snapshot
• Weigeren van data.

Administratie

Zowel de aanleverende (Supplier) als de afnemende (Client) partij houden een offline administratie bij. Hierin staat geregistreerd bij het aanleverend systeem:

• End Point waarop het afnemende systeem de data wil ontvangen;

Hierin staat geregistreerd bij het afnemende systeem:

• End Point waarop de het aanleverend systeem de registratie wil ontvangen.

Start Connection and Deliver Data

De client state is 'offline'. Het aanleverend systeem (Supplier) maakt kenbaar dat het klaar is voor levering door een openSession bericht te sturen naar het afnemend systeem.

sd 1.0 openSession

Dit zal het aanleverende systeem elke 10 minuten doen net zolang tot het afnemende systeem reageert of tot dit handmatig overruled wordt.

Het afnemende systeem reageert op een van de drie volgende mogelijkheden:

• Succes Snapshot on openSession
• Succes Ack on openSession
• Fail on openSession

Succes Snapshot on openSession

In dit geval zal het afnemend systeem, wanneer het een Exchange openSession bericht ontvangt, een Exchange snapshotSynchronizationRequest bericht terugsturen waarna het leverende systeem de client State naar 'online' zet.

sd 1.1.1 return snapshotSynchronizationRequest

Hierna wordt er door het leverende systeem een snapshot gegenereerd wat met een ExchangeInformation(payloadDelivery) naar de afnemende partij wordt gestuurd. De gegevens bevinden zich in een payload van het type 'situationPublication'.

sd 1.1.2 payloadDelivery Snapshot

Het ontvangende systeem reageert met een 'ack'-bericht dat het snapshot correct is ontvangen.

sd 1.1.3 return ack

Hierna gaat het leverende systeem uit de loop 'Supplier Status offline Open Session' en gaat deze naar het volgende sequence diagram 'Maintain Connection' (zie het volgende hoofdstuk).

Succes Ack on openSession

In dit geval zal het afnemend systeem, wanneer het een Exchange openSession bericht ontvangt, een Exchange bericht met de waarde 'ack' terugsturen waarna het leverende systeem de client State naar 'online' zet.

sd 1.2.1 return ack

Daarna gaat het leverende systeem uit de loop 'Supplier Status offline Open Session' en gaat deze naar het volgende sequence diagram 'Maintain Connection' (zie het volgende hoofdstuk).

Fail on openSession

Wanneer het afnemend systeem een fail terugstuurt op de openSession of er helemaal geen antwoord komt, blijft het aanleverende systeem elke tien minuten proberen een verbinding op te zetten.

sd 1.3.1 return fail

Maintain Connection

De verbinding tussen het aanleverend systeem en het afnemend systeem zal worden onderhouden door het aanleverend systeem. Er zijn twee scenarios: 'Data Ready for Payload Push' en 'no data keepAlive'

Data ready for payload push

Wanneer er binnen 5 minuten na het laatst verstuurde bericht er een update op de data is zal deze direct verstuurd worden door middel van een allElementUpdate bericht waarbij de data zich bevindt in een payload van het type situationPublication.

sd 2.1.1 allElementUpdate

sd 2.1.2 return ack

No data keepAlive

Wanneer er na 5 minuten sinds het versturen van het laatste bericht nog geen update op de data te versturen is, zal het aanleverende systeem een keep-alive bericht sturen. Dit zal het systeem elke 5 minuten blijven doen totdat er een update op de data is en er een allElementUpdate verstuurd wordt (de vorige paragraaf).

sd 2.2.1 keepAlive

sd 2.2.2 return ack

CloseSession or Fail

Wanneer het ontvangende systeem de verbinding wil verbreken, dient deze een closeSessionRequest sturen als reactie op een pushbericht of een keepAlive-bericht. Het aanleverende systeem reageert dan met een closeSession bericht. Het ontvangende systeem reageert hetzelfde wanneer een bericht geweigerd wordt door het ontvangende systeem (fail).

Ook wanneer het ontvangende systeem voor een timeout zorgt bij het aanleverende systeem, zal het aanleverende systeem een closeSession sturen.

Het aanleverende systeem zal na bevestiging of timeout de sessie naar 'offline' zetten, zo wordt de verbinding inactief en zal er geen data meer verstuurd worden.

sd 3.1 return closeSessionRequest

sd 3.2 return fail

sd 3.3 closeSession

sd 3.4 return ack

Snapshot Request

Wanneer een ontvangend systeem, om wat voor reden dan ook, een snapshot nodig heeft om de huidige situatie weer te weten, kan deze op elk bericht een return bericht sturen met een snapshotSynchronizationRequest. Het aanleverende systeem zal als gevolg van dit verzoek een snapshot genereren en daarna deze naar het ontvangende systeem sturen en daarna doorgaan met de 'maintain Connection'. Dit verzoek kan alleen plaats vinden wanneer de session op 'online' staat. Anders moet eerst de verbinding weer opgezet worden.

sd 4.1 return snapshotSynchronizationRequest

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <ndw:NdwVms xmlns:ndw="http://schemas.ndw.nu/wsdl/NdwTmisMrm10/">
      <ndw:exchange>
        <denyReason>unknownReason</denyReason>
        <response>requestDenied</response>
      </ndw:exchange>
    </ndw:NdwVms>
  </SOAP:Body>
</SOAP:Envelope>

Hierna wordt er door het leverende systeem een snapshot met alle relevante situations gegenereerd dat samen met een ExchangeInformation(payloadDelivery) naar de afnemende partij wordt gestuurd. De gegevens bevinden zich in een payload van het type 'situationPublication'.

sd 4.2 payloadDelivery Snapshot

1 WSDL-omschrijvingen zijn hier te vinden.

InformationManagement

In het geval van situatie publicaties worden met behulp van het informationManagement situaties en situatieonderdelen beëindigd of geannuleerd. Dit geldt voor zowel de individuele situationRecords als voor de situation waar de situationRecords onderdeel van zijn. Dit betekent op het moment dat een event wordt beëindigd, aanvullend op het informationManagement onderdeel ook de payload nog één maal wordt verstuurd. Op dat moment wordt ook de definitieve eindtijd van het event opgenomen in het validity-onderdeel overallEndTime.

Voorbeeld:

```xml

<informationManagement>
  <inf:informationManagedResourceList>
    <inf:elementReference>
      <managementStatus xmlns="http://datex2.eu/schema/3/informationManagement">closed</managementStatus>
      <reference xmlns="http://datex2.eu/schema/3/informationManagement" id="NDW03_WW_RWKSID_1_249390738" />
    </inf:elementReference>
  </inf:informationManagedResourceList>

</informationManagement ```