Registros

Estas cuatro pantallas son la columna vertebral de la configuración. El orden de creación importa: Aplicación → Interfaz → Definición/Recolección.

Aplicaciones — /applications

Registro de los sistemas integrados. Además de nombre y sigla, la Aplicación controla:

• Monitoreo de disponibilidad — el tipo de keep-alive (HTTP, base de datos, MQTT, OPC UA, Modbus, SAP, PI…) y la Conexión Externa usada; alimenta el Panel de Aplicaciones y el informe de uptime
• Prioridad, ícono y logotipo — lo que ordena e identifica la aplicación en los paneles
• Observaciones — texto libre que aparece en el Cockpit y en el cuerpo de la alerta de aplicación offline; en la práctica, el teléfono de quien atiende ese sistema
• Agrupación — prácticamente toda pantalla del sistema filtra por aplicación

Los botones de la fila

Una Aplicación recién creada y todavía sin Interfaz muestra una invitación arriba en la pantalla, ofreciendo el asistente correspondiente. Es la forma más rápida de salir de cero.

URL propia o Conexión Externa

Una Aplicación HTTP tiene dos formas de decir dónde está su sistema, elegidas en el campo Dirección:

• URL propia — la URL, la URL de Keep Alive y el certificado quedan en la propia Aplicación. Es el valor por defecto, y es como funcionaba toda Aplicación HTTP antes.
• Conexión Externa — los tres valores vienen de una Conexión HTTP y aparecen bloqueados, con candado. Cambiar la dirección en la conexión la cambia en todas las Aplicaciones vinculadas, y en sus Entregas HTTP.

Use la Conexión Externa cuando más de una Aplicación habla con el mismo servidor. La Credencial sigue en la Aplicación en los dos modos. En la lista, la Aplicación vinculada muestra un ícono de enchufe junto a la URL, con el nombre de la conexión.

Convertir en Conexión Externa. Al editar una Aplicación HTTP con URL propia, el enlace debajo de la URL crea una Conexión HTTP con sus datos y la vincula a ella. La ventana sugiere las otras Aplicaciones que usan la misma dirección, ninguna marcada, y avisa cuando el Keep Alive o el certificado de alguna es distinto: al vincularse, pasa a usar los de la conexión. Solo va junto lo que se marque. Se necesita permiso para crear Conexiones Externas.

El Tipo de Conexión, cuando ya hay Recolección o Entrega

El Tipo de Conexión de una Aplicación decide cómo se ejecutan todas sus Recolecciones y Entregas. Por eso, al editar una Aplicación que ya tiene alguna Recolección o Entrega, el campo abre bloqueado, con candado y la cantidad de Recolecciones y Entregas que dependen de él. No hay cómo desbloquear: cambiar HTTP por SQL, por ejemplo, dejaría las Entregas HTTP sin dirección y las Recolecciones SQL sin base de datos. El servidor rechaza el cambio también por la API, el MCP y la importación.

Sigue permitido:

• cambiar la Conexión Externa por otra del mismo tipo;
• editar la URL, y pasar una Aplicación HTTP de URL propia a Conexión Externa y de vuelta;
• cambiar el tipo de una Aplicación que solo tiene Interfaces, sin Recolección ni Entrega.

En las Aplicaciones InfluxDB con Recolección o Entrega InfluxDB, las conexiones InfluxDB de otra versión aparecen deshabilitadas en el selector: cada versión (1.8, 2.x, 3.x) habla un lenguaje de consulta y graba por una dirección distinta.

Interfaces — /interfaces

CRUD de las interfaces de procesamiento, con:

• Tipo: ENTREGA o COLETA
• Orden de procesamiento: SEQUENCIAL (orden preservado) o PARALELO (throughput)
• Programación: cron o intervalo fijo — es lo que se vuelve el job en Programadores
• Días de retención de mensajes: por cuánto tiempo se guardan los mensajes de esta interfaz antes de la purga automática de la madrugada
• Alerta de mensajes acumulados: el techo a partir del cual dispara la alerta
• Bloquear / liberar: retiene la entrega sin perder mensajes

