Ga naar de inhoud

Zelfstandig gebruik

Bekijken als Markdown Bewerken op GitHub Documentatie op 2cc7b2b

Queuety is verpakt als een WordPress-plugin, maar voor het grootste deel van de runtime is geen actieve WordPress-aanvraag nodig.

De wachtrij, workflowengine, statusmachines, signalen, artefacten, batchverwerking, planning, logboekregistratie, statistieken en het resourcebeheer werken allemaal met dezelfde MySQL-tabellen. Als een ander PHP-proces dezelfde database kan openen, kan het die kern rechtstreeks gebruiken.

Dat is de grens voor zelfstandig gebruik in Queuety. De databasegestuurde orkestratie- engine kan buiten WordPress worden gebruikt. De WordPress-bruggen horen nog steeds bij WordPress.

Wat buiten WordPress werkt

Met een directe Connection-verbinding kan een zelfstandig proces Queuety initialiseren en dezelfde facademethoden gebruiken als de plugin voor de runtimekern:

  • taken versturen
  • workers en workerpools uitvoeren
  • workflows opbouwen en versturen
  • signalen, goedkeuringen en workflowinvoer verzenden
  • statusmachines opbouwen en uitvoeren
  • de status van workflows en statusmachines bekijken
  • artefacten opslaan en lezen
  • batchverwerking, ketenvorming en terugkerende planningen uitvoeren
  • logboeken, statistieken, wachtrijen en runtimestatus opvragen

Zo kan een extern product communiceren met dezelfde orkestratiestatus zonder WordPress eerst te starten, zolang het dezelfde database- en tabelnamen gebruikt.

Workerpools vormen voorlopig de enige uitzondering: Queuety::run_worker_pool() en Queuety::run_auto_scaling_worker_pool() lezen de constanten WordPress DB_HOST, DB_NAME, DB_USER en DB_PASSWORD in plaats van de geïnitialiseerde verbinding. Een zelfstandig proces moet die constanten daarom instellen voordat het een pool start (#5).

Wat binnen WordPress blijft

De bruggelaag die specifiek is voor WordPress is nog steeds afhankelijk van het laden van WordPress.

Dat omvat:

  • het bootstrap- en activeringsgedrag van de plugin in queuety.php
  • Queuety::on_action(), waarvoor add_action() nodig is
  • Queuety::replace_wp_cron() en Queuety::restore_wp_cron(), die afhankelijk zijn van de filters WordPress cron en do_action()
  • het daadwerkelijke registratiepad van de opdracht wp queuety ..., dat afhankelijk is van het laden van WP-CLI WordPress

Dit zijn adapters rond de runtimekern. Ze vormen niet de runtime zelf.

Initialisatie

Het zelfstandige pad is bewust klein gehouden. Open een DB-gestuurde Connection, initialiseer de facade en zorg dat het schema bestaat.

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();

Daarna is de normale runtime-API beschikbaar:

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();

Tabelnamen

Voor zelfstandig gebruik zijn WordPress-tabelnamen niet specifiek nodig. Er is alleen een stabiele prefixstrategie nodig.

Als u Queuety naar een WordPress-database laat verwijzen, gebruik dan dezelfde prefix als de plugin daar gebruikt. Als u Queuety in een aparte database gebruikt, kan de verbindingsprefix zijn wat uw hostapplicatie verwacht. Het Queuety-specifieke tabelgedeelte wordt nog steeds bepaald door QUEUETY_TABLE_PREFIX en de overschrijvingen per tabel.

Ingebedde runtimes die één database delen, kunnen dat Queuety-specifieke gedeelte per verbinding instellen:

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

Zo blijft de databaseprefix van WordPress intact en worden tabellen zoals queuety_jobs omgezet naar wp_themequeue_jobs.

Mentaal model

De eenvoudigste manier om over deze verdeling na te denken is:

  • Queuety-kern = wachtrij, workers, workflows, toestandsmachines, signalen, artefacten en runtimemetagegevens
  • WordPress-adapter = plugin-bootstrap, hookbruggen, vervanging van WP-Cron en registratie van WP-CLI

Zo blijft er één orkestratie-engine, terwijl de WordPress-specifieke gebeurtenis- en verzoekintegratie op de juiste plek blijft.