Sub-Pipelines

Eine Pipeline ruft eine andere wie eine Funktion auf — um Logik wiederzuverwenden oder eine Fähigkeit zwischen Organisationen zu teilen, vollständig auditiert.

Ab einem gewissen Punkt wird das Kopieren derselben Knotenfolge über zehn Pipelines hinweg zu technischer Schuld. Sub-Pipelines ermöglichen es einer Pipeline, eine andere wie eine Funktion aufzurufen: Definieren Sie ein Stück Logik einmal, verwenden Sie es überall wieder — auch organisationsübergreifend.

Zwei symmetrische Bausteine:

pipeline_callable (ein Receiver, am Start-Knoten deklariert) stellt eine Pipeline hinter einer URL bereit, mit einem typisierten Eingabe- und Ausgabe-Vertrag.
pipeline_call (ein Knoten) ruft diese Pipeline auf: Er ordnet ihre Eingaben aus dem aktuellen Kontext zu und speichert das Ergebnis in einem Ausgabeschlüssel.

Eine Pipeline bereitstellen (`pipeline_callable`)

Auf der „Dienst"-Pipeline fügen Sie einen pipeline_callable-Receiver hinzu, der deklariert:

Eingaben — die Liste der erwarteten Parameter (Name, Typ, erforderlich oder optional).
Ausgaben — die Schlüssel des zurückgegebenen Ergebnisses.
Antwortschlüssel — welcher Kontextwert die Antwort darstellt (standardmäßig exchange.result).
Antwortmodus — sync (der Aufrufer wartet auf eine JSON-Antwort) oder stream (Fortschritt in Echtzeit).
Zeitbudget — maximale Ausführungszeit (standardmäßig 60 s, maximal 300 s).

Fehlt beim Aufruf eine als erforderlich deklarierte Eingabe, schlägt dieser fehl (400).

Die Pipeline erhält dann eine öffentliche URL (mit einem Token), die mit der aufrufenden Pipeline geteilt wird. Das Token ist jederzeit rotierbar, um den Zugriff zu widerrufen.

Eine Pipeline aufrufen (`pipeline_call`)

Auf der „Konsumenten"-Pipeline wird der pipeline_call-Knoten konfiguriert mit:

Der URL der Ziel-Pipeline (fest, nicht per Vorlage befüllbar: sie wird beim Speichern analysiert, um Schleifen zu erkennen).
Einer Eingabezuordnung — für jeden erwarteten Parameter der Kontextselektor, der ihn liefert.
Dem Ausgabeschlüssel, in dem das Ergebnis gespeichert wird (standardmäßig exchange.subresult).
Dem Modus (sync, ack, stream) und einem Timeout (standardmäßig 30 s, maximal 300 s).

Bei einem Fehlschlag (Timeout, Fehler, fehlerhafte Antwort) läuft die Pipeline weiter: Der Ausgabeschlüssel erhält null und ein ._error-Schlüssel beschreibt, was passiert ist. Es ist die Verantwortung Ihrer Pipeline, den Fallback zu orchestrieren (Fallback-Zweig, Warnung).

Organisationsübergreifende Aufrufe: Opt-in und auditiert

Eine Sub-Pipeline kann von einer anderen Organisation aufgerufen werden — dies ist die Grundlage für das Teilen von Fähigkeiten zwischen Entitäten. Das Modell bleibt strikt:

Standardmäßig abgelehnt. Organisationsübergreifende Aufrufe sind nur möglich, wenn der Administrator der bereitgestellten Pipeline dies explizit autorisiert (allow_cross_org).
HMAC-Signatur empfohlen. Sobald ein organisationsübergreifender Aufruf geöffnet ist, wird auf beiden Seiten ein gemeinsames Secret aktiviert: Jede Anfrage wird signiert (Header X-Pipeline-Signature), und der Receiver lehnt jede fehlende oder ungültige Signatur ab (401). Einmal gespeichert, wird dieses Secret auf keiner der beiden Seiten je wieder angezeigt (siehe Der visuelle Editor, Abschnitt Secrets); entfernt man es auf der aufrufenden Seite, entfällt die Signatur, entfernt man es auf der exponierten Seite, entfällt die Prüfung.
Alles wird nachvollzogen. Jeder Aufruf schreibt einen Audit-Datensatz (aufrufende Organisation, Knoten, Tiefe, Latenz, Status) — vor der Ausführung, sodass auch im Störungsfall eine Spur existiert. Beide Parteien können ihre eigenen Protokolle einsehen (Aufrufer- und Aufgerufenenseite), im Einklang mit den DSGVO-Auskunftsrechten.

Abrechnung: Die aufgerufene Organisation zahlt für die während der Ausführung verbrauchten Ressourcen (LLM, Sprache …). Gastlogik: Sie nutzen die Ressourcen Ihres Gastgebers.

Schleifenverhinderung

Eine Pipeline, die sich direkt oder über eine Kette selbst aufruft, würde unbegrenzt Credits verbrauchen. Zwei Schutzmechanismen:

Statische Erkennung bei der Registrierung (innerhalb einer Organisation): Der Editor verweigert die Veröffentlichung eines direkten Zyklus (A → A) oder indirekten Zyklus (A → B → C → A) und benennt die betroffene Kette.
Laufzeit-Schutz (organisationsübergreifend, wo statische Sichtbarkeit unmöglich ist): Jeder Aufruf propagiert seine Tiefe; jenseits von 10 Ebenen wird der Aufruf abgelehnt.

Ausführungsmodi

Synchron (sync) — der Knoten wartet auf die vollständige Antwort. Geeignet für kurz laufende Operationen.
Ohne Warten (ack) — der Aufruf wird gestartet und die aufrufende Pipeline läuft sofort weiter; der Ausgabeschlüssel bleibt leer.
Streaming (stream) — für eine lang laufende Sub-Pipeline (LLM-Reasoning, Batch-Verarbeitung) wird der Fortschritt in Echtzeit empfangen (unter <Ausgabeschlüssel>._progress); der Timeout bezieht sich dann auf die maximale Zeit ohne Ereignis, nicht auf die Gesamtdauer.

Wann verwenden

Eine von mehreren Pipelines wiederverwendete Sequenz auslagern (einen Thread zusammenfassen, einen Lead qualifizieren, ein Dokument prüfen).
Eine Fähigkeit zwischen Organisationen teilen — eine Entität stellt „eine Rechnung gegen das ERP validieren" bereit, eine andere konsumiert sie, mit Audit-Trail auf beiden Seiten.
Ein Fan-out unabhängiger Teilaufgaben aus einer Schleife parallelisieren.

Eine Pipeline bereitstellen (pipeline_callable)