Introduction

Durable Workflow 2.0 conserve l’état et l’historique des workflows en dehors des processus applicatifs de courte durée. Les workers PHP, Python et Rust peuvent ainsi reprendre leur travail après un redémarrage. Pour une première visite, commencez par le démarrage rapide : vous obtiendrez un workflow completed avant de consulter l’index des fonctionnalités.

Choisir un modèle de déploiement

Mode service

Les applications utilisent un runtime durable distant à travers les SDK officiels. Choisissez qui l’exploite :

• Durable Workflow Cloud est l’option gérée. Durable Workflow exploite l’orchestration, le stockage persistant et Managed Waterline. Votre équipe exécute les clients SDK et les workers dans l’espace de noms provisionné. Les utilisateurs de Cloud n’installent pas Server et n’exécutent pas un service Waterline séparé.
• Server auto-hébergé offre la même frontière de service. Votre équipe déploie, sécurise, dimensionne, sauvegarde et met à jour le runtime. Vous pouvez déployer Waterline séparément pour observer l’espace de noms géré par Server.

Les deux options exposent le même plan de contrôle HTTP+JSON versionné, le même protocole worker, le même modèle d’espaces de noms et une enveloppe de données indépendante du langage. Les modes de déploiement précisent les responsabilités de chacun.

Mode intégré à Laravel

Le mode intégré convient à une application Laravel qui souhaite garder l’état des workflows, les files, la configuration et les outils d’exploitation dans sa propre infrastructure. Elle installe durable-workflow/workflow, sans connexion à Cloud ni Server séparé. Le package Waterline intégré lit directement l’état géré par cette application.

Commencez par l’installation intégrée si vous souhaitez que votre application possède et exploite le runtime.

Les équipes Laravel qui passent de la version stable v1 à v2, ou qui réévaluent leur déploiement intégré 2.0, peuvent comparer les parcours exécutables intégré et PHP SDK dans le guide d’adoption Laravel et de transition du runtime avant de modifier le trafic.

Choisir un SDK pour le mode service

• SDK PHP : installez durable-workflow/sdk dans une application PHP indépendante du framework ou dans un worker distant.
• SDK Python : définissez des workflows et des activités déterministes et utilisez le client asynchrone du plan de contrôle. La version stable du SDK Python figure dans le même manifeste de versions stables que le démarrage rapide de Server.
• SDK Rust : définissez des workflows et des activités déterministes et exécutez des services workers natifs.

Les trois sont des implémentations officielles de la même frontière de service publique. Le guide des fonctionnalités des clients et workers précise les fonctions prises en charge et les différences intentionnelles.

Terminer un premier workflow

Le démarrage rapide indique dès le début l’objectif, le choix du runtime, les prérequis, la durée et le résultat attendu. PHP, Python et Rust disposent chacun d’un parcours exécutable. Un seul langage est affiché à la fois.

Le parcours local auto-hébergé utilise des packages et des images publiés, sans récupérer le code source du produit. Le parcours Cloud utilise les informations de connexion d’un espace de noms géré, sans exécuter Server.

Les éléments du mode service

Un déploiement en mode service comporte trois éléments :

• Le runtime gère l’état durable, l’enregistrement des commandes et de l’historique, l’appariement des tâches, les temporisateurs, les planifications, les espaces de noms et les protocoles authentifiés. Cloud l’exploite pour les espaces de noms gérés. Votre équipe l’exploite en auto-hébergement.
• Les workers applicatifs exécutent le code des workflows et des activités avec les SDK PHP, Python ou Rust. Ils peuvent être déployés avec l’application ou comme services indépendants, et dimensionnés séparément du runtime.
• Les clients et outils d’exploitation démarrent, inspectent et commandent le même état géré par le runtime, avec les clients SDK, la CLI dw, les API HTTP, les schémas lisibles par machine, Waterline et les interfaces pour agents.

Un contrat public d’exécution durable

Les SDK officiels partagent des noms de types de workflows et d’activités enregistrés sous forme de chaînes, ainsi qu’une enveloppe publique pour les données. Cette enveloppe identifie son codec et transporte des valeurs utilisables entre langages, sans dépendre de la sérialisation PHP, du pickle Python ou des types internes de Rust.

Les workers de workflows reconstruisent leurs décisions à partir des commandes durables et de l’historique. Les entrées et résultats des activités et des workflows enfants peuvent passer d’un langage à l’autre lorsque les workers annoncent le même codec public et enregistrent les mêmes noms de types. Consultez l’index des fonctionnalités et les informations de découverte du runtime avant de dépendre d’une fonction particulière d’un SDK.

Utiliser les exemples adaptés

• Mode service et plusieurs langages : utilisez le démarrage rapide et le guide du SDK PHP, Python ou Rust.
• Mode intégré à Laravel : explorez les modèles de workflows Laravel et les observations Waterline dans la Sample App.

La galerie intégrée est destinée aux applications Laravel. Pour Cloud ou Server en mode service, commencez par les guides du mode service.

Un contrat utilisable par les agents

Les opérateurs humains et les agents autonomes utilisent le même contrat lisible par machine. Le parcours testable est Découvrir → Modifier → Exécuter → Diagnostiquer → Réparer : manifestes de versions et de fonctionnalités, commandes explicites, résultats structurés, historique typé, diagnostics des workers et des files, modifications sûres et vérification après modification. Consultez la boucle d’exploitation pour agents et le guide d’évaluation pour agents IA.

Avez-vous besoin d’un workflow ?

Un workflow est probablement adapté si :

• Le processus dure des minutes, des heures ou des jours.
• Vous attendez une approbation humaine.
• Vous attendez un webhook ou un événement externe.
• Vous devez suspendre le travail et le reprendre plus tard sans garder un processus actif.
• Vous devez reprendre après un arrêt brutal sans provoquer d’erreurs ni dupliquer le travail.

Pour « exécuter cinq jobs en file dans l’ordre et s’arrêter au premier échec », une chaîne de jobs convient généralement mieux. Durable Workflow convient lorsque l’étape suivante dépend d’un événement externe, d’une attente ou d’une décision impossible à connaître à l’avance.