Neu JTL Rest API

[Rico Giesler]

Das Problem hierbei ist ja nicht, dass Fehler auftreten könnten, sondern dass der Support die Nadel im Heuhaufen suchen muss wenn der Kunde X verschiedene externe Systeme angebunden hat die in der DB irgendetwas ändern, was gar nicht so vorgesehen ist.
Grundsätzlich ist deine Idee ja sehr gut, wenn dabei in der DB nichts kaputt geht ist das auch alles kein Thema.

 

[mschop]

@Rico Giesler Ich gehe davon aus, dass früher oder später etwas kaputt gehen wird. Das Thema ist viel zu Komplex um Fehler zu 100% zu vermeiden. JTL schafft es ja schon selbst, inkonsistenzen in der DB hervorzurufen. Wie sollte ich diese also verhindern

Das ihr sowas nicht bei jedem Kunden leisten könnt, der ggf. auch keine kostenpflichtige Lizenz hat, ist verständlich. "Power-User", die sich auf ihr Tagesgeschäft konzentrieren müssen, zahlen aber auch gerne etwas für Support. Solchen Kunden sollte man eine Lösung bieten, auch wenn es für den Support unbequem ist.

 

[Thomas Lisson]

Hi mschop,

ich habe das Gefühl, dass du dir das Ganze zu einfach vorstellst.

Ich finde es etwas schade, dass eine Belastung eures Supportes ein solches Projekt im Keim erstickt.

Kannst du denn absehen, wie diese Belastung aussehen könnte? Ich nicht. Ich muss aber eine funktionierende Supportabteilung sicherstellen, damit der reibungslose Betrieb bei JTL und bei allen Kunden sichergestellt ist.

Aber wenn jemand entsprechend Geld bei euch lässt, sollte das doch eigentlich möglich gemacht werden. Ggf. auch über einen zusätzlichen Supportvertrag oder gegen entsprechende Vergütung.

Wir geben einem Entwickler einen Freifahrtsschein, etwas zu bauen, Kunden nutzen es und wenn etwas dabei schief geht, muss JTL die Kohlen aus dem Feuer holen und dem Kunden zusätzlich Geld aus der Tasche ziehen? Das klingt nicht nach Win/Win/Win. Du hast aber selbst natürlich die Möglichkeit einen Supportvertrag mit den Kunden abzuschliessen, die dein Tool nutzen. Dann hast du es selber in der Hand.

Aber die betroffenen Kunden dann einfach im Regen stehen zu lassen, finde ich nicht OK.

Ich auch nicht. In Härtefällen helfen wir auch, auch wenn es mit Kosten verbunden ist, sofern es selbstverschuldet oder über einen Drittanbieter ausgelöst wurde.
Um das zu vermeiden, sollten wir den Kunden vor einem evtl. aufziehenden Gewitter warnen. Das tun wir, indem wir dir keinen Freifahrtsschein geben.

Ich finde es etwas schade, dass eine Belastung eures Supportes ein solches Projekt im Keim erstickt.

Es wird entsprechende Lösungen direkt von JTL geben - die dann auch 100% supportet werden.

 

[mschop]

ich habe das Gefühl, dass du dir das Ganze zu einfach vorstellst.

Ich stelle mir vieles einfach vor, aber nicht Software-Entwicklung und Support.

Kannst du denn absehen, wie diese Belastung aussehen könnte? Ich nicht. Ich muss aber eine funktionierende Supportabteilung sicherstellen, damit der reibungslose Betrieb bei JTL und bei allen Kunden sichergestellt ist.

Das kann keiner absehen.

Wir geben einem Entwickler einen Freifahrtsschein, etwas zu bauen, Kunden nutzen es und wenn etwas dabei schief geht, muss JTL die Kohlen aus dem Feuer holen und dem Kunden zusätzlich Geld aus der Tasche ziehen? Das klingt nicht nach Win/Win/Win. Du hast aber selbst natürlich die Möglichkeit einen Supportvertrag mit den Kunden abzuschliessen, die dein Tool nutzen. Dann hast du es selber in der Hand.

Ich wollte keinen Freifahrtschein. Darum ja der Vorschlag mit dem kostenpflichtigen Support um euren Mehraufwand aufzufangen. Ich bin bei einem Händler in einer Festanstellung. Ich habe keine Möglichkeiten irgendwelche Supportverträge anzubieten. Das ganze war als Community-Projekt gedacht.

