Neu JTL-Wawi DHL Worker – DHL API, DirectJTL, OTTO-Retoure & Auto-Druck – All-in-One

web-nf

Aktives Mitglied
17. Juni 2017
30
1
Von mir auch ein voller Respekt für die Lösung. Ich werde auch versuchen das zum laufen zu bringen.
Auch für mich sind die Buchung des größeren JTL Tarifes "nur" um mein DHL Tarif weiter zu nutzen nicht relevant. Das möchte ich so nicht unterstützen.
 
Zuletzt bearbeitet:

NikuTRAX

Gut bekanntes Mitglied
13. Juli 2023
36
32
Auch wenn ich aktuell selbst kein DHL nutze, möchte ich an dieser Stelle einmal ein ausdrückliches Lob aussprechen!

Vielen Dank, dass du mit einem solchen Tool den blutsaugenden Investoren wie HG auf diese Weise den Stinkefinger zeigst.

Mich ärgert es schon seit Längerem, dass immer mehr elementare Funktionen, die ursprünglich selbstverständlicher Bestandteil der Software waren, in zusätzliche kostenpflichtige Pakete ausgelagert werden, nur um auch noch das letzte Quäntchen aus den ohnehin schon belasteten Händlern herauszupressen.

Diese zunehmende Monetarisierung bestehender Funktionen geht meiner Meinung nach völlig an den Interessen der langjährigen JTL-Nutzer vorbei.

Umso erfreulicher ist es, wenn engagierte Entwickler solchen Entwicklungen mit eigenen Lösungen etwas entgegensetzen.

Ich persönlich würde mir ein solches Tool auch für GLS wünschen!
@Merlin84
Vielen Dank für dein positives Feedback! 👍

Genau das war auch mein Gedanke bei der Entwicklung des DHL-Workers. Viele Händler haben ohnehin schon mit steigenden Kosten und sinkenden Margen zu kämpfen. Da muss man nicht auch noch für jede zusätzliche Funktion ein kostenpflichtiges Paket buchen.

Ich finde, dass gerade grundlegende Funktionen wie die Versandabwicklung möglichst unkompliziert und ohne zusätzliche laufende Kosten nutzbar sein sollten.

Deshalb habe ich den DHL-Worker entwickelt und stelle ihn der Community kostenlos zur Verfügung. Mir geht es nicht darum, mit solchen Tools Geld zu verdienen, sondern eine funktionierende Alternative anzubieten.

Und zu deinem Wunsch nach GLS:

Das ist tatsächlich eine interessante Idee! 😊

Der bestehende DHL-Worker ist bereits so aufgebaut, dass sich grundsätzlich auch weitere Versanddienstleister integrieren lassen. Eine zusätzliche GLS-Anbindung wäre daher technisch durchaus denkbar.

Allerdings gibt es dabei eine kleine Herausforderung: Ich selbst nutze GLS nicht und habe auch keinen GLS-Geschäftskundenvertrag.

Somit fehlen mir die entsprechenden Zugangsdaten und vor allem die Möglichkeit, den gesamten Versandprozess unter realen Bedingungen selbst zu testen.

Ich habe mich aber bereits ein wenig mit der technischen Umsetzung beschäftigt.

GLS bietet mit der neueren ShipIT-Farm-API eine Schnittstelle zur automatischen Erstellung von Versandlabels und zur Verarbeitung von Versandaufträgen.

Interessant ist dabei, dass GLS auch eine Sandbox- beziehungsweise Testumgebung zur Verfügung stellt. Darüber sollten sich zumindest grundlegende Funktionen wie die Kommunikation mit der API und die Erstellung von Testlabels entwickeln und überprüfen lassen.

Ob ein solcher Testzugang auch ohne bestehenden GLS-Geschäftskundenvertrag vollständig genutzt werden kann, müsste allerdings noch geklärt werden.

Mein Gedanke wäre folgender:

Ich würde den bestehenden DHL-Worker entsprechend erweitern, sodass künftig beide Versanddienstleister über denselben Worker genutzt werden können.

Die JTL-Wawi würde anhand der hinterlegten Versandart erkennen, ob eine Sendung über DHL oder GLS abgewickelt werden soll.

