Sub-pipelines

A partir de cierto punto, copiar la misma secuencia de nodos en diez pipelines se convierte en deuda técnica. Los sub-pipelines permiten que un pipeline llame a otro como una función: define una pieza de lógica una vez, reutilízala en todas partes — incluso entre organizaciones.

Dos bloques de construcción simétricos:

• pipeline_callable (un receiver, declarado en el nodo Start) expone un pipeline detrás de una URL, con un contrato de entrada y salida tipado.
• pipeline_call (un nodo) llama a ese pipeline: mapea sus entradas desde el contexto actual y almacena el resultado en una clave de salida.

Exponer un pipeline (pipeline_callable)

En el pipeline «servicio», añades un receiver pipeline_callable que declara:

• Entradas — la lista de parámetros esperados (nombre, tipo, obligatorio u opcional).
• Salidas — las claves del resultado devuelto.
• Clave de respuesta — qué valor del contexto constituye la respuesta (exchange.result por defecto).
• Modo de respuesta — sync (el que llama espera una respuesta JSON) o stream (progreso en tiempo real).
• Presupuesto de tiempo — tiempo máximo de ejecución (60 s por defecto, 300 s máximo).

Una entrada declarada obligatoria y ausente en la llamada hace que esta falle (400).

El pipeline recibe entonces una URL pública (con un token) para compartir con el pipeline que llama. El token es rotatable en cualquier momento para revocar el acceso.

Llamar a un pipeline (pipeline_call)

En el pipeline «consumidor», el nodo pipeline_call se configura con:

• La URL del pipeline de destino (fija, sin plantillas: se analiza al guardar para detectar los bucles).
• Un mapeo de entradas — para cada parámetro esperado, el selector de contexto que lo suministra.
• La clave de salida donde se almacena el resultado (exchange.subresult por defecto).
• El modo (sync, ack, stream) y un timeout (30 s por defecto, 300 s máximo).

En caso de fallo (timeout, error, respuesta malformada), el pipeline continúa: la clave de salida recibe null y una clave ._error describe lo ocurrido. Es responsabilidad de tu pipeline orquestar el fallback (rama de reserva, alerta).

Llamadas entre organizaciones: opt-in y auditadas

Un sub-pipeline puede ser llamado por una organización diferente — este es el fundamento para compartir capacidades entre entidades. El modelo sigue siendo estricto:

• Rechazado por defecto. Las llamadas entre organizaciones solo son posibles si el administrador del pipeline expuesto las autoriza explícitamente (allow_cross_org).
• Firma HMAC recomendada. Una vez abierta una llamada entre organizaciones, se activa un secreto compartido en ambos lados: cada petición se firma (cabecera X-Pipeline-Signature), y el receiver rechaza cualquier firma ausente o inválida (401). Una vez guardado, este secreto nunca se vuelve a mostrar, en ninguno de los dos lados (consulta El editor visual, sección Secretos); quitarlo en el lado llamante suprime la firma, quitarlo en el lado expuesto suprime la verificación.
• Todo se traza. Cada invocación escribe un registro de auditoría (organización que llama, nodo, profundidad, latencia, estado) — antes de la ejecución, de modo que exista una traza incluso en caso de incidente. Ambas partes pueden consultar sus propios registros (lado del que llama y lado del llamado), conforme a los derechos de acceso del RGPD.

Prevención de bucles

Un pipeline que se llamara a sí mismo, directamente o a través de una cadena, consumiría créditos indefinidamente. Dos protecciones:

• Detección estática en el registro (dentro de una organización): el editor se niega a publicar un ciclo directo (A → A) o un ciclo indirecto (A → B → C → A), citando la cadena infractora.
• Guarda en tiempo de ejecución (entre organizaciones, donde la visibilidad estática es imposible): cada llamada propaga su profundidad; más allá de 10 niveles, la llamada se rechaza.

Modos de ejecución

• Síncrono (sync) — el nodo espera la respuesta completa. Adecuado para operaciones de corta duración.
• Sin espera (ack) — la llamada se lanza y el pipeline que llama continúa de inmediato; la clave de salida queda vacía.
• Streaming (stream) — para un sub-pipeline de larga duración (razonamiento LLM, procesamiento por lotes), el progreso se recibe en tiempo real (bajo <clave de salida>._progress); el timeout se aplica entonces al tiempo máximo sin eventos, no a la duración total.

Cuándo usarlo

• Factorizar una secuencia reutilizada por varios pipelines (resumir un hilo, cualificar un lead, verificar un documento).
• Compartir una capacidad entre organizaciones — una entidad expone «validar una factura contra el ERP», otra la consume, con una traza de auditoría en ambos lados.
• Paralelizar un fan-out de subtareas independientes a partir de un bucle.