Dentro de la tarjeta de cada Aplicación, las Interfaces vienen separadas en dos bloques — Recolección y Entrega — con las mismas franjas de título y los mismos colores de Definición de Mensaje. En una aplicación con diez interfaces, el badge de color de la sigla no dejaba ver de lejos cuántas eran de cada lado.

Todo bloqueo y desbloqueo queda registrado — manual o automático por error de negocio, con autor y duración — y sale en el informe de Bloqueo de Interfaces.

Las herramientas de tickets activadas en Help Desk aparecen aquí en una categoría propia, Mesa de ayuda, después de Archivos — con la Interfaz por donde salen los tickets. Es por ella que se bloquea, libera o sigue la cola de tickets. No aparecen en Aplicaciones: nacen y se desactivan desde la pestaña Help Desk.

Definiciones — /definitions

El contrato de entrega. Los campos que más dudas generan:

Permitir reenvío

El interruptor Permitir reenvío está en el encabezado del formulario, junto a Probar, en la Entrega y en la Recolección — vale para la Definición entera, y ya aparece en Nueva y Duplicar. Viene desactivado: si el destino no trata duplicados, reenviar puede registrar el mismo dato dos veces, y quien configura la integración es quien sabe si lo soporta. Cómo reenviar está en Mensajes.

Validaciones de Recepción

La sección reúne lo que vale para el mensaje cuando llega al CMS: el Content-Type y su validación, el tamaño máximo del payload, Activar WebService (WSDL) — con la opción de WS-Security en el encabezado — y la llave Exponer como tool MCP.

Justo debajo está la URL de la API Dinámica de esta Entrega, POST /api/{interfaz}/{sigla}, con botón de copiar — el mismo aspecto de la Recolección. Mientras Interfaz y sigla no estén completas, un aviso en ámbar pide las dos; con el WebService activado, la URL del WSDL aparece justo debajo. Es la URL que se entrega al equipo del sistema productor, sin necesidad de abrir Cómo Enviar.

El editor del Payload de Entrada — los parámetros y el Payload de Entrada Modelo, en las Entregas HTTP, SQL, MQTT y de archivo — también vive aquí, junto a la dirección a la que envía el productor. Solo cambió de lugar: los alias se siguen resolviendo en el envío al destino, no en la recepción.

Transformador por Aplicación productora

Una Entrega suele recibir de más de un sistema — el WMS y el SVAI enviando al mismo destino —, y no siempre en el mismo formato. En lugar de un Transformador que intenta reconocer cada dialecto, cada Aplicación productora puede tener el suyo: convierte lo que ella envía al formato que la Entrega espera (el Payload de Entrada Modelo) y se ejecuta antes del Transformador de la Entrega, que sigue valiendo para todos los mensajes.

Cuando la Interfaz tiene dos o más Aplicaciones productoras habilitadas — por las API Keys y Credenciales de Entrada que valen para ella —, el campo Transformador del formulario se vuelve el botón Configurar, con un resumen al lado (1/3 productoras · Entrega: nombre). Abre el popup Transformador por Aplicación productora:

Aplicar solo lleva la elección al formulario; quien graba es el Guardar de la Entrega, y Cancelar descarta lo que se cambió en el popup. Quitar el Transformador de una productora que ya tenía uno muestra, en el popup y debajo del campo, quién lo pierde al guardar — sus mensajes pasan a tratarse como si ya vinieran en el formato de la Entrega. Duplicar la Entrega lleva la lista consigo, y cada cambio en ella entra en el historial de cambios de la Entrega.

Quién es la productora de un mensaje lo decide quien se autenticó: la Aplicación usuaria de la API Key o de la Credencial de Entrada. Después del Transformador de ella, todo lo que lee el payload ve el formato de la Entrega, y no el dialecto de la productora — el contrato de entrada, los {{alias}}, el :alias de SQL y SAP y las tags de OPC UA, Modbus y PI. Una productora sin Transformador propio sigue exactamente el camino de antes.

El campo sigue como Configurar mientras haya una fila grabada, aunque solo quede una productora — ocultar el popup escondería una configuración que sigue valiendo. En la grilla de Entregas, el cuadro Aplicaciones Externas (vía HTTP) gana la columna Transformador propio cuando alguna productora tiene uno.

El camino, y el host que viene de la Aplicación

