Neu REST-API nur noch für Premium Kunden - oder wie verhindere ich Nutzung moderner Schnittstellen...

[John]

Moin,

nachdem ich etliche Kundenprojekte mit mühsamem, direkten Zugriff auf die Wawi Datenbank realisiert habe, wollte ich ich das nächste Projekt eigentlich auf die modernere REST API setzen.

Das ist nun aus Entwicklersicht komplett unattraktiv geworden, weil ich meine Entwicklung abseits von Premiumkunden, die gewillt oder gezwungen sind, teure Pakete zu buchen nicht wiederverwenden und für die restlichen Kunden nutzen kann.
JTL verhindert mit den teuren Tarifen damit aktiv die Nutzung und Verbreitung von Zusatztools auf moderner Schnittstelle und zwingt weiterhin zum direkten Arbeiten auf der Datenbank.

Entwickler, die bereits REST API für angedachte Tools für alle Wawi Nutzer programmiert haben, dürften das ähnlich sehen. Ihr Kundenkreis ist gerade massiv geschrumpft. Es gibt ja z.B. ein Übersetzertool auf REST.

JTL, wieso?

John

 

[elevennerds.de]

Eine durch Externe entwickelte REST-Api könnte hier eine Lösung sein. Damit hätte man dann auch schon einen Unterbau für ein alternatives GUI (bspw. ein besserer Packtisch), bzw. Zusatzfunktionen wie "manuelle Workflows"?

 

[SebiW]

Ja, die Rest API hinter ner Bezahlschranke zu verstecken ist so ziemlich die bescheuertste Entscheidung des neuen Preismodells. JTL schneidet sich damit aktiv selbst ins Fleisch indem es die Weiterentwicklung des eigenen Ökosystems massiv behindert. Schlicht und ergreifend wirtschaftlich bescheuert. Die minimalen fiskalischen Steigerungen stehen in keinem Verhältnis zu dem Verlust an Attraktivität des Ökosystems, die JTL sich damit erkauft.

 

[John]

@elevennerds.de Robert Wall von @T4DT.GmbH hat wohl in den leztzten Tagen einen Teil seiner Entwicklung zur Lizensierung freigegeben.
Zumidest gab es ein Posting auf Facebook in die Richtung...

 

[sjk]

In den FAQs glaube ich gelesen zu haben, dass von SPs entwickelte bzw. über den Extension Store verkaufte Tools kostenlos (für die Endnutzer) an die API andocken dürfen. Keine Ahnung, welche Kosten da auf Entwicklerseite für anfallen.

Aus meiner Sicht ist das Ganze auch totaler Quatsch. Eine Wawi bzw. ein "ERP" ist seit vorvorgestern keine Insellösung mehr. @Powalowski hat das letztens treffend beschrieben

API, Workflows, vielleicht eine Skriptsprache? Ganze Ansichten und Cockpits zu bauen, das wäre in der heutigen Softwarewelt angemessener Standard. Anschluss an alle denkbaren externen Systene, sodass man sich Ansichten und Funktionen für seinen Usecase zusammenklicken kann. Ein ERP sollte aus meiner Sicht wie ein Alleskleber für Geschäftsprozesse funktionieren und nicht alle Funktionen beinhalten/vorgeben.

Naja, immerhin scheint es möglich zu sein Tools zu entwickeln, die dann auch von allen Wawi-Nutzern verwendet werden können. Besser als nichts. Trotzdem wird das nur kommerzielle Lösungen hervorbringen, bei denen die Entwickler einen entsprechender ROI erwarten. Communitylösungen wird man an einer Hand abzählen können. Z. B. hatte @kelvin. hier im Forum schon darüber gesprochen, dass er ein Python package für die Wawi API fast fertig hat. Wie cool wäre das bitte gewesen?

edit:
Habe es im FAQ gefunden

Was kostet die neue Rest-API?
Die neue Rest-API kann in allen JTL-Editionen außer JTL Start genutzt werden. In JTL Enterprise ist die Rest API bereits inkludiert, in JTL Advanced kann diese für 199 € und in JTL Pro für 99 € hinzugebucht werden. Erweiterungen aus dem JTL Extension Store, die die Rest API nutzen, können in allen Editionen genutzt werden.

 

