Transporte entre ambientes — /transports

La integración se arma y se prueba en un CMS de pruebas, y después tiene que existir igual en el CMS de producción. Volver a cargarla registro por registro es lento y es donde nace el error: un campo olvidado, un Transformador de la versión equivocada, un reenvío que quedó atrás. El transporte lleva la configuración de un CMS a otro en un paquete, y el destino no graba nada hasta que una persona revisa y aprueba.

Tres reglas valen siempre:

• Nada se aplica solo. El paquete llega como pendiente y se graba solo después de la vista previa y de la aprobación de alguien con permiso en el destino.
• Todo nace inactivo. Entregas, Recolecciones, Conexiones, Transformadores, Alertas, Disparadores y Enrutadores creados por el transporte nacen desactivados, y un checklist indica qué falta antes de activarlos.
• Los secretos no viajan. Credenciales y Conexiones Externas van sin contraseña y sin usuario, y la Aplicación va sin URL y sin certificado. Esos datos son de cada ambiente y se completan en el destino.

El menú Transportes está justo después del Laboratorio, porque es el paso siguiente del mismo camino:

Tipo de ambiente

En Parámetros › Apariencia, el campo Tipo de este ambiente (Desarrollo, Pruebas o Producción) muestra una franja de color arriba de todas las pantallas y en el login, para que nadie trabaje en el ambiente equivocado. El transporte usa este valor:

• Producción no envía. En Producción, Generar paquete y Paquetes generados salen del menú, y el servidor rechaza la generación.
• Producción no recibe de Producción. Se rechaza el paquete cuyo origen se declara Producción.
• Un origen con tipo No informado se acepta, con un aviso en la vista previa.

Generar paquete

La página tiene tres pasos, de arriba abajo.

1. Qué transportar. Hay dos grupos:

• Estructura — una Aplicación entera, una o más Interfaces de la misma Aplicación, o una Entrega o Recolección suelta. Va junto lo que usan: reenvíos, condiciones, Transformadores, Errores de Negocio, Alertas, Disparadores, las Credenciales y Conexiones (sin secretos) y todas las variables de la Aplicación (solo el nombre).
• Elementos sueltos — Transformador, Error de Negocio, Disparador, Regla de Cifrado, Alerta o Enrutador. Aquí viaja solo lo que marque. Es el camino para corregir un Transformador o llevar un Disparador nuevo sin reenviar la Interfaz entera. Lo que el elemento referencia (la Entrega del Disparador, la Clave de la Regla de Cifrado, las Entregas del Enrutador) tiene que existir en el destino.

2. Contenido del paquete, calculado en el servidor antes de generar nada:

• los conteos por tipo y el tamaño del paquete;
• Viaja sin secretos — los registros que pedirán contraseña, usuario o URL en el destino;
• Debe existir en el destino — lo que el paquete referencia pero no lleva. Si falta allá, la vista previa lo señala y el transporte no se puede aprobar;
• Variables usadas — viajan solo por el nombre; la Calculada lleva la expresión;
• Avisos — puntos para revisar. No impiden el envío.

3. Destino. Descargar archivo, que genera un .json para importar en el destino, o uno o más ambientes registrados para el envío directo (vea Envío directo). El campo Observación se muestra a quien aprueba en el destino. Úselo para decir qué cambia.

Todo paquete sale firmado con la clave de este CMS (vea Firma del paquete).

Los íconos de transporte en las filas de Aplicación, Interfaz, Entrega y Recolección son atajos: abren esta página con el elemento ya elegido.

Paquetes generados

El historial de todo lo que salió de este CMS: cuándo, qué, hacia dónde (archivo o ambiente) y el resultado, por ejemplo “Transferido #12” o “Falla en el envío” con el motivo. Descargar paquete vuelve a descargar el archivo de cualquier fila. Es la salida cuando el envío directo falló y hay que importar el archivo. El ícono en Quién generó abre los datos de contacto de quien armó el paquete y su resumen, para facilitar la conversación entre los responsables de los dos lados.

Situación en el destino

En el envío directo, la columna Situación en el destino muestra qué pasó allá: Pendiente, Aplicado, Activado, Rechazado (con el motivo), Deshecho o Expirado. El origen pregunta al destino con el mismo token del envío; el destino nunca llama al origen. La pantalla pregunta sola al abrir, solo por lo que todavía puede cambiar, y Actualizar situación pregunta de nuevo en el momento. Un destino eliminado o desactivado no se consulta: la fila guarda la última situación conocida. Un paquete descargado como archivo no se puede consultar y queda con ”—”. El combo Cualquier situación en el destino filtra la grilla por esa columna, con los mismos íconos de la bandeja del destino.

