Użycie samodzielne

Queuety jest dostarczany jako wtyczka WordPress, ale większość środowiska uruchomieniowego nie potrzebuje aktywnego żądania WordPress.

Kolejka, silnik przepływów pracy, maszyny stanów, sygnały, artefakty, grupowanie zadań, planowanie, rejestrowanie, metryki i zarządzanie zasobami działają w oparciu o te same tabele MySQL. Jeśli inny proces PHP może otworzyć tę samą bazę danych, może korzystać bezpośrednio z tego rdzenia.

To właśnie granica użycia samodzielnego w Queuety. Silnik orkiestracji oparty na bazie danych działa poza WordPress. Mostki WordPress nadal należą do WordPress.

Co działa poza WordPress

Przy bezpośrednim połączeniu Connection samodzielny proces może zainicjować Queuety i używać tych samych metod fasady co wtyczka w podstawowym środowisku uruchomieniowym:

• uruchamiać zadania
• uruchamiać workery i pule workerów
• tworzyć i uruchamiać przepływy pracy
• wysyłać sygnały, zatwierdzenia i dane wejściowe do przepływu pracy
• tworzyć i uruchamiać maszyny stanów
• sprawdzać stan przepływów pracy i maszyn stanów
• zapisywać i odczytywać artefakty
• obsługiwać grupowanie zadań, łańcuchy i harmonogramy cykliczne
• odpytywać logi, metryki, kolejki i stan środowiska uruchomieniowego

Dzięki temu zewnętrzny produkt może komunikować się z tym samym stanem orkiestracji bez wcześniejszego uruchamiania WordPress, o ile korzysta z tej samej bazy danych i nazw tabel.

Obecnie jedynym wyjątkiem są pule workerów: Queuety::run_worker_pool() i Queuety::run_auto_scaling_worker_pool() odczytują stałe WordPress DB_HOST, DB_NAME, DB_USER i DB_PASSWORD zamiast zainicjowanego połączenia, więc samodzielny proces musi zdefiniować te stałe przed uruchomieniem puli (#5).

Co pozostaje w WordPress

Warstwa mostków specyficzna dla WordPress nadal wymaga załadowania WordPress.

Obejmuje to:

• uruchamianie wtyczki i zachowanie podczas aktywacji w queuety.php
• Queuety::on_action(), który wymaga add_action()
• Queuety::replace_wp_cron() i Queuety::restore_wp_cron(), które zależą od filtrów WordPress cron oraz do_action()
• właściwą ścieżkę rejestracji polecenia wp queuety ..., która wymaga załadowania WordPress przez WP-CLI

Te elementy są adapterami otaczającymi podstawowe środowisko uruchomieniowe. Nie stanowią samego środowiska.

Inicjalizacja

Ścieżka samodzielna jest celowo prosta. Otwórz połączenie Connection oparte na bazie danych, zainicjuj fasadę i upewnij się, że schemat istnieje.

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

Następnie dostępny jest zwykły API środowiska uruchomieniowego:

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

Nazewnictwo tabel

Do samodzielnego użycia nie są potrzebne konkretne nazwy tabel WordPress. Wystarczy stabilna strategia stosowania prefiksów.

Jeśli połączysz Queuety z bazą danych WordPress, użyj tego samego prefiksu co wtyczka. Jeśli używasz Queuety w osobnej bazie danych, prefiks połączenia może być zgodny z oczekiwaniami aplikacji hostującej. Część nazw tabel specyficzna dla Queuety jest nadal kontrolowana przez QUEUETY_TABLE_PREFIX i nadpisania dla poszczególnych tabel.

Środowiska uruchomieniowe osadzone we wspólnej bazie danych mogą ustawić tę część specyficzną dla Queuety osobno dla każdego połączenia:

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

Dzięki temu prefiks bazy danych WordPress pozostaje bez zmian, a tabele takie jak queuety_jobs są mapowane na wp_themequeue_jobs.

Model myślowy

Najprościej rozumieć ten podział tak:

• rdzeń Queuety = kolejka, workery, przepływy pracy, maszyny stanów, sygnały, artefakty i metadane środowiska uruchomieniowego
• adapter WordPress = uruchamianie wtyczki, mostki hooków, zastępowanie WP-Cron i rejestracja WP-CLI

Dzięki temu jeden silnik orkiestracji obsługuje wszystkie zadania, a integracja zdarzeń i żądań specyficzna dla WordPress pozostaje na swoim miejscu.