Anschließend würden die Versandlabels automatisch erstellt, die Sendungsnummern in die JTL-Datenbank zurückgeschrieben und die Versandinformationen wie bisher über JTL an die jeweiligen Marktplätze übermittelt.

Natürlich müsste die bisherige DHL-Funktion dabei vollständig erhalten bleiben.

Was ich dafür allerdings benötigen würde, wäre die Unterstützung von jemandem aus der Community, der GLS tatsächlich nutzt.

Wenn jemand einen GLS-Geschäftskundenvertrag besitzt und bereit wäre, eine solche Erweiterung später unter realen Bedingungen zu testen, wäre das eine große Hilfe.

Idealerweise könnte man zunächst gemeinsam mit der Sandbox arbeiten und anschließend mit einem echten GLS-Zugang überprüfen, ob die komplette Versandabwicklung zuverlässig funktioniert.

Ich möchte allerdings noch nichts versprechen. Erst einmal müsste geklärt werden, welche API-Funktionen verfügbar sind und welche Voraussetzungen GLS für die Nutzung verlangt.

Aber eines steht für mich fest: Sollte ich die GLS-Erweiterung umsetzen und zuverlässig zum Laufen bekommen, wird auch diese kostenlos für die Community zur Verfügung gestellt.

Vielleicht finden sich hier ja ein paar GLS-Nutzer, die Interesse daran haben und bei den Tests unterstützen würden. Dann könnte daraus durchaus etwas werden! 👍

Viele Grüße
Christian
 
  • Gefällt mir
Reaktionen: microline

NikuTRAX

Gut bekanntes Mitglied
13. Juli 2023
36
32
Klasse Arbeit! So etwas für DPD wäre mein Traum
@microline
Vielen Dank für dein Lob! 👍😊

DPD wäre tatsächlich eine interessante Erweiterung meines JTL-Versandworkers!

Die gute Nachricht: DPD bietet eine eigene API inklusive Sandbox-Testumgebung an. Damit könnte ich die Anbindung zunächst entwickeln und testen, ohne echte Pakete verschicken zu müssen.

Allerdings nutze ich selbst kein DPD und habe auch keinen entsprechenden Geschäftskundenvertrag. Ob ich sämtliche Testzugänge ohne Vertrag bekomme, müsste ich noch klären.

Mein Ziel wäre ein universeller, kostenloser JTL-Versandworker für DHL, GLS und DPD.

Der Worker soll automatisch den Versanddienstleister erkennen, Versandlabels erstellen und die Sendungsnummern direkt an die JTL-Wawi zurückgeben.

Dafür bräuchte ich allerdings Unterstützung aus der Community!

Wenn du DPD nutzt und bereit wärst, die Erweiterung später mit deinem Geschäftskundenzugang unter realen Bedingungen zu testen, wäre das ideal.

Ich werde mir die Schnittstelle genauer ansehen. Versprechen möchte ich noch nichts, aber technisch sieht es durchaus machbar aus.

Und selbstverständlich würde auch die DPD-Erweiterung kostenlos bleiben! 👍

DPD-Sandbox:
https://esolutions.dpd.com/entwickler/dpdcloudwebservice/sandbox.aspx?allowcloud=true

Viele Grüße
Christian
 
  • Gefällt mir
Reaktionen: microline

Alex R

Aktives Mitglied
15. Januar 2020
16
11
Von mir auch ein voller Respekt für die Lösung!!
Ich habe die JTL WaWi-Version 2.0.5.0. Der Export CSV unter „Versand → Import/Exportvorlagen“ ist bei mir komplett gesperrt. Diese Funktion ist also in der JTL WaWi Start Edition ab 2.0 Versionen deaktiviert.

Deshalb bin ich einen anderen Weg gegangen: Über „Admin → Druck, E-Mail, Exportvorlagen“ kann man im Unterbereich „Lieferschein → Exportieren“ eine eigene CSV-Datei erstellen.

Diese Datei lässt sich dann beim Versenden eines Pakets exportieren. Dabei spielt es keine Rolle, ob man den Lieferschein tatsächlich ausdruckt oder nicht. Man muss lediglich das Häkchen bei „Exportieren“ setzen, und schon funktioniert alles.
1.JPG2.JPG3.png4.png5.png6.png
 