Paquetes recibidos

La bandeja de entrada. La pantalla abre en Pendientes, y el combo de estado cambia a Aplicados, Rechazados, Deshechos, Con falla, Vencidos o todos. Cada opción muestra cuántos paquetes tiene, con el mismo ícono y el mismo color de la columna Estado. Se combina con la búsqueda (sigla, origen, quién generó o número), el tipo y el período. Importar archivo, en el título, deposita un .json como pendiente y no graba nada más.

El ícono en Remitente abre quién generó el paquete. La persona es del CMS de origen, así que el popup muestra lo que el paquete trajo de ella (nombre, login y correo, con el botón de copiar), de qué CMS vino, cuántos paquetes suyos ya llegaron aquí y el resumen de este paquete. Lo mismo vale en el encabezado del paquete.

Cada persona ve solo los paquetes de las Aplicaciones que alcanza. Un paquete que no involucra ninguna Aplicación (un Transformador suelto, por ejemplo) solo lo ven los usuarios con acceso irrestricto.

Contador y aviso por correo

El ítem Transportes del menú muestra un contador ámbar con los paquetes pendientes que la persona ve, actualizado cada minuto. Cuando llega un paquete, por archivo o envío directo, el CMS también envía un correo a quienes pueden aprobarlo: usuarios activos con el permiso de aprobar (/transports/approval), con correo registrado, que alcanzan la Aplicación del paquete. El correo trae el origen, quién lo generó, la observación y el enlace al paquete. Sin SMTP configurado el aviso no sale, pero el paquete está igual en la bandeja y en el contador.

El paquete

El encabezado muestra de dónde vino el paquete, quién lo generó, el hash del contenido, la firma y la observación. Informe (PDF) genera el documento para auditoría: origen, quién lo generó, id del envío, hash, firma, quién decidió, elemento por elemento lo que se creó o se sustituyó (con los campos modificados) y toda la línea de tiempo.

Vista previa

La vista previa compara cada elemento del paquete con lo que existe en este CMS:

Otras pendencias que bloquean la aprobación: una referencia que no existe aquí (la Entrega de un reenvío, una Clave de Cifrado), una Interfaz existente con otro tipo de cola, una Aplicación fuera del alcance de quien aprueba o, con “Exigir firma” activado, un paquete sin firma de origen confiable.

Credenciales y Conexiones tienen equivalencia. En vez de crear una nueva (sin secretos), se puede apuntar a una que ya existe aquí, de la misma dirección o del mismo tipo. La equivalencia queda recordada para los próximos paquetes del mismo origen. Guárdela antes de aprobar, porque la aprobación usa la equivalencia guardada.

Dejar ítems fuera

Algunas exigencias del paquete se pueden resolver al aprobar, sin generar otro paquete. Quien aprueba puede dejar fuera los ítems que nada en el paquete usa: Regla de Cifrado, Error de Negocio, Alerta y Disparador. En la fila del ítem, No traer este ítem lo saca del paquete. Pasa al grupo Dejado fuera, con Traerlo de vuelta, y la vista previa se recalcula sin él. Por ejemplo, una Regla de Cifrado cuya Clave no existe aquí deja de bloquear la aprobación.

Lo que queda fuera entra en el hash de la vista previa y en la aprobación. La línea de tiempo y el informe en PDF registran el evento Ítems dejados fuera en la aprobación, con cada ítem. Interfaz, Entrega, Colecta, Transformador y los demás ítems no se pueden dejar fuera, porque otros ítems dependen de ellos.

Cambiar siglas

Cuando la Interfaz, la Entrega o la Recolección tiene otro nombre en este ambiente (MES_QAS en pruebas, MES_PRD aquí), abra Cambiar siglas (opcional) en la equivalencia e indique la sigla de aquí. El cambio vale para el elemento y para toda referencia a él: reenvíos, condiciones, Errores de Negocio, Disparadores, Alertas, Reglas de Cifrado, alcance de Transformador, el grafo del Enrutador y la URL de recepción, que se recalcula. Scripts y plantillas no se modifican. Si un script cita la sigla, ajústelo a mano.

La sigla nueva puede ser una que ya existe aquí; en ese caso el elemento se compara con el de aquí en vez de crearse. La vista previa muestra cada cambio como aviso. Dos siglas que quedan iguales son una pendencia, porque el paquete juntaría dos elementos en uno. El cambio queda recordado para los próximos paquetes del mismo origen.

Aprobación

Aprobar y crear inactivo graba todo en una transacción. Antes del commit, el CMS relee cada elemento grabado y lo compara con lo que mostró la vista previa. Si algo no coincide, no se graba nada y el transporte queda como Falló. Si la configuración del destino cambió entre la vista previa y la aprobación, la aprobación se rechaza y pide una vista previa nueva.

