Neu JTL Rest API

[Thomas Lisson]

Hi,

das Thema ist in Umsetzung. Frühstens in JTL-Wawi 1.6 werden wir hierzu einiges veröffentlichen.

 

[mschop]

@Thomas Lisson könnt ihr schon ganz grob das technische Konzept und den Zeitplan erläutern? Wir stehen gerade an dem Punkt, an dem wir überlegen, ob wir bei JTL bleiben oder zu einem anderen ERP wechseln. Wir haben Anforderungen, die weit über die Standard-Anwendungsfälle hinaus gehen und für die wir u.A. eine solide API benötigen.

Wichtig im Bezug auf die API wäre auch, dass man Events aus der JTL-Wawi Subscriben kann (wie auch immer man das technisch löst z.B. über Webhooks). Weil wir müssen nicht nur Daten in die Wawi schreiben, sondern auch auf Events in der Wawi reagieren. Die Workflows sind dafür aus verschiedenen Gründen eher weniger geeignet.

Des weiteren wäre es interessant, einen ganz groben Zeitplan für die 1.6 bzw. API zu haben. Wir haben jetzt wahrscheinlich erstmal noch ein anderes großes Projekt vor der Brust, bei dem wir mit dem aktuellen Zustand gut leben können. Aber Konzept und Zeitplan für die API müsste passen, da wir ansonsten bei der Umsetzung des darauffolgenden Projektes in Verzögerung kommen würden.

 

[SebiW]

@mschop ich vermute mal da wird mindestens ein Jahr ins Land gehen. Die Pilotkundenversionen für die frühen Testkunden fangen gerade erst mit der 1.5. an. Es wird also mindestens noch ein halbes Jahr dauern, bis eine 1.5. stable raus kommt. Zwischen 1.3 Stable und 1.4 Stable lagen auch 6 Monate, genau wie bei den vorherigen Majors.

 

[mschop]

@SebiW Ein Jahr ist wahrscheinlich noch in Ordnung. Eher fangen wir wahrscheinlich nicht mehr der Umsetzung an.

 

[Thomas Lisson]

Hi,

könnt ihr schon ganz grob das technische Konzept und den Zeitplan erläutern?

Alle wichtigen Entitäten sollen über die API lesend sowie schreibend angesprochen werden. Sie wird dem REST API Standard folgen.
Einen Zeitplan kann ich dir nicht geben, damit würde ich den Releasezeitpunkt der 1.6 verraten Die 1.5 steht vor der Tür, die 1.6 ein riesiger Meilenstein in der Geschichte von JTL-Wawi, nimmt bei uns intern immer mehr Gestalt an. In die Pilotphase sollten wir es dieses Jahr schaffen.

Wichtig im Bezug auf die API wäre auch, dass man Events aus der JTL- Wawi Subscriben kann (wie auch immer man das technisch löst z.B. über Webhooks).

Das wird die API nicht können - zumindest nicht von Anfang an. Für dieses Szenario sind jedoch die Workflows prädestiniert, als Aktion kannst du da z.B. einen beliebigen Webservice ansprechen.

 

[mschop]

Danke für das Feedback!

Alle wichtigen Entitäten sollen über die API lesend sowie schreibend angesprochen werden. Sie wird dem REST API Standard folgen.
Einen Zeitplan kann ich dir nicht geben, damit würde ich den Releasezeitpunkt der 1.6 verraten Die 1.5 steht vor der Tür, die 1.6 ein riesiger Meilenstein in der Geschichte von JTL-Wawi, nimmt bei uns intern immer mehr Gestalt an. In die Pilotphase sollten wir es dieses Jahr schaffen.

Werdet ihr auch GraphQL unterstützen?
Wird es auch möglich sein, Ausgaben anzustoßen?

Das wird die API nicht können - zumindest nicht von Anfang an. Für dieses Szenario sind jedoch die Workflows prädestiniert, als Aktion kannst du da z.B. einen beliebigen Webservice ansprechen.

Bei den Workflows stehen aktuell viel zu wenige Events bereit. Wir werden für anstehende Projekte einige Dinge im Lager anpassen müssen. Z.B. werden wir wahrscheinlich auf Bestandsänderungen reagieren müssen.

