Bases de datos
Las cuatro bases SQL soportadas siguen el mismo diseño: la Recolección ejecuta una consulta en un intervalo programado y convierte el resultado en mensajes; la Entrega ejecuta un comando de escritura (o procedure) con los datos del mensaje. Esta página describe lo que vale para todas.
Lo que cambia entre ellas — los campos de la conexión, lo que ofrece el motor y las particularidades del dialecto — está en la página de cada una:
| Base | Recolección | Entrega |
|---|---|---|
| SQL Server | SQL_SERVER | SQL_SERVER_EXEC |
| Oracle | ORACLE | ORACLE_EXEC |
| PostgreSQL (incluye TimescaleDB) | POSTGRES | POSTGRES_EXEC |
| SQLite | SQLITE | SQLITE_EXEC |
| InfluxDB | INFLUXDB | INFLUXDB_WRITE |
| MongoDB | MONGODB | MONGODB_WRITE |
En todas ellas la conexión se registra en Conexiones Externas. Las contraseñas se guardan cifradas y nunca vuelven a la pantalla — al editar, el campo en blanco mantiene la contraseña actual.
InfluxDB también aparece en la lista de arriba, pero no sigue este diseño: no tiene Columna Clave ni Comando Post-Recolección (el recorrido incremental se hace por la ventana de tiempo de la consulta) y su Entrega graba line protocol en vez de ejecutar un comando. Vea su página.
MongoDB también tiene un diseño propio: la consulta es un filtro o un pipeline en JSON (no SQL) y la Entrega graba el documento directo, sin comando. Vea su página.
Recolección — SQL_SERVER / ORACLE / POSTGRES / SQLITE
El CMS ejecuta la Query SELECT en el intervalo programado de la Recolección y convierte el resultado en mensajes. El Modo del Resultado decide la granularidad:
| Modo | Resultado |
|---|---|
LINHA_UNICA_PAYLOAD_UNICO | Todo el resultado se convierte en un mensaje (arreglo JSON con todas las filas) |
UMA_LINHA_POR_PAYLOAD | Cada fila se convierte en un mensaje independiente (objeto JSON) |
Cada ejecución abre la conexión, consulta y cierra — no hay pool mantenido entre ciclos. El Timeout de la Recolección limita el tiempo de conexión en SQL Server y Oracle; en SQLite no tiene efecto, porque allí lo que hace esperar a una ejecución es el bloqueo del archivo.
Marcar lo que ya fue leído
Para no recolectar los mismos registros en la ejecución siguiente, configure el par Columna Clave + Comando Post-Recolección:
- Columna Clave — nombre de la columna devuelta por la Query SELECT que identifica cada fila
(ej.:
id). - Comando Post-Recolección — comando de escritura ejecutado justo después de la consulta, con el
marcador
:idsreemplazado por la lista de valores de esa columna en las filas recién recolectadas.
-- Query SELECT
SELECT id, ordem, quantidade FROM fila_producao WHERE processado = 0
-- Comando Post-Recolección
UPDATE fila_producao SET processado = 1 WHERE id IN (:ids):ids es una lista de tamaño variable, así que va concatenada en el comando (los valores de
texto se escapan); los demás valores siguen yendo como bind. El comando post-recolección solo se
ejecuta si la consulta trajo filas y si la Columna Clave trajo valor.
Sin ese par — o sin una consulta que filtre lo que ya fue leído — la próxima ejecución recolecta los mismos registros otra vez. El CMS no mantiene un cursor de lectura por usted.
Parámetros en la consulta
Tanto la Query SELECT como el Comando Post-Recolección aceptan :nombre para las Variables
(globales y de la Aplicación) y para los Parámetros de Entrada de la Recolección:
SELECT * FROM apontamento WHERE planta = :PLANTA_PADRAO AND turno = :turnoSolo se bindean los nombres que realmente aparecen en el texto, y el valor siempre va como parámetro del driver — nunca concatenado. Si hay nombres repetidos, la Variable tiene prioridad sobre el Parámetro de Entrada, igual que en la resolución de los demás campos.
No ponga el marcador entre comillas (':turno'): dentro de un literal deja de ser bind y pasa a
ser texto — comparación siempre falsa en SQL Server, error de bind en Oracle y PostgreSQL. El CMS
avisa al guardar.
Entrega — SQL_SERVER_EXEC / ORACLE_EXEC / POSTGRES_EXEC / SQLITE_EXEC
Ejecuta el Comando SQL de la Definición de Mensaje en la base destino, con los datos del mensaje.
El comando se ejecuta con commit automático y el retorno (fila(s) afectada(s)) entra en el
historial del mensaje, donde puede ser evaluado por reglas de error de negocio. Cuando la base
rechaza el comando, el error registrado incluye el comando ejecutado con los valores en lugar de los
marcadores — es lo que permite reproducir la falla directo en el cliente SQL.
| Marcador | Valor |
|---|---|
:payload | Cuerpo del mensaje como texto |
:datetime | Fecha/hora del procesamiento |
:transformer | Salida del Transformador configurado en la Entrega |
:NOMBRE | Variable global o de la Aplicación |
:alias | Parámetro de Entrada |
INSERT INTO recebimento (payload, recebido_em, planta)
VALUES (:payload, :datetime, :PLANTA_PADRAO)Procedures y SQL dinámico
| Dialecto | Cómo llamar |
|---|---|
| SQL Server | EXEC mi_procedure :payload, :datetime — procedure nombrado; EXEC(@variable) y EXEC('texto') están bloqueados |
| SQL Server | EXEC (:transformer) — ejecuta como SQL el texto generado por el Transformador |
| Oracle | Solo DML (INSERT/UPDATE/DELETE). Para ejecutar PL/SQL generado por el Transformador, use exactamente BEGIN EXECUTE IMMEDIATE :transformer; END; |
| PostgreSQL | Solo DML (INSERT/UPDATE/DELETE/MERGE), incluyendo INSERT ... ON CONFLICT. CALL de procedure y bloques DO $$...$$ no se aceptan |
| Todos | Comando igual a solo :transformer — el texto generado por el Transformador es el comando ejecutado |
Llamar un procedure Oracle por nombre (bloque PL/SQL o {call proc(...)}) todavía no está
soportado: validar esa sintaxis con la misma seguridad ya aplicada al T-SQL es un diseño aparte.
Mientras tanto, el camino es generar el bloque desde el Transformador.
Lo que el CMS bloquea en los campos SQL
Todo campo de comando — Query SELECT, Comando Post-Recolección, Comando SQL de la Entrega y Query de
Prueba — pasa por un guard antes de guardarse y otra vez antes de ejecutarse. Exige que el
comando empiece con un verbo compatible (lectura: SELECT/WITH; escritura:
INSERT/UPDATE/DELETE, más MERGE en PostgreSQL y REPLACE en SQLite), rechaza varios
statements encadenados por ; y veda el vocabulario de
abajo:
| Alcance | Bloqueado |
|---|---|
| Todos los dialectos | CREATE, ALTER, DROP, TRUNCATE, GRANT, REVOKE, DENY, BACKUP, RESTORE |
| SQL Server | OPENROWSET, OPENQUERY, OPENDATASOURCE, SHUTDOWN, DBCC, procedures sp_/xp_, EXECUTE AS |
| Oracle | UTL_HTTP, UTL_TCP, UTL_SMTP, UTL_FILE, DBMS_SCHEDULER, DBMS_JOB, DBMS_SQL, EXECUTE IMMEDIATE (fuera del bloque del Transformador) |
| PostgreSQL | COPY (incluso COPY ... FROM PROGRAM, que ejecuta shell en el servidor), dblink, pg_read_file, pg_write_file, pg_ls_dir, lo_import, lo_export, pg_sleep, pg_terminate_backend |
| SQLite | ATTACH, DETACH, PRAGMA, VACUUM, REINDEX, LOAD_EXTENSION, READFILE, WRITEFILE |
Los comentarios y los literales de texto se neutralizan antes de la verificación, así que esconder
una palabra prohibida dentro de un comentario (CRE/**/ATE) o de un string no pasa. Cada intento
bloqueado queda registrado en el log de auditoría, con el campo y el motivo.
El guard es defensa en profundidad, no la protección principal. Lo que realmente limita el daño es
el permiso del usuario configurado en la conexión: sin DDL/DCL, y con GRANT EXECUTE solo en los
procedures necesarios.