Liebe Leute, Ein Webshop ist weder Lagerverwaltung noch Artikelverwaltung! Um eine saubere Lagerverwaltung zu haben, bedarf es einer ordentlichen WaWi !. Egal wie es gedreht und gewendet wird, der korrekte Weg ist z.B. pro Produkt, Größe. Farbe, etc. eine eigenen Strickcode zu vergeben. Die Attribute sind Fakten für die Filterung. Somit entfällt der EAN-Code in den Attributen. Das war damit gemeint. Und ist auch so in einem der namhaftesten Softwarelösungen für Textilhändler. LG Franz
Da sind wir uns einig. Der Shop ist bei mir nur Bestellsystem, nichts weiter. Lagerverwaltung, Fakturierung, Finanzbuchhaltung ink. OP-Verwaltung sind Aufgabe der WaWi. Du gehst dabei aber von deiner Branche aus. Bei mir unterscheiden sich Reinigungswerkzeuge z.B. nur in der Farbe, von denen es 14 verschiedene gibt. In der Wawi lege ich dafür 14 Artikel an, das ist OK, aber im Shop habe ich dafür einen Artikel mit einem Attribut und 14 Farben. Jede der 14 Farben hat eine EAN, bzw Artikelnummer. Das funktioniert mit der Lagerverwaltung und der Kunde bekommt im Shop statt 14.000 nur 1.000 Artikel angezeigt. Verschlankt die Auswahl ungemein und ist wesentlich übersichtlicher.
Das würden wir übrigens weniger schwarz/weiss sehen. Früher war das mal so, heute hat das klassische ERP Modell hie und da etwas Staub angesetzt.
Ich benutze auch seit Jahren php und sql um den Bestand von meiner Warenwirtschaft mit Gambio zu synchronisieren. Dabei vergleiche ich die EANs in der products_properties_combis. Meine Artikel haben nur die Eigenschaft Farbe. Das sollen wir also Updatesicher mit der REST-API machen. Der Umstieg wird nicht einfach. Ich habe damit noch nie gearbeitet. Die Doku hier wirkt kompliziert (Link nur für registrierte Nutzer sichtbar.) Gibt es im Forum keine Beispielcodes, wie es diese bei SQL gibt? Wenigstens die ersten schritte auf deutsch wären gut. Wie man eine Verbindung aufbaut. Das weitere kann man ja lernen. Und der Link zur Githubseite ist tot. Page not Found
Hi kidcars, es gibt ja scon wieder eine neue API :-D Die alte wird auch nur noch gewartet, aber neue Funktionen wird es nur für die neue geben. Ich weiß nicht, ob es Eigenschaften-Unterstützung für die v2 API gibt. War für GX 4.5 mal angekündigt, aber ist vielleicht noch nicht in der Doku. Wenn es das gibt, müsste das irgendwo hier sein: (Link nur für registrierte Nutzer sichtbar.) Ganz unten findest du einen Beispiel-API Call mit PHP und SQL: Code: <?php $curl = curl_init(); curl_setopt_array($curl, array( CURLOPT_URL => "https://gambio-shop.de/shop1/api.php/v2/products/{product_id}", CURLOPT_RETURNTRANSFER => true, CURLOPT_ENCODING => "", CURLOPT_MAXREDIRS => 10, CURLOPT_TIMEOUT => 30, CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1, CURLOPT_CUSTOMREQUEST => "PUT", CURLOPT_POSTFIELDS => "{\"id\":0,\"isActive\":false,\"sortOrder\":0,\"dateAdded\":\"\",\"dateAvailable\":\"\",\"lastModified\":\"\",\"orderedCount\":0,\"productModel\":\"\",\"ean\":\"\",\"price\":0,\"discountAllowed\":0,\"taxClassId\":0,\"quantity\":0,\"weight\":0,\"shippingCosts\":0,\"shippingTimeId\":0,\"productTypeId\":0,\"manufacturerId\":0,\"isFsk18\":false,\"isVpeActive\":false,\"vpeId\":0,\"vpeValue\":0,\"name\":{\"en\":\"\",\"de\":\"\"},\"description\":{\"en\":\"\",\"de\":\"\"},\"shortDescription\":{\"en\":\"\",\"de\":\"\"},\"keywords\":{\"en\":\"\",\"de\":\"\"},\"metaTitle\":{\"en\":\"\",\"de\":\"\"},\"metaDescription\":{\"en\":\"\",\"de\":\"\"},\"metaKeywords\":{\"en\":\"\",\"de\":\"\"},\"url\":{\"en\":\"\",\"de\":\"\"},\"infoUrl\":{\"en\":\"\",\"de\":\"\"},\"urlKeywords\":{\"en\":\"\",\"de\":\"\"},\"checkoutInformation\":{\"en\":\"\",\"de\":\"\"},\"viewedCount\":{\"en\":0,\"de\":0},\"images\":[{\"filename\":\"\",\"isPrimary\":false,\"isVisible\":false,\"imageAltText\":{\"en\":\"\",\"de\":\"\"}}],\"addonValues\":{\"productsImageWidth\":\"\",\"productsImageHeight\":\"\",\"codeIsbn\":\"\",\"codeUpc\":\"\",\"codeMpn\":\"\",\"codeJan\":\"\",\"googleExportCondition\":\"\",\"googleExportAvailabilityId\":\"\",\"brandName\":\"\",\"identifierExists\":\"\",\"gender\":\"\",\"ageGroup\":\"\",\"expirationDate\":\"\"},\"settings\":{\"detailsTemplate\":\"\",\"optionsDetailsTemplate\":\"\",\"optionsListingTemplate\":\"\",\"showOnStartpage\":false,\"showQuantityInfo\":false,\"showWeight\":false,\"showPriceOffer\":false,\"showAddedDateTime\":false,\"priceStatus\":0,\"minOrder\":0,\"graduatedQuantity\":0,\"onSitemap\":false,\"sitemapPriority\":\"\",\"sitemapChangeFrequency\":\"\",\"propertiesDropdownMode\":\"\",\"startpageSortOrder\":0,\"showPropertiesPrice\":false,\"propertiesCombisQuantityCheckMode\":0,\"usePropertiesCombisShippingTime\":false,\"usePropertiesCombisWeight\":false,\"groupPermissions\":[{\"id\":0,\"isPermitted\":false}]},\"quantityUnitId\":0,\"specialOfferId\":0,\"additionalFields\":[0]}", CURLOPT_HTTPHEADER => array( "authorization: Basic REPLACE_BASIC_AUTH", "content-type: application/json" ), )); $response = curl_exec($curl); $err = curl_error($curl); curl_close($curl); if ($err) { echo "cURL Error #:" . $err; } else { echo $response; } Hier gehts zur neuen v3 API: (Link nur für registrierte Nutzer sichtbar.) Ich weiß aber jetzt auch nicht, ob die Eigenschaften bald Optionen oder Varianten heißen, und wie denn die jetzigen Optionen heißen werden. Jedenfalls gibt’s für Varianten und Optionen was in der v3 API: (Link nur für registrierte Nutzer sichtbar.) Das kannst du aber vermutlich erst benutzen, wenn du auf Gambio GX 4.5.x bist, weil zu dem Zeitpunkt ja erst die Eigenschaften und Attribute abgeschafft oder umgebaut werden. Psst! Nicht laut drüber sprechen: Wenn du etwas weitgehend Konstantes suchst, dann bleib dabei, direkt auf die Datenbank zu gehen. Habe ich auch vor für die eine oder andere Funktion. Da ändert sich seltener was als an den APIs, und du hast anders als bei APIs vollen Zugriff, volle Kontrolle und volle Flexiblität auch für Spezialanforderungen.
Sachlich schwierige Feststellung. Ja, es gibt neue API-Knoten die in der URL zu ihnen eine andere Versionsnummer tragen. Es ist aber egal ob man nun V2 oder V3 sagt, die Dinge dahinter haben im Interface zum Apinutzer dieselben Paradigmen und es wurde nichts vorheriges entfernt. Gibt es also ein Problem? Nein, gibts nicht, war auch nicht angekündigt. Angekündigt war API Unterstützung für Eigenschaften und die ist nun da.
Oh! Also für eine Migration zu V3 muss man nichts anpassen außer der URL die man anspricht? Das wäre ja gut...
Nein, das hast du nicht richtig. Richtiger ist: In 90% der Fälle ist über ein längeren Zeitraum keine Migration nötig, das ist die Aussage. Die Aussage ist auch man kann V2 und V3 API Aufrufe wild miteinander mischen, das ist völlig egal und über einen längeren Zeitraum hier auch die richtige Herangehensweise. Eine Migration kann nötig werden, wenn ein oder mehrere Knoten einer alten API-Version durch neuere, in neueren API -Versionen ersetzt werden und der Support für die alten Knoten ausläuft. Das hat dann normal ein dickeres Zeitpolster. Eine Migration kann auch nötig werden, wenn der Shop eine Funktionalität erlangt die man anbinden will, die über ältere Versionen eines API-Knotens die man bislang nutzt dann aber nicht angeboten werden. Eventuell nötige, neue Felder könnten dann nur in den aktuellsten Varianten der jeweiligen Knoten hinzugefügt werden.
Warum denn in 90 % der Fälle über einen längeren Zeitraum? Du hast doch hier geschrieben: (Link nur für registrierte Nutzer sichtbar.) Diese Aussage ist doch im aktuellen Anwendungsfall 100% zutreffend, eindeutig und unmissverständlich, oder? Also auch wenn die API v2 unverändert bestehen bleibt (oder auch nicht, siehe dein obiger Beitrag, Wilken), dann braucht kidkars für Optionen, Eigenschaften, Attribute, Variationen und Kindartikel mit der v2 gar nichts mehr anfangen, oder? Weil wenn sich das alles ändert, wird die v2 da nichts mehr von können? Ist doch dann richtig, dass v2 für seine Zwecke veraltet ist und er die neue API nehmen muss, weil die neuen Attribute, Eigenschaften, Optionen etc. eine neue Funktion sind, die nicht mehr mit v2 kompatibel gemacht wird? Das habe ich jetzt auch aus diesem Beitrag so zwischen den Zeilen herausgelesen? Und die Tatsache, dass man dann, wenn man zukunftstauglich sein möchte und auch künftig neue Funktionen über eine API ansprechen will und jetzt erst beginnt mit APIfizierung, irgendwie lieber die Finger von der v2 lässt, ist auch richtig, oder? So hatte ich es Kidkars geschrieben? Oder was war daran eine "schwierige Feststellung"? Eine Herausforderung wird ja vermutlich auch, herauszufinden, welche API-Version welche Funktionen unterstützt. Ich kann auf jeden Fall nachvollziehen, wenn man in Sachen Shop-Anbindung erstmal konservativ bleibt.
Ich konstruier mal was wildes: Stell dir vor etwas neues wird zur Pflicht, zum Beispiel die Einverständnis eines Kunden zur Beilegung von Gummibärchen in Versandkartons. Stell dir dann vor, dass der Shop diese dann neue Information eventuell nur über einen neueren Knoten zur Verfügung stellt und die alten nicht entfernt aber auch nicht mehr verändert werden, dann hast du einen Migrationszwang. Falsch. Es gibt auch viele Informationen, die nur über V2 Knoten bereitstehen, also gehts wahrscheinlich nicht ohne V2. Kundendaten beispielsweise bekommt man Stand heute ziemlich ausschliesslich über V2. Nein, viel zu pauschal, falsches Entscheidungskriterium. Die Frage lautet: Wenn ich Daten erlangen oder ändern möchte, sollte ich dann immer den neuesten dafür zur Verfügung stehenden Knoten nehmen? Die Antwort ist: Ja. Dafür gibts die Doku. Es gibt keinen plausiblen Grund.
Außer dass man in mehreren Dokus parallel herumwühlt und sich mit 2 APIs auskennen muss. Ist das keine Zumutung für externe Entwickler? Für mich selbst ist es auch frustrierend: Du hast so viel für die API geworben, und ich habe erste Schritte gemacht und kleine Sachen geschrieben. Wenn ich jetzt sehe, dass ich für die dauerhafte und vollumfängliche Nutzung mich noch in eine zweite API einarbeiten muss, ist das etwas frustrierend und verleitet dazu, einfach per PHP so wie früher einen SQL-Befehl in die Datenbank zu werfen, und fertig. Also ich verstehe euer Anliegen mit der API, finde das aber für meinen Gebrauch ineffizient, weil die Einarbeitungszeit dann offenbar immer groß bleiben wird und die Halbwertzeit der erworbenen Kenntnisse gering ist. Sieht für mich aus wie: "Werd Profi und mach das im großen Stil für ein paar Hundert Shops, oder lass es ganz sein." Das erste kann ich nicht, das zweite will ich nicht. Für mich ist das ein wichtiger Vorteil von Gambio zu anderen Shopsystemen, dass man doch noch immer eine ganze Menge selbst basteln konnte und damit unterm Strich kostengünstig unterwegs war.
Das kann man relativ bequem auch als eine sehen. Nochmal, die Paradigmen sind gleich. Die Verdrahtung im Shop ist anders. Wir hätten die V3 Knoten auch V2 nennen können, hätte keinen Unterschied gemacht, so wars aber für uns intern schöner. Wenn jemand das behaupten will kann er. Praktisch spielts keine Geige. Nein, das ist folgefalsch. Du hast das bisher nicht verstanden. Es ist doch nichts weg. Nein, ein einmal gelerntes Verhalten hat normal über Jahre Bestand. Wir sind mit Sicherheit aus den Zeiten raus, in dem ein Shopsystem 300 Zeilen relativ unkomplexer Code war, wo man "alles" als Heimwerker zwischenfummeln konnte, das geht nicht mehr. Alle Shopsysteme sind inzwischen ein grosser Berg von komplexen Abhängigkeiten, das schneidet die simpelsten Anläufe ab. Mit einem System was soviel kann wie irgendwas in 2005 wär aber auch niemand mehr zufrieden, die Wünsche aller sind ja auch gestiegen, das ist zusammenhängend. Wir erklären die API, weil es der einfachste und verlässlichste Anlaufpunkt unter den gültigen, vertretbaren Möglichkeiten ist. Die Existenz von Serviceklassen in PHP als Alternative zur API und zur internen Beschaffung von Daten im Shopsystem und angeflanschtem Code muss auch verstanden werden, geht aber dauernd unter.
@L & B Du brauchst aktuell v2 und v3 als API um alle Endpunkt die der Shop zur Verfügung stellt nutzen zu können. Welche Endpunkte welche API zur Verfügung stellt, steht nicht nur in der Doku, sondern du kannst dafür auch die API selbst nutzen, indem du den Endpunkt /api.php/v2 ohne Parameter ansprichst, dann bekommst du eine Liste aller Endpunkte. Das gleiche gilt für v3. Damit kannst du deine Schnittstelle so bauen, dass dort nachgeschaut wird, ob der Endpunkt vom Shop zur Verfügung gestellt wird. Keine der Endpunkte die in der v2 sind, sind in der v3, daher kann man sagen, willst du die neuen Optionen haben musst du die Endpunkte der v3 ansprechen und wenn du z.B. Kundendaten (customers) verarbeiten, willst musst du v2 ansprechen. Ruf mal über den Browser api.php/v2 und api.php/v3 auf, dann wirst du sehen was welche API kann.
Ok, aber der Sinn erschließt sich mir immer noch nicht ganz, das dann zu trennen, wenn es doch eigentlich eine API ist. Vielleicht ist dann die Namensgebung auch etwas irreführend und sollte besser API Basisfunktionen und API Erweiterungen heißen, weil man sonst denken könnte, dass das v in v2 und v3 für Version steht und dann v2 veraltet ist oder so. Ebenso die Darstellung hier: (Link nur für registrierte Nutzer sichtbar.) Da muss man dann raten, welche API (oder welche Kombination der APIs) für die gewünschten Zwecke verwendet werden muss. Aber das was Wilken anspricht, die Services, die habe ich tatsächlich nicht auf dem Schirm gerade. Ist vermutlich der bessere Weg, wenn es zum Beispiel um Lieferstatus-Aktualisierungen auf Basis der Bestände etc. geht. Versteckt sich das unter dem Punkt PHP Docs? Gibt’s dazu auch Beispiel-Code? Und die Namensgebung der Services scheint sich dann aber doch auch wieder nach den Namen der Datenbank-Tabellen zu richten? Dann ist es ja nicht so zweckmäßig, dass ihr nicht verraten wollt, in welchen Tabellen sich künftig die neuen attribute, optionen, Eigenschaften, Varianten, Variationen verbergen? Oder benennt ihr die Services noch so um, dass sie den Bezeichnungen im Backend oder Frontend entsprechen, um eine sauberere Trennung zwischen dem was man anstoßen möchte und dem was im System passiert zu erreichen?
@kidcars Ich habe gerade einen 4.5.1.0 (RC1) Testshop aufgesetzt, um das gut gehütete Geheimnis zu lüften, was mit den Eigenschaftstabellen passiert: Du kannst weiterhin die Bestände und Preise in der Tabelle products_properties_combis pflegen und als Identifizierungsfeld die combi_ean oder combi_model verwenden. Ich weiß aber nicht, ob da künftig noch mehr umgebaut wird. Bis 4.5.1.0 jedenfalls klappts....
Ich brauche etwas Zeit um das mit der Rest-API zu lernen. Habe mit dem Programm Postman angefangen. Mal sehen wie es läuft Mit der Api v2 kann ich mich verbinden, aber bei v3 bekomme ich einen Fehler Fatal error: Uncaught Doctrine\DBAL\DBALException: Malformed parameter "url". in /www/htdocs/....... Ich habe die Shopversion 4.4.0.1 Ab wann ist denn die API in version3 benutzbar? Liegt der Fehler woanders?
Wäre schön wenn Ihr Code-Snippets zu der Rest-API anbieten würdet. So wie es im forum SQL Befehle gibt. Ich habe mit Shopurl + /api.php/v2/products/roductId eine bestimmte ShopId unter Postman abfragen können. productModel schaffe ich aber nicht. Ich weiss auch nix mit der Ausgabe anzufangen. Muss ich jetzt auch JSon lernen? Ich hoffe es kommt nächstes Jahr nicht auch noch eine API v4