Des Weiteren ist die Versionierbarkeit eher nicht gegeben. Wir werden unseren Quellcode in Zukunft in einem Mono-Repository verwalten. Dadurch können wir bei allen unseren Systemen eine konsequente Versionierung durchführen. Probleme macht uns hierbei nur die JTL-Wawi. Die Workflows interagieren mit unserer restlichen Software und müssen daher auch immer auf dem gleichen Stand sein wir der Rest unserer Software. Es ist jetzt derzeit nicht das riesen Problem, sorgt aber für unnötigen Aufwand und Fehlerquellen. Ggf. werde ich die Workflows im Repository pflegen und dann in die JTL-Wawi-DB schreiben müssen. Wirklich befriedigend ist dieser Ansatz aber nicht.

Ein weiterer wichtiger Punkt ist, dass wir nicht mit bekommen, wenn bei den Workflows etwas schief läuft. Wir können die Workflows ja in keiner Weise überwachen. Wenn z.B. der Web-Request fehlschlägt, sei es weil ein Netzwerkproblem existiert, dann bekommen wir das Problem erst dann mit, wenn die Probleme beim User aufschlagen.

 

[Thomas Lisson]

Hi,

Werdet ihr auch GraphQL unterstützen?

Nein - zumindest nicht initial.

Wird es auch möglich sein, Ausgaben anzustoßen?

Was meinst du damit genau? Mach mal ein Beispiel.

Wenn z.B. der Web-Request fehlschlägt, sei es weil ein Netzwerkproblem existiert, dann bekommen wir das Problem erst dann mit, wenn die Probleme beim User aufschlagen.

Kannst du nicht mit der Rückgabe des Webservices arbeiten, indem du diesen Wert in eine Variable schreibst? Aber ich verstehe, dass es problematisch ist.

Wie ist es mit Triggern auf Tabellen, die euch wichtig sind? Die können SPs / .NET Code aufrufen. Verlangsamt jedoch die Wawi.

 

[mschop]

Was meinst du damit genau? Mach mal ein Beispiel.

Ich meine die Ausgaben wie Rechnungen, Aufträge etc. Soweit ich weiß, kann man die Ausgabe auch über die JTL-Wawi-Extern.dll anstoßen. Wir hatten uns damals allerdings für eine Anbindung der Wawi über eine PHP basierte Web-API entschieden. Einfach aus dem Grund heraus, dass wir dringend etwas fertig bekommen mussten und ich damals flüssiger in der Programmierung von PHP war. Die Ausgabe haben wir allerdings nicht über die dll umgesetzt, sondern wir stoßen Workflows über die DB an um die Dokumente auf dem Worker auszudrucken. Das funktioniert soweit auch, allerdings ist es auch hier schwierig etwaige Probleme im Druck mitzubekommen. Soll heißen: Wenn der Druckerspooler rum spinnt oder ein Fehler in der Ausgabe ist und ein PrintLog auf dem Desktop gespeichert wird, dann bekommt man davon wieder nur schwerlich was mit. Das zu überwachen wäre eher kompliziert.
Ich würde diese Art der Ausgabe gerne ablösen und stattdessen eine deutlich Fehlertolerantere Lösung nutzen. Wenn ihr also die Ausgabe über die API anbieten würdet, könnte man z.B. über die http Response zurück geben, ob die Ausgabe erfolgreich war.

Kannst du nicht mit der Rückgabe des Webservices arbeiten, indem du diesen Wert in eine Variable schreibst? Aber ich verstehe, dass es problematisch ist.

Mhhhh. Wäre eine Möglichkeit. Aber eine echt hässliche. Wirklich zufriedenstellend fände ich die Lösung nicht. Aber ich behalte den Vorschlag im Hinterkopf.

Wie ist es mit Triggern auf Tabellen, die euch wichtig sind? Die können SPs / .NET Code aufrufen. Verlangsamt jedoch die Wawi.

Das wäre technisch gesehen eine Möglichkeit. Allerdings dachte ich, dass dies von JTL so nicht gewünscht sei. Die letzte Info, die ich hatte war, dass JTL im Zweifelsfall sogar den Support einstellt, wenn eigene Trigger hinzugefügt wurden. Oder ist diese Information falsch / veraltet?

 

[Thomas Lisson]

Hi,

