Table of Contents |
---|
1 Allgemein
1.1 Änderungshistorie
1.0
16.09.2015
MHP
ML
Erstellung des Dokuments
1.1
11.01.2016
MHP
ML
Aufnahme der URL für das Testsystem und Beschreibung der einzelnen Datenebenen hinzugefügt
1.2
19.02.2016
MHP
ML
Ergänzung der minimalen Felder für die Sammelabfrage
1.3
02.06.2016
MHP
ML
PUT aus der Sammelabfrage entfernt und
Anpassungen an den Frachtführerkürzeln
1.4
22.06.2016
MHP
MWi
Anpassungen des Verweises der minimalen Felder auf Kapitel 2.3.2
1.5
13.09.2016
MHP
LK
Ergänzung fehlender Frachtführerkürzel
1.6
11.10.2016
MHP
ML
Referenzen umbenannt, Beschreibungen ergänzt
1.7
31.05.2017
MHP
ML
Parameter send_customerservice eingeführt
1.8
13.06.2017
MHP
LRS
Hinzufügen weiterer Parameter
1.8.1
16.08.2017
MHP
LK
Layout-Anpassungen
1.8.3
21.12.2017
MHP
ML
Shipmenttags & VorsystemIds rein rein Testsystem raus
1.2 Einführung
Nachfolgend wird die Schnittstelle beschrieben, die der Shiptrack.com Service anbietet. Die Schnittstelle ist in mehrere URL-Endpunkte nach dem REST Paradigma aufgeteilt. Mithilfe jedes URL-Endpunktes kann eine spezifische Ressource bearbeitet oder abgefragt werden. Sämtliche Abfragen erfolgen per HTTPS. Dabei müssen die in der folgenden Tabelle angegebenen HTTP-Header mit den aufgeführten Werten gesetzt werden. Die Authentifizierung des Aufrufers, erfolgt an der Schnittstelle mithilfe eines zuvor definierten Benutzernamens und Passworts über die HTTP-Basic Authentifizierungsmethode (siehe RFC2617).
HTTP-Header
Wert
Content-Type
application/json
1.3 Fehlerbehandlung
Damit bei einem auftretenden Fehler in der Schnittstelle der Aufrufer eine aussagekräftige Fehlermeldung bekommt, sendet die Schnittstelle eine Antwort mit einem HTTP-Statuscode, der den Fehler repräsentiert. Außerdem wird eine Nachricht zurückgeliefert, die Detailinformationen zum Fehler enthält. Für den Fehler, dass ein Kunde als Parameter angegeben wird, der nicht existiert, wird zum Beispiel der HTTP-Statuscode 404 zurückgesendet. Die dazugehörige Detail-Fehlermeldung sieht wie folgt aus:
{
"Message": "Requested client does not exists"
"ErrorCode" : "404.1"
}
Der Standardfehlercode für undefinierte Fehler ist der HTTP-Statuscode 505. Nachfolgend ist eine Tabelle mit allen bekannten Shiptrack.com spezifischen Fehlercodes aufgelistet:
Fehlercode
HTTP-Status
Beschreibung
404.1
404
Die angegebene Client-Id existiert nicht in der Datenbank
400.1
400
Das angegebene Datumsformat im since-Parameter entspricht nicht den Richtlinien
500.1
500
Es ist kein Statusbaum konfiguriert um die Status auszuwerten
2 Sendungsverfolgungsdaten
Zum Abruf der Sendungsverfolgungsdaten existieren zwei unterschiedliche Methoden. Die erste Methode ist die Sammelabfrage. Mit dieser können große Datenmenge zwischen zwei Systemen übertragen werden, dabei existiert ein Mechanismus um nur aktualisierte Daten seit dem letzten Abruf zu übertragen. Des Weiteren ist es möglich über diese Methode neue Sendungen oder zusätzliche Informationen für Sendungen an Shiptrack.com zu senden. Als zweite Methode steht die Einzelabfrage zur Verfügung mit der einzelne Sendungen abgefragt werden können. Nachfolgend werden die beiden Methode genauer Erläutert.
2.1 Sammelabfrage
URL Livesystem: https://service.shiptrack.com/clients/<Client-Id>/shipments
Der Parameter Client-Id muss mit der mitgeteilten Kunden-Id gefüllt werden.
2.1.1 GET
Mit der http-Methode GET werden alle Sendungen, die den Kunden mit der in der URL angegebenen Client-Id zugeordnet sind auf. Das Ergebnis wird als JSON-String zurückgeliefert und als Stream übertragen. Die Liste der Sendungsdaten die zurückgeschickt wird, kann mit folgenden optionalen GET Parametern eingeschränkt werden:
- since Wird dieser Parameter angegeben, werden nur Datensätze zurückgeliefert, die seit dem Zeitpunkt importiert oder bei denen neue Daten hinzugefügt wurden.
Datentyp:
Datum - Format(YYYYMMddHHmmss) in der Zeitzone UTC oder ISO-8601 - until Wird dieser Parameter angegeben, werden nur Datensätze zurückgeliefert, die bis zu dem Zeitpunkt importiert oder bei denen neue Daten hinzugefügt wurden.
Datentyp:
Datum - Format(YYYYMMddHHmmss) in der Zeitzone UTC oder ISO-8601
2.2 Einzelabfrage
URL: https://service.shiptrack.com/clients/<Client-Id>/shipmentsSearch
Der Parameter Client-Id muss mit der mitgeteilten Kunden-Id gefüllt werden.
2.2.1 GET
Mit dem GET-Verb kann eine Suche auf den Sendungsdaten durchgeführt werden. Dabei wird der jeweilige Suchparameter als GET-Parameter der Anfrage übergeben. Eine Kombination von mehreren Suchparametern ist noch vorhergesehen und führt zu einem leeren Ergebnis. Folgende Suchparameter stehen zur Verfügung:
- trackingNr Führt eine Suche auf der Trackingnummer einer Sendung oder eines Paketes durch. Es wird immer die komplette Sendung zurückgeliefert auch wenn die Trackingnummer sich auf Paketebene findet. Betroffene Felder sind: shipment_tracking_id auf Sendungsebene und send_id auf Paketebene
Datentyp:
string - referenceNr Dieser Parameter ermöglicht eine Suche auf den Referenznummern einer Sendung, sowohl auf Sendungs- als auch auf Paketebene. Der angegebene Wert wird in folgenden Feldern gesucht: send_referenznr_01, send_referenznr_02, send_referenznr_03, send_referenznr_04, send_referenznr_05 auf Sendungsebene und send_referenznr_06, send_referenznr_07, send_referenznr_08, send_referenznr_09, send_referenznr_10 auf Paketebene.
Datentyp:
string
2.3 Sendungsanlage
2.3.1 PUT
Mit dem http-Verb PUT können eine oder mehrere Sendungen an den Service übermittelt werden. Bei erfolgreicher Annahme der Anfrage wird nur ein HTTP Status-Code 202 zurückgemeldet. Zur erfolgreichen Übermittlung müssen die Minimalfelder die in Abschnitt 2.3.2 angegeben werden gefüllt sein.
Nach erfolgreicher Übermittlung stehen die Daten nicht sofort zum Abruf über die Sammel- oder Einzelabfrage zur Verfügung sondern müssen erst durch den Service verarbeitet werden.
Falls Sie größere Blöcke übertragen möchten, sprechen Sie uns bitte an, damit wir den Import darauf optimieren können! Eine Blockgröße von mehr als 10 Sendungen ist nicht ratsam.
2.3.2 Minimale Felder für Anlage einer neuen Sendung
Feld
Beschreibung
shipment_tracking_id
Tracking-Sendungsnummer des Frachtführers. (Ist nicht über längeren Zeitraum eindeutig)
frachtfuehrer
Kürzel des Frachtführers, mit dem die Sendung befördert wird.
package.send_id
Tracking-Paketnummer des Frachtführers.
(Wenn keine abweichende Paketnummer vorhanden ist, dann ist die Sendungsnummer als Paketnummer anzulegen!)
package.send_referenzid
(Nur Pflicht beim Frachtführer DPB (Deutsch Post))
RFID für den Ländernachweis.
(Wenn keine abweichende Paketnummer vorhanden ist, dann ist die Sendungsnummer und die Paketnummer wie RFID anzulegen!)
send_versanddatum
Datum an dem die Sendung versendet wurde.
2.3.3 Beispiel die für Anlage einer einzelnen neuen Sendung
{
"shipment": [
{
"shipment_tracking_id": "123456789",
"frachtfuehrer": "DHL",
"send_versanddatum": {
"time": "12:00:00",
"date": "01/01/2016"
},
"package": [{
"send_id": "123456789",
"send_referenzid": "AV123456789DE"
}]
}
]
}
2.3.4 Zusatzparameter
Zur Unterscheidung der auszuführenden Workflows kann ein weiterer Headerparameter mitgegeben werden:
- source Wird dieser Parameter angegeben (nach Absprache mit der MHP), werden alle gelieferten Sendungen einem bestimmten Workflow zugeführt.
Datentyp:
string
2.4 Sendungsverfolgungsdatenformat
Nachfolgend wird das Format der Sendungsverfolgungsdaten, welche von der Schnittstelle zurückgeliefert und angenommen werden erläutert. Die Übertragung der Daten findet im JSON-Format statt. Dabei wird immer ein Dokument, welches ein Array an Sendungen enthält, übermittelt. Somit wird mindestens folgende Nachricht übertragen:
{
„shipment“ : [ ],
„shipment_count“ : "0"
}
Eine Abfrage die Daten enthält sieht wie folgt aus:
{
{
}
Status zurückgelieferten MHP Minimal mitgesendet Datumswerte Shipmentebene ShipmentstatusebeneMHP3 Packageebene PackagestatusebeneMHP DokumentebeneIncidentebene Timingebene MHP zugrundeliegenden Versandart Versandart Anhang1 Mögliche Frachtführerkürzel