Workflow/tasks/signal_wait.md

# `signal_wait` — Auf ein internes Signal warten

**Zweck:** Catch-Gegenstück zu `signal_fire`: Der Workflow pausiert, bis ein anderes Workflow-/Systemereignis ein passendes Signal (Name + Korrelationsschlüssel) hinterlegt hat. Damit sind Workflow-zu-Workflow-Abhängigkeiten möglich („warte, bis der Freigabe-Workflow desselben Verfahrens durch ist"). Optional beendet ein Timeout das Warten mit einem Flag statt ewig zu blockieren.

**Parameter**

| Name | Pflicht? | Default | Beschreibung |
|---|---|---|---|
| `signal` | **ja** | — | Signalname, auf den gewartet wird |
| `korrelation` | nein | *(leer)* | Korrelationsschlüssel; leer = jedes Signal dieses Namens |
| `ab_start` | nein | `true` | Nur Signale nach Task-Start zählen; `false` = auch bereits vorhandene |
| `consume` | nein | `true` | Signal verbrauchen (einmalige Zustellung) |
| `timeout_tage` | nein | — | Nach N Tagen ohne Signal mit Flag weiter |
| `timeout_flag_var` | nein | `<task_id>_timeout` | Variablenname des Timeout-Flags |
| `payload_var` | nein | — | Variablenname für die Payload des Signals |

**Eingangswerte:** Platzhalter in allen Parametern, z. B. `{{vkz}}` in `<korrelation>`.

**Ausgangswerte:**
- `<payload_var>` — Payload des empfangenen Signals (String); bei JSON zusätzlich `<payload_var>_data`
- `<timeout_flag_var>` — `"1"` bei Timeout, sonst `"0"`

**XML-Beispiel**

```xml
<task type="signal_wait" id="warte_auf_freigabe">
  <config>
    <signal>verfahren_freigegeben</signal>
    <korrelation>{{vkz}}</korrelation>
    <timeout_tage>14</timeout_tage>
    <payload_var>freigabe_daten</payload_var>
  </config>
</task>
```

**Hinweis:** Persistenz über eine systemseitig eingerichtete Signal-Tabelle. Der Task hinterlegt beim ersten Lauf einen Listener-Marker im Ausführungszustand; `signal_fire` findet ihn und weckt den Workflow über `resume_at` + `cron-resume`. Ist ein Timeout gesetzt, wird zusätzlich ein Weckruf zum Timeout-Zeitpunkt geplant.