---
title: "Workflow-Orchestrierung: State, Retries und Recovery"
description: "Workflow-Orchestrierung koordiniert mehrstufige Arbeit über Systeme, Menschen und KI mit State, Policy, Observability und Recovery."
canonical: "https://zephior.com/de/glossary/workflow-orchestration"
last-updated: 2026-07-28
---

# Workflow-Orchestrierung: State, Retries und Recovery

> Workflow-Orchestrierung koordiniert mehrstufige Arbeit über Systeme, Menschen und KI mit State, Policy, Observability und Recovery.

Von [Tony Kim](https://zephior.com/de/authors/tony-kim). Published 2026-07-28; updated 2026-07-28. 4 minute read.

## Definition

Workflow-Orchestrierung koordiniert eine Sequenz oder einen Graph von Tasks über Systeme und Akteure und bewahrt Execution State. Sie steuert Start, Wait, Retry, Branch, Approval, Failure Handling und Completion.

## Problem

Eine Kette erfolgreicher API Calls ist kein belastbarer Business Process. Services timeouten, Messages kommen doppelt, Menschen antworten Tage später und Partial Writes erzeugen Konflikte. KI-Schritte bringen probabilistischen Output. Ohne Durable Orchestration beruht Recovery auf Logs und Raten.

## Perspektive

Orchestration macht Business State explizit. Modellieren Sie Transitionen, machen Sie External Writes idempotent, trennen Sie Technical Retry von Business Exception und bewahren Sie einen verständlichen Record bis zum reconciliierten Outcome.

## Integration bewegt Daten, Orchestration besitzt Progress

Integration verbindet Systeme und transformiert Messages. Orchestration koordiniert mehrere Integrationen und Entscheide zu einem Outcome. Sie weiss, dass ein Case auf Evidenz wartet, ein Approval morgen abläuft oder ein Target Write vor späterem Fehler gelang.

Einfache synchrone Operationen brauchen keine Workflow Engine. Durable Orchestration lohnt sich bei Systems, Time, Retries, Approvals oder Compensation. Das Design reduziert Ambiguität statt jede Function zu verstecken.

| Concern | Schwache Umsetzung | Durable Response |
| --- | --- | --- |
| State | Status über Services verteilt | Explizite Workflow History |
| Retry | Ganzes Script wiederholen | Task Policy und Idempotency |
| Human Wait | Polling oder Thread | Durable Task und Deadline |
| Partial Failure | Manual Log Search | Compensation und Resolution State |
| Completion | Letzte Function returned | Business Outcome reconciled |

## Probabilistische Schritte brauchen deterministische Envelopes

Erfassen Sie Modell, Prompt, Kontext und Validation Version. Prüfen Sie Struktur und Policy vor nächstem Effekt. Speichern Sie Accepted Output, damit ein Network Retry nicht einen neuen Business Decision generiert.

Nutzen Sie Risk-based Review und Abstention Paths. Low-confidence Extraction geht zu Human Correction, Unsupported Answer zurück zur Evidenz. Orchestrator kontrolliert State und Recovery, Modell den begrenzten Language Task.

- Business States explizit modellieren.
- External Writes idempotent machen.
- Retry von Exception Handling trennen.
- Accepted AI Output und Provenance speichern.
- Completion mit Systems of Record abstimmen.

## Ablauf

1. **Business States und Invariants definieren.** Benennen Sie Trigger, Inputs, States, Completion und Failure Outcomes. Definieren Sie Invariants wie eine freigegebene Zahlung je Rechnung. Modellieren Sie nicht nur technische Schritte, sondern verständliche Business Reality.
2. **Task Boundaries entwerfen.** Jeder Task bekommt Input, Output, Timeout und Owner. Trennen Sie External Effects von Computation. Nutzen Sie stabile Business- und Idempotency-IDs. Entscheiden Sie Transient Error versus korrigierte Daten, Approval oder Alternate Path.
3. **Waiting, Review und Compensation hinzufügen.** Stellen Sie Timer, Callbacks und Human Tasks als Durable Waits dar. Speichern Sie die Evidenz einer Freigabe. Für nicht rückrollbare Effekte definieren Sie Compensation oder Manual Resolution und zeigen die Konsequenz.
4. **End to end betreiben.** Zeigen Sie Current State, History, Attempts, Dependencies und Next Action. Alerten Sie Business Deadlines und Stuck Work statt jedem Retry. Reconciliieren Sie Workflows mit Target Systems und proben Sie Replay, Cancel und Recovery.

## Wichtige Entscheidungen

- Welche States drücken Business Meaning aus?
- Welche ID verhindert doppelte Effekte?
- Welcher Fehler ist retryable oder braucht Business Action?
- Wie wird Partial Completion kompensiert oder reconciled?
- Welche Evidenz muss mit späterem Approval bestehen?

## Risiken

- Blind Retries duplizieren Zahlungen, Nachrichten oder Records.
- Verteilte Statusfelder driften ohne führenden State.
- Human Tasks warten ohne Deadline unendlich.
- Replay eines Model Steps liefert anderes Resultat.
- Technical Completion wird gemeldet, obwohl Target ablehnt.

## Kennzahlen

- End-to-end Completion und Business Failure Rate
- Workflow Age und Time in State
- Retries und verhinderte Duplicate Effects
- Exceptions nach Technical und Business Cause
- Human Wait und Escalation Time
- Reconciliation- und Compensation-Erfolg

## Häufige Fragen

### Was ist Workflow-Orchestrierung?

Koordination mehrstufiger Arbeit über Systeme und Menschen mit State, Branching, Waiting, Retries, Approvals, Failure Handling und Completion Record.

### Wie unterscheidet sich Orchestration von Automation?

Automation erledigt einen Task. Orchestration koordiniert mehrere Tasks, Dependencies und Actors und steuert Wait und Failure zum End-to-end Outcome.

### Was ist ein Durable Workflow?

Ein Workflow mit persistentem State und History, der Restarts überlebt, auf externe Events wartet und ohne Progressverlust oder Duplicate Effects fortsetzt.

### Wie orchestriert man KI-Schritte?

Task begrenzen, Version und Kontext erfassen, Output validieren, Unsicherheit routen, Accepted Result speichern und Policy vor External Effects setzen.


## Primärquellen

- [Business Process Model and Notation Version 2.0.2](https://www.omg.org/spec/BPMN/2.0.2/), Object Management Group
- [AI Risk Management Framework Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/), National Institute of Standards and Technology