[JTL_fwenzl]

Relaxed doch mal... für Endkunden die selbst die für die REST-API entwickeln wollen ist diese kostenpflichtig...

 

[SebiW]

Relaxed doch mal... für Endkunden die selbst die für die REST-API entwickeln wollen ist diese kostenpflichtig...

Jo - also bspw für uns. Und im Endeffekt für jeden der sich eine Sonderlösung stricken will. Aus diesen Sonderlösungen widerum gehen viele der Tools, die das JTL Ökosystem attraktiv machen, dann später hervor.
Macht schlicht und ergreifend 0 Sinn. Ihr beschränkt damit die API auf eingetragene Servicepartner und dreht jede kreative Lösung aus dem weiteren Umfeld ab.

 

[John]

Erweiterungen aus dem JTL Extension Store, die die Rest API nutzen, können in allen Editionen genutzt werden.

Ja, genutzt werden. Da steht aber nichts von ohne API Nutzungskosten.
Da muß man ja leider bei dem Marketingsprech genau hinschauen.

 

[JTL_fwenzl]

Geht mal davon aus, das auch nicht alles in Stein gemeißelt ist, dafür ist die Softwarewelt zu dynamisch.
JTL ist gerade in einem Transformationsprozess.

 

[SebiW]

Und auf diesen Transformationsprozess versuchen wir einzuwirken indem wir Euch Fehlentwicklungen aufzeigen.
Die Bezahlschranke der Rest API ist eine solche Fehlentwicklung, die Euch langfristig sogar mehr schadet als uns.
Bitte, gern geschehen, ich würde dann ein Jahr Enterprise also Finderlohn nehmen

Schnittstellen müssen technisch und fiskalisch stabil und planbar sein. Wir geben keinen Cent für die Entwcklung von etwas aus, bei dem wir nicht zumindest grob abschätzen können, was es morgen kosten wird. Kosten/Nutzenrechnung eben.

 

[John]

Geht mal davon aus, das auch nicht alles in Stein gemeißelt ist, dafür ist die Softwarewelt zu dynamisch.
JTL ist gerade in einem Transformationsprozess.

Aber JTL weiß doch sehr genau, wie die Wawi von seiten der Userschaft genutzt wird und hat bewußt darauf die neuen Editionen geschnürt, oder ist die [dbo].[ifGetInformations] etwa nicht ausgewertet worden?
Insb. die Bereiche, in denen zunächst schwer nachvollziehbar eingeschränkt wird ( Ameise, Workflows, Eigene Übersichten), werden über diese sp detailliert abgefragt.

 

[Powalowski]

Moin,

nachdem ich etliche Kundenprojekte mit mühsamem, direkten Zugriff auf die Wawi Datenbank realisiert habe, wollte ich ich das nächste Projekt eigentlich auf die modernere REST API setzen.

Ich denke wir können die Cloud abwarten: 200€ pro Benutzer, pro Monat. Dann wäre auch endlich Ruhe mit Kreativität, Tweaks aus dem Forum oder Datenbankzugriff. Sensible Daten? Bitte nur noch durch's Internet schicken. Datenhaltung? Nur noch bei Azure. Lokale Zusatzprogramme im Firmennetz? Gerne, wenn man das API Modul bucht. Ihr wollt kreativ sein? Baut doch euer eigenes ERP.

Ich kann nicht genug betonen, dass ich einen Gang in Richtung OSS mit berechtigten Cloud-Diensten ( eazyauction, T&T, Shopify, Bank, Mollie, Paypal etc.) und optionaler Wawi-Cloud für den besten Weg halte. Wenn JTL diesen Weg nicht geht, dann sicher bald ein anderer Anbieter.

