Neu JTL Rest API

[mschop]

Hallo Zusammen,

ich überlege, eine REST API für die JTL-Wawi zu programmieren. Aktuell nutzt mein Unternehmen eine Eigenentwicklung um Prozesse in der Wawi zu automatisieren. Mein Idee ist es, das ganze aufzubereiten und daraus ein OpenSource Projekt (GPL) zu machen um hier in der Entwicklung schneller voran zu kommen und ein breiteres Spektrum an Funktionalitäten abzudecken. Ich würde gerne wissen:

• Habt ihr Interesse an einer solchen Lösung?
• Wofür würdet ihr diese einsetzen?
• Wer ist Entwickler und würde sich an der Entwicklung beteiligen?
• Welchen Technologie-Stack würdet ihr bevorzugen?
• Sollte ich das Projekt starten: Wie soll es genannt werden. Aktuell schwebt mir JAPI vor . Aber ich bin für Vorschläge offen.

Aktuelle Überlegungen zum Technologiestack:
Die aktuelle Lösung ist in PHP (Slim Framework) programmiert. Das funktioniert soweit ganz gut, allerdings ist es auch keine eierlegende Vollmilchsau. Z.B. könnte man diese Lösung bei den meisten Hosting-Anbietern nicht einsetzen, da dort die Installation des MSSQL-Treibers nicht möglich ist. Zudem würde ich wenn von Slim Framework auf Symfony wechseln.
Von daher bin ich offen zu den eingesetzten Technologien. .NET, NodeJS, PHP, ...: Was würde aus eurer Sicht am meisten Sinn machen? Von denjenigen, die gerne die Entwicklung Unterstützen möchten: Welche Sprachen beherrscht ihr?

Features:

• Multiuser (Authentifizierung & Authorisierung)
• Administrationsbackend (um z.B. auth zu konfigurieren)
• Bereitstellen sämtlicher Entitäten der Wawi über eine REST-API (soweit technisch machbar)

Danke im Voraus für Feedback

Gruß
mschop

 

[Rico Giesler]

In dem Zusammenhang könnte folgende Seite für dich interessant sein: https://wawi-db.jtl-software.de/

 

[ag-websolutions.de]

Als Umgebung würde ich ausschließlich das einsetzen/verwenden, was die WaWi schoon von Hause aus benötigt ... sprich .net

 

[mschop]

@Rico Giesler Danke.
@ag-websolutions.de Warum? . Fast jede gängige Programmiersprache kann doch mit einer MSSQL interagieren oder nicht?

 

[ag-websolutions.de]

kann doch mit einer MSSQL interagieren oder nicht?

Prinzipiell schon, aber das "warum" führst du doch schon selber aus.
Je nach Entwicklungsumgebung sind spezielle Treiber, spezielle DLLs or what ever erforderlich, die eben auf dem Rechner nicht zur Verfügung stehen bzw. zur Verfügung gestellt werden können.

Setzt du zu spezielle Systemumgebungen voraus, schränkst du natürlich den Nutzerkreis erheblich ein.

 

[mschop]

@ag-websolutions.de Das hängt sehr von der Programmiersprache ab. Unter NodeJS z.B. gibt es auch einen in NodeJS geschriebenen Treiber, der keine Systemabhängigkeiten voraus setzt. Oder Go-Lang -> Da wird der Treiber mit in die ausführbare Datei kompiliert. Also Möglichkeiten gibt es da schon, das unabhängig von der Umgebung einfach zum laufen zu bekommen. PHP war jetzt ein Fall, wo man erst einen Treiber installieren muss. Da das Setup eines Webservers allerdings eh ein wenig Grundwissen voraus setzt, würde 'JAPI' eh einen ITler vorraussetzen, der die Umgebung einrichtet. Es ist nicht so gedacht, dass das jeder Wawi-Nutzer installieren sollte, sondern eher für jene, die einen solchen Application-Server zu bedienen wissen.

 

[Eiko]

Ich würde mir sowas sicherlich gern anschauen.

Rechnung schreiben im Außendienst wäre so ein Fall, wo eine einfach zu handhabende Schnittstelle sicherlich hilfreich ist. Wir nutzen die Wawi zum größten Teil klassisch als Warenwirtschaft für unser B2C- und B2B-Geschäft. Aktuell noch ohne Shop und Onlineanbindung. Ich habe schon öfter mit dem Gedanken gespielt, dem Ganzen eine Schnittstelle zu verpassen. Für unseren Außendienst habe ich einen Webserver per VPN angebunden, wo diverse Sachen abrufbar sind, welche Daten vom internen Datenbankserver beziehen. Und da liegt es nahe, eine Anbindung an die Wawi aufzusatteln. Zeit und Muße fehlten allerdings bisher...

 