Anhänge

Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: TheEnd und elcheffe

Merlin84

Gut bekanntes Mitglied
25. Oktober 2013
47
82

@ NikuTRAX ich kann das dann gerne testen mit GLS ich könnte ggf. auch bei der Entwicklung mitwirken falls nötig.​

Eine wichtige Info ist sicher noch das wir die Wawi in Version 1.5.55.8 verwenden, ich weiß nicht ob JTL zwischenzeitlich in dem Bereich Änderungen an der Datenbank vorgenommen hat.

Setzt bzw. übermittelt dein Worker auch automatisch die Sendungsnr. je nach Auftrag z.B. an Ebay bzw. Amazon?
 
Zuletzt bearbeitet:

Vape & Make

Aktives Mitglied
15. Januar 2016
61
10
@microline
Vielen Dank für dein Lob! 👍😊

DPD wäre tatsächlich eine interessante Erweiterung meines JTL-Versandworkers!

Die gute Nachricht: DPD bietet eine eigene API inklusive Sandbox-Testumgebung an. Damit könnte ich die Anbindung zunächst entwickeln und testen, ohne echte Pakete verschicken zu müssen.

Allerdings nutze ich selbst kein DPD und habe auch keinen entsprechenden Geschäftskundenvertrag. Ob ich sämtliche Testzugänge ohne Vertrag bekomme, müsste ich noch klären.

Mein Ziel wäre ein universeller, kostenloser JTL-Versandworker für DHL, GLS und DPD.

Der Worker soll automatisch den Versanddienstleister erkennen, Versandlabels erstellen und die Sendungsnummern direkt an die JTL-Wawi zurückgeben.

Dafür bräuchte ich allerdings Unterstützung aus der Community!

Wenn du DPD nutzt und bereit wärst, die Erweiterung später mit deinem Geschäftskundenzugang unter realen Bedingungen zu testen, wäre das ideal.

Ich werde mir die Schnittstelle genauer ansehen. Versprechen möchte ich noch nichts, aber technisch sieht es durchaus machbar aus.

Und selbstverständlich würde auch die DPD-Erweiterung kostenlos bleiben! 👍

DPD-Sandbox:
https://esolutions.dpd.com/entwickler/dpdcloudwebservice/sandbox.aspx?allowcloud=true

Viele Grüße
Christian
Bitte Internetmarke nicht vergessen (falls möglich). DANKE!
 

KristinaS

Gut bekanntes Mitglied
8. Mai 2017
133
18
Hallo @KristinaS ,

vielen Dank für deine ausführliche Rückmeldung und das Testen! 😊

Ich habe die v1.14 noch einmal überprüft.

1. Premium und Filialrouting

Premium für V66WPI ist bereits in der Funktion Build-OrderBody enthalten (ab Zeile 1191).

Du hast aber recht: Das Filialrouting parcelOutletRouting für V62KP fehlt noch. Das werden wir ergänzen, einschließlich der Prüfung der Empfänger-E-Mail-Adresse.

Eine optionale Aktivierung über die Config ist ebenfalls sinnvoll.

2. Amazon-Versandstatus

Die experimentelle SQL-Funktion ist tatsächlich bereits in der v1.14 enthalten.

Du findest sie innerhalb von Write-JtlTracking:

  • Zeile 692: Prüfung von EnableExperimentalShippingStatusSql
  • Zeile 737: Auslesen von AmazonPlatformId
  • Ab Zeile 740: Amazon-spezifische SQL-Verarbeitung
  • Zeile 1017: Protokollierung der vorgemerkten Versandmeldung
Allerdings gibt es einige Sicherheitsbedingungen. Beispielsweise verarbeitet die Funktion derzeit nur Amazon-Aufträge mit genau einer Bestellposition.

Die Übermittlung wird im Zusammenhang mit dem Eintragen der DHL-Sendungsnummer vorbereitet. Voraussetzung ist unter anderem, dass die Plattform-ID stimmt und die zugehörige Amazon-Bestellung in der JTL-Datenbank eindeutig gefunden wird.