Ich auch nicht. In Härtefällen helfen wir auch, auch wenn es mit Kosten verbunden ist, sofern es selbstverschuldet oder über einen Drittanbieter ausgelöst wurde.
Um das zu vermeiden, sollten wir den Kunden vor einem evtl. aufziehenden Gewitter warnen. Das tun wir, indem wir dir keinen Freifahrtsschein geben.


Es wird entsprechende Lösungen direkt von JTL geben - die dann auch 100% supportet werden.

Eine API von euch wäre mir deutlich lieber. Habt ihr da schon konkrete Pläne?


Zusammenfassend

Ich verstehe euren Standpunkt, auch wenn ich andere Meinung bin. Ich glaube wir können das hier abkürzen und uns viel Zeit sparen. Solltet ihr euch entscheiden an eurer Strategie etwas zu ändern, überlege ich mir das mit dem Projekt nochmal. Für mich ist es erstmal gestorben, da ich das Risiko nicht eingehen möchte. Da verbringe ich die Zeit lieber mit Frau und Kind . Zumal ihr ja eh eine eigene Lösung ins Auge fasst. Dann wäre das ja eh hinfällig.

Es war auf jedenfall eine nette Fingerübung.

Gruß
mschop

 

[gerfriedd]

"räusper" Gedankengänge zu "externen Tool's"

--

1st,- 2nd & 3rd-Level Support = jeweiliger "Entwickler"

"Extern" somit = "Extern" ( und deren Verantwortlichkeit )

Anbindung "externes" für die JTL-Wawi

https://www.jtl-software.de/hilfecenter/entwickler-dokumentation

--

"Open Source Projekt" ( freie Lizenz ) = eigenes ( kalkulatorisches ) Risikomanagement

--

JTL selber ist sicherlich "offen" für Inspirationen / Wünsche von "externen Entwicklern", wenn dieses Begründet vorgetragen werden

--

Vorstellungen ist vielleicht das "externe Entwicklungen" Step-by-Step in die JTL-Wawi integriert werden "könnten" ( wenn dementsprechender Bedarf besteht ),
-> mit den Erfahrungen & Know-how der "externen" Entwickler,
-> sodass jeder Partei seine "Win/Win/Win" Situation hat & behält.

--

Eine "Rest-Api" für Funktionen / Module XY könnte interessant sein / werden..
.. aber für welche Funktion / Module
.. in welchem Step's genau

Erst aus X-Pilotkunde ergibt sich ein "Produkt" Kern & immer noch ( eventuellen ) individuellen Anpassungen ( für den JTL-Wawi Kunden )

--

Es ist zu beachten das "externes" / Schnittstellen auch jeweilig "individuelle" Anforderung haben

@mschop

siehe "Tradebyte" Schnittstelle ( als Beispiel nur )

1. TB.ONE Order Input XML ist je Kanal sogar "unterschiedlich"
2. + Kundenspezifische "Wünsche / Einstellungen"
3. + JTL-Wawi Version Anforderungen

wo willst Du hier genau die "Grenzen" ziehen ?

1. 2. oder 3.
a., b. oder c.

a.) Entwicklung, b.) Weiterentwicklung, c.) Pflege und damit auch d.) Support ist doch auch unterschiedlich zu betrachten

--

ergo: korrekt -> das ist "komplex" und nicht als "einfach" zu betrachten, da eben unterschiedliche Aus, und Eingangssituationen zu beachten sind.

ganz abgesehen von "Vertragsverhältnissen" und damit verbundener Verantwortlichkeit

--

Meinung basierend aus x - Schnittstellen Projekten ( EDIfact, XML, Marktplatz Anbindungen für die JTL-Wawi )

 

[nesh]

@mschop
Grundsätzlich finde ich deine Idee sehr spannend.
Das das JTL Team den Support verweigern würde wenn es durch ein externes Tool zu Inkonsistenzen kommt, kann ich absolut nachvollziehen! Da gibt es meiner Ansicht nach auch nichts zu diskutieren.
Kann ja nicht sein, das da "jemand" Danten in die DB schreibt und das Team von JTL das dann ausbaden muss / soll wenn dabei was schief gegangen ist.
Diene Enttäuschung kann ich daher nicht nachvollziehen.

