Entre Aplicaciones

Los otros asistentes traen un sistema nuevo al CMS. Este resuelve el caso opuesto: los dos lados ya están configurados y falta la pieza del medio — el Transformador que convierte el payload de uno al formato del otro, y el reenvío que une uno con el otro.

Se abre con el botón “Integrar dos Definiciones”, en Transformadores.

El Contrato Observado

Escribir ese Transformador a mano exige conocer el formato de los dos lados. El CMS lo descubre solo: conforme los mensajes pasan, arma un schema de lo que de hecho circula en cada Colecta y cada Entrega — qué campos aparecen, de qué tipo, y en cuántos de los mensajes observados.

Esa última parte es la que marca la diferencia. Un ejemplo real:

muestras=5   obligatorios=[pedido, status]
  pedido       string          en 5 de 5
  status       string          en 5 de 5
  items        number|string   en 4 de 5
  observacion  string          en 2 de 5

El contrato no dice apenas “existe un campo items”. Dice que items llega ora número, ora texto, y que falta en uno de los cinco. Un Transformador escrito sin esa información se rompería en el tercer mensaje.

Los tres pasos

1. Elegir origen y destino

El origen puede ser una Colecta o una Entrega — quien produce mensaje puede ser cualquiera de los dos. El destino es siempre una Entrega, que es quien consume en el modelo del CMS.

Los dos combos tienen búsqueda por texto y vienen agrupados por la categoría de Tipo de Conexión de la Aplicación (SAP, base de datos, IoT…), con el ícono de la Aplicación y Aplicación · Interfaz bajo cada sigla — en una instalación con decenas de Definiciones, siglas iguales en Aplicaciones distintas eran indistinguibles. El ✓ al lado de la sigla marca las que ya tienen contrato observado.

Si cualquiera de los lados todavía no tiene contrato observado, el asistente se detiene con un error claro. Es mejor rechazar que generar un script sobre un formato que nadie conoce — deje pasar un poco de tráfico y vuelva.

2. Generar el script

La IA recibe los dos schemas y escribe el Transformador. Note lo que recibe: los schemas, no los mensajes. Necesita saber que existe cantidadBuena: number, no que el pedido 4711 tuvo 37 piezas.

En el ejemplo de arriba, fue el schema el que hizo que el script saliera con conversión de tipo y valor por defecto para el campo ausente — la IA trató el caso difícil sin ver ningún mensaje, porque el contrato ya contaba la historia.

3. Probar contra el tráfico real, y aplicar

El script generado corre contra los mensajes que el origen ya procesó, dentro del sandbox del Transformador, en el servidor. Los mensajes reales nunca salen de ahí: la IA escribió el script sin ver el dato, y el dato valida el script sin salir de casa.

El resultado viene como “X de Y convirtieron”. Cuando alguno falla, el CMS muestra el payload que causó la falla (hasta cinco) — sin eso usted solo sabría que “algunos fallaron”, que es la información menos útil posible.

El botón de aplicar solo se libera después de que la prueba corrió. Aplicar sin probar desperdicia justamente la parte que solo el CMS puede hacer.

Al aplicar, se crean el Transformador (marcado como generado por IA) y el reenvío del origen al destino — este último, como todo lo que crea un asistente, desactivado.

Privacidad, en una línea

Los schemas van a la IA; los mensajes, no. La prueba corre en el servidor del CMS. Si su política prohíbe enviar incluso estructura de datos a un proveedor externo, use un modelo local — el CMS habla con proveedores compatibles con la API de OpenAI, lo que incluye Ollama corriendo en su red.