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

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. …
Zikula 3.0.1 veröffentlicht - erstes Bugfix Release für Zikula Core 3
- Genau einen Monat nach der Veröffentlichung von Zikula 3.0.0 ist nun das erste Update erschienen. Zikula 3.0.1 bringt wichtige Korrekturen und sorgt somit für ein Stück mehr Stabilität in der neuen …
Zikula Framework in Version 3 veröffentlicht
- Heute haben wir das finale Release von Zikula Core 3.0.0 veröffentlicht. Es basiert auf Symfony 5.1 sowie Twig 3 und verwendet unter anderem Bootstrap 4 und Font Awesome 5. Einen grundlegenden …
Zikula 3 erscheint als Release Candidate
- Heute wurde der erste Release Candidate für Zikula Core 3.0.0 veröffentlicht. Einen grundlegenden Überblick über die wichtigsten Änderungen sowie die weiterführenden Links zur Dokumentation und zu den …
Zikula Core Dokumentation in neuem Gewand
- Schon seit einiger Zeit werden im GitHub-Repository des Zikula Core die Dinge dokumentiert, die zusätzlich zu den Handbüchern von Symfony, Doctrine, Twig, Bootstrap usw. zu beachten sind. Nun wurde …