[mschop]

Hallo Zusammen,

hier ein kleines Update.

Aktuell tendiere ich dazu, PHP als Unterbau zu nehmen. Hierfür gibt es verschiedene Gründe:

• Ich kenne PHP/Symfony/Doctrine am besten. Daher werde ich hier schneller Ergebnisse erzielen als in anderen Sprachen. Die Nachteile im Deployment werde ich mit Docker oder Vagrant ausgleichen.
• NodeJS fliegt aus der Kandidaten-Liste raus. Es gibt dort keinen gescheiten (gut dokumentierten) Query-Builder oder ORM für MSSQL. (Wenn ihr einen kennt, immer her mit den Links)
• C# / .NET -> Wäre eine Möglichkeit. Allerdings habe ich mich immer über NuGet bzw. im Allgemeinen die Paketverwaltung aufgeregt, wenn ich mit C# gearbetet haben. Außerdem waren meine Erfahrungen beim Deployment in der Vergangenheit eher "durchwachsen". Visual Studio ist mir zu teuer und Visual Studio Code ist mir noch nicht weit genug entwickelt. Aber im Endeffekt ist es eher Punkt 1
• GoLang -> Da konnte ich auch kein passendes ORM oder QueryBuilder finden.

Bezüglich des Namens: Es wird ggf. auf den Namen "JPI" hinaus laufen.

@Eiko Könntest du bei der Entwicklung unterstützen? Gerne auch für Testing oder Dokumentation etc..

@Rico Giesler Welche Voraussetzung müssen erfüllt sein, damit der Einsatz von JPI keine Einfluss darauf hat, ob JTL noch Support leistet? Ich erinnere mich daran, dass bei https://github.com/GuybrushX/JtlDbWrapper extra darauf hingewiesen wird, dass in einem solchen Falle kein Support geleistet wird.


Bis dahin...

Gruß
mschop

 

[Eiko]

Im Rahmen meiner Möglichkeiten sicherlich gerne. PHP-Kenntnisse sind bei mir nur grundlegend vorhanden, eher .NET, da aber auch nur (fortgeschritten) VB, daher dann eher Hilfe beim Testen/Dokumentation.

 

[luffi]

Ich werfe hier nochmal .NET in den Ring. Ich habe mit .NET Core und dessen WebAPI features gute Erfahrungen gemacht. Das EF Core nimmt Form an, und ist mittlerweile brauchbar und auch einigermaßen Performant.
Als Vorteil des .NET frameworks ist, dass du eben auf JTL Hausmittel zurückgreifen kannst, falls nötig. Die freigegebene JtlWawiExtern.dll kann plötzlich von Nöten sein - und dann ist es ärgerlich, wenn du nicht weiter kommst weil du auf PHP und Symfony gesetzt hast.

Ich warne davor, voreilige Schlüsse zu ziehen, nur weil die NuGet Paketverwaltung und die IDE dir mal nicht gefallen haben...
Du kannst die Visual Studio Community Edition für das Projekt nutzen, da das ganze Projekt ja Open Sourced werden soll. Somit wirst du dann, falls du es in Firmenregie entwickelst, auch licence compliant.
Zum hosten der WebAPI kannst du auch Docker oder eine IIS Instanz nutzen.

Egal für welche Basis du dich entscheidest, bin ich bereit mir deinen Code anzuschauen und ein zu Testen - falls mir die Zeit dies zulässt.

 

[mschop]

Ich werfe hier nochmal .NET in den Ring. Ich habe mit .NET Core und dessen WebAPI features gute Erfahrungen gemacht. Das EF Core nimmt Form an, und ist mittlerweile brauchbar und auch einigermaßen Performant.
Als Vorteil des .NET frameworks ist, dass du eben auf JTL Hausmittel zurückgreifen kannst, falls nötig. Die freigegebene JtlWawiExtern.dll kann plötzlich von Nöten sein - und dann ist es ärgerlich, wenn du nicht weiter kommst weil du auf PHP und Symfony gesetzt hast.

Ich warne davor, voreilige Schlüsse zu ziehen, nur weil die NuGet Paketverwaltung und die IDE dir mal nicht gefallen haben...
Du kannst die Visual Studio Community Edition für das Projekt nutzen, da das ganze Projekt ja Open Sourced werden soll. Somit wirst du dann, falls du es in Firmenregie entwickelst, auch licence compliant.
Zum hosten der WebAPI kannst du auch Docker oder eine IIS Instanz nutzen.

