Zum Inhalt springen

Eigenständige Nutzung

Als Markdown anzeigen Auf GitHub bearbeiten Dokumentation zu 2cc7b2b

Queuety wird als WordPress-Plugin bereitgestellt, aber für den Großteil der Laufzeitumgebung ist keine aktive WordPress-Anfrage erforderlich.

Warteschlange, Workflow-Engine, State Machines, Signale, Artefakte, Batchverarbeitung, Zeitplanung, Protokollierung, Metriken und Ressourcenverwaltung greifen alle auf dieselben MySQL-Tabellen zu. Wenn ein anderer PHP-Prozess dieselbe Datenbank öffnen kann, kann er den Kern direkt verwenden.

Das ist die Grenze der eigenständigen Nutzung von Queuety. Die datenbankgestützte Orchestrierungs-Engine lässt sich außerhalb von WordPress verwenden. Die WordPress-Bridges gehören weiterhin zu WordPress.

Was außerhalb von WordPress funktioniert

Mit einer direkten Connection kann ein eigenständiger Prozess Queuety initialisieren und dieselben Fassadenmethoden wie das Plugin für die Laufzeitumgebung des Kerns verwenden:

  • Jobs ausführen
  • Worker und Worker-Pools starten
  • Workflows erstellen und ausführen
  • Signale, Genehmigungen und Workflow-Eingaben senden
  • State Machines erstellen und ausführen
  • Workflow- und Maschinenstatus einsehen
  • Artefakte speichern und lesen
  • Batchverarbeitung, Verkettung und wiederkehrende Zeitpläne steuern
  • Protokolle, Metriken, Warteschlangen und Laufzeitstatus abfragen

So kann ein externes Produkt auf denselben Orchestrierungsstatus zugreifen, ohne zuvor WordPress zu starten, solange es dieselbe Datenbank und dieselben Tabellennamen verwendet.

Worker-Pools sind derzeit die einzige Ausnahme: Queuety::run_worker_pool() und Queuety::run_auto_scaling_worker_pool() lesen die Konstanten WordPress DB_HOST, DB_NAME, DB_USER und DB_PASSWORD statt der initialisierten Verbindung. Deshalb muss ein eigenständiger Prozess diese Konstanten definieren, bevor er einen Pool startet (#5).

Was innerhalb von WordPress bleibt

Die WordPress-spezifische Bridge-Schicht setzt weiterhin voraus, dass WordPress geladen ist.

Dazu gehören:

  • Plugin-Bootstrap und Aktivierungsverhalten in queuety.php
  • Queuety::on_action(), wofür add_action() erforderlich ist
  • Queuety::replace_wp_cron() und Queuety::restore_wp_cron(), die auf WordPress cron-Filter und do_action() angewiesen sind
  • der echte Registrierungsweg des wp queuety ...-Befehls, der voraussetzt, dass WP-CLI WordPress lädt

Diese Komponenten sind Adapter für die Laufzeitumgebung des Kerns. Sie sind nicht die Laufzeitumgebung selbst.

Initialisierung

Der eigenständige Pfad ist bewusst schlank gehalten. Öffne eine datenbankgestützte Connection, initialisiere die Fassade und stelle sicher, dass das Schema vorhanden ist.

PHP
use Queuety\Connection;
use Queuety\Queuety;

$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
);

Queuety::init( $conn );
Queuety::ensure_schema();

Danach ist die normale Laufzeit-API verfügbar:

PHP
Queuety::dispatch( 'send_email', [ 'to' => 'user@example.com' ] );

$workflow_id = Queuety::workflow( 'report' )
    ->then( FetchReportData::class )
    ->then( RenderReport::class )
    ->dispatch( [ 'report_id' => 42 ] );

$machine_id = Queuety::machine( 'agent_session' )
    ->state( 'awaiting_input' )
    ->on( 'message', 'planning' )
    ->state( 'planning' )
    ->action( PlanSessionAction::class )
    ->dispatch();

Tabellennamen

Für die eigenständige Nutzung sind keine spezifischen Tabellennamen von WordPress erforderlich. Du brauchst lediglich eine konsistente Präfixstrategie.

Wenn du Queuety auf eine WordPress-Datenbank verweist, verwende dasselbe Präfix wie das Plugin. Wenn du Queuety in einer separaten Datenbank verwendest, kann das Verbindungspräfix dem entsprechen, was deine Host-Anwendung erwartet. Der Queuety-spezifische Tabellenanteil wird weiterhin durch QUEUETY_TABLE_PREFIX und die Überschreibungen pro Tabelle gesteuert.

Eingebettete Laufzeitumgebungen, die eine Datenbank gemeinsam nutzen, können diesen Queuety-spezifischen Anteil pro Verbindung festlegen:

PHP
$conn = new Connection(
    host: '127.0.0.1:3306',
    dbname: 'wordpress',
    user: 'root',
    password: 'secret',
    prefix: 'wp_',
    table_prefix: 'themequeue_',
);

Dadurch bleibt das Datenbankpräfix von WordPress unverändert, während Tabellen wie queuety_jobs in wp_themequeue_jobs aufgelöst werden.

Denkmodell

Die Aufteilung lässt sich am besten so verstehen:

  • Queuety-Kern = Warteschlange, Worker, Workflows, State Machines, Signale, Artefakte und Laufzeitmetadaten
  • WordPress-Adapter = Plugin-Bootstrap, Hook-Bridges, WP-Cron-Ersatz und WP-CLI-Registrierung

So bleibt eine einzige Orchestrierungs-Engine erhalten, während die ereignis- und anfragebezogene Integration für WordPress dort bleibt, wo sie hingehört.