Önálló használat

A Queuety WordPress bővítményként van csomagolva, de a futtatókörnyezet nagy részéhez nincs szükség aktív WordPress kérésre.

A várólista, a munkafolyamat-motor, az állapotgépek, a jelzések, az artefaktumok, a kötegelés, az ütemezés, a naplózás, a metrikák és az erőforrás-kezelés mind ugyanazon MySQL táblákon futnak. Ha egy másik PHP folyamat hozzáfér az adatbázishoz, közvetlenül használhatja ezt a magot.

Ez jelenti az önálló használat határát a Queuety esetében. Az adatbázis-alapú vezénylőmotor WordPress környezetén kívül is használható. A WordPress hidak továbbra is a WordPress környezetéhez tartoznak.

Mi működik WordPress környezetén kívül

Közvetlen Connection használatával egy önálló folyamat inicializálhatja a Queuety értéket, és ugyanazokat a felületi metódusokat használhatja a központi futtatókörnyezethez, mint a bővítmény:

• feladatok indítása
• workerek és workerpoolok futtatása
• munkafolyamatok összeállítása és indítása
• jelzések, jóváhagyások és munkafolyamat-bemenet küldése
• állapotgépek összeállítása és indítása
• munkafolyamat- és gépállapot vizsgálata
• artefaktumok tárolása és beolvasása
• kötegelés, láncolás és ismétlődő ütemezések működtetése
• naplók, metrikák, várólisták és futásidejű állapot lekérdezése

Ez azt jelenti, hogy egy külső termék hozzáférhet ugyanahhoz a vezénylési állapothoz anélkül, hogy előbb elindítaná a WordPress értéket, feltéve, hogy ugyanazt az adatbázist és táblaneveket használja.

A workerpoolok jelenleg kivételt képeznek: a Queuety::run_worker_pool() és a Queuety::run_auto_scaling_worker_pool() az inicializált kapcsolat helyett a WordPress DB_HOST, DB_NAME, DB_USER és DB_PASSWORD konstansokat olvassa, ezért egy önálló folyamatnak a pool indítása előtt definiálnia kell ezeket a konstansokat (#5).

Mi marad WordPress környezetén belül

A WordPress-specifikus hídréteg továbbra is attól függ, hogy a WordPress betöltődött-e.

Ide tartozik:

• a bővítmény inicializálása és aktiválási működése a queuety.php környezetében
• a Queuety::on_action(), amelyhez szükség van a add_action() értékre
• a Queuety::replace_wp_cron() és a Queuety::restore_wp_cron(), amelyek a WordPress cron szűrőitől és a do_action() értéktől függenek
• a tényleges wp queuety ... parancsregisztrációs útvonal, amely attól függ, hogy a WP-CLI betölti-e a WordPress értéket

Ezek a részek a központi futtatókörnyezet köré épülő adapterek. Nem maga a futtatókörnyezet.

Inicializálás

Az önálló útvonal szándékosan egyszerű. Nyisson meg egy adatbázis-alapú Connection példányt, inicializálja a felületi réteget, és gondoskodjon róla, hogy a séma rendelkezésre álljon.

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

Ezután elérhetővé válik a szokásos futásidejű API:

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

Táblanévadás

Az önálló használathoz nem szükséges kifejezetten WordPress-táblaneveket használni. Csak stabil előtagolási stratégiára van szükség.

Ha a Queuety példányt WordPress adatbázisra állítja, használja ugyanazt az előtagot, mint a bővítmény. Ha a Queuety értéket külön adatbázisban használja, a kapcsolat előtagja a gazdaalkalmazás elvárásai szerint tetszőleges lehet. A Queuety-specifikus táblarészt továbbra is a QUEUETY_TABLE_PREFIX és a táblánkénti felülbírálások határozzák meg.

Az egy adatbázist megosztó beágyazott futtatókörnyezetek kapcsolatonként állíthatják be ezt a Queuety-specifikus részt:

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

Így az WordPress adatbázis-előtagja érintetlen marad, és az olyan táblák, mint a queuety_jobs, a következőre oldódnak fel: wp_themequeue_jobs.

Mentális modell

A felosztást így érdemes elképzelni:

• Queuety core = sor, workerek, munkafolyamatok, állapotgépek, jelek, artefaktumok és futásidejű metaadatok
• WordPress adapter = bővítményindítás, hookhidak, WP-Cron-csere és WP-CLI-regisztráció

Így megmarad egyetlen vezérlőmotor, miközben az WordPress-specifikus esemény- és kérésintegráció a megfelelő helyen marad.