# Erilliskäyttö

Queuety on paketoitu WordPress-lisäosaksi, mutta suurin osa ajonaikaisesta ympäristöstä ei varsinaisesti tarvitse aktiivista WordPress-pyyntöä.

Jono, työnkulkumoottori, tilakoneet, signaalit, artefaktit, eräajot, ajoitus, lokitus, mittarit ja resurssienhallinta toimivat kaikki samoja MySQL-tauluja vasten. Jos toinen PHP-prosessi voi avata saman tietokannan, se voi käyttää ydintä suoraan.

Tämä on ratkaisun Queuety erilliskäytön raja. Tietokantapohjaista orkestrointimoottoria voi käyttää WordPress-ympäristön ulkopuolella. WordPress-sillat kuuluvat edelleen WordPress-ympäristöön.

## Mitä toimii WordPress-ympäristön ulkopuolella

Suoralla `Connection`-yhteydellä erillinen prosessi voi alustaa Queuety-ratkaisun ja käyttää samoja julkisivumetodeja kuin lisäosa ydinaikaisessa ympäristössä:

- lähetä töitä
- suorita työntekijöitä ja työntekijäpooleja
- rakenna ja lähetä työnkulkuja
- lähetä signaaleja, hyväksyntöjä ja työnkulun syötteitä
- rakenna ja lähetä tilakoneita
- tarkastele työnkulkujen ja koneiden tilaa
- tallenna ja lue artefakteja
- hallitse eräajoja, ketjutusta ja toistuvia aikatauluja
- hae lokeja, mittareita, jonoja ja ajonaikaisen ympäristön tilaa

Ulkoinen tuote voi siis käyttää samaa orkestrointitilaa käynnistämättä ensin WordPress-ratkaisua, kunhan se käyttää samaa tietokantaa ja taulujen nimiä.

Työntekijäpoolit ovat tällä hetkellä ainoa poikkeus: `Queuety::run_worker_pool()` ja `Queuety::run_auto_scaling_worker_pool()` lukevat WordPress-määrityksen `DB_HOST`-, `DB_NAME`-, `DB_USER`- ja `DB_PASSWORD`-vakiot alustetun yhteyden sijaan, joten erillisen prosessin on määritettävä nämä vakiot ennen poolin käynnistämistä ([#5](https://github.com/inline0/queuety/issues/5)).

## Mikä pysyy WordPress-ympäristössä

WordPress-kohtainen siltakerros edellyttää edelleen, että WordPress on ladattu.

Tähän kuuluvat:

- lisäosan käynnistys ja aktivointikäyttäytyminen ympäristössä `queuety.php`
- `Queuety::on_action()`, joka edellyttää `add_action()`
- `Queuety::replace_wp_cron()` ja `Queuety::restore_wp_cron()`, jotka ovat riippuvaisia WordPress-cron-suodattimista ja `do_action()`-toiminnosta
- varsinainen `wp queuety ...`-komennon rekisteröintipolku, joka on riippuvainen WP-CLI-ratkaisun WordPress-latauksesta

Nämä osat ovat sovittimia ydinaikaisen ympäristön ympärillä. Ne eivät itsessään ole ajonaikainen ympäristö.

## Alustus

Erilliskäytön polku on tarkoituksella suppea. Avaa tietokantapohjainen `Connection`, alusta julkisivu ja varmista, että skeema on olemassa.

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

Tämän jälkeen tavallinen ajonaikainen API on käytettävissä:

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

## Taulujen nimeäminen

Erilliskäyttö ei edellytä erityisesti WordPress-taulujen nimiä. Tarvitaan vain vakaa etuliitestrategia.

Jos osoitat Queuety-ratkaisun WordPress-tietokantaan, käytä samaa etuliitettä kuin lisäosa käyttää siellä. Jos käytät Queuety-ratkaisua erillisessä tietokannassa, yhteyden etuliite voi olla mikä tahansa isäntäsovelluksen odottama arvo. Queuety-kohtaiset taulujen osat määräytyvät edelleen `QUEUETY_TABLE_PREFIX`-asetuksen ja taulukohtaisten ohitusten perusteella.

Samaan tietokantaan yhteyttä käyttävät upotetut ajonaikaiset ympäristöt voivat määrittää kyseisen Queuety-kohtaisen osan yhteyskohtaisesti:

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

Näin WordPress-tietokannan etuliite säilyy ennallaan, ja taulut, kuten `queuety_jobs`, saavat nimekseen `wp_themequeue_jobs`.

## Ajattelumalli

Selkein tapa hahmottaa jako on tämä:

- Queuety-ydin = jono, työntekijät, työnkulut, tilakoneet, signaalit, artefaktit ja ajonaikaisen ympäristön metatiedot
- WordPress-sovitin = lisäosan käynnistys, hook-sillat, WP-Cron-korvaus ja WP-CLI-rekisteröinti

Näin käytössä pysyy yksi orkestrointimoottori, ja WordPress-kohtainen tapahtuma- ja pyyntöintegraatio jää sille kuuluvaan paikkaan.