Uso autonomo

Queuety è distribuito come plugin WordPress, ma la maggior parte dell'ambiente di esecuzione non ha effettivamente bisogno di una richiesta WordPress attiva.

La coda, il motore dei workflow, le macchine a stati, i segnali, gli artefatti, l'elaborazione in batch, la pianificazione, la registrazione dei log, le metriche e la gestione delle risorse usano tutte le stesse tabelle MySQL. Se un altro processo PHP può aprire lo stesso database, può usare direttamente quel nucleo.

Questo è il confine dell'uso autonomo in Queuety. Il motore di orchestrazione basato su database è utilizzabile al di fuori di WordPress. I bridge WordPress restano invece parte di WordPress.

Cosa funziona al di fuori di WordPress

Con un Connection diretto, un processo autonomo può inizializzare Queuety e usare gli stessi metodi facade impiegati dal plugin per il runtime principale:

• inviare processi
• eseguire worker e pool di worker
• creare e inviare workflow
• inviare segnali, approvazioni e input ai workflow
• creare e inviare macchine a stati
• esaminare lo stato di workflow e macchine
• archiviare e leggere artefatti
• gestire elaborazioni in batch, concatenamenti e pianificazioni ricorrenti
• interrogare log, metriche, code e stato di esecuzione

Questo significa che un prodotto esterno può accedere allo stesso stato di orchestrazione senza avviare prima WordPress, purché usi lo stesso database e gli stessi nomi delle tabelle.

Al momento, i pool di worker sono l'unica eccezione: Queuety::run_worker_pool() e Queuety::run_auto_scaling_worker_pool() leggono le costanti WordPress DB_HOST, DB_NAME, DB_USER e DB_PASSWORD invece della connessione inizializzata, quindi un processo autonomo deve definire tali costanti prima di avviare un pool (#5).

Cosa resta all'interno di WordPress

Il livello bridge specifico di WordPress dipende ancora dal caricamento di WordPress.

Include:

• bootstrap del plugin e comportamento di attivazione in queuety.php
• Queuety::on_action(), che richiede add_action()
• Queuety::replace_wp_cron() e Queuety::restore_wp_cron(), che dipendono dai filtri e dagli hook di WordPress cron do_action()
• il percorso effettivo di registrazione dei comandi wp queuety ..., che dipende dal caricamento di WP-CLI WordPress

Questi componenti sono adattatori attorno al runtime principale. Non costituiscono il runtime stesso.

Inizializzazione

Il percorso autonomo è volutamente essenziale. Aprite un Connection basato su DB, inizializzate la facade e verificate che lo schema esista.

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

Dopodiché, il normale API runtime è disponibile:

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

Denominazione delle tabelle

L'uso autonomo non richiede specificamente nomi di tabelle WordPress. Serve solo una strategia di prefissi stabile.

Se configurate Queuety su un database WordPress, usate lo stesso prefisso utilizzato lì dal plugin. Se usate Queuety in un database separato, il prefisso della connessione può essere quello previsto dall'applicazione host. La parte dei nomi delle tabelle specifica di Queuety è comunque controllata da QUEUETY_TABLE_PREFIX e dalle sovrascritture per singola tabella.

I runtime incorporati che condividono un database possono impostare quella parte specifica di Queuety per connessione:

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

In questo modo il prefisso del database WordPress resta invariato e le tabelle, come queuety_jobs, vengono risolte in wp_themequeue_jobs.

Modello mentale

Per comprendere chiaramente la suddivisione:

• Core di Queuety = coda, worker, workflow, macchine a stati, segnali, artefatti e metadati runtime
• Adapter di WordPress = avvio del plugin, bridge degli hook, sostituzione di WP-Cron e registrazione di WP-CLI

Così si mantiene un unico motore di orchestrazione, lasciando l'integrazione di eventi e richieste specifica di WordPress al suo posto.