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 6.2.7 korrigiert CSRF-Problem im SecurityBundle
- Am ersten Februar, also vor genau einem Monat, wurden mit Symfony 6.2.6 zwei Sicherheitsprobleme adressiert. Ein Patch im SecurityBundle hatte allerdings auch valide Use Cases gebrochen, wie zum …
Flexible Tabellenspalten im EasyAdminBundle
- Vor kurzer Zeit haben wir das EasyAdminBundle (EAB) in die Entwicklungsversion von Zikula 4 integriert um das alte Admin-Interface abzulösen. Seitdem beobachten wir natürlich stets, was sich bei …
Kommende Neuerungen in Symfony 6.2
- Gegenwärtig laufen die Arbeiten an der nächsten Symfony-Version 6.2. Wie immer gibt es regelmäßige Einblicke in die wichtigsten, zu erwartenden Features und Verbesserungen. Dieser Beitrag zeigt im …
Zikula 4 - Ansätze für ein leichtgewichtigeres User Management
- Im Rahmen der Schlankheitskur vom Zikula Core sind einige Altlasten bereits entfernt worden. Das Admin-Interface baut nun auf dem EasyAdminBundle auf. Ein größerer Knoten, den es noch zu entwirren …
Zikula 4 und ModuleStudio - Weitere Integration mit dem EasyAdminBundle
- Im letzten Beitrag wurde unter anderem dargestellt, dass Zikula 4 nun das EasyAdminBundle (EAB) integriert um das alte Admin-Interface abzulösen. Zwischenzeitlich sind die Arbeiten daran etwas …