Workflow/tasks/signal_fire.md

signal_fire — Internes Ereignis auslösen

Zweck: Feuert ein Ereignis auf dem internen Event-Bus der Anwendung, sodass registrierte Listener reagieren — ohne Umweg über die HTTP-API. Als Argumente können skalare Werte oder geladene Fachobjekte übergeben werden. Ist der Event-Bus nicht verfügbar, wird der Task mit Warnhinweis übersprungen.

Parameter

Name	Pflicht?	Default	Beschreibung
event	ja	—	Ereignisname.
korrelation	nein	(leer)	Korrelationsschlüssel (z. B. {{vkz}}); persistiert das Signal für signal_wait-Empfänger.
payload	nein	(leer)	String/JSON; landet beim Empfänger in dessen payload_var.
<arg>	nein	—	Wiederholbar; skalares Argument (Platzhalter erlaubt).
<load type="massnahme" md5="…"/>	nein	—	Lädt eine Maßnahme als Argument.
<load type="person" id="…"/>	nein	—	Lädt eine Person als Argument.
<load type="ereignis" id="…"/>	nein	—	Lädt ein Ereignis als Argument.

Die Argumente werden in XML-Reihenfolge übergeben; nicht ladbare <load>-Objekte werden übersprungen.

Eingangswerte: Platzhalter in event, <arg> und <load>-Attributen (z. B. {{massnahme_md5}}, {{ICH.id}}).

Ausgangswerte: Keine Kontextvariablen. Wirft ein Listener eine Exception, endet der Task mit error.

<task type="signal_fire" id="emit_done">
  <config>
    <event>massnahme.saved</event>
    <korrelation>{{vkz}}</korrelation>
    <payload>{{ergebnis_json}}</payload>
    <load type="massnahme" md5="{{massnahme_md5}}" />
    <arg>{{ICH.id}}</arg>
  </config>
</task>

Hinweis: Sind <korrelation> und/oder <payload> gesetzt, wird das Signal zusätzlich zum Event-Bus-Feuer persistiert und weckt Workflows, die per signal_wait darauf lauschen (über resume_at + cron-resume). Die Persistenz nutzt eine eigene Signal-Tabelle, die per mitgelieferter .sql anzulegen ist; fehlt sie, wird nur gewarnt und das Event-Bus-Feuern läuft normal weiter.