Работни потоци в един файл

Работният поток може да бъде напълно самостоятелен в един файл PHP. Дефинирайте класовете на стъпките и билдъра заедно, поставете файла в директория и заредете тази директория с Queuety::load_workflows() (показано по-долу). Queuety не сканира самостоятелно нито една директория.

// 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');

Файлът връща WorkflowBuilder. Всеки клас за стъпка е дефиниран в самия файл. При зареждането му класовете стават достъпни и работният поток се регистрира като шаблон.

Зареждане на работни потоци

Заредете всички файлове с работни потоци от директория:

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

Или заредете един файл:

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

След това стартирайте по име:

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

Рекурсивно зареждане

Предайте true като втори аргумент, за да сканирате поддиректориите:

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

Това ви позволява да организирате работните потоци в папки:

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

Използване на всички функции на работните потоци

Работните потоци във файлове поддържат всичко, което поддържа билдърът, с изключение на idempotency_key(), което не се съхранява в шаблона; вместо това го предавайте при всяко стартиране чрез Queuety::run_workflow( $name, $payload, [ 'idempotency_key' => '...' ] ). Забавянията, сигналите, паралелните стъпки, условното разклоняване, изпълнението на работни потоци, обработчиците за отмяна и съкращаването на състоянието работят:

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

Кога да използвате работни потоци във файлове

Работните потоци във файлове са идеални, когато:

• LLM или генератор на код създава работни потоци програмно
• Работният поток е достатъчно прост, за да се побере в един файл
• Искате логиката на стъпките да остане близо до дефиницията на работния поток
• Правите прототип и искате да повтаряте промените бързо

При по-големи работни потоци със споделени класове за стъпки, сложен междинен софтуер или стъпки, използвани повторно в няколко работни потока, по-лесно за поддръжка е стандартният подход с отделни файлове за класовете и автоматично зареждане чрез PSR-4.

Как работи

Под капака работните потоци във файлове използват същия механизъм като билдъра API. Всяка стъпка е отделна задача в базата данни. Състоянието се предава чрез таблицата queuety_workflows. Няма повторно изпълнение, изискване за детерминизъм или разлика в производителността.

Всяко извикване за зареждане requireва файла (не require_once), затова зареждайте всеки файл само веднъж на заявка; повторното му зареждане декларира класовете отново и води до грешка. Върнатият WorkflowBuilder се преобразува в WorkflowTemplate и се съхранява в WorkflowRegistry. Стартирането и изпълнението са идентични с тези на всеки друг работен поток.