Cómo llevar datos de SAP a Snowflake: las 5 opciones reales

Hay cinco formas de llevar datos de SAP a Snowflake, y la diferencia entre ellas no es solo técnica: una de las cinco puede dejarte fuera de soporte y otra te obliga a mantener código propio durante años. Esta es la comparación honesta de cada una, con el escenario donde cada una tiene sentido.

La respuesta corta para la mayoría de las organizaciones: un extractor especializado que use las interfaces soportadas por SAP, porque las otras cuatro opciones o tienen un costo de mantenimiento que crece con el tiempo, o resuelven solo una parte del problema.

Por qué esta decisión es más delicada que con otras fuentes

Conectar un CRM o una plataforma de comercio electrónico a Snowflake es casi trivial: hay conectores gestionados y la estructura de datos es razonable.

SAP no. Tres razones concretas:

• El modelo de datos es enorme y opaco. Decenas de miles de tablas con nombres derivados del alemán: VBAK para cabecera de pedido de venta, MARA para maestro de materiales, BSEG para partidas contables.
• No todas las tablas se pueden leer con SQL. Las tablas de tipo pool y cluster —BSEG es el caso clásico— guardan varias tablas lógicas comprimidas dentro de una sola entidad física. A nivel de base de datos simplemente no se ven como esperarías.
• El acceso directo a la base de datos no es el camino soportado. SAP puede cambiar el uso interno de una tabla sin aviso previo, y leer por debajo salta toda la capa de seguridad de la aplicación.

Ese contexto explica por qué las opciones se ordenan como se ordenan. Lo desarrollamos a fondo en por qué extraer datos de SAP es más difícil de lo que parece.

Opción 1 — Desarrollo ABAP a la medida

Programar dentro de SAP la extracción que necesitas y escribir los archivos a un destino que Snowflake pueda leer.

A favor: control total. Accedes exactamente a la lógica de negocio que quieras, incluyendo tablas cluster, porque estás dentro de la aplicación.

En contra: necesitas un desarrollador ABAP disponible de forma permanente, no solo al inicio. Cada tabla nueva es un desarrollo, cada actualización de SAP es una revisión, y cuando esa persona se va, el conocimiento se va con ella. Y la parte que casi nunca se presupuesta: la lógica de carga incremental hay que construirla y mantenerla tú mismo.

Cuándo tiene sentido: cuando necesitas lógica de negocio muy específica que ninguna herramienta expone, y tienes capacidad ABAP interna estable.

Opción 2 — Acceso directo a la base de datos

Conectarse por debajo de SAP, directo al motor de base de datos.

A favor: parece lo más simple y rápido de montar.

En contra: es la opción que evitamos recomendar, por tres motivos que no son de opinión:

1. Salta la capa de seguridad de SAP por completo. Los permisos y la auditoría de la aplicación dejan de aplicar.
2. Las tablas pool y cluster no son legibles así. BSEG y compañía quedan fuera de tu alcance, y suelen ser justo las que necesita finanzas.
3. SAP puede cambiar el uso interno de una tabla sin avisar, así que lo que hoy funciona puede devolver datos inválidos después de una actualización.

Súmale que las implicaciones de licenciamiento del acceso indirecto son un tema que hay que revisar con tu contrato y con SAP — no algo que se resuelva en una decisión técnica.

Cuándo tiene sentido: en la práctica, casi nunca para una integración productiva.

Opción 3 — Herramientas nativas de SAP

El propio ecosistema de SAP: BW, SAP Datasphere y los mecanismos de aprovisionamiento de datos.

A favor: todo dentro del mundo SAP, soportado por el fabricante, y si ya tienes BW hay modelado de negocio ya construido que puedes reutilizar.

En contra: te ancla al ecosistema, añade una capa de licenciamiento y de administración propia, y suele requerir perfiles especializados en esas herramientas. Si tu destino es Snowflake y tu stack analítico ya vive fuera de SAP, estás pagando y operando una plataforma intermedia que no necesitas.

