# Configuración (Airflow Variables)

## Fuente de configuración real

El código en `SaveUrl.py` obtiene configuración principalmente desde **Airflow Variables** usando `airflow.models.Variable.get(...)`.

Esto implica:

- Debes definir estas Variables en tu instancia de Airflow (UI o CLI).
- El archivo `.env.example` sirve como **referencia de nombres**, pero **no es la fuente** en ejecución si corres bajo Airflow.

## Variables requeridas

### SQL Server

- `DB_MSSQ_SERVER`: hostname o IP del SQL Server
- `DB_MSSQ_USER`: usuario
- `DB_MSSQ_PASSWORD`: password

Notas:

- La conexión ODBC usa `ODBC Driver 18 for SQL Server`.
- La tabla destino es fija: `URL_FTP`.
- El nombre de “database” (catálogo) se toma de la lista `INFORMATIONS` dentro del código (ej. `glm_pmi`, `IS001`, etc.).

### FTP

- `FTP_000oqta_SERVER`
- `FTP_000oqta_USER`
- `FTP_000oqta_PASSWORD`

Notas:

- El código construye el path como `FTP_BASE_PATH + code_folder`.
- `code_folder` se calcula como `<name_folder><MM>` (mes actual), por ejemplo `glmpmi04`.

### Kafka

- `BOOTSTRAP_SERVERS_DOCKER`: brokers accesibles desde el entorno Airflow (por ejemplo `kafka-kraft:9092`)
- `KAFKA_USE_SSL`: `"True"` o `"False"`

Si `KAFKA_USE_SSL == "True"`, además se leen (desde variables de entorno del proceso, vía `os.getenv`, no Airflow Variables):

- `SECURITY_PROTOCOL` (ej. `SASL_SSL`)
- `SASL_MECHANISM` (ej. `SCRAM-SHA-256`)
- `SASL_PLAIN_USERNAME`
- `SASL_PLAIN_PASSWORD`
- `SSL_CAFILE` (path al CA dentro del contenedor/host)
- `SSL_CHECK_HOSTNAME` (`True`/`False`)

> Importante: en el código actual, `BOOTSTRAP_SERVERS_DOCKER` y `KAFKA_USE_SSL` se obtienen como Airflow Variables, pero los demás parámetros de seguridad se obtienen desde `os.getenv`. En despliegues en contenedores, asegúrate de definir esas variables en el **entorno del scheduler/worker**.

### Webhook de notificación

- `WEBHOOK_URL_NOTIFICATION`: endpoint que acepta `POST` con JSON `{"message": "..."}`

## Plantilla `.env.example`

El archivo `.env.example` contiene los nombres esperados (útil para referencia), pero:

- el proyecto **no debería** versionar un `.env` real con secretos
- en Airflow, se recomienda gestionar secretos con backend (Vault/Secrets Manager/etc.) o Variables protegidas

## Validación recomendada (pre-flight)

Antes de activar el DAG en producción, valida:

- Variables existen (sin typos)
- SQL user tiene `SELECT` e `INSERT` sobre `URL_FTP`
- FTP credenciales permiten `NLST` sobre el path base
- Kafka accesible desde el contenedor/worker que ejecuta el DAG