[TYPO3-german] Caching von Webserviceantworten

[Stephan Schuler]

Hallo Fabian.

> 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.

Nein, falsch verstanden. Der Scheduler synchronisiert nicht die Daten die die Plugins brauchen sondern alle die er bekommt. Dem Scheduler soll vollkommen egal sein welche Daten die Plugins brauchen. Man kann das ggf. optimieren und diejenigen Daten weglassen die unter keinen Umständen von Plugins angezeigt werden können. Wenn sich z.B. das Plugin ohnehin immer auf das aktuelle Jahr bezieht und im Plugin auch kein Zeitwähler existiert der Daten älter als ein Jahr beschreibt, dann kann man den Scheduler natürlich so optimieren, dass er nur das aktuelle Jahr in die Datenbank legt. Aber abgesehen von solchen kleinen Optimierungen soll der Scheduler wirklich alles synchronisieren was über die API kommt, weil er nicht wissen kann, welche Daten die Plugins brauchen.

> 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?

Du hast bei der Synchronisation praktisch keinerlei Vorteile, das Domain-Model zu verwenden.

Wenn die Quelldaten XML sind, wirst Du das wohl per PHP DOMDocument oder SimpleXML einlesen, dann per xpath die Objekte ansprechen und darüber iterieren. Pro Result des xpath-Query machst Du dann ein „new“ eines Extbase-Models und schreibst 50 Zeilen Code, nur im alle Attribute aus dem SimpleXML-Element in das Extbase-Model zu überführen. Anschließend kommt das nach „repository->add()“ und die Daten gehen in die Datenbank.

Die im Frontend relevanten Vorteile des ORM verwendet der Import in dieser Form gar nicht.
Weder brauchst Du das Query-Model, weil Du ja gar keine Daten aus dem Repository ausliest. Bestenfalls musst Du wissen ob es das Objekt schon gibt. Das machst Du aber nicht über „findByIdentifier()“ sondern vielmehr liest Du am Anfang des Import-Prozesses per „findAll()“ alle bestehenden Objekte aus und hältst sie im Arbeitsspeicher vor. Das QOM kommt also nicht zum Zug weil „findAll()“ ohnehin nur ein „SELECT * FROM table“ macht, ohne weiter Einschränkung.
Noch brauchst Du den Property Mapper, weil Deine Quelldaten gar nich in der Struktur vorliegen die der Property Mapper direkt verwenden kann.
Noch helfen Dir Relationen, insbesondere mit Lazy Loading, weil Du Die ja zur Laufzeit erst aufbaust und dann nichts lazy geladen werden kann.
Auch das Mapping der Daten zwischen „so wie ich mir das im Objekt vorstelle“ zu „so wie das in die Datenbank muss“ fehlt komplett, weil die Daten aus dem XML großteils nicht in dem Format vorliegen wie sie im Objekt sein sollen. Beispiel: Datum. Im XML wird das wohl als Timestamp oder als RFC-Format vorliegen, also als String. Das Extbase Domain-Objekt soll natürlich ein DateTime-Objekt verwenden. Dein Import also muss, wenn Du Extbase verwendest, erst per „new Date($xmlValue)“  ein neues DateTime-Objekt erzeugen das Du dann an Dein Model übergeben kannst. Das ist Deine Aufgabe im ImportCommand. Oder in der Factory, wenn Du das in eine Serviceklasse auslagern möchtest. Nur, damit im unmittelbar nachfolgenden Schritt Extbase wieder dieses Date-Objekt zum String oder Integer konvertieren kann damit es in die Datenbank passt.
Zwar findet das Mapping da also offensichtlich durchaus statt, es nimmt Dir aber keine Arbeit ab.

Dann kannst Du auch gleich auf den ORM verzichten und die Daten per DataHandler in die Datenbank schieben. Immerhin spart das dann wenigstens noch ein paar MB Arbeitsspeicher.

Und nicht zuletzt erzeugt der DataHandler eine sinnvolle History. Du kannst also als Administrator jederzeit im Backend die History eines konkreten Datensatzes ansehen und nachvollziehen, wann die SOAP-API welchen Wert verändert hat.
Du glaubst gar nicht, wie häufig ich mit Kunden telefonieren muss und ihnen erklären, dass die Daten die ihre Webseite anzeigt schon richtig sind und dass das Quellsystem (Youtube, Vimeo, irgend ein RSS feed für News, oder ein hausgemachtes Protokoll zur Veröffentlichung von Stellenausschreibungen) die Daten bereits falsch liefert. Wenn ich dann belegen kann, dass die Daten da schon seit vier Tagen falsch sind, und zwar um exakt 13:35 falsch synchronisiert wurden, finden Kunden in der Regel inhouse den Schuldigen Kollegen, der die Daten im Quellsystem zum fraglichen Zeitpunkt geändert hat.

Beste Grüße,


Stephan Schuler
Web-Entwickler | netlogix Web Solutions

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Web: websolutions.netlogix.de



----------------------------
Neu: Wir sind Amazon Web Services Partner. Mehr erfahren:
https://websolutions.netlogix.de/technologie/amazon-web-services-aws
----------------------------




netlogix GmbH & Co. KG
IT-Services | IT-Training | Web Solutions
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Web: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Matthias Schmidt