Ich habe für den Internen Gebrauch auch einige JTL-Toolbox entwickelt die schon so einiges kann.
Jedoch schreibe ich mit diesem auch nicht direkt in die Datenbank. Für Schreibzugriffe ruft mein Tool die Ameise auf, nutzt die Extern.DLL oder führt StoredProcedures aus.

Als Entwicklungsplattform käme für mich ausschließlich .NET zum Einsatz. So wie ich das verstanden habe, soll das Tool ja für JTL Nutzer sein. Warum also auf Technologien wie PHP / Node.JS ausweichen. Das bekommt ja ein "Noramalsterblicher" gar nicht zum laufen.
Dann doch lieber eine "simple" .exe mit der jeder umgehen kann und dabei gleichzeitig die volle Power von .NET nutzen.

Ich bin gespannt wie es hier weiter geht. Wenn sich hier ein paar Kompetenzen Zusammengefunden haben, hätte ich auch sehr viel Lust hier mit zu machen.
Sicherlich kann ich einiges beisteuern.

 

[mschop]

@nesh Ich kann es auch nachvollziehen. Trotzdem greift das Argument IMHO nicht. Ich verlange ja gar nicht, dass der JTL-Support das kostenlos macht. Ich habe ja vorgeschlagen, ein kostenpflichtiges Angebot für solche Fälle anzubieten. Die Konkurrenz von JTL bietet das doch auch an. Auf der einen Seite hat man dort die kostenlose Variante. In dieser Variante ist nur grundlegender Support vom Software-Hersteller enthalten. Wenn man einen professionellen Support vom Software-Hersteller braucht, muss man entsprechend Geld da lassen. Nichts anderes würde ich mir für die JTL-Wawi wünschen.
Wenn die JTL-Wawi OpenSource wäre, würde ich mich ja im Zweifelsfall selbst mit dem Bug auseinander setzen. Aber die Möglichkeit habe ich ja nicht. Ich bin darauf angewiesen, dass mir der JTL-Support im Zweifelsfall hilft. Sollte einem Händler mit Drittsoftware der Support verweigert werden, könnte das im schlimmsten Fall den Bankrott bedeuten.

JTL kann hierbei doch sogar noch Geld verdienen. Von daher verstehe ich die Ablehnung seitens JTL nicht.

JTL hat doch auch die Support-Tarife (Basic, Plus, Premium). Mindestens ein Support-Tarif sollte es doch ermöglichen, dass der Support garantiert wird. Dieser Support sollte auch dann greifen, wenn bekannt fehlerhafte Drittsoftware im Einsatz ist.
Die Antwort von @Thomas Lisson hat ja nicht dahingehend differenziert. Das heißt für mich: Auch mit Premium-Support-Abbonement würde ich im Regen stehen gelassen werden, wenn Drittsoftware im Einsatz ist, welche ggf. Probleme macht. Ihr könnt auch gerne einen Ultimate-Tarif für 2000€ anbieten. Das wäre mir auch recht .

Bezüglich .NET: Ich lasse mir das nochmal durch den Kopf gehen. Die Argumente für .NET sind ja recht vielfältig. Wenn .NET: Würdest du auch mit F# klar kommen?

 

[SebiW]

Hallo @mschop ,
Du verlangst aber, dass JTL eine unbestimmte Anzahl an Supportern vorhält und bezahlt damit Dein Projekt unterstützt werden kann. Damit verlangst Du, dass JTL ein unternehmerisches Risiko eingeht um Dir die Umsetzung Deines Projektes zu ermöglichen.

Und was ist wenn durch das Projekt ein irreperabler Schaden entsteht, der auch durch den speziell dafür bezahlten Support bei JTL nicht repariert werden kann? Wer steht dann in Haftung? Soll JTL für Fehler in Deinem Bastelprojekt fiskalisch geradestehen? Und wenn das ganze nun 100e Installationen betrifft weil das Projekt beliebt ist (Sicherheit wird durch den bezahlten Support ja immerhin suggeriert). Das könnte im schlimmsten Fall den Bankrott von JTL bedeuten.

Kurz und gut: JTL kann ein paar Euro einstreichen indem sie eine Dienstleistung anbieten, bei der sie nicht sicher sein können ob sie sie im Extremfall überhaupt erbringen können und muss dafür im Zweifelsfall nur die eigene Existenz riskieren. Und Du fragst Dich wirklich warum JTL das nicht umsetzen möchte?

 

[mschop]

Hallo @SebiW ,

