Ir al contenido

La solución

Cómo funciona, del alta al historial.

Las piezas de la plataforma, en el orden en que las va a usar.

Los cuatro bloques

Con estos cuatro se monta cualquier rutina.

Job

Un proceso. Es lo que se programa, se ejecuta y se supervisa.

Etapa

Un paso del proceso: SQL, script, copia de datos, copia de seguridad. Cada una decide qué hacer si falla.

Programación

Cuándo se ejecuta. Con alta propia, reutilizable y zona horaria explícita.

Ejecutor

El servicio que ejecuta sus rutinas en su propio servidor. Está separado del portal, y puede haber varios — en máquinas distintas, cerca de donde vive el dato.

Tipos de etapa

Lo que se monta en pantalla y lo que necesita un script.

Conviene saber la diferencia: es la que dice si necesita a alguien que programe.

🗃️

SQL

Consulta o procedimiento en cualquiera de las bases de datos conectadas. El resultado puede alimentar la etapa siguiente.

🔁

Copia de datos

Origen, destino y mapeo de campos en pantalla. Carga completa o incremental, sin una línea de código.

💾

Copia de seguridad

Volcado programado, comprimido, con retención propia — y aviso cuando falla.

🐍

Python

Por aquí entra cualquier sistema con API — Salesforce, Dynamics, HubSpot, el ERP de la casa, un servicio interno. Las conexiones y credenciales llegan listas como variable de entorno, así que el script no lleva contraseña.

Sin catálogo, sin techo: no hay conector listo para arrastrar — a cambio, no hay integración fuera de alcance ni módulo extra que comprar.

⌨️

Shell / PowerShell

Lo mismo, para quien prefiere script de sistema. SFTP, SMB y rsync ya vienen en la imagen del ejecutor.

🔗

Comando compartido

Escríbalo una vez y úselo en varios procesos. Versionado, con sincronización explícita.

Ficheros y Python

Una hoja de cálculo es una fuente de datos, no un adjunto.

Buena parte del ETL real del mundo empieza en un Excel que alguien exporta. Aquí entra por una etapa Python — con pandas y openpyxl ya instalados en el ejecutor y la conexión de destino ya inyectada — y se convierte en una carga tratada en la base de datos, a la hora acordada, con historial y aviso cuando falla.

Excel

.xlsx leído directamente, sin conversión manual y sin que nadie abra la hoja para guardarla como CSV antes.

Listo en la imagen: pandas + openpyxl, nada que instalar.

CSV y texto

Biblioteca estándar de Python, o pandas cuando el fichero es grande y necesita tratamiento.

JSON, XML y Parquet

Los dos primeros de forma nativa; Parquet mediante pyarrow, también ya en la imagen.

Cualquier API

REST, SOAP, el servicio interno de la casa. La credencial llega como variable de entorno.

ETL o ELT — usted elige

Transformar en Python antes de grabar, o volcar en crudo y transformar en SQL después: la plataforma no impone el diseño. Lo que aporta en ambos casos es lo que le falta a un script suelto — programación, orden entre etapas, historial, aviso cuando falla y control de quién puede tocarlo.

Entre etapas

Qué entrega una etapa a la siguiente.

Éxito y fallo

Cada etapa elige: parar, seguir a la siguiente o saltar a una etapa concreta.

Datos

El resultado de una consulta se convierte en variable en la etapa siguiente — incluso en bucle, una ejecución por fila.

Dependencia y encadenamiento

Un proceso puede esperar a otro, o lanzar el siguiente cuando termina bien.

Preguntas frecuentes

Lo que preguntan antes de concertar la reunión.

¿Se puede cargar una hoja de Excel en la base de datos automáticamente?
Sí. La carga de Excel (.xlsx) y CSV se hace con una etapa Python, con pandas y openpyxl ya instalados en el ejecutor y la conexión de destino ya inyectada — el script no lleva contraseña. La rutina se ejecuta a la hora que usted programe, con historial y aviso por correo cuando falla.
¿Se pueden copiar tablas entre bases de datos distintas?
Sí, y sin escribir código: la etapa de copia de datos tiene origen, destino y mapeo de campos en pantalla, con carga completa o incremental. Origen y destino pueden ser de fabricantes distintos — por ejemplo, de Oracle a PostgreSQL.
¿Con qué bases de datos se comunica?
Siete para ejecución: Oracle, SQL Server, PostgreSQL, MySQL/MariaDB, Firebird, DB2 y ODBC. La propia base de control de la plataforma puede ser SQL Server, MySQL, PostgreSQL, Firebird u Oracle — usted usa la que ya tiene.
¿Hace falta saber programar para usarlo?
Para SQL, copia de datos y copia de seguridad, no: se monta en pantalla. El script (Python, Shell o PowerShell) solo hace falta cuando la rutina tiene que hablar con algo que no es una base de datos — una API, un fichero remoto, un sistema heredado.
¿Se integra con sistemas que tienen API, como Salesforce, Dynamics o el ERP de la casa?
Sí, mediante la etapa Python: cualquier sistema con API REST o SOAP está al alcance, y las credenciales llegan como variable de entorno. No hay catálogo de conectores listos para arrastrar — a cambio, no hay integración fuera de alcance ni módulo extra que comprar.
¿Funciona sin internet, dentro de nuestra red?
Funciona. La instalación es en su servidor, en contenedor, y con la base de control también en su casa nada necesita salir de la red. No hay telemetría y el producto no “llama a casa”.
¿Sustituye a cron y a SQL Server Agent?
Los sustituye, y resuelve lo que ellos no: una sola rutina que atraviesa bases de datos de distintos fabricantes, con historial, aviso cuando falla, control de quién puede ejecutar y versión de lo que se cambió.
¿Funciona en Windows?
El portal y los ejecutores se ejecutan hoy en Linux, en contenedor — incluso sobre Windows Server con virtualización. El ejecutor nativo para Windows está en desarrollo y todavía no está disponible para contratación.
¿Cómo me entero de que una rutina ha fallado?
Por correo, en dos niveles independientes — el proceso completo y cada etapa — y por el panel, que muestra qué se ejecutó, cuándo, durante cuánto tiempo y con qué resultado, junto con el registro completo de la ejecución.

¿Ejecutamos un proceso suyo?

Montamos con usted una rutina parecida a la que hoy se ejecuta en su empresa.