Re: [TYPO3-german] Caching von Webserviceantworten
Alles klar, jetzt habe ich das "Problem" mit dem Caching-Framework verstanden. Mein Vorschlag bezieht sich *nicht* auf das CF. Bau ein Extbase Domain Model mit Domain-Objekten, sinnvollem Datenbank-Layout für Dein Model und einem Repository, das Du im Plugin entsprechend Deinen Anforderungen fragen kannst. Der Scheduler füllt die Datenbank asynchron. Ich würde den Scheduler nicht über Extbase sondern über den DataHandler mit der Datenbank reden lassen, aber das ist Implementierungsdetail. Diese Daten siehst Du dann auch im TYPO3 Backend. Wenn Du möchtest, dass Deine Redakteure sie nicht bearbeiten können, verweiger ihnen entsprechende Berechtigungen. Ok, soweit verstanden. Wenn ich das richtig sehe, werden hier aber auch nur dann Daten angezeigt wenn der Scheduler gelaufen ist. Bei neu eingefügten Plugins hab ich potentiell fast 1 Stunde keine Daten, die ich ausgeben kann. Lässt sich das irgendwie vermeiden? Durch den erwähnten Hook z.B.? Wenn der Webservice aus irgendwelchen Gründen zu der Zeit keine Daten liefert, dann kann man ja immer noch auf den nächsten Scheduler Durchlauf warten und dem Redakteur eine entsprechende Notitz anzeigen. Der Scheduler füllt die Datenbank asynchron. Hast du dazu noch ein Beispiel bzw. Anhaltspunkt? Aus welchem Grund würdest du den DataHandler (https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Typo3CoreEngine/Database/Index.html ?) vorziehen? Vielen Dank und viele Grüße Fabian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Caching von Webserviceantworten
Guten Morgen Stephan, vielen Dank, dass du dir die Zeit für die ausführlichen Antworten nimmst. Ich verstehe deine aufgeführten Punkte (denke ich zumindest), ich konnte mir allerdings noch kein "Gesamtbild" daraus bilden. Derzeit habe ich sowas im Kopf: - Plugin wird auf einer Seite eingefügt, konfiguriert und gespeichert. - Ein Hook holt beim Speichern (vorausgesetzt so einen Hook gibt es, bin noch am Infos suchen) initial die Daten vom Webservice und speichert diese mittels Caching Framework in den Cache (cf_irgendwas). Die Konfigurationsparameter des Plugins werden dabei als Identifier genutzt. - Bei Aufruf der Seite durch einen Nutzer holt der Controller die Daten aus der Cache Tabelle und gibt sie an das Fluid Template. - Scheduler läuft jede Stunde und geht die gecachten Einträge in cf_irgendwas durch. Ist der Ablaufzeitpunkt überschritten werden die Daten erneut abgefragt und der alte Datensatz im Cache gelöscht. Grüße Fabian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Caching von Webserviceantworten
Hallo, Es wäre schön, wenn ich Dich mit Namen ansprechen könnte. Ein sinnvoller Absender und eine Grußformel an Ende wäre dabei hilfreich. Hab mein Profil mal angepasst, aber keine Ahnung, ob und wann das auf das Forum durchschlägt. Ich würde das nach Möglichkeit entkoppeln und per Scheduler synchronisieren. Eine Synchronisation zur Laufzeit mit gleichzeitigem lokalem persistenten Model ist keine gute Idee, dann machst Du alles von Hand. Angefangen damit, dass Du Dir überlegen musst, welcher dieser Requests jetzt diese Daten aktualisieren muss und welche nicht. Sprich: Du musst Dir bei jedem Objekt das „last synced" merken um zu entscheiden, ob das zu synchronisieren ist oder nicht. Natürlich hat der Datensatz bereits das Attribut „tstamp" womit die letzte Modifikation in der Datenbank gemeint ist. Aber dieser tstamp gehört ja eigentlich nicht in deine Domäne. Das ist ein Hilfsmittel, ein Werkzeug. Ein eine Object-Property des Extbase Domain-Models würde ich den tstamp nicht mappen solange er nicht wirklich im Frontend für den Benutzer als „letzte Änderung: Vor 15 Minuten" o.ä. angezeigt werden soll. Wenn Du die Synchronisation in einen Scheduler packst ist klar: Jedes Mal wenn der läuft synchronisiert der. Aber wie mache ich es dann? Ich muss ja irgendwie aus der XML-Antwort meine Objekte basteln, über die ich dann im Fluid Template iteriere und die Tabellen zusammensetze. Die Aufteilung in den Teil der sich geändert hat und den Teil der sich nicht geändert hat kannst Du im Scheduler immer noch durchführen. Lass Dir eine Liste aller Objekte geben, evtl. mit reduziertem Datenumfang. Diejenigen die im SOAP-Request ein Änderungsdatum neuer als tstamp lokal haben sind lokal zu aktualisieren. Die die im SOAP-Request ein Änderungsdatum älter als tstamp haben kannst Du in Ruhe lassen. Die die lokal existieren aber nicht über den SOAP-Request kommen musst Du lokal löschen. Insbesondere die Entscheidung welches Objekt ggf. zu löschen ist kannst Du nur über Bande treffen wenn Du im Controller des Frontend-Requests synchronisierst. Leider liefert der Webservice kein Änderungsdatum o.Ä. an dem ich entscheiden könnte, ob aktualisieren, nicht aktualisieren oder löschen. Bleibt also nichts anderes übrig als lokal zu entscheiden mittels timestamp, oder? Weiterhin bringt Dir bei der Synchronisation im Frontend die Extbase-Persistenz eigentlich keinen relevanten Vorteil. Wenn Du stattdessen den Plugin eine Stunde lang als HTML-Snippet cachen kannst, genügt es, die Objekte oer SOAP zu holen, an Fluid zu übergeben und nach dem PHP-Request wieder zu vergessen. Der dritte, weit schlimmste Nachteil der Synchronisation im Controller ist, dass Du Deine Frontend-Laufzeit von fremden Servern abhängig machst. Wenn der SOAP-Server mal nen schlechten Tag hat und ein paar Sekunden für die Antwort braucht, oder gar nicht antwortet, weil irgendwas hängt, dann hängt auch Dein Frontend. Solange Du Deine Daten nicht in der Datenbank als geändert schreibst (sprich: die Nicht-Antwort des SOAP-Servers als leeres Result und damit Löschanweisung interpretierst) bedeutet das für Dein Frontend, dass mehrfache Anfragen im Frontend jeweils parallel auf die Idee kommen, für die Synchronisation zuständig zu sein, und alle hängen am hängenden SOAP-Server fest. Dein Webserver hat ja nicht unendlich viel Arbeitsspeicher und kann damit nicht unendlich viele PHP-Prozesse gleichzeitig bedienen. Wenn Du für das Betriebssystem 1GB RAM abziehst und jedem PHP-Prozess 64MB RAM spendierst kansnt Du Dir ausrechnen, wie viele parallele PHP-Prozesse Du Dir erlauben kannst ohne dass der Server swappen muss. Die Zahl liegt mit großer Wahrscheinlichkeit im unteren zweistelligen Bereich. Wenn die Seite mit der Tabelle jetzt etwas Load hat, vielleicht vom ein oder anderen Crawler gefunden wird, wenn Du jetzt auch noch ungeduldige Webseitenbesucher hast die nach 10 Sekunden Ladekringel gleich auf reload drücken, dann hast Du sehr schnell alle Deine PHP-Prozesse damit belegt, auf den nicht mehr reagierenden SOAP-Server zu warten. Ab diesem Zeitpunkt sind Frontend und Backend nicht mehr erreichbar. Da hast du natürlich recht. Ich werde also die getrennte Lösung per Scheduler vorziehen. Gruß, Fabian ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Caching von Webserviceantworten
Ok, mit so einer ausführlichen Atnwort hab ich nicht gerechnet. Danke! Quote: Stephan Schuler wrote on Fri, 11 August 2017 14:02 Eine Variante wäre, die Remote-Daten als lokale Domäne abzubilden und per Scheduler einen Import zu bauen. Wenn z.B. ein beliebiges JSON- oder XML-Format verwendet wird um Daten bereitzustellen die in TYPO3 als News angezeigt werden sollen bietet es sich ja an, alle paar Minuten die Daten remote abzufragen und in lokale News-Records zu überführen. Der Vorteil daran ist natürlich, dass man keinen gesonderten Renderingprozess für diese News konfigurieren muss, wenn es ohnehin schon anderweitige, lokale News gibt. Das ist der Weg, den ich so jetzt auch gegangen wäre. Vorab zum Verständnis grad nochmal was ich brauche: Ich möchte eine Extension bauen, die den Redakteuren ein Frontend Plugin zur Verfügung stellt, welches sie auf beliebigen Seiten einfügen können. Dieses Plugin soll letztendlich Daten eines Webservice (genauer handelt es sich dabei um Veranstaltungsdaten (Termin, Ort, etc.)) tabellarisch aufbereiten und anzeigen. Der Redakteuer hätte in der Plugin Konfiguration gewisse Einstellungsmöglichkeiten, was genau angezeigt werden soll (aus diesen Einstellungen wird die Request für den Webservice gebaut). Die angezeigten Daten müssen von Zeit zu Zeit aktualisiert werden (nehmen wir als Richtwert mal an das die Daten immer 1 Stunde lang gültig sind). Stellt sich für mich nur noch die Frage, ob ich die Aktualisierung der Remote-Daten per Scheduler oder im Controller durchführe. Ersteres scheint mir eigentlich der sauberere Weg zu sein, allerdings sehe ich beim Controller den Vorteil, dass nur Einträge aktualisiert werden, die auch abgefragt werden. Seiten mit dem Plugin, die nicht aufgerufen werden, müssen ja nicht aktuell sein. Nachteil wäre halt, dass es jede Stunde einen Nutzer trifft, der einige Sekunden warten muss, bis die Remote-Daten neu abgefragt wurden. Auch wenn man in eine lokale Suche die Remote-Daten integrieren möchte bietet sich dieser Schritt an. Wenn man erst einen Import von einer Remote-API in lokale Datensätze durchführt, kann im Folgeschritt z.B. ein Solr-Indexing-Task die Daten in den Solr schaufeln und sie sind im Frontend über die Suche verfügbar. Dabei sollte der Import natürlich über den TYPO3 DataHandler durchgeführt werden, weil das die zentrale Stelle ist, die sowohl eine für Redakteure nachvollziehbare History erzeugt also auch der API-Call, an den sich wiederum Record-Indexer wie eben Solr hängen um innerhalb von TYPO3 über Datenänderungen informiert zu werden. Auch was Caching innerhalb einer TYPO3-Seite betrifft (Cache-Tags im Caching-Framework) ist die Verwendung des DataHandler dringend angeranten. Eine Verfügbarkeit der Daten über eine Suche ist nicht nötig. Eine weitere Möglichkeit ist ein Runtime-Cache. Der API-Aufruf ist sicherlich in irgendeiner Form ein HTTP GET-Request. Das heißt hier gibt es eine URL aus der sich ein Cache-Identifier ableiten lässt sowie einen Response-Body der der Cache-Content sein kann. Hier rate ich dringend dazu, nicht irgendeine selbst erfundene Datenbankstruktur zu verwenden, sondern das Caching-Framework. Für die Speicherung der Daten gibt es unterschiedliche Backends, nämlich u.a. dateibasiert, datenbankbasiert, memcache oder redis. Je nach Bedarf und Verfügbarkeit. Dem Konsumenten des Caches gegenüber stellt man die Daten dan entweder über das Variable-Frontend zur Verfügung (z.B. wenn es sich um Array oder Objekte handelt) oder über das String-Frontend (wenn der Konsument den Text-Body bekommen soll). Wenn der Cache richtig konfiguriert ist, lässt er sich über die „Clear Cache"-Buttons im Backend rechts oben ganz einfach leeren, wodurch das auch von Redakteuren bedient werden kann. Oder auch ein „Clear all Caches" wie man es ja vermutlich im Rahmen jedes Code-Deployments anstößt (Stichwort CLI-API!) nimmt das Caching-Framework, man muss sich also nicht selbst darum kümmern. Ja, der Webservice wird über eine SOAP-Request angesprochen. Werde mir diese Möglichkeit mal genauer ansehen. In beiden Fällen ist natürlich kein Weg beschrieben, wie Inhaltsänderungen des Providers an TYPO3 kommuniziert werden können. Das heißt, dass Du Dir eine Cache-Lifetime ausdenken musst die im Zweifelsfall zu kurz oder zu lang ist. Eine Lifetime von wenigen Minuten könnte dafür sorgen, dass Du trotzdem an ein anbieterseitiges Request-Limit stößt. Eine Lifetime von mehreren Minuten dagegen sorgt immer für panische Anrufe von Redakteuren, warum die Inhaltsänderung nicht sofort auch in TYPO3 sichtbar ist. Hier sollte es im Idealfall Empfehlungen des API-Providers geben an die man sich halten kann. Dann lassen sich diese Empfehlungen dem Kunden kommunizieren und die panischen Redakteure können mit Fakten beruhigt werden. Wenn es sich um einen HTTP GET-Request handelt der seinerseits Cache-Header enthält,
Re: [TYPO3-german] Caching von Webserviceantworten
Quote: Stephan Bauer wrote on Thu, 10 August 2017 09:30 Hier gibt es die Github-Version vom Extension-Builder für 8.7: https://github.com/FriendsOfTYPO3/extension_builder/ Wie installiere ich den? Habe 8.7.4 im Composer Mode laufen und habe den Inhalt des git repos unter typo3conf/ext/extension_builder/ abgelegt. Nachdem ich ihn über den EM aktiviert habe und öffnen will kommt dieser fehler: Could not analyse class: "EBT\ExtensionBuilder\Controller\BuilderModuleController" maybe not loaded or no autoloader? Class EBT\ExtensionBuilder\Controller\BuilderModuleController does not exist Quote: Christian Platt (platti) wrote on Thu, 10 August 2017 09:48 Die Frage ist ja, wie häufig sich die Quelldaten erneuern 2 Ansätze... wenn z.B. einmal täglich sich die Daten ändern 1. On the fly Request kommt rein, man prüft, ob es schon einen Eintrag für den Tag gibt, wenn nein, lädt man die Daten und speichert die in der Datenbank. Ist schon ein Eintrah vorhanden, dann wird dieser ausgegeben. Werden die Daten häufiger erneuert,lässt sich das ähnlich umsetzen oder man schafft eine Methode, die nur die Daten in die DB schaufelt und ruft die regelmäßig auf. Das mit dem CommandController war nur ein Test unabhängig von dem "Caching-Problem" hier. Öfter als einen Tag müssen die Daten auf jeden Fall aktualisiert werden. Eher so jede Stunde, vielleicht sogar öfter. ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Caching von Webserviceantworten
Da ich später 8.7 nutze (und es dafür ja noch keinen Extension Builder gibt), würde ich dann einfach zum Erstellen des Grundgerüsts 7.6 mit Extension Builder aufsetzten und später auf 8.7 "portieren"? Alles manuell direkt für 8.7 anlegen ist wahrscheinlich für einen Anfänger wie mich ziemlich aufwendig, schätze ich. Müsste ich nicht eher den timestamp in der Datenbank checken, um zu sehen, ob ich die Daten aus der Datenbank an die View gebe oder die schon so alt sind, dass ich den Webservice abfrage und neu in die Datenbank schreibe? Oder habe ich dich da falsch verstanden? Das müsste ich noch genauer schauen. Testweise hab ich auch schon mal einen CommandController gebastelt, der einmal am Tag nachts eine XML Datei aktualisiert. Ab welcher Häufigkeit würde ich denn besser einen Scheduler/CommandController nutzen? ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Caching von Webserviceantworten
Hallo, wie kann ich Antworten die ich von einem Webservice bekomme innerhalb einer Extension cachen? Angenommen ich möchte ne Extension bauen, die mir Daten von einem Webservice holt und in einem Fluid Template im Frontend ausgibt. Wie kann ich die ankommenden Daten für eine gewisse Zeit cachen, sodass beim Aufruf der Seite nicht jedesmal der Webservice abgefragt wird und man mehrere Sekunden warten muss bis die Seite geladen ist. Geht das schon mit Typo3 "Boardmitteln" oder bin ich auf was externes angewiesen? Vielen Dank ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Anleitung/Workflow zum Erstellen einer Extension
Vielen Dank für die Antworten. Das Buch "TYPO3 Extbase. Moderne Extension Entwicklung für TYPO3 CMS mit Extbase & Fluid. 2. Auflage" habe ich mir mal besorgt. Das Beispiel mit der Minimal Extension "efempty" hat mir dabei schon weitergeholfen. Ziel ist es eine Extension zu entwickeln, die Daten aus einer Datenbank liest (idealerweise über das Backend konfigurierbar z.B. Zeitraum) und im Frontend darstellt. Dort sollte der Nutzer noch die Möglichkeit einer Suche, Sortierung und Filterung bekommen. Version 8.7 ganz einfach deshalb, weil diese produktiv eingesetzt werden wird. Ich dachte mir, wenn keine älteren Versionen supportet werden müssen, macht am meisten Sinn die Extension direkt dafür zu entwickeln. Wie aufwändig ist den eine Portierung bei dem von dir genannten Vorgehen? ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Anleitung/Workflow zum Erstellen einer Extension
Hallo, ich versuche mich derzeit an der Extension Entwicklung (Version 8.7) und bin noch auf der Suche nach Grundlegenden Informationen zur Herangehensweise. Bücher habe ich leider zur aktuellen Typo3 Version noch nicht gefunden. Lediglich zu den Vorgägngerversionen. Bei denen wird das Thema Extension Entwicklung allerdings immer mit Hilfe des Extension Builders behandelt, welche ja für die 8.7 Version noch nicht aktualisiert wurde. Jetzt suche ich nach Informationen zur Extension Entwicklung eben ohne Extension Builder, idealerweise durchgespielt an einer kleinen Beispiel Erweiterung, wie es auch in den meisten Büchern der Fall ist. Kennt da jemand Quellen zu der Sache (ob englisch oder deutsch ist egal)? Vielen Dank im Voraus. ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
