Statusdaten Export Standard Schnittstelle: Unterschied zwischen den Versionen
Treum (Diskussion | Beiträge) |
Treum (Diskussion | Beiträge) |
||
| (2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 109: | Zeile 109: | ||
Die Felder werden auf der Rechten seite auf die Angegebene Länge aufgefüllt. | Die Felder werden auf der Rechten seite auf die Angegebene Länge aufgefüllt. | ||
| − | === Datenbank | + | === JDBC / Datenbank === |
Die Daten werde mithilfe eines JDBC-Treiber (jar-Datei) welcher vom Datenbank Hersteller bereitgestellt wird in Ihre Datenbank übertragen. | Die Daten werde mithilfe eines JDBC-Treiber (jar-Datei) welcher vom Datenbank Hersteller bereitgestellt wird in Ihre Datenbank übertragen. | ||
Der Standard Tabellenname ist „status“ kann aber auch beliebig geändert werden. So auch die Namen der Felder. | Der Standard Tabellenname ist „status“ kann aber auch beliebig geändert werden. So auch die Namen der Felder. | ||
| + | |||
| + | Für die JDBC Verbindung zu Datenbank benötigen wir also folgendes: | ||
| + | * Die JDBC Jar Datei der Datenbank | ||
| + | * Die Connection URL (bei MySQL z.B. jdbc:mysql://127.0.0.1:3306/heidler) | ||
| + | * Die Connection Klasse des JDBC Treiber (bei MySQL z.B. com.mysql.jdbc.Driver) | ||
| + | * User und Passwort für den DB Zugriff | ||
| + | |||
| + | === DGS (DataGatewayServer) === | ||
| + | Über den DataGatewayServer (DGS) werden die Statusdaten aktiv an Ihr Zielsystem gesendet – vergleichbar mit einem „Webhook" bzw. Push. Sie müssen die Daten also nicht abholen: Der Versand erfolgt automatisch, sobald neue Statusdaten vorliegen. Ein Zielsystem kann bei Bedarf auch an mehrere Empfänger gleichzeitig senden. | ||
| + | |||
| + | Die exportierten Felder entsprechen den Standardfeldern aus der Tabelle oben. | ||
| + | |||
| + | Voraussetzung: StatusdatenManager ab Version 1.6.9, DatagatewayService ab Version 3.8.45. | ||
| + | |||
| + | ==== Mögliche Zielsysteme ==== | ||
| + | Der Versand ist zu unterschiedlichen Zielsystemen möglich. Der häufigste Fall ist der Push an eine REST-API. | ||
| + | |||
| + | {| class="wikitable" | ||
| + | ! Zielsystem / Weg | ||
| + | ! Beschreibung | ||
| + | |- | ||
| + | | REST-API | ||
| + | | Push per HTTP an eine Web-API (Standardfall, Format JSON) | ||
| + | |- | ||
| + | | SOAP-Webservice | ||
| + | | Push an einen SOAP-Webservice (Format XML) | ||
| + | |- | ||
| + | | HTTP-Endpoint | ||
| + | | Einfache HTTP-Aufrufe (GET/POST/PUT) | ||
| + | |- | ||
| + | | Datei | ||
| + | | Ablage als Datei (XML oder Bild) in einem Verzeichnis | ||
| + | |- | ||
| + | | SAP | ||
| + | | Übergabe an SAP (RFC oder IDoc) | ||
| + | |- | ||
| + | | CUBE3 / PSI-WMS | ||
| + | | Anbindung an CUBE3 bzw. ein PSI-Warehouse-Management-System | ||
| + | |} | ||
| + | |||
| + | ==== Voraussetzungen – was Sie bereitstellen müssen ==== | ||
| + | Je nach gewähltem Zielsystem benötigen wir von Ihnen die folgenden Angaben. | ||
| + | |||
| + | Push-Ziele (REST/SOAP/HTTP): | ||
| + | |||
| + | {| class="wikitable" | ||
| + | ! Zielsystem | ||
| + | ! Von Ihnen bereitzustellen | ||
| + | |- | ||
| + | | REST-API | ||
| + | | Ziel-URL (Endpoint); Authentifizierung (keine / Benutzer + Passwort / API-Key / OAuth-Zugangsdaten); erwartetes Datenformat (i. d. R. JSON); bei HTTPS ggf. das TLS-Zertifikat | ||
| + | |- | ||
| + | | SOAP-Webservice | ||
| + | | Endpoint-URL bzw. WSDL; Authentifizierung; erwartete XML-Struktur; bei HTTPS ggf. das TLS-Zertifikat | ||
| + | |- | ||
| + | | HTTP-Endpoint | ||
| + | | Ziel-URL und HTTP-Methode; ggf. Authentifizierung | ||
| + | |} | ||
| + | |||
| + | Weitere Ziele: | ||
| + | |||
| + | {| class="wikitable" | ||
| + | ! Ziel | ||
| + | ! Von Ihnen bereitzustellen | ||
| + | |- | ||
| + | | Datei (XML/Bild) | ||
| + | | Zielverzeichnis sowie gewünschtes Format und Encoding | ||
| + | |- | ||
| + | | SAP (RFC/IDoc) | ||
| + | | SAP-Zugangsdaten (Mandant, Benutzer, Passwort, Host) und den Namen der RFC-Funktion bzw. des IDoc | ||
| + | |- | ||
| + | | CUBE3 / PSI-WMS | ||
| + | | jeweils Ziel-URL und Zugangsdaten | ||
| + | |} | ||
| + | |||
| + | ==== Technische Details ==== | ||
| + | Ablauf: Der StatusdatenManager sendet die Daten über das Export-Event „DGS REST SERVER EXPORT" an ein DGS-Server-Plugin (Typ „DGSRestServerGatewayFactory"). Von dort werden sie über den Mediator (GatewayID + Funktion „exportData") an ein oder mehrere Client-Plugins weitergeleitet, die den eigentlichen Versand an das Zielsystem durchführen. Als Authentifizierung zwischen SEM und DGS werden NONE und ClientCredentials unterstützt. | ||
Aktuelle Version vom 1. Juli 2026, 15:10 Uhr
Im Standard werden die folgenden Felder exportiert. Unterhalb der Tabelle finden Sie noch verschiedene Exporttypen (CSV, Datenbank)
| Feldname HVS32 | Datentyp | Länge | Beschreibung |
|---|---|---|---|
| FFKURZNAME | Text | 30 | Kennung des Frachtführers zum Host-System |
| FFSTATUSCODE | Text | 10 | Frachtführerspezifischer Statuscode |
| FFSTATUSKLARTEXT | Text | 250 | Klartext der den Statuscode beschreibt |
| FFZUSATZCODE | Text | 10 | Zusätzlicher Statuscode |
| FFZUSATZKLARTEXT | Text | 120 | Klartext der den zusätzlichen Statuscode beschreibt |
| ZUSATZKLARTEXT | Text | 80 | Zusätzliche Informationen |
| STATUSORT | Text | 30 | Ort an dem der Status eingetreten ist (z.B. Nummer des Depots) |
| EMPFANGSQUITTIERER | Text | 100 | Name des Empfängers, der das Paket/die Sendung entgegen nahm |
| STATUSDATETIME | Text | 25 | Datum und optional Uhrzeit des Statuscodes (Format: dd.mm.yyyy hh:mm:ss) |
| DRUCKDATETIME | Text | 25 | Datum und Uhrzeit des Etikettendrucks (Format: dd.mm.yyyy hh:mm:ss) |
| AUSGANGDATETIME | Text | 25 | Datum der Übergabe an den Frachtführer (Format: dd.mm.yyyy) |
| TRACKINGNR | Text | 35 | Trackingnummer |
| VERSANDSENDUNGSNR | Text | 20 | Sendungsnummer |
| LIEFERSCHEINNR | Text | 50 | Lieferscheinnummer des Haupt-Lieferscheins |
| PACKSTKNR | Integer | 3 | Packstücknummer innerhalb des Lieferscheins |
| PACKSTUECKID | Text | 20 | Eindeutige Packstück-ID aus dem Host-System (nur Automatik-Polling) |
| STATUSTYP | Text | 2 | E = Endestatus, Z = Zwischenstatus |
| FEHLERSTATUS | Text | 2 | I = Info, F = Fehler |
CSV
Die Felder werden Semikolon separiert in eine CSV-Datei geschrieben. Wobei die Feldnamen die Definitionszeile bilden. Die Länge der Felder definiert nur die maximale Länge, es wird nicht auf die angegebene Länge aufgefüllt.
Flatfile
Die Felder werden mit festen Feldlängen, wie angegeben, in eine Textdatei geschrieben. Es gibt keine Definitionszeile. Die Felder werden auf der Rechten seite auf die Angegebene Länge aufgefüllt.
JDBC / Datenbank
Die Daten werde mithilfe eines JDBC-Treiber (jar-Datei) welcher vom Datenbank Hersteller bereitgestellt wird in Ihre Datenbank übertragen. Der Standard Tabellenname ist „status“ kann aber auch beliebig geändert werden. So auch die Namen der Felder.
Für die JDBC Verbindung zu Datenbank benötigen wir also folgendes:
- Die JDBC Jar Datei der Datenbank
- Die Connection URL (bei MySQL z.B. jdbc:mysql://127.0.0.1:3306/heidler)
- Die Connection Klasse des JDBC Treiber (bei MySQL z.B. com.mysql.jdbc.Driver)
- User und Passwort für den DB Zugriff
DGS (DataGatewayServer)
Über den DataGatewayServer (DGS) werden die Statusdaten aktiv an Ihr Zielsystem gesendet – vergleichbar mit einem „Webhook" bzw. Push. Sie müssen die Daten also nicht abholen: Der Versand erfolgt automatisch, sobald neue Statusdaten vorliegen. Ein Zielsystem kann bei Bedarf auch an mehrere Empfänger gleichzeitig senden.
Die exportierten Felder entsprechen den Standardfeldern aus der Tabelle oben.
Voraussetzung: StatusdatenManager ab Version 1.6.9, DatagatewayService ab Version 3.8.45.
Mögliche Zielsysteme
Der Versand ist zu unterschiedlichen Zielsystemen möglich. Der häufigste Fall ist der Push an eine REST-API.
| Zielsystem / Weg | Beschreibung |
|---|---|
| REST-API | Push per HTTP an eine Web-API (Standardfall, Format JSON) |
| SOAP-Webservice | Push an einen SOAP-Webservice (Format XML) |
| HTTP-Endpoint | Einfache HTTP-Aufrufe (GET/POST/PUT) |
| Datei | Ablage als Datei (XML oder Bild) in einem Verzeichnis |
| SAP | Übergabe an SAP (RFC oder IDoc) |
| CUBE3 / PSI-WMS | Anbindung an CUBE3 bzw. ein PSI-Warehouse-Management-System |
Voraussetzungen – was Sie bereitstellen müssen
Je nach gewähltem Zielsystem benötigen wir von Ihnen die folgenden Angaben.
Push-Ziele (REST/SOAP/HTTP):
| Zielsystem | Von Ihnen bereitzustellen |
|---|---|
| REST-API | Ziel-URL (Endpoint); Authentifizierung (keine / Benutzer + Passwort / API-Key / OAuth-Zugangsdaten); erwartetes Datenformat (i. d. R. JSON); bei HTTPS ggf. das TLS-Zertifikat |
| SOAP-Webservice | Endpoint-URL bzw. WSDL; Authentifizierung; erwartete XML-Struktur; bei HTTPS ggf. das TLS-Zertifikat |
| HTTP-Endpoint | Ziel-URL und HTTP-Methode; ggf. Authentifizierung |
Weitere Ziele:
| Ziel | Von Ihnen bereitzustellen |
|---|---|
| Datei (XML/Bild) | Zielverzeichnis sowie gewünschtes Format und Encoding |
| SAP (RFC/IDoc) | SAP-Zugangsdaten (Mandant, Benutzer, Passwort, Host) und den Namen der RFC-Funktion bzw. des IDoc |
| CUBE3 / PSI-WMS | jeweils Ziel-URL und Zugangsdaten |
Technische Details
Ablauf: Der StatusdatenManager sendet die Daten über das Export-Event „DGS REST SERVER EXPORT" an ein DGS-Server-Plugin (Typ „DGSRestServerGatewayFactory"). Von dort werden sie über den Mediator (GatewayID + Funktion „exportData") an ein oder mehrere Client-Plugins weitergeleitet, die den eigentlichen Versand an das Zielsystem durchführen. Als Authentifizierung zwischen SEM und DGS werden NONE und ClientCredentials unterstützt.