| 863 Wörter
Ahoi,
im Zuge eines Projektes auf der Arbeit war es nötig, manuell mit Laravels Queue zu interagieren, also Jobs abzurufen und auszuwerten, ohne das Laravels eigene Queue-Verwaltung dadurch beeinflusst wird.
Da der gesamte Prozess nicht offiziell dokumentiert ist, möchte ich hier die Möglichkeit nutzen und es festhalten.
Zu aller erst ist die Implementierung als regulärer Service Provider verfügbar. Zum Verständnis ist es zwingend notwendig, die Funktionsweise folgende Komponenten verstehen: Service Provider, Service Container, Facades.
Das Laden des Service Providers übernimmt die Klasse Illuminate\Queue\QueueServiceProvider
Abhängig von der Konfiguration der Queues, entscheided dann die über den QueueServiceProvider bereitgestellte Klasse Illuminate\Queue\QueueManager welche exakte Implementierung verwendet werden soll (bspw. Queues in einer Db-Tabelle oder in Redis). Welche Backends unterstützt werden und wie diese zu Konfigurieren sind, würde den Umfang des Beitrages sprengen, weswegen ich lediglich auf die Dokumentation verweisen möchte: Laravel Queues.
Unabhängig von der globalen Konfiguration kann eine _Queueabl_e-Klasse auch eigenständig definieren, in welchem Queue und Queue-Backend diese “geschoben” werden soll. Zuständig dafür ist das Trait Illuminate\Bus\Queueable. Die bereitsgestellten Attribute connection und queue können respektieve angepasst werden, andernfalls wird die globale Konfiguration übernommen.
Wollen wir also jetzt ein Objekt in eine Queue für eine asynchrone Bearbeitung schieben, müssen wir lediglich dieselben Traits und Klassen wie ein Laravel Job erben und können dann über ein wenig Reverse-Engineering des Packets laravel/framework manuell Jobs aus der Queue abrufen und bearbeiten.
Für diesen Beitrag erzeugen wir uns einen neuen Job:
|
|
Und erhalten folgenden Boilerplate
|
|
Interessanterweise wird die handle() Methode nicht durch ein Interface vorgeschrieben, aber ist zwingend notwending, wenn man auf Laravels eigene Queue-Verwaltung verwenden möchte. Da wir das aber explizit in diesem Fall nicht möchten, können wir diese entfernen oder bspw. alle Aufrufe loggen, um zu erfahren, wann ungewollterweise Laravel die Bearbeitung übernommen hat.
Der über die Klasse QueueServiceProvider bereitgestellte Service Provider bietet über die Methode
|
|
uns den nächsten Eintrag in der angegebenen Queue.
Nun müssen wir nur noch die Einträge aus der Queue abfragen:
|
|
Falls der Queue nicht-leer ist, bekommen wir ein Objekt vom Typ_ Illuminate\Contracts\Queue\Job_ wessen Implementierung anhand des Illuminate\Queue\Jobs\DatabaseJobs nachfolgzogen werden kann.
Konkret interessiert uns nur die payload() Methode, welche schlicht und einfach die serialisierte Queueable-Klasse und ein paar Meta-Informationen enthält.
Wir können also ziemlich einfach auf den Inhalt zugreifen:
|
|
Folgendes ist alles in dem Payload enthalten:
|
|
Da uns die Meta-Informationen am Anfang nicht interessieren, müssen wir nur sicherstellen, dass das Array data und der Key command vorhanden sind:
|
|
Dann deserialisieren wir das Objekt und können es verarbeiten:
|
|
Der Inhalt ist selbstverständlich identisch zu dem Objekt, welches auf den Queue geschoben wurde:
|
|
Der gesamte Code zum Abrufen des Queues sieht dann so aus:
|
|