{"id":32060,"date":"2026-10-02T10:14:53","date_gmt":"2026-10-02T08:14:53","guid":{"rendered":"https:\/\/www.portbase.com\/?post_type=release_note&p=32060"},"modified":"2026-10-02T10:21:43","modified_gmt":"2026-10-02T08:21:43","slug":"eta-train-vollstaendig-in-betrieb-start-der-testphase","status":"publish","type":"release_note","link":"https:\/\/www.portbase.com\/de\/release-notes\/eta-train-vollstaendig-in-betrieb-start-der-testphase\/","title":{"rendered":"ETA Train vollst\u00e4ndig in Betrieb: Start der Testphase."},"content":{"rendered":"\n

Diese Release Note richtet sich an Traktionsanbieter.<\/strong><\/em><\/p>\n\n\n\n

Die ETA Train-Funktionalit\u00e4t ist in zwei Teile unterteilt:<\/p>\n\n\n\n

    \n
  1. Einblick in den Standort des Zuges im Hinterland.<\/li>\n\n\n\n
  2. Einblick in die Ankunfts- und Abfahrtszeiten des Zuges sowie in den Verlauf der Abl\u00e4ufe an den Deepsea-Terminals im Rotterdamer Hafen.<\/li>\n<\/ol>\n\n\n\n

    ETA Train im Hinterland<\/strong>
    Um den Standort des Zuges im Hinterland abzurufen, muss der rail operator in der Rotation die incoming und\/oder outgoing train number<\/strong> sowie die first departure date und\/oder outgoing first departure date<\/strong> angeben. Werden diese Daten nicht korrekt \u00fcbermittelt, kann kein Abgleich mit den von einer externen Partei bereitgestellten Standortdaten des Zuges im Hinterland vorgenommen werden.<\/p>\n\n\n\n

    Sobald die Daten korrekt eingegeben wurden, k\u00f6nnen die ETA Train-Daten f\u00fcr die verbleibenden Fahrplanpunkte abgerufen werden, die der Zug auf dem Weg zum Rotterdamer Hafen und\/oder vom Rotterdamer Hafen zur\u00fcck ins Hinterland passieren wird. Diese Punkte und damit auch die Daten f\u00fcr jeden einzelnen Punkt werden erst sichtbar, sobald der Zug den jeweiligen Punkt passiert hat. Standardm\u00e4\u00dfig handelt es sich dabei um den Abfahrtsort im Hinterland, den niederl\u00e4ndischen Grenz\u00fcbergang, Barendrecht Vork und die G\u00fcterbahnh\u00f6fe bei den Terminals.<\/p>\n\n\n\n

    Die ETA Train-Daten k\u00f6nnen nicht r\u00fcckwirkend abgerufen werden. Das bedeutet, dass, wenn die erforderlichen Daten vom rail operator erst ab Barendrecht Vork korrekt \u00fcbermittelt werden, die ETA Train-Informationen f\u00fcr den Abfahrtsort im Hinterland und den niederl\u00e4ndischen Grenz\u00fcbergang nicht mehr abgerufen werden k\u00f6nnen.<\/p>\n\n\n\n

    Verwenden Sie zum Abrufen der Standortdaten des Zuges aus dem Hinterland die Tracking API. Dabei geht es speziell um die trainLocationReports<\/em>, eine voyage-level list. Jeder report enth\u00e4lt die folgenden Felder: operationalTrainNumber<\/em>, startDate<\/em>, direction<\/em>, trainAccessPointType<\/em>, terminalShortName<\/em>, trainLocationStatus<\/em>, trainLocation<\/em>, locationDateTime<\/em>, bookedLocationDateTime<\/em>, referencedLocationDateTime<\/em>, trainDelay<\/em>.<\/p>\n\n\n\n

    Bitte beachten Sie<\/strong>: Die Tracking API kann verwendet werden, um Echtzeit-Updates zu voyages, visits und (detached) handlings zu erhalten. Um diese Echtzeit-Updates zu erm\u00f6glichen, verwendet die API einen Mechanismus, der als \u2018long polling\u2019 bezeichnet wird. Wenn Sie eine Anfrage senden, um auf Updates zu warten, erhalten Sie sofort ein Update, wenn seit Ihrer letzten Anfrage eines stattgefunden hat. Wenn kein Update vorliegt, wartet die Anfrage, bis ein Update erfolgt, oder es kommt zu einem time-out, sobald das von Ihnen angegebene maxTimeout<\/em> erreicht ist. Nachdem die API-response zur\u00fcckgegeben wurde und Ihr client die Verarbeitung der Updates abgeschlossen hat, m\u00fcssen Sie Ihre Position immer aktualisieren. Auf diese Weise sucht die API bei Ihrer n\u00e4chsten Anfrage nach Updates nach dieser Position im eventlog. Dieser Mechanismus erm\u00f6glicht auch batching, da Sie alle Updates so schnell erhalten, wie Sie diese verarbeiten k\u00f6nnen.<\/p>\n\n\n\n

    In Bezug auf die trainLocationReports<\/em> <\/strong>ist es wichtig zu beachten, dass Sie Updates mit einer Vorher- und Nachher-Situation erhalten, in denen nur die \u00c4nderungen enthalten sind. Wenn also nur ein handling ge\u00e4ndert wurde, erhalten Sie nur dieses handling innerhalb des visit innerhalb des voyage und nicht alle containers und visits. Dieselbe delta per item gilt f\u00fcr die trainLocationReports<\/em> <\/strong>eines rail voyage: Jedes Update enth\u00e4lt nur die reports, die hinzugef\u00fcgt oder ge\u00e4ndert wurden, und nicht die reports, die Sie bereits in fr\u00fcheren Updates erhalten haben.<\/p>\n\n\n\n

    Weitere Informationen finden Sie im Hinterland Notification API Changelog.<\/a><\/p>\n\n\n\n

    ETA Train im Hafen Rotterdam<\/h2>\n\n\n\n

    Dieser Teil der Funktionalit\u00e4t bietet Transparenz pro vorgemeldeter Visit \u00fcber die Ankunfts- und Abfahrtszeiten sowie den Fortschritt der Abfertigung. Hierf\u00fcr stehen die unten aufgef\u00fchrten Datenfelder zur Verf\u00fcgung. Alle diese Daten k\u00f6nnen von allen an der Visit beteiligten Parteien abgerufen werden.<\/p>\n\n\n\n

      \n
    1. Estimated time of arrival (ETA)<\/strong> \n