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

<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.