Cuándo tiene sentido: cuando ya hay una inversión importante en BW con modelos maduros, o cuando la estrategia corporativa es consolidar en el stack de SAP.

Opción 4 — Conectores ELT genéricos

Las plataformas de ingesta que usarías para cualquier otra fuente.

A favor: si ya tienes una para el resto de tus sistemas, es una herramienta menos que administrar. Para fuentes no-SAP es exactamente lo que recomendamos — así trabajamos con Fivetran.

En contra: la cobertura de SAP suele ser parcial. Funciona bien para tablas transparentes y se queda corta en lo que hace difícil a SAP: tablas cluster, extractores de BW, jerarquías, y los mecanismos delta propios de SAP. Terminas con el 70 % resuelto y el 30 % que importa a finanzas convertido en un proyecto aparte.

Cuándo tiene sentido: cuando tu necesidad de SAP se limita a unas pocas tablas transparentes simples.

Opción 5 — Extractor especializado en SAP

Herramientas construidas específicamente para este problema, que se conectan a través de las interfaces que SAP soporta en lugar de por debajo. Es la categoría de Theobald con Xtract Universal, que es la que usamos.

A favor:

• Cubre los tipos de extracción difíciles: tablas transparentes y cluster, BAPIs y módulos de función, queries, reportes ABAP, extractores DeltaQ, ODP y vistas CDS, jerarquías de BW, y captura de cambios a nivel de tabla.
• Sin desarrollo ABAP. La configuración es declarativa, así que sobrevive a la rotación del equipo y no depende de una persona.
• Snowflake es un destino nativo, junto con SQL Server, almacenamiento en la nube, Power BI, Tableau y archivos.
• La carga incremental viene resuelta en lugar de ser algo que construyes tú.

En contra: es una licencia más en el presupuesto y un componente más que administrar. Si solo necesitas tres tablas simples, es sobreingeniería.

Cuándo tiene sentido: cuando SAP es una fuente primaria de tu analítica, cuando necesitas datos de módulos financieros o logísticos con tablas complejas, y cuando quieres que la integración sobreviva a las actualizaciones de SAP y a los cambios de equipo.

La comparación en una tabla

	ABAP a medida	Acceso directo a BD	Nativas SAP	ELT genérico	Extractor especializado
Tablas cluster	Sí	No	Sí	Parcial	Sí
Delta incremental	Lo construyes	Lo construyes	Sí	Parcial	Incluido
Requiere ABAP	Sí	No	Depende	No	No
Respeta seguridad SAP	Sí	No	Sí	Depende	Sí
Snowflake como destino	Vía archivos	Directo	Vía capa extra	Sí	Nativo
Costo dominante	Mantenimiento	Riesgo	Licencia + admin	Licencia	Licencia

Cómo decidir en tu caso

Tres preguntas, en orden:

1. ¿Qué módulos de SAP necesitas? Si la respuesta incluye finanzas —partidas contables, documentos, cuentas— las tablas cluster entran en juego y eso descarta el acceso directo y limita el ELT genérico.

2. ¿Necesitas carga incremental? Si tus volúmenes hacen impagable recargar todo cada noche, la lógica delta deja de ser opcional. Construirla a mano es donde estos proyectos se atascan — lo tratamos en carga incremental de SAP a Snowflake.

3. ¿Quién lo va a mantener en dos años? Si la respuesta depende de una persona específica, cualquier opción que requiera código propio es un riesgo que se materializa cuando esa persona cambia de trabajo.

Y antes de firmar con cualquier proveedor, vale la pena revisar las 8 preguntas que conviene hacer.

---

En EGOS BI integramos SAP a arquitecturas modernas con Theobald como puente hacia Snowflake, y la analítica encima con Tableau u Omni. Si SAP es tu fuente primaria y hoy la información llega en extracciones manuales, agenda un diagnóstico.

Fuentes: Theobald Software — Xtract Universal · SAP Community — acceso a tablas cluster