Por qué extraer datos de SAP es más difícil de lo que parece

La frase que arranca la mayoría de estos proyectos es “solo necesitamos sacar unas tablas de SAP”. Y la razón por la que ese proyecto casi nunca dura lo que se estimó es que SAP no es una base de datos con tablas: es una aplicación que usa una base de datos como almacenamiento, y las dos cosas no se parecen tanto como se supone.

Estas son las cinco razones técnicas concretas, con lo que implica cada una.

1. El modelo de datos es enorme y los nombres no ayudan

Un sistema SAP productivo tiene decenas de miles de tablas. Y los nombres están derivados del alemán, comprimidos a cuatro o cinco caracteres:

Tabla	Qué contiene
VBAK	Cabecera de pedido de venta
VBAP	Posiciones del pedido de venta
MARA	Maestro de materiales, datos generales
KNA1	Maestro de clientes, datos generales
BKPF	Cabecera de documento contable
BSEG	Partidas del documento contable

Nada de eso es adivinable. Y el dato que el negocio pide casi nunca vive en una sola tabla: “ventas por cliente y material” requiere unir cabecera, posiciones, maestro de clientes y maestro de materiales, cada una con sus propias claves compuestas y sus campos de mandante y sociedad.

Lo que implica: el cuello de botella no es técnico, es de conocimiento del negocio. Sin alguien que entienda cómo está configurado ese SAP —porque cada implementación es distinta— el equipo de datos pasa semanas adivinando reglas.

2. No todas las tablas se leen con SQL

Esta es la que descarrila los proyectos que arrancaron con acceso directo a la base de datos.

SAP tiene tres tipos de tabla, y solo uno se comporta como esperarías:

• Transparentes. Una tabla de SAP corresponde a una tabla física en la base. Se leen normal.
• Pool. Varias tablas lógicas pequeñas comparten una tabla física.
• Cluster. Varias tablas lógicas se guardan comprimidas dentro de un solo campo de una tabla física.

BSEG —las partidas contables, es decir el corazón de cualquier reporte financiero— es históricamente una tabla cluster. Si te conectas por debajo con un cliente SQL, no vas a encontrar las columnas que esperas: vas a encontrar un campo binario comprimido.

Las tablas pool y cluster solo se pueden leer a través del servidor de aplicaciones, no desde la base de datos. Ese no es un detalle de implementación: es una restricción de diseño.

Lo que implica: cualquier enfoque que lea por debajo de SAP queda automáticamente limitado a tablas transparentes. Y las que finanzas necesita suelen no serlo.

3. El acceso directo no es el camino soportado

Aparte de la limitación técnica, hay tres razones por las que leer directo de la base de datos es una mala idea incluso cuando funciona:

Salta la seguridad de SAP. Toda la autorización de la aplicación —qué usuario puede ver qué sociedad, qué centro de costo, qué región— vive en la capa de aplicación. Por debajo no existe.

SAP puede cambiar el uso interno de una tabla sin avisar. Lo que hoy devuelve el dato correcto puede devolver algo distinto después de una actualización, sin que nada falle visiblemente. Ese es el peor tipo de error: silencioso.

Los tipos de dato no coinciden. SAP hace conversiones propias entre su definición y la de la base. Fechas, decimales y campos con relleno pueden llegar en un formato que no es el que la aplicación muestra.

Lo que implica: el camino soportado es a través de las interfaces de la aplicación —RFC, BAPIs, módulos de función, extractores— no por debajo. Cualquier herramienta seria de extracción de SAP trabaja así, y es la razón por la que existen.

4. La carga incremental no es uniforme

Aquí es donde los proyectos se atascan en el mes cuatro.

Recargar todo cada noche funciona bien en las pruebas con tres meses de datos, y deja de funcionar cuando entra el histórico completo. Entonces alguien pregunta por la carga incremental y aparece el problema real: SAP no tiene una forma única de saber qué cambió.

Depende de la tabla y del objeto:

• Algunas tablas tienen campos de fecha y hora de modificación que sirven como marca de agua.
• Otras no tienen ninguna forma confiable de detectar cambios a nivel de tabla.
• Los borrados son especialmente problemáticos: un registro eliminado no deja rastro en un filtro por fecha.
• SAP tiene mecanismos propios de delta —extractores DeltaQ, aprovisionamiento operacional de datos (ODP)— pero usarlos requiere saber que existen y cómo se activan.

Lo que implica: la lógica delta hecha a mano es donde se va la mayor parte del esfuerzo de mantenimiento, y donde aparecen las discrepancias que nadie puede explicar. Lo tratamos a fondo en carga incremental de SAP a Snowflake.

5. Cada implementación de SAP es distinta

Dos empresas del mismo sector con el mismo módulo de SAP pueden tener modelos de datos que no se parecen, por tres razones:

• Campos Z. Los campos personalizados que se agregaron en la implementación original y que nadie documentó.
• Configuración. Las mismas tablas usadas con lógicas distintas según cómo se configuró el sistema.
• Versión. ECC, S/4HANA y BW no son intercambiables. S/4HANA cambió estructuras que en ECC llevaban veinte años estables — el caso más citado es la tabla universal de finanzas.

Lo que implica: ninguna plantilla resuelve tu caso completo. Lo que sí se puede reutilizar es el método de extracción; el modelado de negocio siempre es específico.

Qué se aprende de todo esto

Las cinco razones apuntan a la misma conclusión práctica: el trabajo difícil de un proyecto SAP → Snowflake no es mover los bytes, es entender qué mover y mantenerlo funcionando.

Eso ordena las prioridades al elegir cómo hacerlo:

1. Usa las interfaces soportadas por SAP, no acceso directo a la base. No es purismo: es lo que te da acceso a las tablas cluster y respeta la seguridad.
2. Que la lógica delta venga resuelta en lugar de construirla. Es el componente que más cuesta mantener.
3. Que la configuración sea declarativa, no código. Sobrevive a las actualizaciones de SAP y a la rotación del equipo.
4. Presupuesta el conocimiento funcional, no solo el técnico. Necesitas a alguien que sepa cómo está configurado tu SAP.

Las cinco opciones concretas para hacerlo, comparadas, están en cómo llevar datos de SAP a Snowflake. Y si SAP es tu fuente principal, esto es un caso particular del problema más grande de centralización de datos.

---

En EGOS BI usamos Theobald como puente entre SAP y Snowflake precisamente porque resuelve los cinco puntos de arriba sin desarrollo ABAP. Si hoy tu data de SAP llega a analítica en extracciones manuales, platiquemos.

Fuentes: SAP Community — acceso a tablas cluster · SAP Community — acceso directo a tablas SAP