Die eigentliche Übertragung an Amazon erfolgt anschließend über die JTL-Verarbeitung. Ob diese erfolgreich ausgeführt wird, muss gesondert geprüft werden.

Schau bitte einmal in dein Worker-Log, ob dort die Meldung

Amazon-Versandstatus SQL vorgemerkt

erscheint oder ob eine Fehlermeldung protokolliert wird.

Bitte teste die experimentelle SQL-Funktion vorerst nur mit entsprechendem Datenbank-Backup und überprüfter JTL-Datenbankstruktur.

Vielen Dank noch einmal für deine Unterstützung! 🤗

Viele Grüße
Christian
Hallo Christian,

ganz herzlichen Dank für Deine tolle Arbeit am Worker! 😊

Ich war ein paar Tage im Urlaub, daher kann ich jetzt erst weitermachen. Das Amazon-Update funktioniert jetzt auch bei mir bei Bestellungen mit einem Artikel einwandfrei – super, vielen Dank! Der Fehler neulich lag übrigens bei mir, bitte entschuldige. 😉

Wäre es möglich, die Versandstatusübermittlung auch auf Amazon-Bestellungen mit mehreren Artikeln zu erweitern? Ich mache keine Teillieferungen, sondern versende die Bestellungen immer vollständig in einem Paket. Daher wäre es klasse, wenn auch diese Bestellungen automatisch berücksichtigt werden könnten, ggf. durch optionale Schalterstellung konfigurierbar, falls es jemand sicherheitshalber nicht so haben möchte.

Für eine DPD-Lösung stehe ich ebenfalls gern für Tests zur Verfügung. Ich habe einen iloxx-Vertrag mit Anbindung über die DPD Cloud und könnte das Ganze damit in der Praxis testen.

Außerdem wäre eine Anbindung an die Deutsche Post Internetmarke für mich noch interessant. Besonders wichtig wären mir zunächst die Inlandstarife Kompaktbrief, Großbrief und Bücher- und Warensendung (BüWa).

Vielen Dank noch einmal für Dein Engagement und dafür, dass du den Worker kontinuierlich weiterentwickelst. Das hilft gerade kleineren Händlern wie mir wirklich sehr! 🤗
 

Alex R

Aktives Mitglied
15. Januar 2020
16
11
Hallo Christian,

nochmals vielen Dank für deine tolle Arbeit an diesem Worker!

Ich habe deinen Worker inzwischen im Bereich der DHL-Paketgewichtsstufen erweitert.

Der Hintergrund dafür ist, dass ich mit DHL einen Vertrag habe, in dem für unterschiedliche Gewichtsstufen verschiedene Versandpreise vereinbart sind. Diese Preisstufen möchte ich auch in meiner eigenen Preiskalkulation berücksichtigen und an meine Kunden weitergeben können. So kann ich bereits im Voraus abhängig vom Paketgewicht unterschiedliche Versandkosten für meine Kunden festlegen und diese Kosten bei meiner Kalkulation und Preisgestaltung berücksichtigen.

Bisher wurde das Gewicht einer Sendung anhand des in der CSV-Datei angegebenen Gewichts übernommen. Jetzt habe ich sechs feste Gewichtsstufen für den nationalen DHL-Paketversand ergänzt:

  • DHL Paket bis 1 kg Inland
  • DHL Paket bis 3 kg Inland
  • DHL Paket bis 5 kg Inland
  • DHL Paket bis 10 kg Inland
  • DHL Paket bis 20 kg Inland
  • DHL Paket bis 31,5 kg Inland
Wichtig ist, dass diese Versandart-Bezeichnungen in JTL-Wawi exakt so geschrieben und hinterlegt werden, damit der Worker sie korrekt erkennt.

Wenn eine dieser sechs Versandarten in JTL ausgewählt wird, erkennt der Worker automatisch die entsprechende Gewichtsstufe und übermittelt an DHL das jeweilige Höchstgewicht dieser Stufe – unabhängig davon, welches Gewicht in der CSV-Datei steht.