Cuando el paquete crea Interfaces, la aprobación pregunta cómo nace su programación:

• Desactivada, activar en “Activar transporte” — se activa junto con las Entregas y Recolecciones;
• Desactivada, la activo después — queda desactivada hasta que alguien la active en Programadores;
• Activada desde ya — corre desde la aprobación, sin procesar nada mientras las Entregas y Recolecciones estén inactivas.

Rechazar pide un motivo, que queda en la línea de tiempo, en la auditoría y en la situación que ve el origen.

Por defecto, quien aprueba no puede ser quien armó el paquete en el origen (Aprobador distinto de quien envió, en Parámetros › Configuración). En Producción esta regla vale siempre.

Activación

Después de aprobado, el paquete muestra el checklist de lo que falta antes de activar:

• Credencial o Conexión esperando su secreto, con enlace al registro;
• Aplicación sin URL o sin Conexión de Keep Alive;
• variable creada vacía;
• Interfaz de entrada sin API Key que la cubra, con atajo para generarla;
• Enrutador cuyo acceso hay que liberar;
• Alerta nueva sin destinatarios (solo aviso).

Activar transporte se habilita cuando no queda ninguna pendencia bloqueante. Activa solo lo que este transporte creó y sigue igual a lo creado: Conexiones, Transformadores, Entregas, Recolecciones, Errores de Negocio, Alertas, Enrutadores y, al final, Disparadores. Lo que alguien ya activó a mano queda como está. Las Reglas de Cifrado piden contraseña y se activan en su pantalla.

La sección Lo que este transporte grabó lista cada elemento creado o sustituido. De los sustituidos se guarda la configuración original, que se puede ver y descargar.

Deshacer

Lo que no puede salir (se modificó después, ya tiene mensajes o lo usa otro registro, como un Error de Negocio que alguien vinculó a mano) queda desactivado y se lista en el resultado. Los conectores siempre activos de los elementos restaurados reconectan con la configuración original. Deshacer respeta el orden: si hay un transporte aplicado después de este, deshaga primero el más reciente, porque puede apuntar a lo que este creó.

Vencimiento

Un paquete que nadie aprueba ni rechaza vence después de Los pendientes vencen en (días), en Parámetros › Configuración (por defecto 30 días, de 1 a 365, solo el administrador lo cambia). La limpieza diaria cambia su estado a Expirado, y el evento va a la línea de tiempo. No se borra nada: el paquete solo sale de la cola de aprobación. Si todavía hace falta, genérelo y envíelo de nuevo.

Actualizar lo que ya existe

Por defecto, el transporte solo crea. Un elemento que ya existe con otro contenido es conflicto y bloquea el paquete. Para llevar una corrección de algo que ya está en producción, tres cosas tienen que valer a la vez:

1. Permitir actualización por transporte activado en Parámetros › Configuración. Solo el administrador lo activa, y activarlo pide confirmación;
2. quien aprueba tiene el permiso de actualizar (/transports/update), que ningún perfil estándar recibe;
3. en la vista previa, quien aprueba marca Actualizar este elemento, elemento por elemento. Un conflicto sin marcar sigue bloqueando.

Se pueden actualizar: Interfaz, Entrega, Recolección (con reenvíos y condiciones), Transformador, Alerta, Disparador y Enrutador.

Si el elemento se modificó en este CMS después del último transporte, o se creó aquí a mano, la vista previa muestra la diferencia en tres columnas (último transporte, este CMS, paquete) y pide una segunda marca: Sobrescribir lo que se modificó aquí.

Algunas cosas nunca se actualizan por transporte, ni con la opción activada: Aplicación, Credencial, Conexión Externa, el valor de una variable, Clave de Cifrado, Regla de Cifrado y Error de Negocio. El transporte tampoco elimina nunca lo que existe solo en el destino.

Conectores siempre activos

Algunas Recolecciones y Entregas mantienen una sesión abierta: suscripción MQTT y Sparkplug, disparador OPC UA, polling Modbus, escaneo de archivos, listener de IDoc y el gate de escritura OPC UA/Modbus de la Entrega. Cuando el paquete actualiza una de ellas mientras está activada, la configuración nueva solo vale después de que la sesión reconecta. La aprobación muestra esos conectores agrupados por Aplicación y pide la decisión:

• Reconectar ahora — la sesión cae y vuelve enseguida con la configuración nueva. Puede haber algunos segundos sin recolección;
• Mantener la conexión actual — nada cae ahora; la configuración nueva vale en la próxima reconexión (edición de la Recolección o Entrega en pantalla, o reinicio del servicio).