JTL unterschätz seine Stärken: JTL wäre prädestiniert für so ein Konzept, da sie im Gegenteil zur verkorksten Cloud-only Starbucks-Äntreprenär Welt (Alles automatisch mit AWS, Function as a Service, pay-per-request, Snowflake, wir brauchen Konfigurations-Berater bla bla) ein Jahrzehnt Erfahrung mit echten rohen On-Prem Kunden und millionenfacher Datenbank Migration haben. Das können die anderen Anbieter in ihrem komischen Microservice-Scrum-Keine-Ahnung-wie-Computer-funktionieren Kosmos nicht mal.

Ein bisschen ungeachtet der Öffentlichkeit, kann man am Randthema Plan&Produce möglicherweise in etwa erahnen, wo die Cloud-Reise hingehen könnte:

 

[JTL_fwenzl]

Das ist genau das Problem, ihr denke wisst ja alles und macht daraus gleich einen weiter Vorwurf an uns.

Ja, es gibt die Proc und nein, die ist noch nicht im großem Umfang aktiv. Und ja, wir hoffen damit irgendwann mal verlässliche (anonyme) statistische Daten zu bekommen.

Ich sag daher nochmal, das ist ein Prozess und wir sind ganz am Anfang.

 

[JTL_fwenzl]

@Powalowski Hat keiner gesagt das alles in die Cloud der Plan von JTL ist... und selbst, wenn er das heute wäre... wie gesagt, die Softwarewelt ist schnelllebig.

 

[Powalowski]

Das ist genau das Problem, ihr denke wisst ja alles und macht daraus gleich einen weiter Vorwurf an uns.

Ja, es gibt die Proc und nein, die ist noch nicht im großem Umfang aktiv. Und ja, wir hoffen damit irgendwann mal verlässliche (anonyme) statistische Daten zu bekommen.

Ich sag daher nochmal, das ist ein Prozess und wir sind ganz am Anfang.

Danke für die Antwort. Ich kann verstehen, dass die aktuellen Beiträge vorwurfsvoll wirken.

Ich denke in erster Linie sind viele User verunsichert über die Zukunft (der unangekündigte Preisschlag war mehr als ein deutliches Signal) und die technisch versierten User haben zusätzlich Sorgen eingekesselt zu werden in eine Abofalle, für die sie sich oder ihre Kunden nicht mehr guten Gewissens entscheiden können.

Wir reden darüber, dass es ein Traum wäre, wenn JTL mit Leistung und Qualität seine Stärken ausbauen könnte. Wie der Titel sagt (REST-API nur noch für Premium Kunden) und @SebiW auch schreibt. Die Einschränkung der wenigen "offenen" Möglichkeiten hinter Megapreisen war ein Schock (der nicht gerade in eine offene Zukunft zeigt). Was ist das für eine Zukunft, in der API und Workflows nur für finanzstärkere Kunden bereitstehen? Als wir kleine Fürze waren, waren genau die integrierten Funktionen ohne Aufpreis -zentraler Entscheidungsfaktor- für JTL.

Eine gewisse Cloudentwicklung wäre ebenso durchaus besorgniserregend (ich sage nicht, sie wird zwangsläufig so ablaufen), dazu habe ich bereits ausführliche Beiträge geschrieben und es würde mich freuen, wenn man das in Betracht zieht.

Ich komme von dem Standpunkt, dass JTL für uns -immer eine Konstante- dargestellt hat und ich mich freuen würde damit weiterhin auf den besten und -richtigen- Anbieter zu setzen. Ich teile meine Abwägungen und Ideen genau von dieser leistungsorientierten Position. Nicht alle User haben 15 Jahre Erfahrung mit intensiver Automatisierung, unterschiedlichsten Softwareprojekten in extrem unterschiedlichen Szenarios mit unterschidlichen Teams.

 

[Powalowski]

@Powalowski Hat keiner gesagt das alles in die Cloud der Plan von JTL ist... und selbst, wenn er das heute wäre... wie gesagt, die Softwarewelt ist schnelllebig.

Dann macht doch gerne Statement hierzu und zeigt den Kunden eure Ideen. Eine Entwicklung in Richtung OSS würde das Ganze sicherlich transparenter machen und Zweifel gar nicht erst schüren 👍🏻

 