Alle sechs neuen Versandarten verwenden das bestehende DHL-Produkt V01PAK und die bereits hinterlegte Abrechnungsnummer. Sie sind ausschließlich für Sendungen innerhalb Deutschlands vorgesehen.

Alle bisherigen Versandarten und deren Verarbeitung bleiben unverändert.

Viele Grüße
 

Anhänge

wawi-dl

Sehr aktives Mitglied
29. April 2008
6.812
839
Vorweg, erstmal eine gute Sache, wir haben kürzlich unsere PackSoftware auch nochmals neu entwickelt mit Versand-Anbindung.

Was mir bei der Lösung überhaupt nicht gefällt, ist die Anbindung an JTL per SQL.
Macht das bitte NICHT, schreiben nur auf minimalstes beschränken!

Bitte keinesfalls versuchen direkt in die SQL Tabelle zu schreiben (nur wenn zwingend erforderlich), auch keine JTLWawiExtern.dll verwenden, da hier schnell interne Prozesse übersprungen werden.
Wir hatten uns das auch lange überlegt und darum nicht gemacht.

Erst @mvh hat den entscheidenden Tipp mit "jtlCore.dll" geliefert, schaut euch diese an, diese haben wir angebunden und diese feuert auch alle internen Prozesse ab!
Versanddaten schreiben wir in eigene Arbeitstabellen, diese werden dann abgeholt und über offizielle interne Prozesse auch an alle Plattformen übermittelt.

Wir schreiben daher wirklich nur "Sendungsnummer" und "Versanddatum" rein, dann wird die "jtlCore.dll" gefeuert die dann alles macht.
Nur als Tipp, nicht dass sich mal jemand wundert warum Worker, SP, Trigger etc. nicht gelaufen sind.
 

web-nf

Aktives Mitglied
17. Juni 2017
30
1
Hallo zusammen,
ich selber könnte sowas nicht selber entwickeln. Zumindest habe ich die Programme und deren Funktionsweise verstanden. KI hat mir sehr geholfen das ganze zu testen.
Ohne solche Hilfe wäre ich wirklich nicht weit gekommen, da Grundlegende Angaben fehlen die nur für einen klar sind der tiefergreifende Kenntnisse hat. Z.B. schon mal mit Powershell gearbeitet hat.
Test im DHL Developer Portal /Sandbox war okay und ich konnte ein Testlabel erstellen.
Ist es richtig das man von den Developer Portal dann nur noch die API Schlüssel braucht und Rest geht dann über das Geschäftkundenportal?
Bei dem Schritt habe ich noch folgende Fehlermeldung "Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert"

Ich möchte den JTL DHL Community Worker v1.14 für DHL Kleinpaket von der Sandbox auf Produktion umstellen. Die Sandbox-Tests liefen. In Produktion bricht der Worker mit -ValidateOnly bereits beim OAuth-Tokenabruf mit HTTP 401 – Nicht autorisiert ab.

So habe ich die beiden DHL-Zugänge eingerichtet:

  • DHL Developer Portal: API Key und API Secret aus meiner App „DHL Paket API“. Die App steht auf approved, Parcel DE Shipping ist für Production (Europe) als aktiviert aufgeführt.
  • DHL Geschäftskundenportal: Benutzername und Passwort zunächst von einem persönlichen Unterbenutzer, danach von einem neu angelegten Systembenutzer mit „Versenden Paket & Waren“ → „Beauftragen“. Die neuen Daten habe ich über Production-Zugang-Einrichten.cmd hinterlegt. Beide Benutzer führten zum selben 401.
Direkter Test: Auch nach 24 Stunden liefert ein direkter PowerShell-POST an https://api-eu.dhl.com/parcel/de/account/auth/ropc/v1/token mit grant_type=password und den frisch eingegebenen Produktionsdaten denselben 401. Der Fehler tritt damit auch unabhängig vom Worker und vor der Prüfung der Versanddaten auf.

Läuft der Worker bei euch in Produktion? Habt ihr die Zugangsdaten aus den beiden Portalen genauso zugeordnet? Falls ihr denselben 401 hattet, was hat ihn bei euch behoben? Musste DHL den API-Schlüssel zusätzlich für Produktion freischalten, obwohl die App bereits genehmigt war?