En las entregas HTTP y SOAP, el campo URI Post Message guarda solo el camino: el host sale de la URL de la Aplicación, registrada en Aplicaciones. Lo mismo vale para el Camino de Recolección (URL) de una Recolección HTTP. En ejecución el CMS concatena los dos pedazos — y por eso pegar la URL entera en el campo producía https://host.comhttps://host.com/api/...: el guardado pasaba, y el error solo aparecía en la primera ejecución, con cara de falla de red.

Ahora la URL de la Aplicación aparece dentro de la misma caja, trabada y más apagada, pegada a la izquierda de lo que usted escribe — porque en ejecución las dos partes son de verdad una sola URL. Y si un valor absoluto entra igual (pegar no mira el prefijo), un aviso muestra el problema con la corrección a un clic: Usar solo el camino corta el host y mantiene el resto.

Recolecciones — /collectors

El sentido inverso: el CMS busca el dato. Cada Recolección tiene un origen (con su Conexión Externa) y uno o más reenvíos — las interfaces/definiciones que reciben el resultado. La excepción es la Recolección solo de consulta, cuyo destino es quien la llamó.

Los detalles por protocolo están en Integraciones.

Puntos comunes a todas las recolecciones:

• Programación — las recolecciones de tipo pull (HTTP, SQL, SAP RFC, Modbus poll) corren por cron o intervalo, gestionados en Programadores
• Recolecciones por evento — MQTT, SAP IDoc y OPC UA trigger reaccionan al suceso, sin polling
• Transformador — aplicable al payload recolectado, antes del reenvío
• Condición por reenvío — el botón Reglas en cada línea de Reenviar Recolección: ese destino solo recibe la lectura que cumple la regla. Ver Condiciones sobre el dato
• Resultado de la última ejecución — éxito/error queda visible en el listado

Detalles de la conexión

Las secciones de origen (en la Recolección) y de destino (en la Entrega) decían solo “usa la Conexión Externa configurada en Aplicaciones: X”. El nombre no cuenta en qué servidor la integración lee ni dónde graba, y descubrirlo exigía abrir Conexiones Externas — pantalla que buena parte de los operadores ni siquiera ve.

Ahora una barra muestra nombre, tipo y dirección ahí mismo, y un clic abre un popup con los campos de esa conexión. Vale en los formularios de Recolección y de Entrega y en el panel de detalles de ambas grillas.

El popup trae además un badge ON/OFF, que es el estado tal como esta Aplicación ve la conexión, y no el agregado de la pantalla de Conexiones Externas: si su Keep Alive está OFF, su Recolección y su Entrega no corren, aunque otra Aplicación alcance el mismo servidor. El valor viene del último ciclo ya grabado, así que abrir el popup no dispara un logon en SAP ni abre un pool en Oracle.

Debajo de los campos viene la disponibilidad por día: una barra para cada uno de los últimos 30 días, verde en el día en que la conexión se mantuvo en pie de principio a fin y de color en el día en que hubo caída, por los mismos cortes del informe de Disponibilidad — meta de 99%, atención a partir de 95%. El badge responde “¿está en pie ahora?”; la franja responde “¿esto se cae seguido?”, que es la pregunta que decide si vale investigar. Con el mouse sobre un día aparecen el porcentaje, cuánto tiempo estuvo fuera de línea y cuántas paradas hubo.

La barra gris es día sin monitoreo: antes de que la Aplicación existiera, y la parte de hoy que todavía no ocurrió. Nunca aparece en verde — día sin medición no es día sin caída — y el porcentaje del período también deja esos días afuera, si no una Aplicación creada hace tres días aparecería con 80% solo por no existir antes.

Al guardar una Recolección o una Entrega

El aviso de resultado

Guardar una Recolección o una Entrega — en Recolecciones, en Entregas o en Definición de Mensaje — abre un aviso con el resultado, en vez de cerrar el formulario en silencio:

Antes, el formulario simplemente desaparecía en el éxito, y el error era una franja al pie del formulario, fácil de pasar por alto en un modal largo.

Cerrar sin guardar

El formulario de Recolección y de Entrega abre en pantalla completa, y el cierre de su encabezado es un botón Cerrar, con texto — la X quedaba justo debajo de la X de la pestaña y de la ventana del navegador.

