Limpieza ETL y lifecycle de tenants: elegir la operación correcta
Objetivo y alcance
Eliminar objetos ETL, extender un trial, suspender acceso y cancelar una suscripción son operaciones distintas. Preferences → Data Cleanup elimina datos ETL de un tenant seleccionado preservando su identidad y configuración de acceso. No borra una VM cloud ni sustituye un procedimiento de eliminación sujeto a retención.
La ruta administrativa aplica permisos de tenant y exige además etl.configuration.manage para la limpieza. La autoridad se valida en el servidor, no sólo en el selector. Para extender trial se exige rol activo Platform Administrator con billing.manage. Antes de actuar confirme tenant, finalidad y mecanismo apropiado.
Qué elimina y qué preserva Data Cleanup
La pantalla identifica Mappings, Sessions, Workflows, Connections, credenciales, runs, Repository y preferencias ETL del tenant como categorías de eliminación. Indica que preserva usuarios, tenant, roles, billing y auditoría global administrativa. Revise siempre el inventario actual; esta lista explica el alcance, no garantiza que cada categoría contenga registros.
El selector Tenant, Refresh inventory y Clean tenant ETL data forman el recorrido. El botón destructivo permanece bloqueado hasta contar con condiciones válidas. El diálogo exige la confirmación indicada y reconocimiento del efecto. No realice el procedimiento como prueba en un workspace con datos reales.
Procedimiento de limpieza
- Confirme autorización y necesidad de eliminar datos ETL, no sólo historial de una ejecución.
- Seleccione tenant y pulse Refresh inventory. Revise categorías, conteos y cualquier bloqueo.
- Obtenga y verifique el respaldo autorizado que corresponda a su operación; el formulario no debe describirse como backup automático de todo el tenant.
- Abra Clean tenant ETL data, compare identidad y frase de confirmación, y acepte sólo el alcance revisado.
- Envíe una vez y espere el resultado. El cliente utiliza la revisión esperada del inventario.
- Actualice inventario y compruebe categorías eliminadas y entidades preservadas. Registre la conclusión sin exportar información sensible.
El servidor serializa la operación con mutaciones de Mappings, orquestación, jobs y conexiones. Una revisión obsoleta o conflicto exige actualizar; no sustituya expectedRevision manualmente. Una respuesta fallida no autoriza borrar archivos directamente.
Restricción de workspaces individuales administrados
Los tenants individuales con suscripción administrada no admiten esta limpieza genérica. El servidor exige un flujo separado que considere retención. No cambie tipo de tenant ni desactive la gestión de suscripción para habilitar el botón. La restricción evita confundir borrado ETL masivo con derechos y obligaciones del lifecycle individual.
Estados y continuidad
| Estado efectivo | Comportamiento relevante |
|---|---|
| trial | Operaciones contratadas durante vigencia |
| trial_expired | Acceso seguro de lectura, exportación y billing |
| active | Operaciones de la suscripción vigente |
| past_due | Lectura segura y billing; puede reactivarse tras pago confirmado |
| suspended/cancelled | Restricciones comerciales; nunca saltar suspensión administrativa o de seguridad |
El modo de lectura no permite crear/editar/borrar negocio, ejecutar, despachar scheduler, enrollment/claims nuevos ni crear o rotar API keys. Hay excepciones de contención autorizadas, como cerrar sesión o terminar una ejecución ya activa, que no autorizan trabajo nuevo. No interprete lectura disponible como permiso para reconstruir el tenant.
Extender trial sin recrear
En Subscription & billing → Subscription → Extend trial, el valor predeterminado es siete días adicionales. Puede elegirse un número de 1–365 días o una fecha/hora personalizada. El diálogo muestra zona local del navegador y almacena instantes UTC. Para trial expirado los días parten de aceptación; para trial vigente, de su vencimiento.
La fecha personalizada debe superar ahora y vencimiento actual, dentro del máximo permitido. El motivo es obligatorio, hasta 500 caracteres. Se conservan tenant, suscripción, inicio original, objetos e historial; no se reinician cuotas ni se conceden nuevos derechos. Trials pagados, cancelados, suspendidos administrativamente o inconsistentes no son elegibles. Un legacy sin propiedad verificada requiere revisión separada.
POC y recuperación
En un fixture aislado genere un tenant de laboratorio y objetos ficticios. Compruebe inventario, rechazo con revisión obsoleta y preservación de usuarios tras limpieza autorizada. En otro fixture pruebe extensión de trial y verifique que identidad y cuotas no cambian. No mezcle ambos ejercicios: un tenant individual administrado debe rechazar limpieza genérica.
Tras error de red revise estado antes de repetir. La extensión idéntica reintentada no debe sumar dos veces. Ante conflicto recargue metadatos y decida otra vez. La activación por pago conserva tenant y objetos; no recree workspace como solución a una incidencia comercial.