Viele Grüße
Bernd
 

NikuTRAX

Gut bekanntes Mitglied
13. Juli 2023
36
32
Hallo zusammen,
ich selber könnte sowas nicht selber entwickeln. Zumindest habe ich die Programme und deren Funktionsweise verstanden. KI hat mir sehr geholfen das ganze zu testen.
Ohne solche Hilfe wäre ich wirklich nicht weit gekommen, da Grundlegende Angaben fehlen die nur für einen klar sind der tiefergreifende Kenntnisse hat. Z.B. schon mal mit Powershell gearbeitet hat.
Test im DHL Developer Portal /Sandbox war okay und ich konnte ein Testlabel erstellen.
Ist es richtig das man von den Developer Portal dann nur noch die API Schlüssel braucht und Rest geht dann über das Geschäftkundenportal?
Bei dem Schritt habe ich noch folgende Fehlermeldung "Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert"

Ich möchte den JTL DHL Community Worker v1.14 für DHL Kleinpaket von der Sandbox auf Produktion umstellen. Die Sandbox-Tests liefen. In Produktion bricht der Worker mit -ValidateOnly bereits beim OAuth-Tokenabruf mit HTTP 401 – Nicht autorisiert ab.

So habe ich die beiden DHL-Zugänge eingerichtet:

  • DHL Developer Portal: API Key und API Secret aus meiner App „DHL Paket API“. Die App steht auf approved, Parcel DE Shipping ist für Production (Europe) als aktiviert aufgeführt.
  • DHL Geschäftskundenportal: Benutzername und Passwort zunächst von einem persönlichen Unterbenutzer, danach von einem neu angelegten Systembenutzer mit „Versenden Paket & Waren“ → „Beauftragen“. Die neuen Daten habe ich über Production-Zugang-Einrichten.cmd hinterlegt. Beide Benutzer führten zum selben 401.
Direkter Test: Auch nach 24 Stunden liefert ein direkter PowerShell-POST an https://api-eu.dhl.com/parcel/de/account/auth/ropc/v1/token mit grant_type=password und den frisch eingegebenen Produktionsdaten denselben 401. Der Fehler tritt damit auch unabhängig vom Worker und vor der Prüfung der Versanddaten auf.

Läuft der Worker bei euch in Produktion? Habt ihr die Zugangsdaten aus den beiden Portalen genauso zugeordnet? Falls ihr denselben 401 hattet, was hat ihn bei euch behoben? Musste DHL den API-Schlüssel zusätzlich für Produktion freischalten, obwohl die App bereits genehmigt war?

Viele Grüße
Bernd
Hallo Bernd,

danke für die ausführliche Rückmeldung. Ich habe den Ablauf in unserem Worker v1.14 und im neutralen Paket noch einmal im Code geprüft. Dein Test mit -ValidateOnly ist für den ersten Produktionscheck genau richtig.

Der Worker liest in Produktion die vier Zugangsdaten aus production.credentials.json und ruft in Get-AuthHeaders denselben DHL-Token-Endpunkt auf, den du direkt getestet hast. Er übergibt die fünf Formularfelder bereits als PowerShell-Hashtable. Sobald DHL ein Token zurückgibt, schickt der Worker im Validierungslauf die Sendung mit validate=true an die Versand-API. Ein Label entsteht erst beim Echtversand.

Da du die Zugangsdaten für den direkten Test frisch eingegeben hast und auch dort einen 401 bekommst, lässt sich der Fehler unabhängig von der verschlüsselten Zugangsdaten-Datei reproduzieren. Die Kleinpaket-Abrechnungsnummer wird bei diesem Aufruf noch gar nicht an DHL übermittelt.

Deine Zuordnung entspricht der DHL-Dokumentation. Key und Secret kommen aus der App im Developer Portal, Benutzername und Passwort aus dem Geschäftskundenportal. Der Systembenutzer ist auch für unser neutrales Paket vorgesehen. Welche Zugangsdaten DHL konkret ablehnt, lässt sich aus dem HTTP-Status allein nicht erkennen.