Con cambios sin guardar, cerrar pregunta antes: Seguir editando o Cerrar sin guardar. Vale para el botón, para el clic fuera del formulario y para el Cerrar del aviso de error. Cerrar la pestaña o la ventana del navegador también hace que el propio navegador pregunte.

La sigla es única en todo el sistema

La sigla de una Recolección, y la de una Entrega, no se repite en ningún lugar del CMS — no solo dentro de la misma Interfaz. Intentar grabar una sigla que otra Definición ya usa da un error que dice exactamente eso y pide ingresar otra sigla. Antes, la misma situación aparecía como “Error interno del servidor”, porque solo la base de datos lo impedía.

Lo mismo vale, con un mensaje genérico, para los demás registros con un campo que no puede repetirse: el CMS responde que ya existe otro registro con ese valor, sin exponer nombre de columna ni de restricción de la base de datos.

Ninguna lista acepta nombres repetidos

En las listas en que cada fila tiene un nombre, no se aceptan dos elementos con el mismo nombre. El segundo desaparecería sin aviso — el nombre se vuelve clave de JSON, :alias en un SQL o {{alias}} en un modelo —, y el defecto solo aparecería en ejecución.

La fila repetida recibe borde rojo y la sugerencia Nombre repetido, y el Guardar queda bloqueado hasta resolverlo. La comparación ignora los espacios en los extremos y distingue mayúsculas de minúsculas — Lote y lote son claves distintas en un JSON. El servidor verifica con la misma regla, así que una grabación por la API también se rechaza — con excepción de los Parámetros Fijos, que ya salen de la pantalla convertidos en objeto JSON y por eso solo los verifica la pantalla.

Definición de Mensaje — /message-management

La vista unificada: todas las Recolecciones y Entregas de una Aplicación en la misma pantalla, agrupadas por Interfaz. Es por aquí que se responde “¿qué intercambia esta aplicación con el CMS?” sin alternar entre dos pantallas.

Una Interfaz creada y todavía no configurada aparece al final de la lista, atenuada y con conteo cero — antes simplemente no existía en esta pantalla, justamente para quien necesitaba terminar de configurarla. Desaparece cuando hay filtro o búsqueda activa, que es cuando se busca algo específico. Dentro de cada Interfaz, las filas vienen ordenadas por sigla.

La categoría Mesa de ayuda también aparece aquí, con la Entrega de cada herramienta de tickets — y los filtros de Aplicación, Interfaz y Definición la incluyen.

Cada fila trae el botón Configuraciones, que abre en un popup todo lo que orbita esa Definición, en pestañas: Errores de Negocio, Alertas, Transformer, Contrato, Reglas de Cifrado, Programador, Credencial, API Keys y Usuarios con acceso. Y el botón Informe, que genera el consolidado de esa Definición — exportable en PDF, útil como documentación de entrega de proyecto. En el popup, la descarga del PDF es el ícono a la derecha de las pestañas, en la misma línea que ellas.

En una Definición expuesta como tool MCP, la pestaña API Keys trae también la línea Expuesta como tool MCP, con el nombre de la tool y la dirección donde un agente de IA la llama — es la otra puerta de entrada de la misma Definición, además de las claves listadas allí.

Contrato Observado

La pestaña Contrato muestra el formato real de los payloads de esa Definición, inferido de los mensajes que ya pasaron por ella. No se declara a mano: es lo que de hecho circuló.

Para cada campo, el contrato registra el tipo y en cuántos de los mensajes observados apareció. Esa segunda información es la que hace la diferencia: saber que itens llega a veces como número, a veces como texto, y falta en uno de cada cinco mensajes, es lo que separa un Transformador que funciona de uno que se rompe en el tercer mensaje.

El origen del contrato queda registrado: observado del tráfico, venido del asistente o editado manualmente. Editar a mano pone en cero el contador de muestras — describe una observación, y un schema escrito a mano dejó de serlo.

La sigla, cuando ya está en uso

