Wenn ein Auftrag unklar endet
Ein Datenimport läuft seit mehreren Minuten. Dann bricht die Verbindung ab. Auf dem Bildschirm steht nur „Fehler“. Sind die Kundendaten noch gar nicht übernommen, teilweise gespeichert oder längst vollständig verarbeitet? Wer jetzt erneut startet, braucht mehr als Hoffnung.
Dieses Beispiel ist bewusst vereinfacht. Es zeigt aber eine wichtige Qualitätsfrage: Weiß die Anwendung, was sie erledigt hat, oder verlagert sie die Unsicherheit auf den Menschen vor dem Bildschirm?
Der aktuelle Anlass: dauerhaft gespeicherte Abläufe
Microsoft beschreibt am 12. Oktober 2026 in einem Praxisbeitrag zu Durable Task, wann dauerhaft gespeicherte Arbeitsabläufe sinnvoll sein können. Dazu gehören längere Aufgaben mit Unterbrechungen oder externen Freigaben. Die Veröffentlichung weist auch auf Grenzen und unnötige Komplexität hin. [1]
Mich interessiert daran weniger der Name des Werkzeugs als die Frage dahinter: Wie wird aus einem unterbrochenen Vorgang wieder ein nachvollziehbarer Auftrag?
Drei Zustände, die nicht dasselbe bedeuten
„Angenommen“ bedeutet zunächst, dass ein Auftrag registriert wurde. „In Bearbeitung“ beschreibt laufende Arbeit. „Abgeschlossen“ sollte dagegen ein bestätigtes Ergebnis bezeichnen. Eine gute Oberfläche hält diese Zustände auseinander.
Ich würde nach einem Verbindungsabbruch zunächst den vorhandenen Auftrag wieder anzeigen lassen. Seine Kennung, der letzte bestätigte Schritt und die noch offene Arbeit sind hilfreicher als ein neuer Startknopf ohne Erklärung. Auch eine bewusste Unterbrechung muss erkennbar sein: Wartet der Vorgang auf eine Freigabe oder ist tatsächlich etwas fehlgeschlagen?
Wiederholen darf keine zweite Buchung erzeugen
Der schwierige Fall entsteht zwischen zwei Systemen. Ein externer Dienst hat eine Aktion möglicherweise ausgeführt, seine Antwort kommt aber nicht zurück. „Keine Antwort“ ist dann weder ein sicherer Erfolg noch ein sicherer Fehlschlag.
Ich würde für solche Schritte eine stabile Auftragskennung, einen Abgleich mit der Gegenstelle und eine bewusste Wiederholungsregel vorsehen. Eine zweite Anfrage zum selben Auftrag sollte nicht unbeabsichtigt einen zweiten fachlichen Vorgang erzeugen. Solche Maßnahmen werden häufig unter dem Begriff Idempotenz zusammengefasst. Auch Microsoft grenzt dauerhaft gespeicherte Ablaufhistorie von garantiert einmaligen externen Wirkungen ausdrücklich ab. [1]
Architektur braucht klare Grenzen
Bei dauerhaft gespeicherten Abläufen kann Steuerungscode erneut abgespielt werden. Microsoft dokumentiert dafür Anforderungen an vorhersagbares Verhalten und die Trennung externer Aktionen von der Ablaufsteuerung. [2]
Für ein Projekt würde ich daraus keine pauschale Framework-Pflicht ableiten. Ein kleiner Import kann mit einer vorhandenen Auftragstabelle und einem sauber gebauten Hintergrundprozess auskommen. Ein komplexer Prozess mit mehreren Freigaben benötigt möglicherweise mehr Unterstützung. Die Lösung sollte zum Problem passen, nicht umgekehrt.
So würde ich die Abnahme gestalten
Ein erfolgreicher Durchlauf allein reicht mir hier nicht. Ich würde gezielt eine Unterbrechung vor der Verarbeitung, während eines Schritts und nach einer extern bestätigten Aktion betrachten. Anschließend muss sich erklären lassen, was gespeichert wurde und wie der Auftrag weiterläuft.
Zusätzlich würde ich zwei nahezu gleichzeitige Startversuche prüfen. Bleibt es beim selben Auftrag? Erkennt die Anwendung widersprüchliche Eingaben? Ist eine manuelle Klärung sichtbar, wenn der externe Zustand ungewiss bleibt? Das sind konkrete Prüffragen, keine Behauptung über ein bestimmtes Produkt.
Mein Fazit
Zuverlässige Software verhindert nicht jede Unterbrechung. Sie verhindert, dass daraus ein Ratespiel wird. Für mich gehört ein nachvollziehbarer Wiederanlauf deshalb zur eigentlichen Funktion und nicht erst zur späteren Fehlerbehandlung.
Die Beispiele sind Gestaltungsvorschläge, keine ausführbare Implementierungsanleitung und keine Garantie für beliebige Fremdsysteme. Berechtigungen, Datenintegrität und fachliche Freigaben müssen auch beim Fortsetzen erhalten bleiben.
Quellen und Einordnung
Recherchestand: 23. Oktober 2026. Herstellerveröffentlichungen sind keine eigenen Produktprüfungen. Beispiele und Empfehlungen sind im Text als solche eingeordnet.
[1] Microsoft: Durable Task in the Real World, 12.10.2026
Quelle lesen ↗
[2] Microsoft Learn: Anforderungen an Orchestrierung und Replay
Quelle lesen ↗