[JTL_fwenzl]

Ja, mit der Kommunikation des Ganzen sind wir auch nicht glücklich. Vor allem das nicht klar wird wo die Reise hin gehen soll.
Ich hoffe das wird mit der Zeit noch nachgereicht.

Wir sind auf dem Weg uns zu professionalisieren, in jeder Hinsicht. JTL ist kein kleines Startup mehr.

Die Beteiligung an der Entwicklung müsste meiner Meinung nach über die Pilotprogramme laufen und nicht hier in der Öffentlichkeit.

 

[chefsalat]

Eine API kostenpflichtig zu machen halte ICH persönlich für falsch und unattraktiv, da man damit

a) Entwickler vergrämt, die mein Ökosystem aufwerten
b) Kunden abschreckt anstatt fester zu binden.

Ich kann es schon nachvollziehen, wenn man selbst kostenpflichtige Services anbietet....Da geht dann die Angst um. daß jemand mit API dann als 3rd Person diesen Dienst GÜNSTIGER oder besser anbieten kann und damit den eigenen Umsatz schmälert (z.B. Track & Trace, da binde ich z.B. 17track.net an für schmalen Taler, gestaffelt nach Anzahl der Sendungen pro Monat....mit allen Carriern, nicht nur denen die TT unterstützt). Aber mancher Kunde nimmt den Dienst trotzdem bei JTL, weil viele Köche und Brei und Supportpingpong, wenns nicht klappt.....

Aber dann den Weg zu gehen, API erst ab einer gewissen Kostenebene überhaupt bereitszustellen UND dann auch sau teuer zu machen ist stramm. Besser wäre es, API einfach als Extension bringen, und zwar günstig, z.B. 29 EUR + x EUR je y-Hundert oder Tausend Aufrufe. Denn je nachdem, was ich mit der API mache habe ich viele oder wenige Aufrufe, und da kann man dann die Preise Staffeln. Ein hoher Preis ist eine hohe Einstiegshürde. Und bei State-of-the-Art Techniken die Einstiegshürden zu errichten ist irgendwo falsch. Außerdem finde ich aktuell (!!) eh unverschämt, eine gefühlt nicht mal halbfertige API zu bepreisen. Elementare Funktionen wie Rechnungsstellung & Zahlungen fehlen noch komplett, wenn ich mich nicht verguckt habe. Erst wenn ich per API quasi die Wawi wie mit Maus und Keyboard steuern kann dürfte es überhaupt in Erwägung gezogen werden, sie zu bepreisen.

Wenn ich z.B Apache Kafka as a service irgendwo buche bezahle ich idR eine GG + Staffelpreis für Messages. Viele = teurer, wenige: Nur Grundgebühr. Und für Heavyuser "kontaktiere unseren Vertrieb". Aber damit bringe ich die Leute dazu, Kafka zu probieren, zu nutzen und dafür Tools und Extensions zu bauen. Und damit bindet man die Nutzer auch.

 

[SebiW]

Ja, mit der Kommunikation des Ganzen sind wir auch nicht glücklich. Vor allem das nicht klar wird wo die Reise hin gehen soll.
Ich hoffe das wird mit der Zeit noch nachgereicht.

Wir sind auf dem Weg uns zu professionalisieren, in jeder Hinsicht. JTL ist kein kleines Startup mehr.

Wir sind auch kein kleines Startup mehr. Ihr habt uns und viele andere Kunden in unserer Größenordnung aber behandelt als wären wir welche.

Insbesondere die völlig unangekündigte Hauruckumstellung des neuen Lizenzsystems ist das exakte Gegenteil von Professionalisierung.

Professionalität beinhaltet auch die Primärtugend Zuverlässigkeit. Hier habt Ihr ganz schön danebengelangt.

 

[JTL_fwenzl]

Ja... nicht gut gelaufen, ist aber nichts auf das ich großartig Einfluss habe.
Und ich bin ziemlich sicher, das die Botschaft bei den Verantwortlichen angekommen ist.