La sigla de una Aplicación, de una Interfaz, de una Recolección o de una Entrega no es un rótulo: es dirección. La sigla de la Interfaz y la de la Recolección/Entrega forman la URL pública por donde los sistemas externos llaman al CMS, y la de la Aplicación identifica la app en packs, colecciones de Postman y automatización. Cambiarla por error rompe una integración que está en el aire, y el daño aparece del lado de afuera — en el sistema del cliente, no en una pantalla de aquí.

Por eso, en la edición, el campo abre trabado, con un candado al lado. En la creación y en la duplicación no: allí todavía no hay nada apuntando hacia él.

Hacer clic en el candado abre un aviso que dice qué se lleva ese cambio, y el texto cambia según lo que se está alterando:

Confirmado el aviso, el campo se libera y pasa a exhibir un recordatorio en ámbar hasta guardar. El candado vuelve a cerrarse en cualquier momento, descartando el cambio y devolviendo el valor actual.

En una Recolección o en una Entrega, el campo Interfaz se traba junto con la sigla: cambiar la Interfaz cambia la URL tanto como cambiar la sigla, porque es el primer tramo del camino. Abre trabado, con el candado en lugar de la flecha y una sugerencia que apunta a la sigla, y solo se libera por el candado de esta — cuyo aviso gana una línea que dice que la Interfaz va junto. Trabar de nuevo devuelve las dos al valor del registro. El cambio de Interfaz entra en el historial de cambios de la Definición.

El mismo candado protege el nombre del Transformador, que no forma URL pero es la clave natural de importación y exportación: renombrar hace que un pack antiguo cree un Transformador nuevo en vez de actualizar el existente. La acción de auditoría es ALTERAR_NOME_TRANSFORMADOR — ver Transformadores.

API dinámica de Recolección

Una Recolección con Parámetros de Entrada puede accionarse desde afuera, al instante, por quien informa esos parámetros:

POST /api/collect/{sigla-de-la-interfaz}/{sigla-de-la-recoleccion}

Es el equivalente, para Recolección, del endpoint de recepción de Entrega: endpoint público (sin login de usuario) que recibe los Parámetros de Entrada en JSON, hace la búsqueda en el origen con ellos en ese mismo momento y encola el resultado — el reenvío a los destinos corre en el próximo ciclo de la cola. La autenticación usa el mismo esquema de la recepción de mensajes: header x-api-token, Authorization: Bearer <token>, o Authorization: Basic — con el token en la posición de la contraseña, o con el login y la contraseña de una Credencial de Entrada.

Una Recolección así deja de correr por el programador: quien la dispara es el sistema de afuera, un Disparador o un agente de IA.

En el formulario

La URL de la API Dinámica aparece en el formulario apenas la Recolección gana la primera fila de Parámetro de Entrada — en todos los tipos que usan ese editor (HTTP, SQL Server, Oracle, PostgreSQL, SQLite, MongoDB, InfluxDB) y en SAP, por las Variables de Entrada. Mientras la fila no tiene nombre, el lugar de la URL pide completarlo: la URL solo existe con al menos un alias, que es la misma regla del servidor. Antes, el bloque solo surgía después de escribir el alias, y la pantalla parecía no reaccionar al clic en Agregar parámetro de entrada.

En la misma línea de la URL están Activar WebService (WSDL) y Exponer como tool MCP. Justo debajo, Devolver el resultado de la recolección en la respuesta de la API — ver la sección siguiente.

Cómo enviar

En la lista de Recolecciones, la expansión Detalles de la columna Recolección tiene el botón Cómo Enviar en toda Recolección con API dinámica — el mismo que ya existía en las Entregas. El popup muestra:

• la URL y qué Parámetros de Entrada son obligatorios;
• el curl con API Token y con Basic Auth, con el cuerpo ya armado a partir de los parámetros (cada alias con su valor por defecto);
• lo que trae la respuesta — solo el recibo, o también collected_payload;
• con el WebService activo, el WSDL y un envelope ExecutarColetaRequest listo.

Descargar PDF, en el encabezado, lleva el mismo contenido para entregar al equipo del sistema que va a llamar. El cuerpo es el mismo de la colección de Postman. En el Cómo Enviar de la Entrega, el ejemplo sigue la misma regla: con Payload de Entrada, el cuerpo trae sus alias, y ya no un {"campo": "valor"} genérico.