ernsthaft? Du argumentierst damit, dass JTL pleite gehen könnte, wenn die für ihre Software kostenpflichtigen Support anbieten?
Wer hat denn hier von Haftungsansprüchen gesprochen? Die OpenSource-Lizenz von JPI schließt etwaige Haftungsansprüche ja aus. Wenn ein Schaden durch JPI entsteht hat der Händler pech gehabt.

Das Leisten von Support hat nichts mit Haftungsansprüchen zu tun. Auch wird da nichts suggeriert.

Ganz ehrlich: Dann müsste Shopware ja schon längst pleite sein, wenn man deiner Logik folgen würde.

Gruß
mschop

 

[nesh]

@mschop
Lasse uns lieber auf das eigentliche Thema hier konzentrieren.
Mit F# grenzen wir meiner Ansicht nach wieder einige potenzielle Helfer aus. Ich bin schon seit über 15 Jahren SW Entwickler und kenne nicht einen, der sich schon ernsthaft mit F# auseinander gesetzt hat.
Da du dich ja schon mit PHP beschäftigst, und du vermutlich auch bei PHP Objektorientiert programmierst, wird Dir der Schritt zu C# nicht schwer fallen. Spätestens dann, wenn Du Code siehst von dem Du schon weißt was er tut, kommst Du da schnell rein.
Mal sehen wieviele JTLer es gibt die SW Entwickeln, etwas Zeit haben, und vor allem auch Lust haben hier etwas zu tun.

Hier mal ein Beispiel wie ich mein Projekt ungesetzt habe:

Meine Toolbox wird via Browser angular webApp bedient. Das gibt den Benutzer das Gefühl mit der JTL Software zu arbeiten da ich diese webApp im Dashboard einblende.

• Dort kann man den Realtime-Stock der Lieferanten zu einem Artikel sehen
• Sehen welche Kunden (eBay) mehrfach bestellt haben und eine neue Rechnung mit reduzierten Versandkosten erstellen.
• Sehen welche Bestellungen bei eBay / amazon noch nicht auf versendet gesetzt sind ob wohl sie bereits versendet wurden (kommt leider zu oft vor) und mit einem Klick den Datensatz an die Plattform senden.
• und noch einiges mehr....

Weiterhin scanne ich die Datenbank nach geöffneten Datensätzen. Sobald ein User einen Datensatz geöffnet hat (das wird ja in die DB geschrieben damit kein anderer parallel an dem Datensatz arbeiten kann)
zeige ich in einem Browser viele Details zu dem Artikel / Aufrag / Kunden an für welche man sich bei in der WaWi durch mehrere Bereiche klicken müsste.

Die Toolbox mach noch viel mehr, aber dass sollte hier mal ein Gedankenanstoß sein für weitere potentielle Entwickler.

 

[Rico Giesler]

@nesh ist es denn von dir/euch angedacht deine Toolbox auch anderen Usern zur Verfügung zu stellen? (ob kostenpflichtig oder nicht sei erst mal dahingestellt)
Wäre für einige User bestimmt ein tolles Werkzeug.

 

[nesh]

@Rico Giesler
Ich glaube, dass ist das angestrebte Ziel von @mschop

Find ich ne super Sache wenn hier ein paar Entwickler zusammen kommen....

 

[Rico Giesler]

Mir ging es um dein Tool.
Das von mschop ist ja noch nicht fertig/entwickelt.
Ihr scheint ja aber schon eine (wenn auch vielleicht andere) Lösung zu haben die diverse Funktionen/Infos mit sich bringt.

 

[nesh]

@Rico Giesler
Ich hab schon mal darüber nachgedacht. Das macht die Sache jedoch komplex. Es gibt z. B. im Moment keine Konfigurationsoberfläche. Netzwerkpfade, IP Adressen und Sonstiges; Das ist alles hart im Code drin.
Das alles in eine Config aus zu lagern ist zwar nicht das Problem, macht das ganze aber schon komplexer. Auch ist es genau so zugeschnitten wie wir das in unserem Workflow brauchen.
Das passt sicher nicht bei jedem, und genau das macht es dann richtig komplex wenn der Workflow konfigurierbar sein soll.

Ich hoffe immer noch auf ein paar Freiwillige mit denen man sich so eine Arbeiten teilen kann, vermute aber, da in diesem Thread nicht mehr passiert, das daraus nichts wird.
Es gibt hat viel zu wenig Entwickler auf diesem Planeten

 

