Preskoči na vsebino
Prikaži kot Markdown Uredi na GitHub Dokumentacija za 2cc7b2b

Poteki dela v eni datoteki

Potek dela je lahko v celoti samostojen v eni datoteki PHP. Razrede korakov in gradnik določite skupaj, datoteko shranite v mapo in to mapo naložite z Queuety::load_workflows() (prikazano spodaj). Queuety sam ne pregleduje nobene mape.

PHP
// workflows/onboard-user.php
use Queuety\Queuety;

class CreateAccount implements \Queuety\Step {
    public function handle(array $state): array {
        $user = create_user($state['email']);
        return ['user_id' => $user->id, 'user_name' => $user->name];
    }
    public function config(): array {
        return ['max_attempts' => 3];
    }
}

class SendWelcome implements \Queuety\Step {
    public function handle(array $state): array {
        wp_mail($state['email'], 'Welcome ' . $state['user_name'], '...');
        return ['welcomed' => true];
    }
    public function config(): array {
        return [];
    }
}

return Queuety::define_workflow('onboard_user')
    ->then(CreateAccount::class, 'create_account')
    ->then(SendWelcome::class, 'send_welcome');

Datoteka vrne WorkflowBuilder. Vsak razred koraka je določen v vrstici. Ko je datoteka naložena, postanejo razredi na voljo, potek dela pa je registriran kot predloga.

Nalaganje potekov dela

Naložite vse datoteke potekov dela iz mape:

PHP
// Load all .php files from the workflows directory
$count = Queuety::load_workflows(__DIR__ . '/workflows/');

Ali naložite eno datoteko:

PHP
$template = Queuety::load_workflow_file(__DIR__ . '/workflows/onboard-user.php');

Nato razpošljite po imenu:

PHP
$workflow_id = Queuety::run_workflow('onboard_user', ['email' => 'user@example.com']);

Rekurzivno nalaganje

Kot drugi argument podajte true, da pregledate podmape:

PHP
Queuety::load_workflows(__DIR__ . '/workflows/', recursive: true);

Tako lahko poteke dela organizirate v mape:

Koda
workflows/
├── onboarding/
│   ├── new-user.php
│   └── trial-upgrade.php
├── reports/
│   ├── daily-summary.php
│   └── weekly-digest.php
└── notifications/
    └── digest-email.php

Uporaba vseh funkcij potekov dela

Poteki dela v datotekah podpirajo vse, kar podpira gradnik, razen idempotency_key(), ki ni shranjen v predlogi; namesto tega ga posredujte pri vsakem razpošiljanju z Queuety::run_workflow( $name, $payload, [ 'idempotency_key' => '...' ] ). Zakasnitve, signali, vzporedni koraki, pogojno razvejanje, izvajanje drugih potekov dela, obravnavalniki preklica in obrezovanje stanja delujejo:

PHP
// workflows/approval-flow.php
use Queuety\Queuety;

class SubmitRequest implements \Queuety\Step {
    public function handle(array $state): array {
        return ['submitted_at' => date('Y-m-d H:i:s')];
    }
    public function config(): array { return []; }
}

class ProcessApproval implements \Queuety\Step {
    public function handle(array $state): array {
        return [
            'approved_by' => $state['approved_by'],
            'processed' => true,
        ];
    }
    public function config(): array { return []; }
}

class CleanupRequest implements \Queuety\Handler {
    public function handle(array $payload): void {
        delete_pending_request($payload['request_id']);
    }
    public function config(): array { return []; }
}

return Queuety::define_workflow('approval_flow')
    ->then(SubmitRequest::class)
    ->delay(hours: 24)
    ->wait_for_signal('approved')
    ->then(ProcessApproval::class)
    ->on_cancel(CleanupRequest::class)
    ->prune_state_after(2);

Kdaj uporabiti poteke dela v datotekah

Poteki dela v datotekah so idealni, kadar:

  • Poteke dela programsko ustvari LLM ali generator kode
  • Je potek dela dovolj preprost, da se prilega v eno datoteko
  • Želite ohraniti logiko korakov blizu definicije poteka dela
  • Izdelujete prototip in želite hitro ponavljati razvojne cikle

Pri večjih potekih dela s skupnimi razredi korakov, kompleksno vmesno programsko opremo ali koraki, ki se ponovno uporabljajo v več potekih dela, je bolj vzdrževan običajen pristop z ločenimi datotekami razredov in samodejnim nalaganjem PSR-4.

Kako deluje

V ozadju delovni tokovi datotek uporabljajo povsem isti mehanizem kot graditelj API. Vsak korak je ločeno opravilo v podatkovni zbirki. Stanje se prenaša prek tabele queuety_workflows. Ni ponovnega predvajanja, zahteve po determinističnosti ali razlike v zmogljivosti.

Vsak klic load requirea datoteko (ne require_once), zato vsako datoteko naložite enkrat na zahtevo; če jo naložite dvakrat, se njeni razredi ponovno deklarirajo in pride do napake. Vrnjeni WorkflowBuilder se pretvori v WorkflowTemplate in shrani v WorkflowRegistry. Odprema in izvajanje sta enaka kot pri katerem koli drugem delovnem toku.