El resultado en la respuesta

Por defecto, la respuesta de la API es solo un recibo: la búsqueda se ejecutó y el resultado sigue a los destinos. Activando Devolver el resultado de la recolección en la respuesta de la API, la respuesta trae también lo que devolvió la búsqueda, en collected_payload — y el reenvío a los destinos sigue como antes.

{
  "id_message": "17d50724-94e3-4bc1-a7bd-3a6385cfe9dc",
  "message_type": "SYNC",
  "return_message": "Data collected successfully",
  "hasError": false,
  "collected_payload": [ { "vazao": [ { "timestamp": "2026-09-23T12:00:00Z", "valor": 128.4 } ] } ]
}

message_type es SYNC porque la búsqueda corre dentro de la llamada; sin Devolver el resultado, el return_message pasa a ser Data collected; forwarding to destinations queued.

• Un ítem por mensaje, en el mismo orden de id_message: una Recolección SQL que trajo tres filas devuelve tres ítems.
• El contenido JSON vuelve como JSON; XML y texto vuelven como texto.
• El contenido guardado cifrado no sale. Si la Recolección cifra lo que guarda (Reglas de Criptografía), la posición viene null y la respuesta trae "collected_payload_omitted": "encrypted".
• Con la Aplicación de origen caída, la búsqueda queda para cuando vuelva, y la respuesta no trae resultado.

Quien autoriza es la Recolección, no quien llama — por eso es una llave en el registro, y no un parámetro de la petición. Solo aparece cuando hay Parámetro de Entrada, porque sin API no hay respuesta a quien devolver.

Recolección solo de consulta

Con Devolver el resultado activado, la Recolección puede quedar sin ningún destino: quien llama a la API es el destino. Se guarda y se activa normalmente sin reenvío — en lugar del aviso de “se guarda inactiva”, la pantalla explica el modo consulta —, y cada mensaje sigue registrado en el histórico, ya como Procesado, sin esperar reenvío y sin depender del programador de la Interfaz.

Es la forma de ofrecer una consulta bajo demanda — “lee estas tags del PI en este período y devuélvemelas” — sin inventar un destino solo para cumplir. Sin la llave, vale la regla de antes: una Recolección sin destino se guarda inactiva.

Valor por defecto con Variable

El valor por defecto de un Parámetro de Entrada puede contener Variables — {{TURNO_INICIO}}, por ejemplo —, y se resuelven en la ejecución. Solo se resuelve el valor por defecto: lo que envía el sistema de afuera llega tal como vino. Si no fuera así, quien llama podría enviar {{NOMBRE_DE_UNA_VARIABLE}} y leer su valor en la respuesta del origen.

La misma API en SOAP

Con Activar WebService (WSDL) encendido, la misma API pasa a responder también como Web Service SOAP — para el sistema del otro lado que solo sabe importar un WSDL:

GET  /api/ws/collect/{sigla-de-la-interfaz}/{sigla-de-la-recoleccion}?wsdl
POST /api/ws/collect/{sigla-de-la-interfaz}/{sigla-de-la-recoleccion}

La operación es ExecutarColeta, y cada Parámetro de Entrada se vuelve un elemento dentro de <parametros>, en cualquier orden. El WSDL solo exige el parámetro obligatorio sin valor por defecto — el que tiene valor por defecto lo completa el propio CMS. Un alias que no puede ser nombre de elemento XML (empieza con número, tiene espacio) queda fuera del contrato, y el WSDL dice cuáles quedaron afuera.

La respuesta sigue el contrato del REST: un id_message por mensaje generado — una Recolección SQL que trajo cinco filas devuelve cinco —, más return_message y hasError. Con Devolver el resultado activado, viene también un <collected_payload> por mensaje, con el contenido en texto (el JSON serializado). Los valores llegan como texto: 000123 sigue siendo 000123, y no se vuelve el número 123.

Sin Parámetro de Entrada no hay URL, y la dirección SOAP responde 404, como el REST. La URL del WSDL aparece en el formulario, en el panel de detalles de la grilla, en el PDF y en el informe de la Definición, y la colección de Postman pasa a traer el WSDL y un envelope de ejemplo de la Recolección.