Hallo, leider hab ich keinen Themenkreis gefunden wo das hier hineinpassen könnte. Während der Arbeit mit der aktuellen REST API sind mir hin und wieder Ungereimtheiten oder besser gesagt Lücken aufgefallen die ich hier mal ansprechen wollte. Vielleicht ist diese dem einen oder anderen schon mal untergekommen und hat das Problem irgendwie anders lösen können. Mal vorweg die Randbedingungen die meinerseits gelten: - Kenne noch nicht alle Untiefen der API, gebe mir aber Mühe diese schnellstmöglich bändigen zu können - Änderungen am Shop selbst vornehmen damit es läuft: geht nicht - Änderungen am Shop durchführen müssen damit es läuft: geht auch nicht - worüber müssen die "Löcher" gestopft werden: Workarounds ausschließlich mittels der "REST"-API, maximal durch "Skripte" die genau einen Zweck erfüllen: Ein Workaround für genau eine Lücke in der API. Warum keine Änderungen am Shop durchführen? Warum ausschließlich über die "REST"-API? Der eine oder andere kennt die Warenwirtschaft Faktura-XP, diese hat eine Verbindung zum Gambio bis Dato immer mittels ODBC-Direktverbindung hergestellt. Dies schränkt die Nutzung mit jedem Hoster ein und kann zu Verbindungsabbrüchen führen. Vorteil dieser Methodik war bis zu guterletzt die Tatsache das die Tabellenstruktur eines xt:C, os:C, HHG:multistore in den Grundfunktionen identisch ist / war. Wie Gambio so durchfährt unsere Warenwirtschaft auch eine Art "Evolution". Ich arbeite bereits seit mehreren Jahren an einem Shop-Framework für Faktura-XP auf Basis von .NET welches die Nachteile der Access-Lösung ausmerzen soll: - Multi-Threading, API-fähig, erweiterbar, schnellere Update-Zyklen, mehr Komfort, mehr Features, Automatisierungen, einfache Anbindung (Domäne, Username, Passwort, fertig) - Last but not least das wichtigste: keine Veränderungen am Shop durchführen müssen! Nun arbeiten wir an einer Schnittstelle speziell für Gambio GX3 (ohne Kompatibilität zu anderen Shopsystemen), möchten aber hierfür die Vorteile der REST-API nutzen die Gambio uns bietet (hier nochmal ein Großes Lob an Wilken Haase und Marco Bruchmann für die geopferte Zeit bei der Einarbeitungsphase) stoßen aber an Kanten die das Nutzungserlebnis einschränkt. Ich möchte hier an der in Version 3.0.0.0 angebundenen REST-API die gefundenen Punkte nicht direkt festmachen aber damit beginnen. Ich weiß man könnt sagen "nimm 3.1.x.x da geht es". Die Frage ist eher: "geht es auch mit 3.0.0.0?" Ich wäre froh wenn wir es schaffen könnten hier mal unsere Köpfe zusammen zustecken. Der eine oder andere wird hier ähnliches wieder finden oder hat was entdeckt aber noch keine Möglichkeit gehabt an der richtigen Stelle danach zu fragen. Ziel des ganzen ist es: Die REST-API zu verbessern, die Kompatibilität durch Workarounds zu gewährleisten falls möglich und den Entwicklern die Suche nach Problemen oder Lücken in der API unter die Arme zu greifen. Damit ein wenig Ordnung und Lesbarkeit vorherrscht wäre super wenn wir immer die folgenden Infos mit dabei geben: Gambio Version REST-API Version Bereich / Ressourcenknoten Beschreibung des Problems, des fehlenden Feldes Erläuterung der Notwendigkeit vielleicht an einem Beispiel damit die Devs es einfacher haben Dringlichkeit oder Priorität würde ich nicht mal wirklich übernehmen, ich denke jede Fehlende Info / jede Fehlende Funktion ist dringlich wenn sie einem fehlt. Wenn jemand einen Ansatz oder eine Lösung zu einem Punkt hat dann am besten immer die Post-Nummer mit angeben damit man weiß um welches Thema es sich handelt. Vielen Dank im Voraus für die geopferte Zeit diesen Beitrag zu lesen
Lange Rede kurzer Sinn hier mal mein Beitrag dazu: Gambio Version : 3.0.0.0 REST-API Version: 2.1.0 Ressourcenknoten: GetProduct with ID - Link zur Dokumentation: (Link nur für registrierte Nutzer sichtbar.) Zwar gibt es hierfür bereits eine Tracker-Nummer damit es in den nächsten Updates behoben wird aber es geht um Workarounds taxClassId ist in diesem Node vorhanden, hat den Wert z.B. "1" - nun aber die Frage bzw. das Problem: Wie kriegt man den prozentualen Wert mittels REST-API 2.1.0 zurück der hinter dem Wert "1" steht? Sprich: "19" für "19% MwSt" JTL legt seine MwSt-Klassen einfach ohne Wenn-und-Aber zB selbst an damit es die IDs kennt. Das muss doch aber auch ohne die Holzhammer-Methodik gehen. Ich nehme mal als Beispiel einen Shop mit 5000 Artikeln. Alle auf 19% MwSt und ID: 1 hinterlegt. Wenn plötzlich alle die ID "20" nehmen sollen für "19%" wie kriegen die anderen Artikel das mit? Nur durch umschreiben was ziemlich "hart an der Grenze" ist in meinen Augen. Wer eine Idee hat das Lösen zu können: immer gerne her mit den Ideen. Wer ein anderes Problem hat, ein Wert fehlt oder eine Funktion: einfach in dem Thread posten. Ich weiß ich bin "neu" hier (verfolge das eine oder andere durch Infos unserer Kunden oder in der Facebook-Gruppe) will aber hier auch helfen wo ich kann. Jedem kommt's zu gute.
Gambio Version : 3.0.0.0 REST-API Version: 2.1.0 Ressourcenknoten: GetProduct with ID Link zur Dokumentation: (Link nur für registrierte Nutzer sichtbar.) Es gibt zwar eine vpeId (number, int) und eine vpeValue (number, float) als Zahl aber vpeName (Verpackungseinheit als Bezeichnung als String) fehlt. Dadurch kann man für die Grundpreisangabe nicht die korrekte VPE übergeben. Auch hier wäre ein Workaround praktisch wenn es einen geben sollte.
Gambio Version : 3.0.0.0 REST-API Version: 2.1.0 Ressourcenknoten: GetProduct with ID Link zur Dokumentation: (Link nur für registrierte Nutzer sichtbar.) Die manufacturerId ist zwar vorhanden, jedoch ist über die API in Version 2.1.0 es nicht möglich an den Hersteller (Bezeichnung des Herstellers, Name des Herstellers) zu kommen Leider nicht erledigt: Label/Marke steht im Product unter addonValues als "brandName" im Klartext, ist aber nicht der Hersteller. Der Hersteller kann nicht über die API abgerufen werden.
Gambio Version : 3.0.0.0 bis neuste REST-API Version : 2.0.0 bis 2.3.0 Ressourcenknoten: keiner Link zur Dokumentation: fehlend Betreff: Fehlender Info-Knoten zur aktuell genutzten Gambio Version Ein "Gambio-VersionsInfo"-Knoten zur API wäre nicht verkehrt. /info/ um die wichtigsten Eckpunkte der Gambioversion herauszubekommen - installierte Gambioversion - aktuelle API Version - Status der XML-API (erreichbar, an oder inaktiv) aktueller möglicher Workaround: - man merke sich einen Zustand "API 2.0.0" in einer Variable - sobald Felder im JSON-Response existieren die erst in einer bestimmten API-Version existieren oder ein Knoten in vorherigen Versionen nicht existierte, ist diese API Version auf jedenfall vorhanden. - Prüfen ob "erkannte" API-Version kleiner als "neu zu lesende" dann aktualisieren sonst Variable so lassen wie sie ist. Ankerpunkte zur Ermittlung sind: API 2.0.0 - Ausgangspunkt API 2.1.0 - die Knoten "Categories", "Products", "Orders" sind erreichbar API 2.2.0 - im Adress-Knoten existiert ein Feld namens "HouseNumber" bzw. "TotalWeight" existiert in Knoten "Orders" API 2.3.0 - im Knoten Customer gibt es einen Wert "addonValues" API 2.0.0 ab Version 2.4.1.0 bis 2.7.0.9 API 2.1.0 ab Version 2.7.1.0 bis 3.0.9.9 API 2.2.0 ab Version 3.1.0.0 bis 3.1.0.9 API 2.3.0 ab Version 3.1.1.0 Man kann über diesen "Ankerpunkt" dann gegen bauen "wenn API 2.0.0 dann... wenn API 2.1.0 dann..."
Gambio Version : 3.0.0.0 bis neuste REST-API Version : 2.0.0 bis 2.3.0 Ressourcenknoten: keiner Link zur Dokumentation: fehlend Betreff: Fehlender Knoten zum Shop Die API bietet in den vorherigen REST-API Versionen (2.0.0 bis 2.3.0) keinen Knoten um die Eckpunkte des Shops auszulesen: - wie ist der Name des Shops - wie ist der Slogan des Shops - wie heißt der Betreiber - wie ist die Domain des Shops im Grunde die Werte der configuration-Tabelle bezogen auf die Infos des Shops (Design-Elementwerte sind irrelevant) müssten als Knoten raus gegeben werden können. Für ERP Systeme welche es ermöglichen, mehrere Gambio-Instanzen in einer Datenbank zu pflegen, muss es einen "Ankerpunkt" geben der Artikel, Kunden, Kategorien, Bestellungen zum Shop zuordnen kann. In unserem System z.B haben wir "Profile" nun hinterlegt, hier ist der Name des Profils die Eindeutigkeit, wird diese aber umbenannt gilt der Abruf als "neuer Shop" weil nicht bekannt. Einen festen Ankerpunkt auf Shopseite auslesbar zu haben wäre hier sicher nicht verkehrt.
Gambio Version : 3.0.0.0 REST-API Version: 2.1.0 Ressourcenknoten: Orders Link zur Dokumentation: (Link nur für registrierte Nutzer sichtbar.) Es ist zwar möglich den Orders-Status zu aktualisieren, jede Order hat auch die StatusId hinterlegt. mit dieser Id kann jedoch kein Kunde etwas anfangen. Wenn man die Assoziation hat StatusId 1 = offen, 2 = in Bearbeitung, 3 = PayPal ausstehend kann man damit viel mehr erreichen. es fehlt ein /status/ Knoten in dem die Bezeichnung der StatusId vorhanden ist.
Wir gehen die Punkte kurzfristig mal durch, dann gibts Feedback. Bei einigen müssen wir auch mal eben überlegen, kommt morgen eine längere Antwort. Da du gut erklärst aber immer weiter her damit
Gambio Version : 3.0.0.0 REST-API Version: 2.1.0 Ressourcenknoten: GetProduct with ID Link zur Dokumentation: (Link nur für registrierte Nutzer sichtbar.) Betreff: Netto und Brutto-Werte Die API ist prädestiniert dafür, Daten schneller vorzuhalten als wenn man das selbst tut, hierfür muss aber kontinuität vorhanden sein. Im Products-Knoten sollte es Netto sowie Brutto-Preise geben, samt MwSt-Satz als Zahl (nicht nur als taxClassId). Die Mehrheit der ERP-Systeme in Deutschland ist auf Netto ausgelegt, hier sollte definitiv dann auch immer nur der Netto-Wert im Product-Knoten auftauchen, das verwenden von einem Feld für zwei Arten (Netto oder Brutto) ist kontraproduktiv da man bei jedem Artikel prüfen muss "ist das jetzt Netto oder Brutto?" Wer die REST-API für eigene Projekte nutzen will, nutzt für "Anzeigetools" oder sonstiges meist das was der Kunde sehen will: den Bruttopreis. Zur Entlastung wäre hier sicher nicht verkehrt alle Werte vorhanden zu haben: - NettoPreis - BruttoPreis - MwSt in einer Diskussion mit Wilken kamen wir auf das Feld "b2bstatus" und dessen "Sinn" in der API. Hier wäre vielleicht nicht verkehrt wenn bzgl. "b2bstatus"-Feld ein wenig mehr Input in der Doku bzw. vorab hier in diesem Thread vielleicht die Auswirkungen dieses Boolean-Wertes mal besprochen werden könnte (bitte angeben "bezogen auf #9") Bestes Beispiel was auch wir bereits bei den DEVs von Shopware moniert haben: in der REST-API gibt es ein Feld für Price. Ist der Schalter "b2b" auf false steht da Brutto drin, sonst Netto, bezogen auf das Produkt. In der Order wird der Product-Knoten pro Position mit verwendet, hier kann aber pro Kundengruppe UND pro Kunde nochmal überstimmt werden. Man kann sich also nicht "global" merken "Shop ist reiner B2B-Shop oder reiner B2C-Shop" Die Idee ist zwar gut, die Umsetzung in der API aber mit einem Feld schlecht da dies viel Prüfarbeit mit sich zieht und zu Fehlern führen kann (ältere API Versionen haben keinen "b2b"-Wert im Kunden, nur Kundengruppe bei Shopware)
Gambio Version : 3.0.0.0 REST-API Version: 2.1.0 Ressourcenknoten: GetProduct with ID Betreff: Fehlender Knoten für Staffelpreise (?) bisher ist mir in der Doku noch nichts über den Weg gelaufen, wie man die Staffelpreise eines Artikels abrufen kann.
Gambio Version : 3.0.0.0 REST-API Version: 2.1.0 Ressourcenknoten: GetProduct with ID Betreff: Verpackungseinheit vorhanden, allgemeine Einheit jedoch nicht, sollte getrennt werden vpeValue und vpeId gibt es (siehe #3 bzgl. fehlendem vpeName), jedoch keine unitId sowie den dadurch resultierenden unitName. Beispiel: Ich verkaufe Socken. Die werden als (unitName) "Paar" verkauft. Als Verpackungseinheit (vpeName) habe ich jedoch "6er Pack"
Gambio Version : 3.0.0.0 REST-API Version: 2.1.0 Ressourcenknoten: GetOrder with ID Betreff: Gesamtgewicht vorhalten Pro Item habe ich zwar die Möglichkeit das Gewicht heraus zu bekommen, jedoch wäre es nicht verkehrt das Gesamtgewicht im Vorfeld zu haben hat sich erledigt: totalWeight ist vorhanden, steht aber nur im "Beispiel für CreateOrder" (Link nur für registrierte Nutzer sichtbar.) hier ggf. in der Doku den Eintrag nachpflegen.
Gambio Version : 3.0.0.0 REST-API Version: 2.1.0 Ressourcenknoten: GetProduct with ID Nach Telefonat bestätigt: im Knoten Orders habt ihr Extra die Möglichkeit "OrderProperties" abzurufen. Im Product-Knoten jedoch nicht. Der Artikel-Knoten gibt weder Attribute noch Properties heraus. Beispiel: Ich habe 2 Artikel, jeweils mit 5 Attributen á 3 Optionen. Würde in der Theorie 30 Artikel machen. Sendet der Product-Knoten mit die 30 zurück. Ein Rücktransport müsste nicht mal geschehen im ersten Step (besonders wenn die System vereint werden sollten) Vorteil für ERP-Systeme: Attribute und Properties können dem Artikel angehängt werden. Unsere WaWi z.B. erstellt daraus einen eigenen Artikel pro Attribut und Property. Dies wäre mit der aktuellen Schnittstelle nur durch Notlösungen die wir nachreichen müssen möglich (XML-API) wenn es hierfür Codebeispiele seitens der XML-API geben würde oder gepostet werden könnte wäre das echt super. Postident ist die #13
Gambio Version : 3.0.0.0 REST-API Version: 2.1.0 Ressourcenknoten: keiner angegeben in welchem Knoten unter welchem Punkt wird die IBAN und BIC bei Lastschrift abgespeichert? In der Dokumentation ist kein Wort davon erwähnt. Sinnvoll währe es diese Daten "allgemein bezeichnend"in den AddonValues der Bestellung neben cc_type, cc_owner und cc_number zu hinterlegen als z.B.: bankname z.B Sparkasse München bankholder z.B Max Mustermann banknumber z.B IBAN bankholdernumber z.B BIC
Die Frage ist: sind die Customizer-Daten seperate Felder? Mir scheint als ob die Grundtabellen und deren "Grundfelder" nur abgeprüft werden. Korrigiert mich wenn ich falsch liegen sollte. Besser (falls nicht vorhanden) wäre es, wenn die API neu angefügte Felder automatisch mit ausgibt, das spart euch und uns Entwicklern eine Menge Arbeit.
Kurzer Einwurf von mir: Die fachliche Beurteilung der Punkte in den Beiträgen habe ich Kollegen übertragen die tief in der Materie stecken. Die brüten noch über Lösungen, aber ein Ergebnis ist schon kommunizierbar: Wir werden in näherer Zukunft eine "REST-API Woche" in der Entwicklung einschieben, um gesammeltes Feedback in Erweiterungen und Verbesserungen umzuwandeln, das gibt dann relativ viele Entwicklerstunden konzentriert auf das Thema
Das hört sich gut an Wilken, wie kriegen wir (diejenigen die an der Umsetzung der API Verbesserung interessiert sind und helfen möchten) denn mit wann die "REST-API Woche" ist und wie können wir unseren Beitrag dazu leisten?
Gambio Version : 3.0.0.0 REST-API Version: 2.1.0 Ressourcenknoten: Orders, Products, Customers Paginierung, Aufteilen von API-Requests auf verschiedene Seiten. Die Funktion ist Klasse (Danke Wilken für den Tipp), schön wäre aber wenn es eine Funktion oder einen Indikator geben könnte der angibt "habe noch Daten, da kommt noch was" Um die Kompatibilität zu bestehenden Systemen nicht zu zerstören wäre ich persönlich für eine neue Funktionsübergabe an den/die Knoten. Stelle mir das in etwa so vor: (Link nur für registrierte Nutzer sichtbar.)getpagecount=true&perpage=10 Rückgabe: 5 für 5 Seiten (4x10 Orders + Rest) (Link nur für registrierte Nutzer sichtbar.)getpagecount=true&page=5&perpage=10 Rückgabe: 1 ( wir haben nur eine Seite, es kommt also keine weitere mehr hinzu ) Somit könnte man nämlich (um den Abruf auch zu beschleunigen) einfach auf "(Count der Tabelle) Modulo perPage > 0" prüfen und "((Count der Tabelle) % perPage) + 1 (wenn Modulo > 0)" zurückgeben lassen. Die Daten werden nicht angefasst und man weiß im Vorfeld schon wie viele Seiten bei der "perPage"-Angabe da gleich noch kommen werden. Ist für Leute mit fixen Arrays bestimmt nicht verkehrt weil man damit dann auch arbeiten kann. In der aktuellen Situation muss man solange die nächste Seite anfunken bis "[]" zurück gegeben wird, man weiß also erst ganz zum Schluss wie viele Seiten man hat und kann die Daten erst dann in ein Array schmeißen.