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

Monitoring von Queues mit dem Symfony Messenger
- Der Symfony Messenger kann über unterschiedliche Transporte mit diversen Queue-Technologien eingesetzt werden, zum Beispiel AMQP, Redis, Amazon SQS oder Doctrine. Um die Messages in den Queues …
MultiPart-Requests in Symfony einfach verarbeiten
- In Symfony gibt es mit der Mime-Komponente eine komfortable Möglichkeit, MultiPart-Nachrichten zu erstellen. Nicht out of the box enthalten ist aber ein Interface, das den Zugriff auf die in …
Kommende Neuerungen in Symfony 6.1
- Gegenwärtig laufen die Arbeiten an der nächsten Symfony-Version 6.1. Wie immer gibt es regelmäßige Einblicke in die wichtigsten, zu erwartenden Features und Verbesserungen. Dieser Beitrag zeigt im …
Zikula 3 - Cross-Release und weitere Ausrichtung
- Heute sind gleichzeitig zwei neue Versionen vom Zikula Core veröffentlicht worden. Zikula 3.0.4 bringt Fehlerkorrekturen Mit der Version 3.0.4 wird ein weiteres Bugfix-Update für die Hauptversion 3 …
Kommende Neuerungen in Symfony 5.4
- Vor einigen Tagen wurde Symfony 5.4.0-BETA3 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 …