[mschop]

@Rico Giesler
Ich hoffe immer noch auf ein paar Freiwillige mit denen man sich so eine Arbeiten teilen kann, vermute aber, da in diesem Thread nicht mehr passiert, das daraus nichts wird.
Es gibt hat viel zu wenig Entwickler auf diesem Planeten

Vorallem bei Proprietärer Software. Bei OpenSource-Software tummeln sich deutlich mehr Entwickler, die Freizeitprojekte bzw. generell Projekte für die Software abwickeln.
Ich würde das Thema aber noch nicht abschreiben. Ggf. ändert JTL ja doch noch die Strategie was den Support angeht.

 

[Walther]

@Thomas Lisson Ok. Schade. Die Aussage ist mir leider zu unkonkret. Ich werde nicht das Risiko eingehen und meine Lebenszeit für das Projekt opfern, wenn am Ende das Risiko besteht, dass es keiner nutzt aus Sorge, JTL könnte den Support verweigern.

Ich finde es etwas schade, dass eine Belastung eures Supportes ein solches Projekt im Keim erstickt. Ich verstehe zwar euren Standpunkt, sehe da aber andere Software-Anbieter deutlich weiter als euch. Bei kostenlosen JTL-Wawi-Installationen kann ich es ja noch verstehen. Aber wenn jemand entsprechend Geld bei euch lässt, sollte das doch eigentlich möglich gemacht werden. Ggf. auch über einen zusätzlichen Supportvertrag oder gegen entsprechende Vergütung. Aber die betroffenen Kunden dann einfach im Regen stehen zu lassen, finde ich nicht OK.

Von daher RIP JPI

Da kann ich mschop nur zustimmen.

 

[nesh]

Das gesamte JTL Team leistet einen super Job! Das Preis/Leistungsverhältnis ist UNSCHLAGBAR. Mit der Extern.dll den StroedProcedures sowie der Ameise ist schon so viel möglich.
Hier jetzt schon Dinge zu kritisieren, ohne das es ein konkretes Projekt gibt, finde ich total daneben.
Ich bin sehr sicher, wenn hier was Sinnvolles / Hilfreiches von Entwicklern auf die Beine gestellt wird, ist auch JTL Bereit an der einen oder anderen Stelle weitere EXTERN Funktionen bereit zu stellen und uns Entwickler zu Supporten.
Da sich hier bis her noch keine Entwickler gemeldet haben, hat sich das Thema wohl schon von selbst erledigt

 

[mschop]

@nesh Wieso sollte es total daneben sein, wenn man Kritik äußert? Eine Software bzw. Ökosystem lebt von Kritik. Sollte JTL seine Strategie ändern, bin ich gerne bereit, meine private Zeit zu opfern, um ein ordentliches Projekt auf die Beine zu stellen. Aber so investiere ich meine Zeit lieber in OpenSource Software.

 

[T4DT.GmbH]

Hi mshop,
leider kann ich deine Haltung nicht so 100%ig verstehen. Datenbank-Inkonsistenzen zu vermeiden muss das absolut oberste Ziel einer "stabilen" Version sein. Und alle anderen Bastler da draußen (wie mich), brauchen schlicht keinen JTL-Support!
Da auf absehbare Zeit das "Produkt" ein Bastel-Ding sein wird, sehe ich hier keine Interessenskonflikte.
Stellt sich dann eine solide Basis heraus, wird es auch keine Probleme mit dem JTL Support geben, wie dir Thomas Lisson ja bereits versichert hat. Insofern: Ich bin dabei, wenn du auch dabei bist.
Meine Empfehlung für den Technologie-Stack: Unbedingt C#/.NET.
Ich fänds ja auch ziemlich geil, wenn man eine Community-Toolbox zusammen stellen könnte. Aber nur so als Gedanke

 

[Alcube GmbH]

Hallo,

gibt es von JTL inzwischen konkrete Umsetzungsmaßnahmen oder mindestens Unterstützungszusagen zum Thema Rest-API?
Da ich keine meinen Ansprüchen genügende FiBu Lösung gefunden habe, habe ich ein ERP implementiert und möchte nun JTL über API anschliessen.
Da die Aufträge über Rest-API von den Plattformen abgeholt werden und das Kassensystem eine Rest-API hat, kann ich mir nicht vorstellen, dass für die Wawi das Theme nicht bereits in Umsetzung ist.

Beste Grüße
Marco