POC 1: normalización determinista de clientes
Esta POC convierte un CSV sintético de 1.000 filas en una salida normalizada de 667 filas. Recorre ocho componentes Transform y comprueba el resultado con un oráculo independiente escrito en Python. El ejercicio permite estudiar limpieza, derivación, conversión, selección de registros y ordenación sin utilizar conexiones externas ni credenciales. Los nombres y valores son datos de prueba repetibles, no registros de personas reales.
Material y alcance
El paquete de muestras incluye inputs/customers.csv, expected/customer_normalized.csv y definiciones coherentes de Mapping, Session y Workflow. La entrada contiene customer_id, raw_name, location, amount y status. Hay espacios repetidos, caracteres acentuados, una ubicación con separador vertical y tres estados alternados: ACTIVE, ENABLED e INACTIVE.
El ejecutor requiere un checkout autorizado de DovaETL y las dependencias Python del proyecto, incluida la versión de openpyxl indicada en el paquete. No instala software ni inicia un servidor. Ejecuta el motor de transformación localmente y valida las definiciones relacionadas; no crea objetos en un tenant, no activa una programación y no prueba conectividad hacia workers remotos.
Comprender la cadena
| Paso | Operación | Regla que debe conservarse |
|---|---|---|
| 1 | Clean | Recortar espacios, compactarlos y retirar acentos en nombre y ubicación |
| 2 | Replace | Reemplazar exactamente ENABLED por ACTIVE |
| 3 | Split | Dividir location en city y country, retirando el campo original |
| 4 | Concat | Crear customer_key con nombre limpio, # e identificador |
| 5 | Derive | Construir segment a partir de país y estado |
| 6 | Convert | Convertir amount a amount_number; fallar ante una conversión inválida |
| 7 | Filter | Conservar únicamente el estado ACTIVE |
| 8 | Sort | Ordenar por importe numérico descendente |
El orden de Replace y Filter explica por qué también se conservan los registros inicialmente ENABLED. Convert debe ocurrir antes de Sort para ordenar números y no representaciones textuales. La configuración conserva además el campo original amount; disponer de ambas representaciones ayuda a examinar el cambio sin ocultar el valor de entrada.
Ejecutar la comprobación local
Descargue y extraiga el paquete. Desde su carpeta principal, indique la ruta de su checkout autorizado y ejecute:
python .\run_pocs.py --repo C:\ruta\DovaETL --report .\verification.json
Sustituya C:\ruta\DovaETL por su ubicación real; no es una ruta que el programa cree. Consulte también el README del laboratorio. El wrapper ejecuta las dos POC del manual en una misma comprobación. Fuerza DOVAETL_STORAGE_BACKEND=local_json, copia las entradas a un directorio temporal, bloquea conexiones de red y elimina los archivos temporales al salir. La opción --report conserva sólo el informe JSON sintético.
Antes de ejecutar el Mapping, el wrapper verifica los hashes de las muestras frente al manifiesto incluido. También valida Mapping, Session y Workflow y comprueba la referencia de la Session al fingerprint del Mapping. Una modificación accidental del CSV o de una definición debe detectarse antes de aceptar el resultado.
Interpretar el oráculo
El oráculo no llama a operadores DovaETL. Limpia las cadenas con funciones Python, aplica la equivalencia de estados, divide la ubicación, calcula los campos derivados, descarta los registros inactivos y ordena la lista resultante. Después serializa el CSV esperado con el orden de columnas definido por la muestra.
La condición de aceptación es triple: 667 filas de datos, coincidencia exacta entre el oráculo y el CSV de referencia, y coincidencia byte por byte entre el motor y ese oráculo. El informe correcto contiene PASS_BYTE_EXACT. Este texto describe el resultado esperado; si su ejecución devuelve una excepción o un código distinto de cero, la POC no ha pasado en su entorno. Conserve la salida del error antes de cambiar cualquier regla.
Una comparación exacta también detecta diferencias de encabezado, orden, salto de línea o representación numérica. No cambie el resultado esperado para que coincida con una salida que todavía no comprende. Si desea modificar la regla de negocio, escriba primero el nuevo resultado esperado mediante una implementación independiente y conserve la muestra original para reproducir el caso base.
Llevar el ejercicio a la interfaz
Use Mappings para estudiar la cadena y Sessions para revisar los bindings. El identificador de fuente es source_csv; el destino es target_csv. Prepare un Domain y una Folder de laboratorio y rutas disponibles para el worker elegido. Los archivos incluidos describen el contrato técnico, pero no sustituyen la selección explícita del entorno.
Después construya o revise el Workflow, ejecute manualmente y consulte Monitor. Compare su salida con expected/customer_normalized.csv. Si la ejecución local pasa y la remota falla, investigue diferencias de versión, lectura de archivos, bindings, permisos y worker. La regla de transformación comprobada no garantiza por sí sola que una ruta del portátil sea accesible desde otro equipo.