Ausgabe haben wir auch auf dem Schirm. Genaueres kann ich derzeit noch nicht sagen. Ihr könnt aber auch die DLL auch über PHP anstoßen.
Am besten kommst du auf die JTL-Connect am 30.08 und sprichst dort mit Maik oder Sebastian. Sie können die wesentlich mehr Input hierzu geben. Sebastian hält auch einen Vortrag um 16:50 zum Thema "Mach die Wawi zu deiner Wawi" - schnapp ihn dir nach dem Vortrag: https://jtl-connect.de/vortraege

Die letzte Info, die ich hatte war, dass JTL im Zweifelsfall sogar den Support einstellt, wenn eigene Trigger hinzugefügt wurden.

Schreibende Eingriffe in der DB, die nicht über unser SPs laufen, sind problematisch. Wenn du einen Trigger einsetzt, um auf ein Update Event zu reagieren ohne in der DB zu schreiben, sollte das keine Auswirkungen haben. Aber grundsätzlich sollte man hierbei sehr vorsichtig sein.

 

[MaxWe]

Kurze Frage: Ist ein jtlConnector nicht bereits eine Schnittstelle => API?

Ich bin grad dabei eine kleine Schnittstelle zu konzipieren, die Variationsdaten eines Artikels in einem Auftrag via Web Formular füllt.
Hierbei schaue ich mir verschiedene Lösungen an und habe mir auch mal den Connector angeschaut.
Im Endeffekt bietet dieser alles was man so braucht und muss vereinfacht nur noch mit Controllern ausgestattet werden.
Ich muss ihn ja nicht in Verbindung mit einem Shop verwenden Ich nutze eben lediglich einige wenige Funktionen.
So schreibe ich nicht direkt in die DB, sondern gehe ganz sauber über die von jtl geschaffene Schnittstelle.

Sehe ich das ganz falsch oder denke ich mir einen eigenen kleinen Connector nur zu leicht?
Als Basis würde ich dann zbsp. Lumen by Laravel nutzen.

Grüße

EDIT: Ich sehe schon das Problem: Multishop Lizenz nötig

 

[mschop]

Kurze Frage: Ist ein jtlConnector nicht bereits eine Schnittstelle => API?

Ich bin grad dabei eine kleine Schnittstelle zu konzipieren, die Variationsdaten eines Artikels in einem Auftrag via Web Formular füllt.
Hierbei schaue ich mir verschiedene Lösungen an und habe mir auch mal den Connector angeschaut.
Im Endeffekt bietet dieser alles was man so braucht und muss vereinfacht nur noch mit Controllern ausgestattet werden.
Ich muss ihn ja nicht in Verbindung mit einem Shop verwenden Ich nutze eben lediglich einige wenige Funktionen.
So schreibe ich nicht direkt in die DB, sondern gehe ganz sauber über die von jtl geschaffene Schnittstelle.

Sehe ich das ganz falsch oder denke ich mir einen eigenen kleinen Connector nur zu leicht?
Als Basis würde ich dann zbsp. Lumen by Laravel nutzen.

Grüße

EDIT: Ich sehe schon das Problem: Multishop Lizenz nötig

Hallo MaxWe,

Das Problem ist nicht die Multishop-Lizenz sondern die Art und Weise, wie der Connector arbeitet. Zunächst einmal ist der JTL-Connector nicht wirklich bidirektional. Es werden zwar Daten von der JTL-Wawi zum Shop-System geschickt und vom Shop-System abgerufen, allerdings geht der Verbindungaufbau immer von der JTL-Wawi aus. Wenn du also wirklich aktuelle Daten brauchst (ohne Verzögerung durch den Abgleichsprozess) ist der Connector dafür nicht geeignet.

Außerdem kann man mit dem Connector nicht auf alle Daten in der JTL-Wawi zugreifen. In meinem Fall z.B. musste ich Rechnungskorrekturen anlegen und verändern. Eine API hätte mir das Leben hier leichter gemacht. So musste ich direkt mit der Datenbank arbeiten. Der JTL-Connector ist halt wirklich nur für die Anbindung eines Shop-Systems konzipiert und deckt bei weitem nicht alle Anwendungsfälle ab.

Gruß
mschop

 

[MaxWe]

Hallo MaxWe,

Das Problem ist nicht die Multishop-Lizenz sondern die Art und Weise, wie der Connector arbeitet. Zunächst einmal ist der JTL-Connector nicht wirklich bidirektional. Es werden zwar Daten von der JTL-Wawi zum Shop-System geschickt und vom Shop-System abgerufen, allerdings geht der Verbindungaufbau immer von der JTL-Wawi aus. Wenn du also wirklich aktuelle Daten brauchst (ohne Verzögerung durch den Abgleichsprozess) ist der Connector dafür nicht geeignet.

