Algunas fuentes de seguridad no entregan un incidente completo en una sola llamada. Primero devuelven una lista de identificadores y después obligan a consultar cada elemento para obtener detalles. Microsoft Sentinel ya admite este patrón en vista previa pública mediante sondeo de API anidado en su Codeless Connector Framework, conocido como CCF.
La novedad evita que un fabricante o un equipo avanzado tenga que mantener un servicio intermedio únicamente para encadenar esas peticiones. No convierte cualquier API en un conector terminado: siguen siendo necesarios la tabla de destino, la regla de recopilación, la definición visual y el empaquetado de despliegue.
Del identificador al registro completo
El flujo parte de un conector RestApiPoller. La llamada padre recupera registros parciales, por ejemplo una colección de incidentes con su identificador. CCF extrae los valores necesarios mediante KQL, los sustituye como marcadores en la configuración del paso hijo y lanza las consultas de detalle.
La documentación oficial del sondeo anidado permite decidir qué ocurre con la respuesta. Si el paso hijo ya contiene el registro completo, puede sustituir al padre. Si aporta solo enriquecimiento, ambos se unen para que la transformación de la regla de recopilación proyecte campos de las dos respuestas.
También se admiten peticiones GET y POST, sustitución de marcadores en URL, cabeceras, parámetros y cuerpo, autenticación en pasos hijo, paginación, reintentos y límites de tiempo. El paralelismo predeterminado de los hijos es 15, pero puede ajustarse cuando la API externa aplica cuotas estrictas.
Los límites importan
La capacidad está en vista previa pública y se rige por los términos adicionales de Azure para funciones preliminares. Una configuración admite hasta cuatro pasos hijo definidos y hasta tres entradas en la secuencia siguiente. No se permiten referencias circulares. Los reintentos van de uno a seis y el tiempo de espera por petición puede configurarse entre uno y 180 segundos.
Estos límites favorecen árboles cortos y previsibles, no orquestaciones generales. Si el proceso necesita decisiones complejas, estado duradero, compensaciones o muchas ramas, una función o un flujo dedicado seguirá siendo más apropiado. CCF encaja mejor cuando la complejidad procede de cómo la API entrega los datos, no de la lógica de negocio.
Un criterio práctico para adoptarlo
Yo empezaría dibujando el contrato de la fuente: llamada padre, valor que se extrae, llamadas hijo, autenticación, paginación y volumen esperado. Después comprobaría si el registro final puede normalizarse en una tabla estable y calcularía el peor caso de peticiones por ciclo. Una lista de mil elementos puede multiplicar rápidamente el consumo de la API y el tiempo de ingestión.
La guía completa de CCF recomienda probar los componentes antes de empaquetar la plantilla ARM. Conviene validar respuestas vacías, límites de tasa, expiración de credenciales, esquemas que cambian y datos parcialmente disponibles. En fuentes sensibles, las herramientas de prueba deben proteger secretos y evitar sincronizarlos a servicios externos.
La mejora es valiosa para conectores que hasta ahora no cabían en una única petición REST. Su beneficio no es escribir menos JSON, sino retirar una pieza intermedia que también habría que parchear, observar y escalar. Mientras siga en vista previa, la usaría primero en un conector de laboratorio y mediría ingestión, errores y coste antes de llevarla a un SOC de producción.