ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

Step Functions (workflow déclaratif managé)

Décrire un workflow en JSON déclaratif (Amazon States Language) et laisser un service managé (AWS Step Functions, Google Cloud Workflows) exécuter, retenter, paralléliser. Le pattern de workflow sans infrastructure à maintenir.

Problème

Maintenir un cluster Temporal, un cluster Camunda ou un Airflow self-hosted impose une équipe ops dédiée : monitoring, upgrades, backup, scaling, sécurité. Pour des workflows EDI modérément complexes (10-30 étapes), l'overhead opérationnel excède la valeur. On voudrait définir le workflow simplement et laisser le runtime au cloud provider.

Forces

  • Maintenir un workflow engine a un coût : installation, monitoring, upgrades, scaling.
  • Les workflows EDI peuvent être nombreux mais simples : 10-30 étapes, sans logique sophistiquée.
  • L'intégration native cloud est appréciable : Lambda, S3, SQS, SNS s'enchaînent naturellement.
  • Le format déclaratif facilite l'audit : le JSON ASL se relit, se versionne, se diff.
  • La facturation à l'usage : pas de coût en l'absence de flux, scale horizontal géré.

Solution

AWS Step Functions définit un workflow en Amazon States Language (ASL), un sous-ensemble JSON typé. Chaque state est un Task (appel Lambda, ECS, etc.), Wait (timer), Choice (branchement), Parallel (exécution parallèle), Map (fan-out), Pass, Succeed, Fail. Le runtime AWS exécute, gère retries (avec policy déclarative), timeouts, persistance. Google Cloud Workflows offre l'équivalent avec un YAML similaire. Azure Logic Apps est un cousin avec UI visuelle.

Définition ASL JSON d'un workflow EDI :

{
  "StartAt": "ParseInvoice",
  "States": {
    "ParseInvoice": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:parse-invoice",
      "Next": "ValidateInvoice"
    },
    "ValidateInvoice": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:validate-invoice",
      "Retry": [{ "ErrorEquals": ["States.ALL"],
                  "IntervalSeconds": 2,
                  "MaxAttempts": 3,
                  "BackoffRate": 2.0 }],
      "Catch": [{ "ErrorEquals": ["ValidationError"],
                  "Next": "SendApErak" }],
      "Next": "RouteToErp"
    },
    "SendApErak": { "Type": "Task", ..., "End": true },
    "RouteToErp": { ..., "Next": "AwaitErpAck" },
    "AwaitErpAck": { "Type": "Wait", "Seconds": 3600,
                      "Next": "CheckAck" },
    "CheckAck": { "Type": "Choice", ... },
    ...
  }
}

Le runtime AWS Step Functions exécute ce JSON,
gère retries, timeout, parallélisme, parallel branches.

Implémentation EDI

Cas concret : workflow de traitement d'INVOIC entrant. Chaque étape est une Lambda : parse-invoice, validate-invoice, route-to-erp, await-erp-ack, archive-to-s3. Le JSON ASL définit l'enchaînement, les retries (3 tentatives backoff exponentiel), les catch d'erreurs (validation error → SendAperak → Notification). Le tout est versionné en GitOps. Le déploiement se fait via Terraform avec ressource aws_sfn_state_machine. Le coût : ~25¢ pour 1000 state transitions (Standard workflow) ou 1¢ pour 1000 transitions (Express workflow). Pour 100k factures/mois avec 10 transitions chacune, coût ~250$/mois en Standard. La console AWS Step Functions visualise chaque exécution avec timeline détaillée. Pour les workflows plus complexes (logique conditionnelle riche, code custom), Temporal reste préférable. Pour les workflows simples cloud-native, Step Functions est imbattable en TCO.

Anti-patterns

  • Workflow trop volumineux : ASL JSON de 5000 lignes pour un workflow avec 200 états → ingérable, illisible. Découper en sous-workflows.
  • Logique métier dans le workflow : ASL n'est pas un langage de programmation. Mettre la logique dans les Lambdas, garder le workflow purement orchestration.
  • Pas de versionning : modifier en console sans Git → audit impossible, rollback douloureux.
  • Coût Standard pour workflows courts : Standard facture chaque transition cher pour workflows < 5min. Pour ces cas, Express Workflows.
  • Lock-in cloud : ASL est propriétaire AWS, les Google Cloud Workflows et Azure Logic Apps ont des syntaxes différentes. Architecture cloud-agnostique difficile.
  • Pas de tests locaux : difficile de tester un workflow sans déployer. Utiliser Step Functions Local pour tester.

Patterns liés

Sources