Außerdem kann man mit dem Connector nicht auf alle Daten in der JTL-Wawi zugreifen. In meinem Fall z.B. musste ich Rechnungskorrekturen anlegen und verändern. Eine API hätte mir das Leben hier leichter gemacht. So musste ich direkt mit der Datenbank arbeiten. Der JTL-Connector ist halt wirklich nur für die Anbindung eines Shop-Systems konzipiert und deckt bei weitem nicht alle Anwendungsfälle ab.

Gruß
mschop

Danke dir für deine Erläuterung!
Ich denke ich könnte den Connector für mein Vorhaben vielleicht nutzen, aber ich werde wohl direkt mit der DB kommunizieren.
Eine API direkt von JTL sollte so oder so das Ziel sein, daran wird aber ja gearbeitet

Grüße

 

[Verkäuferlein]

Bei den Workflows stehen aktuell viel zu wenige Events bereit. Wir werden für anstehende Projekte einige Dinge im Lager anpassen müssen. Z.B. werden wir wahrscheinlich auf Bestandsänderungen reagieren müssen.

Bitte mal hier voten, diese Funktion wird bisher von JTL leider scheinbar nicht als wichtig genug für eine Warenwirtschafts-Software erachtet und schafft es daher leider seit über 31/2 Jahren nicht in die Umsetzung:
https://issues.jtl-software.de/issues/WAWI-10099

@Thomas Lisson
Warum braucht eine solche "Kernfunktion" einer Warenwirtschafts-Software solange für die Umsetzung?

 

[T4DT.GmbH]

Bitte mal hier voten, diese Funktion wird bisher von JTL leider scheinbar nicht als wichtig genug für eine Warenwirtschafts-Software erachtet und schafft es daher leider seit über 31/2 Jahren nicht in die Umsetzung:
https://issues.jtl-software.de/issues/WAWI-10099

Zunächst einmal (bis zur Lösung des Problems) kann man auf das tatsächlich auslösende Ereignis horchen: Minusbuchung, Plusbuchung, Pickliste abgeschlossen, Auftrag vollständig ausgeliefert, etc.

Warum braucht eine solche "Kernfunktion" einer Warenwirtschafts-Software solange für die Umsetzung?

Warum, lässt sich ganz einfach beantworten. JTL ist mittlerweile eine der am meisten verwendete Software im Bereich E-Commerce in Deutschland überhaupt. Es dürfte also mehrere hundert dieser Anfragen, mit dem gleichen Schweregrad bei JTL geben. Dieser Bereich (Workflows) ist völlig kostenlos. Sprich: Diese Funktion bringt keinen Euro Umsatz für das Unternehmen. Also konzentriert man sich auf die Dinge überwiegend, welche die dahinter stehenden Familien auch satt macht. Das ist keine "Sei doch froh mit dem was du hast"-Apell, sondern ein: "Es ist nicht zu viel verlangt, für eine kostenlose Funktion, von denen jeden Monat haufenweise von JTL erzeugt werden, etwas mehr Wertschätzung zu äußern, als mit einem "Was braucht ihr denn so lange dafür" um die Ecke zu kommen.

 

[Verkäuferlein]

Warum, lässt sich ganz einfach beantworten. JTL ist mittlerweile eine der am meisten verwendete Software im Bereich E-Commerce in Deutschland überhaupt. Es dürfte also mehrere hundert dieser Anfragen, mit dem gleichen Schweregrad bei JTL geben. Dieser Bereich (Workflows) ist völlig kostenlos. Sprich: Diese Funktion bringt keinen Euro Umsatz für das Unternehmen. Also konzentriert man sich auf die Dinge überwiegend, welche die dahinter stehenden Familien auch satt macht. Das ist keine "Sei doch froh mit dem was du hast"-Apell, sondern ein: "Es ist nicht zu viel verlangt, für eine kostenlose Funktion, von denen jeden Monat haufenweise von JTL erzeugt werden, etwas mehr Wertschätzung zu äußern, als mit einem "Was braucht ihr denn so lange dafür" um die Ecke zu kommen.

