Symfony Services asynchron im Hintergrund aufrufen

in  Zikula Apps , , , , ,

Symfony Services asynchron im Hintergrund aufrufen

Oftmals greift man in Symfony-Projekten auf CLI-Kommandos mit Hilfe der Symfony Console-Komponente zurück, um länger laufende Prozesse außerhalb des Webservers durchzuführen. In komplexeren Vorhaben gibt es weitere Ansätze, wie etwa eine Job Queue oder die noch relativ junge Symfony Messenger-Komponente. Diese haben gemeinsam, dass sie eine bestimmte Struktur voraussetzen. Für die Umstellung von Legacy-Code, in dem selbstgeschriebene Jobs mit ReactPHP Event-Loops zum Einsatz kommen, haben wir vorerst einen anderen Weg gewählt, um diese Worker in Einklang mit Symfony zu bringen.

Schritt 1 - ein gemeinsamer CLI-Einstiegspunkt

Zunächst haben wir ein generisches CLI-Kommando gebaut, mit dem die unterschiedlichen Jobs über einen einheitlichen Aufruf gestartet werden können. Dies hat erst einmal einige Redundanzen eliminiert. Zum Starten etwaiger untergeordneter Jobs gibt es die Möglichkeit, andere Commands programmatisch aufzurufen.

Nun gab es nur noch ein Problem: die ReactPHP-basierten Event-Loops laufen permanent und triggern regelmäßig weitere Kindprozesse zur Abwicklung anstehender Aufgaben. CLI-Kommandos sind aber nicht asynchron.

Schritt 2 - das Ganze asynchron machen

Um die Tasks nun im Hintergrund ausführen zu können, wird das KrloveAsyncServiceCallBundle verwendet. Zum Einsatz kommt konkret dieser Fork, der das Bundle kompatibel zu neueren Symfony-Versionen anbietet.

Dieses Bundle ermöglicht es, beliebige Services zu starten, entweder unter Nutzung von exec oder der Symfony Process-Komponente.

Die interne Funktionsweise des Bundles besteht darin, ein Symfony CLI-Command (krlove:service:call) im Hintergrund zu starten, welches dann die Ausführung der gewünschten Funktionalität übernimmt.

Schritt 3 - beides zusammen bringen

Unser eigenes CLI-Command arbeitet nunmehr in zwei verschiedenen Modi: wird ein optionales debug-Argument angegeben, startet es den gewünschten Job synchron im Vordergrund. Ohne dieses Argument fungiert es hingegen als Wrapper und ruft wiederum das oben beschriebene Bundle auf, um die eigentliche Ausführung des gewünschten Jobs mit Hilfe dessen CLI-Commands im Hintergrund zu starten. Also zusammengefasst ruft das eigene Command den Service des Bundles auf, welcher das Command des Bundles als Prozess im Hintergrund aufruft, der dann schließlich den eigenen Job ausführt.

Weitere Informationen

Um zu sehen, wie das Bundle intern arbeitet, empfiehlt sich erstens die Lektüre der Dokumentation und darüber hinaus ein Einblick in die Quelltexte.

Weitere Beiträge in Kategorie Zikula Apps

Symfony Messenger - Behandlung erneut fehlgeschlagener Nachrichten
- Im Symfony Messenger gibt die Möglichkeit, fehlgeschlagene Nachrichten an eine failed queue zu leiten. In diesem Sammelbecken können diese dann inspiziert und nach Korrektur des zu Grunde liegenden …
Response-Eigenschaften im Zikula Theme-Layer anpassen
- In Zikula gibt es eine Besonderheit zu beachten, welche Einfluss darauf nimmt, wie die aus einem Request resultierende Response zum anfragenden Client gelangt. Per Standard wird die Response in …
Tabellennamen mit Doctrine dynamisch anpassen
- Mit Hilfe der Metadaten von Doctrine lassen sich jegliche Daten zu einer Entität zur Laufzeit verändern. Allerdings kann das in manchen Anwendungsfällen fortwährend notwendig sein, zum Beispiel in …
Kommende Neuerungen in Symfony 5.2
- Vor zwei Tagen wurde Symfony 5.2.0-BETA2 veröffentlicht. Dies nehme ich zum Anlass, um einmal einen Überblick über die wichtigsten neuen Funktionen zu geben, auf die wir uns im Rahmen dieses Updates …
Zikula Core 3.0.3 mit Sicherheits-Update von Symfony 5
- Vor kurzem hatten wir über das Release von Zikula 3.0.1 berichtet, welches wichtige Korrekturen für Zikula 3 bereitgestellt hat. Vor einer Woche wurde die nächste Version 3.0.2 veröffentlicht. …