Dokumentation

Sub-Pipelines

Eine Pipeline kann eine andere wie eine Funktion aufrufen — um wiederverwendbare Logik auszulagern oder eine Fähigkeit organisationsübergreifend zu teilen, mit vollständigem Audit-Trail.

Sub-Pipelines

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.
  • Zeitbudget — maximale Ausführungszeit (standardmäßig 30 s, maximal 300 s).

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.
  • Einer Eingabezuordnung — für jeden erwarteten Parameter der Kontextselektor, der ihn liefert.
  • Dem Ausgabeschlüssel, in dem das Ergebnis gespeichert wird.

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 ein gemeinsames Secret aktiviert: Jede Anfrage wird signiert, und der Receiver lehnt jede fehlende oder ungültige Signatur ab.
  • 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 einer konfigurierten Obergrenze wird der Aufruf abgebrochen.

Ausführungsmodi

  • Synchron — der Knoten wartet auf die vollständige Antwort. Geeignet für kurz laufende Operationen.
  • Streaming — für eine lang laufende Sub-Pipeline (LLM-Reasoning, Batch-Verarbeitung) wird der Fortschritt in Echtzeit gestreamt, ohne festen Timeout. Die aufrufende Pipeline kann diesen Fortschritt in einer UI sichtbar machen.

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.