Das wird jetzt etwas Offtopic, aber die Reaktion kann ich ehrlich gesagt nicht gelten lassen, das Kostenargument schonmal gar nicht. Wir zahlen jedes Jahr mehrere tausend Euro für das Gesamtpaket JTL mit steigender Tendenz. Wir reden hier über eine Warenwirtschafts-Software (die mittlerweile von JTL selbst als ERP-System bezeichnet wird), die nicht automatisch (im Workflow-System) auf die Veränderung des verfügbaren Bestandes reagieren kann. Das ist aber die Kernbeschreibung von Warenwirtschaft.

Da ist die Frage durchaus berechtigt, wenn grundsätzlich auf Workflows verwiesen wird, in diesen dann aber allerhand Variablen und Auslöseereignisse fehlen, warum solche Verbesserungsvorschläge dann nun schon bald 4 Jahre brauchen und immer noch nicht bekannt ist ob und wann und in welcher Version das eventuell mal umgesetzt wird (wenn man übrigens in den Thread für fehlende Auslöseereignisse schaut, ist davon auch fast gar nichts umgesetzt).

Wir reden hier nicht über die Ultra-Mega-Super-Duper-NicetoHave-Lösung, sondern ein (aus meiner Sicht) recht simples Feature was wirklich jeder Warenwirtschafts-Benutzer potenziell benötigt. Die eigentliche Frage muss doch sein, wieviele Nutzer benötigen das?, Wie wichtig ist die Funktion für die Kernfunktionalität eines Wawi-(ERP-)Systems? Und welchen Kosten-/Nutzenvorteil bringt das (wieviele Programmierstunden kostet das und wieviele Arbeitsstunden spart das bei den Nutzern, die für sinnvolle Vertriebstätigkeiten eingesetzt werden können)?

Im Übrigen ist es so, dass die Kunden von JTL mit jeder vernünftigen Funktion Umsatz machen und sich dies auch auf den Umsatz von JTL auswirkt. Mit den Workflows verdient JTL folglich indirekt Geld, weil die Kunden Anpassungen auf Ihre Prozesse selbst vornehmen können und JTL sich damit Programmieraufwand erspart und dennoch größere Kundengruppen erreichen kann.

Nach Deiner Aussage dürften alle Basis-Funktionen der Wawi nicht weiterentwickelt werden, dann würde aber auch keiner mehr die Zusatzfunktionen kaufen.

Wenn ich mich aber damit beschäftige, 23 Workflows anzulegen (sofern dies denn wirklich sauber funktioniert und auch noch ein Stück weit Übersichtlichkeit gegeben ist), die mit einem Auslöseereignis abzudecken wären, verdiene ich kein Geld, meine Familie muss verhungern (und ich auch) und ich kann dann weder weiterhin das an JTL bezahlen, was ich jetzt bezahle noch zusätzliche Funktionen bei JTL erwerben, wodurch dann die Familien der JTL-Mitarbeiter auch wieder verhungern.

Lange Rede kurzer Sinn, mir geht es nicht um JTL-Bashing sondern im Kern um die Frage, ob und wann mit dieser Funktion zu rechnen ist und wann überhaupt mit mehr Auslöseereignissen und Variablen im Workflow-System zu rechnen ist!?

 

[T4DT.GmbH]

...

Versteh mich bitte nicht falsch. Ich finde deinen Wunsch nach Umsetzung nicht illegitim (Ich habe für selbst für das Feature bereits gestimmt)!
Mir missfällt nur manches mal der etwas herrische Ton, der hier im Forum gerne herrscht. Dagegen habe ich eine inhaltliche Einordnung gestellt. Natürlich gibt es Dinge, die ich kritisiere und auch Dinge, auf die ich warte. Aktuell ist es halt nur einfach so, dass JTL, so wie du es seit Jahren kennst, technisch in der absoluten (C++)-Sackgasse steht. Daher müssen Stück für Stück alle Teile der WAWI neu geschrieben werden. Das nennt sich dann Artikel 2.0, Auftrag 2.0, und so weiter. Am Ende wird eine komplett neu geschriebene Wawi stehen, die vermutlich nicht mal besonders viel mehr Funktionen hat als heute. Sie stellt aber immerhin die Grundlage dafür auch in der Zukunft verwendet zu werden. Ich finde den Schritt insofern Features komplett hinten an zu stellen, völlig in Ordnung.

 

[DrGreen]

Tut sich hier noch was wegen einer API?
Shopware macht hier einen sehr guten Job