MEMM verbindet eine verteilte BPMN-Ausführung mit stabiler VBucket-Zuordnung, shard-lokalen Transaktionen, explizitem Failure Containment und wiederaufnehmbarer Migration. Draft_TI-Flow_26_2 dient dabei als externe Entwicklungsreferenz und stellt keinen Konformitäts- oder Zulassungsnachweis dar.
Technischer Stand: implementierte BPMN/VBucket Runtime Foundation · Website-Mapping geprüft 23.08.2026
Die Aussagen beziehen sich auf die implementierte Workflow-/Sharding-Foundation. Sie werden bewusst nicht zu einer vollständigen TI-Flow-, HCC-, ZETA- oder FHIR-Konformitätsaussage erweitert.
Ein begrenzter virtueller Bucket-Raum ordnet Workflows stabil über workflow_id → bucket_id → shard_id einer benannten Ausführungsgrenze zu. Die konkrete Bucket-Anzahl und physische Topologie bleiben deployment- und versionsgebundene Implementierungsdetails.
Workflow State, Jobs, Timer, Subscriptions, Journal sowie Effect-/Outbox-Datensätze bleiben im Ausführungspfad auf dem zuständigen Shard. Distributed JOINs und distributed writes gehören nicht in den Execution-Hot-Path.
Worker arbeiten ausschließlich innerhalb ihrer zugeordneten shard-lokalen Ausführungsgrenze; Jobs werden dort kontrolliert beansprucht und ausgeführt. Wakeup-, Recovery- und Scheduling-Mechanismen bleiben interne Runtime-Details.
Ownership, Leases und Fencing begrenzen Ausführung auf den zuständigen Shard. Ein Fehler in einer Worker-/Shard-Domain wird als eigener Betriebszustand sichtbar, statt still auf eine andere Datenbankgrenze auszuweichen.
Bucket-Migration folgt einem expliziten, wiederaufnehmbaren Ablauf mit Draining, Copy, Verification und Locked Cutover. Crash/Restart- und Recovery-Semantik sind Teil des Migrationsprotokolls.
VBuckets sind Routing- und Placement-Primitives. Bereiche wie „medizinisch“ oder „Finanzbuchhaltung“ werden nicht allein durch feste Bucket-Nummernbereiche zu Datenschutz- oder Mandantengrenzen.
Migration wird als kontrollierter Protokollablauf behandelt. In besonders sensiblen Phasen können neue Kommandos bewusst fail-fast/retryable behandelt werden, um Split-Brain oder unklaren Besitz zu vermeiden.
Checkpointed Phasen sind so angelegt, dass ein Coordinator nach Restart einen eindeutigen Fortsetzungs- oder Fehlerzustand bestimmen kann.
Vor einem verifizierten Cutover bleibt Source Ownership maßgeblich; ein Netzwerk- oder Datenbankfehler darf nicht als erfolgreiche Migration erscheinen.
Versionierte Topologie, Locked Cutover und Fencing dienen dazu, gleichzeitig aktive Owner derselben Bucket-Domain zu verhindern.
Die gematik-Vorabveröffentlichung vom 30.06.2026 umfasst TI-Flow-Fachdienst, HCC-Cluster, Inbetriebnahme-Konzept, Produkt-/Anbietersteckbriefe und mehrere FHIR Implementation Guides. Diese Ebenen werden nicht automatisch aus der BPMN/VBucket Runtime abgeleitet.
Offizielle gematik Vorabveröffentlichung Draft_TI-Flow_26_2 öffnen →
Die technische Foundation behandelt unbekannte Shards, fehlende Owner, stale Ownership und ungeklärte Migration als explizite Zustände. ZETA-spezifische Validierung wird daraus nicht abgeleitet.
Unvollständige oder widersprüchliche aktive Topologie wird nicht als normaler Routingzustand behandelt.
Local/remote ownership und Fencing begrenzen Ausführung auf den benannten Owner.
Auth-, Tenant-/Project- und Request-Metadaten gehören zur Routing-Grenze und dürfen nicht still verloren gehen.
ZETA bleibt externer TI-2.0-/TI-Flow-Kontext. Eine vollständige ZETA-Validierung oder Konformität wird hier nicht behauptet.
Die Darstellung ist ein UI-Konzept mit synthetischen Daten. Sie zeigt keine reale TI-Flow-Instanz, keine gematik-Prüfung und keine gemessenen Betriebswerte.
Beispielhafte Perspektive auf Prozesszustand, technische Ausführung und Betriebsgrenzen.
Wir können FHIR-/Service-Vertrag, Security-/HCC-Kontext, Workflow Translation und die bereits implementierte Runtime Foundation getrennt gegen Ihren Zielkontext einordnen.