Beim Nachsehen ist mir aufgefallen, dass unsere ausführliche DHL-Fehlerausgabe erst beim Aufruf der Versand-API greift. Der Tokenabruf liegt davor. Deshalb wäre der Antworttext des direkten Token-Tests jetzt am hilfreichsten. Falls DHL einen Fehlercode oder eine Request-ID zurückgibt, poste die Angaben gern hier, bitte ohne Zugangsdaten oder Tokens.

Falls DHL nur den 401 zurückgibt, würde ich den DHL-API-Support mit App-Name und genauem Zeitpunkt des Aufrufs bitten, die Produktionsfreigabe für den verwendeten App-Key zu prüfen und nachzusehen, ob die Anfrage am App-Zugang oder am Systembenutzer scheitert. Sobald der direkte Tokenabruf klappt, kannst du im neutralen Paket mit Production-Nur-Validieren.cmd weitermachen. Wenn die Validierung durchläuft, kannst du mit Production-Einmal-Echtversand.cmd eine CSV mit genau einer Sendung für den ersten Labeltest auswählen.

Viele Grüße
Christian
 

web-nf

Aktives Mitglied
17. Juni 2017
30
1
Hallo Bernd,

danke für die ausführliche Rückmeldung. Ich habe den Ablauf in unserem Worker v1.14 und im neutralen Paket noch einmal im Code geprüft. Dein Test mit -ValidateOnly ist für den ersten Produktionscheck genau richtig.

Der Worker liest in Produktion die vier Zugangsdaten aus production.credentials.json und ruft in Get-AuthHeaders denselben DHL-Token-Endpunkt auf, den du direkt getestet hast. Er übergibt die fünf Formularfelder bereits als PowerShell-Hashtable. Sobald DHL ein Token zurückgibt, schickt der Worker im Validierungslauf die Sendung mit validate=true an die Versand-API. Ein Label entsteht erst beim Echtversand.

Da du die Zugangsdaten für den direkten Test frisch eingegeben hast und auch dort einen 401 bekommst, lässt sich der Fehler unabhängig von der verschlüsselten Zugangsdaten-Datei reproduzieren. Die Kleinpaket-Abrechnungsnummer wird bei diesem Aufruf noch gar nicht an DHL übermittelt.

Deine Zuordnung entspricht der DHL-Dokumentation. Key und Secret kommen aus der App im Developer Portal, Benutzername und Passwort aus dem Geschäftskundenportal. Der Systembenutzer ist auch für unser neutrales Paket vorgesehen. Welche Zugangsdaten DHL konkret ablehnt, lässt sich aus dem HTTP-Status allein nicht erkennen.

Beim Nachsehen ist mir aufgefallen, dass unsere ausführliche DHL-Fehlerausgabe erst beim Aufruf der Versand-API greift. Der Tokenabruf liegt davor. Deshalb wäre der Antworttext des direkten Token-Tests jetzt am hilfreichsten. Falls DHL einen Fehlercode oder eine Request-ID zurückgibt, poste die Angaben gern hier, bitte ohne Zugangsdaten oder Tokens.

Falls DHL nur den 401 zurückgibt, würde ich den DHL-API-Support mit App-Name und genauem Zeitpunkt des Aufrufs bitten, die Produktionsfreigabe für den verwendeten App-Key zu prüfen und nachzusehen, ob die Anfrage am App-Zugang oder am Systembenutzer scheitert. Sobald der direkte Tokenabruf klappt, kannst du im neutralen Paket mit Production-Nur-Validieren.cmd weitermachen. Wenn die Validierung durchläuft, kannst du mit Production-Einmal-Echtversand.cmd eine CSV mit genau einer Sendung für den ersten Labeltest auswählen.

Viele Grüße
Christian
Okay, ich bin nun einen Schritt weiter.
Die Api Key wollte ich mit Copy und Paste einfügen, dabei hat er aber nur einen Stern als Verschlüsselung angzeigt. Hatte ich mir nichts bei gedacht.
Habe das Production-Zugang-Einrichten nun erweitert indem er die Zeichen aus der Zwischenablage korrekt übernimmt und nun auch meldet wieviel Zeichen er eingefügt hat.
Nun klappt auch schon mal die Anmeldung.
 

Ähnliche Themen