La decisión queda en la línea de tiempo del transporte.

Firma del paquete

Cada CMS tiene su propio par de claves, generado la primera vez que firma un paquete. Todo paquete sale firmado. El destino verifica la firma al recibir: un paquete modificado después de generado se rechaza en el momento, por archivo o envío directo.

La clave pública aparece en Ambientes y tokens › Adónde envío › Clave de este CMS, con la huella (ocho grupos de cuatro caracteres) y el botón para copiarla. En el destino, quien lo administra pega esa clave en Orígenes confiables y confirma la huella con alguien del origen, por teléfono u otro canal.

El detalle del paquete recibido muestra la firma:

• Firmado por origen (verde) — la clave está en Orígenes confiables, o es la clave fijada en el token que lo depositó;
• Firmado por un CMS que este ambiente no conoce (ámbar), con la huella. Quien administra el transporte puede usar Confiar en este origen, que ya completa la clave;
• Sin firma — un paquete de una versión anterior del CMS.

Un paquete de origen desconocido o sin firma tiene aviso en la vista previa. Con Exigir firma de origen confiable activado (Parámetros › Configuración, solo el administrador), se vuelve pendencia y no se puede aprobar.

En el envío directo, el primer paquete firmado que llega por un token fija la clave en él. Desde ahí, el token rechaza paquetes firmados con otra clave y paquetes sin firma. La huella de la clave fijada aparece en la pestaña Quién envía para acá.

Envío directo

El envío directo lleva el paquete de un CMS a la bandeja de otro, sin descargar ni importar archivo. Del otro lado cae en Paquetes recibidos como pendiente y sigue el mismo camino: vista previa, aprobación y activación.

Se configura en Transportes › Ambientes y tokens (Herramienta /settings/transport, que en los perfiles estándar solo tiene el administrador):

1. En el destino (normalmente producción), en la pestaña Quién envía para acá, genere un token (cmst_…). Aparece una sola vez: cópielo y entréguelo a quien administra el origen. El token queda atado al primer CMS que deposite con él, y a la clave que firma sus paquetes, y tiene un límite de paquetes pendientes.
2. En el origen (pruebas), en la pestaña Adónde envío, registre el destino con la dirección (la misma del navegador, sin /api) y el token. Si el destino usa un certificado de CA propia, informe también el certificado. Use Probar conexión: verifica el token y muestra el tipo de ambiente que declara el destino. Una dirección con http:// se acepta, pero la pantalla avisa en rojo: el token y el paquete viajan sin cifrado.
3. Desde ahí, Generar paquete ofrece el destino al lado de Descargar archivo.

El token queda cifrado y no vuelve a aparecer en pantalla. Desactivar o eliminar el token en el destino corta el envío de inmediato. Si el envío falla, el paquete sigue en Paquetes generados, desde donde se puede descargar el archivo e importarlo.

Varias plantas de producción

Un CMS de desarrollo o de pruebas puede alimentar varios CMS de producción, uno por planta. Cada producción genera su propio token, y el origen registra cada una en Adónde envío. En Generar paquete, marque todos los destinos que deben recibir: el paquete se arma una sola vez y el mismo contenido, con el mismo hash, va a todos. En Paquetes generados queda una fila por destino, con el resultado y la situación de cada uno. Si una planta está fuera de servicio, las demás reciben igual, y el paquete de esa planta se puede descargar e importar después.

Del otro lado, cada planta decide por su cuenta: tiene su bandeja, sus aprobadores, su equivalencia y su checklist. Contraseñas, URLs y valores de variables se completan en cada planta. Si una planta usa otras siglas, el cambio de sigla queda recordado allá. Una producción no envía a otra: la configuración sale siempre de pruebas o de desarrollo.

Vino de un transporte

En las listas de Interfaces, Entregas, Recolecciones y Transformadores, el elemento que vino por transporte muestra un pequeño ícono de paquete al lado de la sigla. Al pasar el mouse aparece qué transporte lo creó o actualizó, de qué origen, cuándo y quién aprobó; el clic abre el transporte. Solo aparece para quien tiene acceso a Paquetes recibidos, y solo para transportes vigentes (no deshechos).

Permisos

Registro

Cada transporte tiene una línea de tiempo en el detalle: recibido, vista previa, aprobado, cada elemento creado o actualizado, la decisión sobre los conectores, activado, deshecho, vencido, con quién hizo cada cosa. La limpieza nunca la borra. Las acciones de usuario (generar, enviar, aprobar, rechazar, activar, deshacer, confiar en un origen y los cambios en las opciones de transporte) también van al Registro de Auditoría, como todo lo demás.

→ Configuraciones · Registros · Conexiones y credenciales · Seguridad y cifrado