Przepływy pracy w pojedynczym pliku

Przepływ pracy może być w pełni samodzielny i zapisany w jednym pliku PHP. Zdefiniuj klasy kroków i konstruktor razem, umieść plik w katalogu i wczytaj ten katalog za pomocą Queuety::load_workflows() (jak pokazano poniżej). Queuety samodzielnie nie skanuje żadnych katalogów.

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

Plik zwraca WorkflowBuilder. Każda klasa kroku jest zdefiniowana bezpośrednio w pliku. Po jego wczytaniu klasy stają się dostępne, a przepływ pracy zostaje zarejestrowany jako szablon.

Wczytywanie przepływów pracy

Wczytaj wszystkie pliki przepływów pracy z katalogu:

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

Możesz też wczytać pojedynczy plik:

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

Następnie uruchom przepływ według nazwy:

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

Rekurencyjne wczytywanie

Przekaż true jako drugi argument, aby skanować podkatalogi:

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

Pozwala to organizować przepływy pracy w folderach:

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

Korzystanie ze wszystkich funkcji przepływu pracy

Przepływy pracy w plikach obsługują wszystkie funkcje konstruktora poza idempotency_key(), które nie jest przechowywane w szablonie; przekaż je przy uruchomieniu za pomocą Queuety::run_workflow( $name, $payload, [ 'idempotency_key' => '...' ] ). Działają opóźnienia, sygnały, kroki równoległe, rozgałęzianie warunkowe, uruchamianie przepływów pracy, procedury obsługi anulowania i przycinanie stanu:

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

Kiedy używać przepływów pracy w plikach

Przepływy pracy w plikach są idealne, gdy:

• LLM lub generator kodu tworzy przepływy pracy programowo
• Przepływ pracy jest na tyle prosty, że mieści się w jednym pliku
• Chcesz umieścić logikę kroków blisko definicji przepływu pracy
• Tworzysz prototyp i zależy Ci na szybkiej iteracji

W przypadku większych przepływów pracy ze współdzielonymi klasami kroków, złożonym oprogramowaniem pośredniczącym lub krokami używanymi w wielu przepływach bardziej łatwe w utrzymaniu jest standardowe podejście z osobnymi plikami klas i automatycznym ładowaniem PSR-4.

Jak to działa

Pod maską przepływy pracy z plikami korzystają z dokładnie tego samego silnika co kreator API. Każdy krok to osobne zadanie w bazie danych. Stan jest przekazywany przez tabelę queuety_workflows. Nie ma ponownego odtwarzania, wymogu deterministyczności ani różnicy w wydajności.

Każde wywołanie load require plik (a nie require_once), więc wczytuj każdy plik raz na żądanie; ponowne wczytanie go powoduje ponowną deklarację jego klas i błąd. Zwrócone WorkflowBuilder jest konwertowane na WorkflowTemplate i zapisywane w WorkflowRegistry. Przekazywanie i wykonywanie przebiegają tak samo jak w każdym innym przepływie pracy.