Egal für welche Basis du dich entscheidest, bin ich bereit mir deinen Code anzuschauen und ein zu Testen - falls mir die Zeit dies zulässt.

Danke für das Feedback. Ich werde mir das nochmal detaillierter anschauen. Folgende Frage hätte ich allerdings noch: Wofür brauche ich die JtlWawiExtern.dll? Soweit ich weiß, kann man darüber z.B. den Druck von Dokumenten anstoßen. Gibt es abgesehen davon noch Dinge, die man über die DLL machen, die ich sonst nicht über die DB direkt machen kann? Den Druck von Dokumenten habe ich z.B. über zeitversetzte Workflows, die vom Worker ausgeführt werden, gelöst. So habe ich es umgangen, mit der JtlWawiExtern.dll interagieren zu müssen. Ich stelle mir das auch gerade für eine REST-Web-Api als Performancekiller vor, wenn ich die Dokumente direkt aus dem Webprozess heraus erstellen lasse. Das müsste dann eigentlich über einen Scheduler oder halt den Worker zeitversetzt passieren.

 

[luffi]

Du kannst über die JtlWawiExtern.dll mit der Wawi kontrolliert interagieren. Aufträge erstellen, Gutschriften erstellen, Versanddaten importieren, Workflows ausführen - das kannst du alles auch direkt über die Datenbank machen, jedoch hast du durch die DLL ein von JTL definiertes Interface. Das bedeutet, dass die DLL bzw. die dort damit definierten Methoden automatisch dafür sorgen sollten, die notwendigen Schritte einzuleiten um die Integrität der Daten zu bewahren. Das wird JTL sicherlich auch besser gefallen, als direkt in der DB herumzuspielen.
Es ist an sich "sauberer", da du durch den von JTL vordefinierten Weg gehst. Ein wenig wie die Ameise, nur besser.
.Net Core hat asynchrone Calls - die, so denke ich, genau für den Fall brauchbar sind.

 

[mschop]

@luffi

http://php.net/manual/de/class.dotnet.php



Ich wusste selbst nicht, dass das geht. Das heißt nicht, dass ich das ein gutes Setup finde .

 

[Rico Giesler]

Hier findest du noch ein paar interessante Infos: http://developer.jtl-software.de/ (bitte mit dem EDGE öffnen)

 

[mschop]

Hier der Link zum Repository: https://github.com/mschop/JPI

Feedback ist natürlich auch schon in einer so frühen Projektphase immer erwünscht. Allerdings ist das natürlich noch weit von nutzbar entfernt .

 

[mschop]

@ JTL : Wäre schön, wenn ihr eine verbindliche Aussage zu dem Thema machen könntet. Wie würdet ihr Supportfälle handhaben? Nehmen wir an jemand setzt JPI ein. Würdet ihr dann im Supportfalle die Arbeit einstellen, wenn ihr seht, dass dort JPI eingesetzt wird?

 

[Thomas Lisson]

Hi,

wir können dir hier keine verbindliche Aussage geben. Wenn wir merken, dass es Kunden gibt mit inskonsistenten DBs, die JPI eingesetzt haben, dann werden wir keinen Support bieten. Wenn sich das aber problemlos gestaltet, dann kann es sein, das wir darüber hinwegsehen.

 

[mschop]

@Thomas Lisson Ich überlege JPI erweiterbar zu bauen. Soll heißen, manche Probleme können zum Beispiel durch Anpassungen von einzelnen Händlern kommen und müssen nicht ein grundsätzliches Problem von JPI sein.

Ab welcher Anzahl von Inkonsistenzen würdet ihr den Support einstellen. JTL schafft es ja schon selbst mit der Wawi, inkonsistenzen in der Datenbank hervor zu rufen. Wie sollte ich es daher jemals sicherstellen, dass nicht irgendwann mal eine Inkonsistenz auftritt? Wenn ihr bei dem ersten Problem direkt den Support einstellt, brauche ich das Projekt nicht weiter zu verfolgen und spare mir viel Zeit .

 

[Thomas Lisson]

Hi mschop,

ich kann dir hier keine pauschale Antwort geben. Wenn es unseren Support belastet, dann können wir es nicht supporten. Ob es 5 oder 50 Fälle sein müssen, kann ich nicht sagen. Es hängt vom Aufwand ab, der uns dadurch entsteht.

 

[mschop]

@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