Rest API: Produktinformationen

Thema wurde von Anonymous, 14. Januar 2022 erstellt.

  1. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Hallo,

    sehe ich das richtig, dass man über keinen REST API Call bekommt:

    • URL der Produktseite
    • Google Shopping Kategorie
    • Den tatsächlichen Brutto-Verkaufspreis des Artikels, wenn man nicht noch die Sonderpreise und die TaxClassIDs mit Extra-Calls abrufen will?
     
  2. Moritz (Gambio)

    Moritz (Gambio) Administrator

    Registriert seit:
    26. April 2011
    Beiträge:
    5.786
    Danke erhalten:
    2.692
    Danke vergeben:
    903
    Hallo,

    das siehst du richtig.
     
  3. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    #3 Anonymous, 16. Januar 2022
    Zuletzt bearbeitet: 16. Januar 2022
    Schade. Und kommt das denn noch? Vielleicht in der REST Api 4.0?

    Ich habe auch einen Blick auf die V2 und V3 geworfen: In der V2 gibts die Möglichkeit, Bestellungen anzulegen, aber ich bin irritiert, dass die API eigentlich nur eure bestehenden Datenbankstrukturen nachbildet. Macht das so Sinn? Also muss ich nach wie vor wissen, was ein Attribut und was im Gambio System unter "checkout_information" verstanden wird? Und ich musss auch wenn ich eine Bestellung anlege, einen separaten Call machen um Bestellpositionen zu erfassen, und dann noch einen um die Bestellzusammenfassung zu erzeugen? Aber der Bestellstatus wird automatisch mitangelegt? Das kann ich dann doch auch alles direkt über die Datenbank machen, wenn ich über die API ebenso die Möglichkeit habe, Datenbankinkonsistenzen zu erzeugen und genauso wissen muss, wie die Datenbank hinter den Kulissen aussieht und es zum Befüllen jeder Tabelle einen separaten Call gibt? Ich dachte, die Idee der API wäre gerade die Entlastung, dass man das alles nicht mehr so genau wissen muss und man nur noch die Daten anliefert über die API und der Shop dann die Daten selbstständig in die passenden Tabellen schiebt?

    Und bei CreateOrderItemAttribute, muss man da die ganzen Merkmale und Preise und Artikelnummern selbst noch übergeben, obwohl die in der Shop-Datenbank vorliegen?

    Warum macht ihr das nicht so:

    CreateOrder, bei der man alle Kundendaten und Lieferdaten etc übergibt, und dann gibt man nur noch als Bestellposition eine EAN oder Artikelnummer an, und dann sucht die API selbst ob es ein Attribut, eine Variation oder ein Hauptartikel ist? Und sucht die passende Bezeichnung und den passenden (Auf-)Preis und legt die Bestellhistorie und oder_totals etc. an? Dann würde eine API mehr Sinn machen, denke ich. Ansonsten muss ja auch jeder Drittanbieter in die Datenbank des Shopbetreibers, um zu wissen wie der Artikel genau im Shop angelegt ist...

    Was ist, wenn ich jetzt für EAN 82300444444 den Preis ändern möchte per API? Geht nicht, wenn ich nicht weiß ob es ein Hauptartikel, eine Eigenschaft, ein Attribut, eine Option, eine Variation oder was auch immer ist ne? Und wenn ich zufällig doch weiß, dass es eine Eigenschaft ist, dann kann ich es immer noch nicht, weil ich nicht weiß, wie der Vaterartikel-Preis ist und wie der Aufpreis dafür dann aussehen muss, oder? Ist das alles praktikabel so? Es kann doch noch kein Drittanbieter wirklich im Live-Betrieb mit der API arbeiten, oder? Oder nur parziell?

    Irgendwie kommt ihr bei der API nicht so recht aus eurer Innenperspektive heraus, oder?
     
  4. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Ich habe aber im Gegenzug festgestellt, dass bei CreateOrder doch eine ganze Menge im Hintergrund passiert: Ich hatte mal GET und POST vertauscht und deswegen versehentlich 5 "leere" Artikel im Shop erstellt, die ich dann schnell wieder gelöscht habe. Das ist so ohne weiteres möglich, ohne die Angabe irgendwelcher Artikeldaten einen Artikel zu erstellen. Man braucht keine Artikelnummer, keine Bezeichnung, keinen Preis, keine EAN. Da gibts offenbar keine Plausibilitätsprüfungen hinter? Dann ist das in etwa so problematisch wie direkt auf die Datenbank zu gehen, oder? Jedenfalls ist mir da beim Löschen aufgefallen, dass durchaus auch passende leere Einträge in der products_description und in der products_to_categories erstellt werden.

    Und kann das sein, dass man über UpdateProduct keine Kategorien zuordnen, löschen oder updaten kann?
     
  5. Moritz (Gambio)

    Moritz (Gambio) Administrator

    Registriert seit:
    26. April 2011
    Beiträge:
    5.786
    Danke erhalten:
    2.692
    Danke vergeben:
    903
    Eine REST-API hat erst einmal den Anspruch unverändert zu bleiben, also dass sich eine einmal definierte Schnittstelle nicht mehr so ändert, dass eine angebundene Software plötzlich nicht mehr durch ein Update des Shops nicht mehr funktioniert. Diese Sicherheit gibt es bei der Datenbank nicht. Diese kann sich jederzeit beliebig verändern, so dass es keinerlei Verlass gibt, dass eine Software, die direkt mit der Datenbank kommuniziert dauerhaft funktioniert. Ändert sich die Datenbank, wird die REST-API von uns so angepasst, dass Daten weiterhin im gleichen Format angenommen und zurückgeliefert werden. Die Wartungsarbeit wird also von uns und nicht dem Drittentwickler durchgeführt, was einen riesen Vorteil bedeutet.

    Die REST-API v2 ist eine Abstraktion der Datenbank, da hast du Recht. Sie berücksichtigt nicht die Geschäftsregeln bei der Nutzung. Sie sorgt zwar dafür, dass keine Datenanomalien in der Datenbank entstehen können, die zu Fehlern führen, aber Plausibilitätsprüfungen finden größtenteils nicht statt.
    Wir halten es für sinnvoll, dass eine REST-API auch die Geschäftsregeln widerspiegelt. Daher gibt es die REST-API v3, die berücksichtigen soll, dass du bei der Nutzung nicht etwas tun kannst, was im Shop selbst nicht ginge.

    Die REST-API arbeitet ausschließlich mit den Daten, die sie bekommt. Also Komfortfunktionien, wie eine Art Autovervollständigung anhand bestimmerter Merkmale, wie einer EAN, gehören nicht zu einer REST-API, es sei denn es ist eine explizite Geschäftregel, dass zum Beispiel beim Anlegen einer Bestellung Produkte mittels EAN zugewiesen werden. Hier geht es mehr um Usability und User Experience, was mehr in eine extra Ebene der Software gehört, die die Schnittstelle nutzt (sei es eine WaWi oder das Shopsystem selbst).

    Die Zuweisung von Produkten zu einer Kategorie wird über die "Product Link" Endpoints verwaltet.
     
  6. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Oi... Ok, verstehe. Dann macht EURE Rest-API aus meiner Sicht jetzt noch weniger Sinn als ich vorher gedacht hatte. Ich dachte, es ginge euch bei dem Wunsch, dass nicht jeder direkt auf der Datenbank herumnudelt, hauptsächlich darum, die Datenbank zu schützen, Standards anzuwenden und Kontrollmechanismen zum Schutz der Datenbank zu haben. Und darum, dass auch Nicht-Gambio-Experten einen schnellen und intuitiven Zugriff finden, dadurch mehr Entwickler und Plattformen eine Anbindung zu entwickeln wagen und Gambio durch eine wachsende Zahl von Schnittstellen attraktiver wird.

    Schade, dass ihr aus so einem groß angekündigten und viel von euch selbst gelobten Projekt absichtlich hinter den Möglichkeiten zurückbleibt.
     
  7. Moritz (Gambio)

    Moritz (Gambio) Administrator

    Registriert seit:
    26. April 2011
    Beiträge:
    5.786
    Danke erhalten:
    2.692
    Danke vergeben:
    903
    Wo ist die Datenbank denn nicht geschützt? Welche Standards werden denn nicht angewendet? Inwiefern sind die REST-API Schnittstellen im Shop kein Kontrollmechanismus zum Schutz der Datenbank? Inwiefern weichen wir von REST-API-Regeln ab, so dass sich ein Nicht-Gambio-Experte, der mit der REST-API-Technologie vertraut ist, nicht damit zurecht finden kann?

    Magst du mal eine REST-API nennen, mit der du schon gearbeitet hast, die die Ansprüche erfüllt, die du meinst? Ich kann deine Kritik leider noch nicht nachvollziehen und würde es gerne besser verstehen.
     
  8. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Hallo,

    eigentlich schon viel zu geschrieben. Ich habe manches ehrlich gesagt noch gar nicht ausprobiert und gehe allein von der Beschreibung der API davon aus, dass es Schwierigkeiten gibt. Korrigiere mich wenn ich was falsch verstanden habe.

    Beispiel 1: Bestellung anlegen
    Für die Erstellung von Bestellungen orientiert sich die API 1:1 an euren Datenbank-Tabellen. Als NIcht-Gambianer und als jemand der noch nie in die Datenbank reingeschaut hat, denke ich, dass ich mit dem Create Order Call eine Bestellung anlegen kann. Wenn ich aber sehe, dass es den Create Order Item Call einzeln gibt und den Create Order Total Call auch noch, dann tippe ich drauf, dass man zum Anlegen einer Bestellung, die nicht in einer kaputten Datenbank endet, alle Calls ausführen muss. Zumindest der orders_status_history Eintrag wird automatisch erstellt? Warum kann man mit dem Create Order Call nicht auch gleich die Items übermitteln? Warum werden orders_total Einträge nicht automatisch erstellt? Das macht der Shop doch auch selbst, wenn eine Bestellung aufgegeben wird? Also wer nicht weiß, dass es diese ganzen Bestellungs-bezogenenen Tabellen in der Gambio-Datenbank gibt, der kommt nicht unmittelbar auf die Idee, dass man für EINEN Vorgang (das Anlegen einer Bestellung) gleich eine Handvoll API Calls benötigt. Das meine ich auch mit "hinter den Möglichkeiten zurückbeiben": Es attraktiv zu machen, "eben schnell" eine API für Gambio mitzubauen, weil man schnell reinkommt und es unkompliziert ist.

    Beispiel 2: Produktdaten senden und erhalten
    Warum kann man nicht alle Produktdaten exportieren? Gerade für Preisvergleichsportale, Affiliate Plattformen, ... ist doch der Produkt-Deeplink total wichtig. Gibts nicht, niemand dran gedacht hat. Weil er nicht 1:1 in der Datenbank zu finden ist. Die Google Shopping Zuordnung ist die einzige Shop- und Plattform-unabhängige Möglichkeit der Kategorisierung von Artikeln. Warum bietet die API auf so etwas keinen Zugriff?
    Ihr schreibt dazu einfach: Gibts nicht. Mehr nicht. Wenn ich jetzt ein Wawi-Anbieter wäre, würde ich mich fragen, warum ich mit der REST API arbeiten soll, wenn es nicht auf alle Felder Zugriff gibt? Das gibt immer ein Durcheinander von Daten, die NUR in der Wawi oder die NUR in Gambio gepflegt werden können. Das erklär auch mal einem Mitarbeiter, der für die Anlage von Artikeln zuständig ist. Geht nicht, oder?
    Das meine ich auch mit "hinter den Möglichkeiten zurückblieben": Eine halbherzige Umsetzung, bei der "Ganz oder gar nicht" Entwickler von Bord sind: Eine Infrastruktur für direkte Datenbank-Zugriffe parallel zur REST-API Infrastruktur aufbauen, warten und nutzen - das sind doppelte Kosten, ist doppelter Aufwand und doppelte Arbeit.

    Beispiel 3: Varianten, Optionen, Attribute, Varkombis, Eigenschaften
    Ich habs mir schon öfter durchgelesen, aber kann mir den Wirrwarr nicht merken. Nicht euer Fehler, ok. Ich weiß aber in der V3 noch immer nicht, welche Calls ich für welche Zwecke in welcher Reihenfolge ausführen muss/kann/soll. Warum es dafür die REST API V3 gibt, wusste ich auch nicht und musste es erst erfragen. Jeder Entwickler wird selbst erstmal davon ausgehen, dass V2 outdated ist und V3 der Nachfolger. Dass beide parallel in Betrieb sind und für unterschiedliche Zwecke verwendet werden - kann man im Forum erfragen oder anhand der Auflistung der Calls erraten, aber ansonsten wirds schwierig. Schön wäre ja ein einziger Call für Kindartikel, in dem man angeben kann, ob die Merkmale einzeln nebeneinander stehen sollen oder kombiniert werden sollen mit Bestandsführung und EAN. Das wäre auch wieder eine Komfortfrage, die Entwicklern die Sache einfacher machen würde. Oder muss jeder Entwickler wissen, wie Merkmale mit und ohne Bestandsführung in Gambio, Magento, Shopware, Oxid, Shopify, Plentymarkets, XTCommerce, ... heißen und in welchen Tabellen sie gespeichert werden, wie die Spalten heißen, damit man erraten kann, welcher API Call jetzt benutzt werden muss...

    Beispiel 4: Schnell was an einem Artikel updaten
    Wenn ich die EAN oder Artikelnr habe, muss ich erst versuchen, per GET in den Artikeln einen Treffer zu finden, dann per GET in den Attributen, dann per GET in den Eigenschaften. 3 Calls. Alle Ergebnisse prüfen. Dann für den Fall, dass es irgendwo einen Treffer gibt, für jede Datenbank-Tabelle einen Update-Call. Ich muss immer noch wissen, dass es Artikel, Eigenschaften, Attribute gibt, wie das Ganze arbeitet, dass auch bei Festpreis-Eigenschaften nicht mit Festpreisen, sondern mit aufaddierten Preisen gearbeitet wird. Im Fall von Eigenschaften muss ich noch per GET Call den Vaterartikel herausfinden und dessen Preis raussuchen. Und wenn es da einen Sonderpreis gibt, auch noch vorsichtshalber per GET Call aus den Sonderpreisen lesen. Und dann den neuen Preis berechnen und dann hochladen.
    Ein Nicht-Gambianer würde sagen: Ich will den Preis für EAN xy updaten. Update-Call EAN xy, Preis z. Fertig. Dazu hast du geschrieben: Da gehts um Usability und User Experience, und das wollt ihr mit der REST API nicht bieten. Liest sich für mich wie: Da soll sich mal jeder Entwickler selbst durchkämpfen und seine Ressourcen investieren. Und daraus schließe ich, dass es euch egal ist, wie viele externe Entwickler "Lust" haben, mit der REST API zu arbeiten statt selbst schnell auf die Datenbank zu gehen. Das meine ich auch mit "hinter den Möglichkeiten zurückbleiben".

    Beispiel 5: Produkte anlegen
    Ich habs nicht weiter getestet, als ich versehentlich "leere" Artikel per API im Shop angelegt habe, sondern schnell zugesehen, dass ich sie gelöscht bekomme, bevor sie noch in die Warenwirtschaft importiert werden und Kollateralschäden anrichten können. Ich finde es aber wie gesagt komisch, dass ich per API Artikel anlegen kann, die kein einziges Unterscheidungsmerkmal haben außer der products_id. Das Problem dabei ist ja auch, dass man sie ohne Zugriff auf die Datenbank gar nicht mehr wiederfindet, um sie zu löschen? Soweit ich das im Kopf habe, kann man Artikel ohne Namen im Gambio Admin gar nicht finden, oder? So wie Artikel ohne Kategoriezuordnung? Das sind dann einfach Datenbank-Leichen, von denen man nichts weiß und die man nicht mehr mit herkömmlichen Mitteln löschen kann. Warum nicht an der Stelle Prüfalgorithmen einbauen? Konnte nicht angelegt werden, weil es keine Artikelnummer gibt. Oder weil es keinen Namen hat. Oder sowas. DAS meine ich auch mit "hinter den Möglichkeiten zurückbleiben". Würde euch doch im Support auch entlasten, denke ich.

    Und wenn ihr irgendwann sagt: Hey, ja, das macht Sinn, wir legen ein paar Operationen zusammen in einen Call, dann ist die stabile API passé. Darum ist das Ganze im aktuellen Status für mich Kategorie "Nichts Halbes und nichts Ganzes". Und wenn es stimmt was hier im Forum geschrieben wird, dass es erst einen einzigen Warenwirtschaftsanbieter gibt, der mit der API arbeitet, dann spricht das Bände. Das Statement von JTL Wawi zur API habt ihr im JTL Forum bestimmt auch schon gelesen, oder?

    Also wenn man Usecase-bezogen über die API nachdenkt, kommt man zu anderen Sichtweisen als wenn man Datenbank-bezogen darüber nachdenkt.

    Aber wie anfangs geschrieben: Du hast Recht, Moritz, dass ich mir eigentlich erst ein Urteil erlauben darf, wenn ich eigene Erfahrungen habe und nicht nur von Vermutungen ausgehe. Für manche der obigen Beispiele habe ich Erfahrungen, für andere nicht. Also schreib ruhig wenn ich irgendwo falsch liege. In manchen Punkten bleiben wohl auch nach Diskussion einfach zwei verschiedene Meinungen gegenüberstehen, wie in Beispiel 4.

    Habt ihr denn eigentlich mal mit ein paar großen Wawi-Anbietern oder anderen Serviceprovidern (Buchhaltungssoftware, Marktplatz-Anbieter, ...) Kontakt gehabt und gefragt, nach welchen Schemen da standardmäßig gearbeitet wird?
     
  9. Anonymous

    Anonymous Erfahrener Benutzer

    Registriert seit:
    19. Juni 2012
    Beiträge:
    4.831
    Danke erhalten:
    1.122
    Danke vergeben:
    947
    Ach so, noch vergessen: Der Call zum Leeren des Cache leert laut Wilken den Cache nicht: (Link nur für registrierte Nutzer sichtbar.)
    *grübel* Nicht intuitiv, nicht verständlich.
     
  10. markus_wick

    markus_wick Erfahrener Benutzer

    Registriert seit:
    10. Oktober 2018
    Beiträge:
    966
    Danke erhalten:
    214
    Danke vergeben:
    153
    Hi!
    Dass manche Dinge wie die Google-Kategorien noch nicht gehen (oder Filter z.B.) finde ich auch sehr.... bremsend, ja.

    Ansonsten bin ich mir der API und der Nutzung recht zufrieden. Ja, für einen Halblaien manchmal etwas sperrig, damit umzugehen, aber bei mir klappt die Nutzung der Features die ich brauche problemlos. Für manche Funktionalität braucht man halt mehrere Schritte/Calls, das finde ich aber nicht ungewöhnlich.

    Deine Kritik, dass Du "versehentlich "leere" Artikel per API im Shop angelegt" hast und "schnell zugesehen" hast diese wieder zu löschen bedeutet ja im Klartext, dass Du mit der REST-API ein wenig herumgespielt hast - im Live-Shop! Das wiederrum würde ich nicht empfehlen, ich denke das weisst Du auch :). Immer nur im Testshop, wenn Du nicht genau weisst was Du tust. Die API gibt Dir ja beim Anlegen eines neuen Produkts die products-ID zurück, die kannst Du ja zum Auffinden und wieder Löschen nutzen. Oder um im Nachgang das Produkt mit "Leben" zu füllen, also Name, Preis und Co.

    Der Aufwand, sich in die Nutzung der API einzuarbeiten ist nicht ohne, grade für Nicht-Coder. Aber wenns dann läuft, läufts. Finde ich gut. Ich mache nichts mehr manuell im Shop, meine WAWI kommuniziert direkt damit. Und auch Dinge die noch nicht gehen (Google-Kategorien z.B.) verzichte ich derzeit, in der Hoffnung, dass die API das irgendwann auch unterstützt.
     
  11. Moritz (Gambio)

    Moritz (Gambio) Administrator

    Registriert seit:
    26. April 2011
    Beiträge:
    5.786
    Danke erhalten:
    2.692
    Danke vergeben:
    903
    Eine REST-API zu haben, die sich mehr an konkreten Anwendungsfällen orientiert als an Datenstrukturen, ist oftmals sinnvoll, weil sie intuitiver und oftmals in weniger Schritten zu nutzen ist. Diesem Ansatz folgen wir mehr in v3 Endpunkten. Es ist aber auch nicht so, dass möglichst versucht werden soll, alles in einem Request unterzubringen, weil es auch wichtig ist, unterschiedliche Daten voneinander zu trennen. Was aus Benutzersicht zusammen gehört, gehört nicht immer technisch zusammen. Die Anforderungen an eine technische Schnittstelle und eine Benutzeroberfläche sind sehr unterschiedlich. Zusammenfassen heißt auch, dass alles scheitert, wenn nur ein kleiner Teil nicht valide ist. Das ist auch nicht immer gewünscht. Werden Anwendungsfälle vorgegeben ist das aber auch eine Einschränkung der Freiheit, weil dann vielleicht gewünscht Abweichungen, also eigene Anwendungsfälle, nicht möglich sind, die du problemlos umsetzen kannst, wenn die API näher an der Datenstruktur ist. Es also nicht schwarz-weiß zu sehen, sondern kommt ganz darauf an, welche Ziele verfolgt werden sollen.

    Du wünscht dir eine REST-API, die alle Daten des Shopsystems verarbeiten kann. Ich hätte sie auch gerne, sie entwickelt sich leider nicht von selbst. Es ist eine Ressourcen-Frage. Wir sehen Anwendungsfälle für eine REST-API, die bereits große Teile abdeckt. Wir sehen mehr Anwendungsfälle, je mehr abgedeckt wird. Wir erweitern die REST-API inkrementell. Ich glaube hätten wir bisher keine REST-API, weil es noch keine komplette Datenabdeckung gibt, wäre noch weniger Leuten geholfen.
    Also du darfst und sollst gerne Feedback geben, warum die REST-API für dich noch nicht ausreichend ist. Wenn wir wissen, wo der Schuh am meisten drückt, ist dort am schnellsten mit Lösungen zu rechnen, besonders dann, wenn mehrere die gleichen Wünsche haben. Wenn z. B. viele Preise mittels EAN aktualisieren wollen, ist eine REST-API dazu auch interessant für uns. Ist die Nachfrage zu einer anderen Anpassung der REST-API größer, wird dein Wunsch niedriger priorisiert.
    Unterschätze nicht die unterschiedlichen Anforderungen der unterschiedlichen Nutzer der REST-API. Deine Wünsche sind nur ein kleiner Teil aller Wünsche. Würden wir alle umsetzen, gäbe es auch zig Varianten etwas sehr ähnliches zu tun und es wäre so gar kein Muster zu erkennen, wie etwas funktioniert, weil es auf sehr spezifische Anwendungsfälle zugeschnitten wäre. Um alle glücklich zu machen wird es also Kompromisse geben. Eine API bleibt übrigens stabil, wenn Änderungen dazu kommen und keine alten ersetzen. Also wir können immer etwas anders machen. Eine stabile API ist da nicht in Gefahr. Das bekommt dann einfach seinen eigenen Endpoint oder seine eigene Version.

    Und ja, wir stehen mit WaWi-Anbietern in Kontakt. Von ihnen stammen viele Änderungswünsche, die zu entsprechenden Aktualisierungen von uns geführt haben.

    Ich bin jetzt nicht auf alle deine Fragen eingegangen. Es geht dann sehr ins Detail und man muss sehr weit ausholen, um zu erklären, warum etwas ist wie es ist und warum etwas, dass erst einmal logisch und besser klingt, auch noch Haken haben oder gar kontraproduktiv sein kann. Es ist bei deinen Ausführungen auch einiges dabei, dem ich zustimme oder was meine Sicht erweitert, also danke fürs Feedback. Also denke nicht, dass es mir oder anderen bei Gambio egal ist, wenn jetzt hier nicht konkret Bezug auf alles genommen wird.