clarius hat geschrieben: ↑10. Aug 2020 21:16
Deswegen behalte ich mein EasyLog solange es läuft auf jeden Fall.
Mich hat vor ein paar Wochen ein DHL-Fritze angerufen und nachgefragt, warum ich immer noch EasyLog und nicht das neue Geschäftskundenportal benutze. Er war dann etwas erschrocken, weil er das Wort "Scheiße" noch nie so oft in einem Satz gehört hat.
Ich hatte DHL ursprünglich versprochen, auf VERSENDEN bis Ende 2019 umzustellen. Im Laufe des Jahres 2019 habe ich mehrere Anrufe von irgendwelchen "Spezialisten" bekommen, die mich im Auftrag von DHL unterstützen sollten. Ich habe dankend abgelehnt, weil die meisten Umstellarbeiten bei uns im Workflow nötig waren. Und da sollen die bitte schön ihre Finger weg lassen. Damals wurde mir gesagt, dass ich ab Januar 2020 keinen Support mehr für EasyLog bekomme. Aus diversen Gründen kam ich aber erst vor kurzem, Mitte 2020 dazu, mich weiter mit dem Thema zu befassen, das meiste vorzubereiten und die vorgelagerte Software umzubauen. Vermutlich in KW 40 werden wir unseren automatisierten Versand von EasyLog auf VERSENDEN umstellen.
Als es kürzlich eine große Störung bei der EDI-Schnittstelle bei EasyLog gab, konnte ich die EasyLog-Hotline noch problemlos erreichen und der Herr war auch willig. Scheinbar sind wir nicht die einzigen, die noch ewig an EasyLog festhalten.
Ganz ehrlich: Der "DHL Shipment Polling Client" ist eines der schlimmsten Stück Software, das ich seit vielen Jahren zu Gesicht bekam!
Das Ding ist so beschissen konstruiert, dass ich jetzt schon über eine Alternative nachdenke, bevor ich produktiv auf VERSENDEN umstelle.
Für mich macht der Polling Client den Eindruck, als ob den ein mittelmäßiger Praktikant während seines Wirtschaftsinformatik-Studiums im 2. Semester zusammengebastelt hat. Kurz nachdem ihm erklärt wurde, wie er ein Hello-World in Java zusammenklickt. Das muss auf jeden Fall jemand gewesen sein, der keinerlei Erfahrung hat, wie eine robust funktionierende Software gebaut werden muss, die ihre Aufgaben zuverlässig ausführt und sich gut in einen Workflow integrieren lässt.
Meine Kritikpunkte am Polling Client bzw. an VERSENDEN allgemein:
- Der Polling Client ist eine "Black Box"! - Also genau etwas, das man so nicht in seinem Workflow haben will!
Wenn keine Verbindung zum Webserver hergestellt werden kann, importiert er die Sendung, aber macht danach nichts. Er zeigt nur eine Meldung in seiner GUI an. Keine maschinenlesbare Ausgabe. Keine Fehlerdatei. Keine Logdatei. Kein Fehler-Ordner. Keine automatische Ausgabe des fehlenden Paketaufklebers, nachdem die Verbindung zum Webserver wieder läuft. Nichts, nada, niente! <Grrrr!>
Was bleibt mir, um das zu lösen? --> Ich muss eine Lösung bauen, die die Eingabe mit der Ausgabe (das Paketaufkleber-PDF) vergleicht. Wenn nicht innerhalb eines bestimmten Zeitraumes der Paketaufkleber rauskommt, dann Eingabedatei erneut an den Pollingclient übergeben... Schleife so lange wiederholen, bis der gewünschte Paketaufkleber rauskommt...
- Die maximale Länge vieler Felder ist kürzer als bei EasyLog. Beispiel: "Empfänger Name 1" bis 3: Durfte in EasyLog max. 40 Zeichen lang sein. Bei VERSENDEN nur noch 35 Zeichen!
Wir haben über 5.000 aktive Kunden in unserer Datenbank. Die meisten davon haben mehrere Lieferadressen. Ca. 40 % hiervon haben eine Lieferadresse abgespeichert, bei der mindestens eines der Felder "Empfänger Name 1" bis 3 mehr als 35 Zeichen enthält.
Wenn der Polling Client eine Datei bekommt, die ein zu langes Feld enthält, dann druckt er den Paketaufkleber einfach stillschweigend nicht aus. Ohne Angabe von Gründen! Es steht dann nur in den Meldungen in der GUI. Die aber, wie oben schon erwähnt, nicht maschinenlesbar sind. 
Erst wenn man sich im Geschäftskundenportal anmeldet und dort in der Liste nachschaut, bekommt man irgendwo einen Hinweis, woran das Problem lag. Das ist nun quasi der Super-GAU! Als kurzfristigen Workaround habe ich die vorgelagerte Software erweitert, so dass sie den Inhalt der betroffenen Felder einigermaßen sinnvoll automatisch neu verteilt. Nur noch ca. 1 % kann auf diese Weise nicht optimiert werden. Da bekomme ich dann eine automatische Mail, damit ich mich manuell darum kümmere. Langfristig müssen wir unseren Webshop umbauen, so dass betroffene Kunden im Bestellprozess gezwungen werden, die Lieferadresse zu korrigieren. 
- Der Polling Client kann kein PDF ausgeben. Online im DHL Geschäftkunden-Portal kann man eine PDF des Paketaufklebers herunterladen. Aber der Polling Client unterstützt schlauerweise nur die direkte Ausgabe an einen Windows-Drucker.
--> Weil wir den Weg über PDF benötigen, habe ich einen "PDF-Drucker" besorgt, der diese Aufgabe übernimmt. Der Polling Client druckt auf diesen PDF-Drucker, in dessen Einstellungen wir einen festen Ausgabeordner hinterlegt haben. Danach kommt die kniffligeste Aufgabe: Herauszufinden, zu welchem Paket das PDF gehört. Zum Glück haben wir einen PDF-Drucker gefunden, der automatisch eine TXT-Datei neben jedes PDF ausgibt. In der TXT-Datei steht sämtlicher Text, der im PDF enthalten ist. Somit brauchten wir "nur" in der TXT-Datei nach den entsprechenden Strings zu suchen und könen somit eine Verbindung des PDFs zum entsprechenden Auftrag und Paket-Nr. herstellen.
- Wenn das Paket an eine Postfiliale oder Packstation addressiert ist, dann wird das Feld "Empfänger Name 3" nicht ausgewertet. Die Postnummer MUSS dann im Feld "Empfänger Name 2" stehen. Sonst wird die Sendung nicht akzeptiert! Es kommt dann kein Paketaufkleber raus und man sieht die Ursache nur online im Geschäftskundenportal, siehe oben.
Dies ist nirgendwo dokumentiert! Ich habe sämtliche Dokus mehrfach elektronisch durchsucht. Das konnte ich nur durch mehrere Tests und der Beobachtung des Verhaltens bei einer manuellen Erfassung herausfinden!
- Wer zum Teufel ist nur auf die beschissene Idee gekommen, den Nachfolger von EasyLog "Versenden" zu nennen???
Fazit: DHL hat das echt massiv verkackt!
Man hätte den Polling Client wirklich cool bauen können. Da hätte man nur 3-4 wichtige Dinge beachten müssen, und schon wäre der eine wirklich sehr praktische Software. Aber so in diesem Zustand muss ich definitiv vermuten, dass das nur eine schlechte Demo-Version ist, die künstlich in ihren Funktionen beschränkt wurde. So beschissen kann man eine solche Software nur bauen, wenn man das absichtlich so beschissen haben will.
Wie geht Ihr damit um?
Habt Ihr Euch eine kostspielige Software von MHP, Heidler, Anton, o.ä. besorgt?
Nutzt Ihr den Polling Client?
Oder habt Ihr Euch was eigenes zusammengebaut, nachdem Ihr Euch die Schnittstellenspezifikation im DHL-Entwicklerportal besorgt habt?
Wir brauchen eine Lösung, die nicht on-demand die Paketaufkleber erzeugt, sondern die entweder offline läuft (so wie EasyLog), oder noch besser die Paketaufkleber schon mit einem Vorlauf von einigen Stunden erzeugt und dann nur noch on-demand ausdruckt.
Grund: Unsere Verpackungsanlage ist direkt an die Produktionsstrecke angebunden. Wenn da ein Paketaufkleber nicht sofort rauskommt, wenn er benötigt wird, dann bleibt die Strecke stehen und nach wenigen Minuten haben sich so viele Pakete aufgestaut, dass wir auf dieser Linie die Produktion pausieren müssen. Deshalb kommt für uns
keine Lösung in Frage, bei der die Paketaufkleber quasi "live" über eine Internetverbindung erzeugt werden. Das ist zu unsicher.
Deshalb die von uns gebaute Lösung mit den PDFs, die wir durch den Polling Client mit einigen Stunden Vorlauf erzeugen lassen.
Ich bin schon kurz davor, mir die Schnittstellenspezifikation reinzuziehen und nochmal aktuelle Angebote von den drei o.g. Anbietern einzuholen...
Der Polling Client ist bei uns nur deshalb nutzbar, weil wir mehrere Programme drumherum gebaut haben, die all seine Defizite kompensieren. Aber nicht jede Firma hat eigene Softwareentwickler, die sowas machen können.
<kopfschüttel>
Grüße
Thorsten
