Banco de Pruebas — /test-bench
Probar una integración recién configurada lo sacaba del producto. Para ejercitar una Recolección
con Parámetros de Entrada había que armar un POST en Postman o Insomnia; para ver una Entrega
ocurrir, hacía falta un mensaje llegando de verdad — es decir, esperar un ciclo real.
El costo no era solo el clic. El payload de prueba quedaba en la colección de una persona: nadie lo revisaba, nadie lo volvía a ejecutar cuando la integración cambiaba, y no viajaba junto cuando la integración se instalaba en otro cliente.
El Banco de Pruebas trae eso adentro del CMS.
Los combos ofrecen las Recolecciones y Entregas de las Interfaces que usted puede ver — cada una con la descripción de la Interfaz junto a la sigla —, menos las de las herramientas de Help Desk: para probar un destino de ticket, use el botón Abrir ticket en la Configuración ITSM, que pasa por el cuerpo del destino.
La regla que sostiene la pantalla
La prueba corre por el camino de producción, marcada como prueba. No existe un segundo motor de ejecución: probar una Entrega es inyectar un mensaje de verdad en la Interfaz, y probar una Recolección es llamar al mismo ejecutor que llama el programador.
Es una decisión sobre confianza. Un camino de prueba aparte sería la garantía de que la prueba pasa y la producción falla — y por eso mismo una prueba verde aquí es una afirmación sobre el sistema real, no sobre una simulación de él.
La marca “prueba”
Si la prueba pasa por el camino de producción, tiene que poder distinguirse del tráfico real. Todo mensaje generado aquí nace marcado, y la marca cambia lo que el sistema hace con él:
| Lo que un mensaje de prueba no hace |
|---|
| No bloquea la Interfaz, aunque caiga en un Error de Negocio con “bloquea la fila” |
| No dispara alerta de error de entrega, error de negocio ni fila bloqueada |
| No cuenta en los paneles, en los informes ni en la Radiografía del Día |
| No entra en el Contrato Observado — el payload de prueba no contamina el esquema inferido del tráfico |
En la pantalla de Mensajes, en el monitor de la interfaz y en el detalle del mensaje aparece con un frasco ámbar, que muestra quién lo disparó al pasar el mouse, y el filtro de tráfico permite elegir entre reales y de prueba, solo tráfico real o solo del Banco de Pruebas.
El modo Publicar en el origen es la excepción, y es deliberada — ver abajo. El mensaje que nace allí es real, porque el CMS no tiene cómo distinguir el estímulo que usted produjo del que produjo el equipo.
Los cuatro modos
El modo es la pregunta central de la pantalla: ¿hasta dónde llega esta prueba?
| Modo | Qué hace | ¿Escribe fuera del CMS? |
|---|---|---|
| Ensayo | Resuelve credencial, variable y plantilla y muestra qué saldría | No |
| Lectura | Ejecuta la búsqueda en el origen y muestra lo que vino; no graba mensaje ni entrega nada | Lee, no escribe |
| Publicar en el origen | Produce el estímulo en el propio origen — publica en el broker, escribe en el PLC, deja el archivo en la carpeta — para que la Recolección reaccione sola | Sí |
| Ciclo completo | Pasa por el camino de producción entero: graba el mensaje y entrega en el destino real | Sí |
Ensayo es el modo del día a día de configuración: muestra el método y la URL, la query string, los encabezados que la petición realmente llevaría (incluidos los que agrega el CMS), el cuerpo ya transformado, o el comando SQL con sus binds — todo sin que nada salga de la máquina. Es el único modo que funciona bien antes de activar la Definición, y por eso existe la casilla “+N inactiva(s)” en el combo: el momento más útil del Ensayo es justo antes de encender la integración.
Lectura existe solo para Recolección, y no toda Recolección la acepta. Cuando no la acepta, la
pantalla dice el motivo en vez de solo negarse — un FILE_WATCH no tiene “buscar ahora”, un
HTTP_POST escribiría en el destino, un tipo push espera que el mundo externo llame.
Publicar en el origen es lo que le da prueba al conector que no es llamado sino accionado: MQTT, OPC UA, Modbus y carpeta observada. Usted publica en el tópico, escribe el valor de disparo o crea el archivo, y ve a la Recolección reaccionar por su camino normal.
De dónde viene el payload
Escribir JSON desde cero es la última opción de la pantalla, no la primera. Encima del editor aparecen las fuentes que el CMS ya tiene:
| Fuente | Qué es |
|---|---|
| Del Contrato Observado | Un ejemplo armado a partir del esquema inferido del tráfico real de esa Definición |
| Ejemplo N | Muestra declarada a mano, guardada en el Contrato Observado |
| Un mensaje real | El payload de uno de los últimos mensajes que pasaron por ahí, con fecha y hora |
Una Definición con Regla de Cifrado no recibe mensajes reales como punto de partida — y la pantalla lo dice, en vez de omitirlo en silencio. Descifrar para completar un campo de prueba esquivaría la misma regla que alguien configuró a propósito.
El editor es el mismo Monaco del resto del producto y colorea por el lenguaje del Content-Type de la propia Definición — un cuerpo XML no sale subrayado en rojo por ser leído como JSON roto.
Cuando la Definición tiene contrato de entrada (los campos “externo” de una Entrega SAP, los
Parámetros de Entrada de una Recolección), el payload gana el selector Formulario | JSON. En el
Formulario, cada campo del contrato es una caja, con los obligatorios marcados — nadie necesita
recordar el nombre exacto de localInstalacao. Las dos vistas editan el mismo contenido: pasar de
una a otra no pierde nada.
Enviar como una Aplicación productora
En una Entrega con Transformador por Aplicación productora, el Ciclo completo gana el campo Enviar como. Sin él, la prueba seguiría solo el camino de quien ya envía el formato de la Entrega, y el Transformador de cada productora quedaría sin prueba.
| Opción | Qué hace la prueba |
|---|---|
| Sin Aplicación productora (ya en el formato de la Entrega) | El predeterminado. Solo se ejecuta el Transformador de la Entrega |
| Una productora (sigla — Transformador) | El payload pasa por el Transformador de ella antes del de la Entrega, como un mensaje real de ella. Escríbalo en el formato que ella envía |
Elegida una productora, el editor y el Content-Type del envío siguen los de ella — XML, si ella envía XML —, y la pantalla deja de verificar los Parámetros de entrada: el payload está en el formato de la productora, y quien lo lleva al contrato es el Transformador de ella. Quien envió sigue siendo usted, y el mensaje nace marcado como prueba como cualquier otro de aquí. En el panel de resultado, el Transformador de la productora aparece antes del de la Entrega, en el orden en que se ejecutaron.
Un mensaje real que pasó por el Transformador de una productora sugiere lo que ella envió, con su sigla junto a la fecha — y elegirlo ya marca Enviar como con la misma productora y pasa al Ciclo completo. Sin eso, la prueba enviaría el dialecto de la productora como si fuera el formato de la Entrega.
El campo solo existe en el Ciclo completo: el Ensayo parte de un payload ya en el formato de la Entrega y no ejecuta el Transformador de la productora, y ofrecerla ahí mostraría una petición que no saldría. Con Enviar como completado tampoco hay Guardar como escenario — el escenario no guarda la productora, y repetido enviaría el dialecto de ella sin su Transformador.
Antes de escribir en el destino real
Ciclo completo y Publicar en el origen piden confirmación escrita: usted teclea la sigla de la Definición para seguir. El texto dice el destino, el tipo de operación y — en el caso de la publicación en el origen — que el mensaje generado será real.
La confirmación existe para que alguien vea cuál destino se va a escribir. Eso lo cumple la primera vez; de la segunda en adelante, en una sesión de ajuste donde se dispara la misma prueba diez veces, sería tecleo repetido. Por eso existe la casilla “no preguntar de nuevo”, con límites deliberados:
- vale por Definición y por modo — dispensar el Ciclo completo no dispensa la publicación en el origen, que es más grave;
- vale mientras la pestaña esté abierta, y muere con ella;
- mientras esté activa, la pantalla avisa en ámbar que el próximo clic dispara directo, con un botón para volver a preguntar.
Qué pasó
El panel de la derecha cuenta la historia en el orden en que ocurre: primero lo que se envió, después la respuesta del destino. Ver el retorno sin ver la petición obliga a adivinar qué armó el CMS — y ahí vive la mayoría de los errores de configuración.
Cada etapa abre y cierra: petición, query string, encabezados, cuerpo, comando, binds, retorno. En las etapas de contenido hay dos pestañas, Vista previa (formateado) y Crudo (byte a byte, tal como salió).
- El valor de una Variable Global usado como bind aparece identificado, sin el valor.
- El contenido protegido por Regla de Cifrado aparece cifrado, con el aviso de que descifrar exige la Herramienta propia.
- Cuando se generó un mensaje, hay un atajo directo a él en la pantalla de Mensajes.
- Cuando la condición de un reenvío no se cumplió, el cuadro Reenvíos no realizados dice qué destino quedó fuera y por qué. La alerta Condición Cumplida no se dispara con un mensaje de prueba.
Recolección que espera el ciclo de la Interfaz
En el Ciclo completo de una Recolección con destino, el mensaje nace No Procesado y solo se reenvía en el próximo ciclo de la Interfaz — que, en una Interfaz programada cada hora, puede estar a casi una hora. El panel lo dice por extenso: “Esperando el próximo ciclo de la Interfaz X: 24/09/2026 15:00” (o “se ejecuta cada N s”, en una Interfaz por intervalo).
Al lado está Reenviar ahora, que adelanta el reenvío solo de los mensajes de esta prueba. No
ejecuta el ciclo de la Interfaz — eso también haría la búsqueda de producción y se llevaría cualquier
otro mensaje detenido allí. Con la Interfaz bloqueada el botón no aparece: nada se reenvía hasta el
desbloqueo. El clic queda en el Log de Auditoría, como
ENCAMINHAR_TESTE_COLETA.
Llegar por el camino corto
Nadie se despierta decidido a “ir al Banco de Pruebas”: la persona está mirando una Definición y quiere ver aquello funcionar. Por eso el acceso principal no es el menú, sino el botón Probar en la fila de la Recolección o de la Entrega en Definiciones de Recolección, Definiciones de Entrega y Definición de Mensaje. Abre esta pantalla ya apuntada a esa Definición.
El Banco de Pruebas lee la Definición ya guardada. Si hay cambios sin guardar en la pantalla de registro, el CMS avisa antes de traerlo aquí: lo que está en pantalla y todavía no se guardó queda fuera de la prueba.
Guardar la prueba que acaba de correr
Una prueba que funcionó es conocimiento que suele perderse. El botón Guardar como escenario toma el disparo que acaba de ocurrir — Definición, modo, payload y parámetros — y lo guarda en un Plan de Prueba, con la opción de convertir el resultado obtenido en expectativa.
Si la prueba falló, la pantalla avisa: el escenario va a afirmar que la falla ocurre. Es útil para documentar un problema conocido, y pésimo si no era esa la intención — de ahí el aviso, y no el bloqueo.
Dónde está en el menú
Laboratorio de Integración, al lado de Planes de Prueba y de los Simuladores. El agrupamiento es una afirmación sobre el trabajo: Config. de Integración es donde la integración se registra, el Laboratorio es donde se ejercita. El simulador falsifica el origen, el Banco de Pruebas dispara el estímulo — probar una Recolección OPC UA es usar los dos juntos.