Fuente de datos de SAP ERP

Importante: Los pasos que se describen en esta página son obligatorios para la implementación de Cortex Framework . En el caso de la implementación de demostración, puedes omitir esta página.

La capa de base de datos de Google Cloud Cortex Framework para SAP ERP requiere conectividad con los datos sin procesar del sistema de origen. Se admiten SAP ECC y SAP S/4HANA.

Antes de implementar el contenido de Cortex Framework, se deben replicar las tablas pertinentes de SAP ERP en BigQuery. Para ello, puedes transferir datos a un conjunto de datos de capa sin procesar dedicado para el procesamiento de captura de datos modificados (CDC) o usar canalizaciones de CDC establecidas para alimentar la capa de base de datos directamente. Para obtener más información, consulta Requisitos técnicos para replicar datos de SAP ERP.

Puedes usar cualquier herramienta de replicación que elijas, siempre que pueda replicar datos en formato de tabla sin procesar en BigQuery. Por ejemplo, Google Cloud las soluciones incluyen el BigQuery Connector para SAP (requiere SAP SLT), y el BigQuery Toolkit para SAP.

Para garantizar la compatibilidad entre los conjuntos de datos sin procesar replicados de SAP ERP y la capa de base de datos de Cortex Framework, asegúrate de cumplir con los siguientes requisitos.

Requisitos técnicos para replicar datos de SAP ERP

Asegúrate de revisar y completar los siguientes requisitos técnicos para replicar datos de SAP en Cortex Framework en BigQuery.

1. Estructura de datos sin procesar: Los datos de ECC o S/4HANA deben transferirse a BigQuery con la misma estructura que las tablas base en SAP y sin transformaciones comerciales. Las tablas se deben replicar con los nombres de campo, los tipos y la granularidad requeridos tal como existen en SAP.

2. Configuración de la tabla: La lista de tablas que se transformarán se define en el archivo table_settings.yaml (ubicado en config/cortex/data_foundation/sap). Si falta una tabla obligatoria durante la implementación, fallarán los productos de datos específicos que dependan de ella.

3. Requisitos de metadatos: Debes replicar tablas de metadatos como DD03L de tu fuente de SAP al conjunto de datos sin procesar (configurado como la fuente de tu módulo de base en config/config.yaml). Ten en cuenta que, si bien estas tablas de metadatos deben existir en el conjunto de datos sin procesar, no deben incluirse en el archivo table_settings.yaml de la base de datos y la capa de base de datos no las procesa. Asegúrate de que la tabla DD03L replicada contenga los registros de metadatos de campo para cualquier tabla que planees ingerir (como tablas personalizadas o complementarias como sflight). Las secuencias de comandos de compilación de Cortex Framework y el solucionador de dependencias leen estas filas de metadatos para identificar listas de columnas, tipos de datos y relaciones de clave primaria entre tablas.

4. Uso de mayúsculas y minúsculas: Los nombres de las tablas de SAP replicadas en BigQuery deben estar en minúsculas para la compatibilidad del modelo de datos de Cortex Framework (por ejemplo, la tabla de SAP MARA se convierte en mara en BigQuery).

5. Nombres de objetos (columnas) y caracteres especiales: Para los nombres de objetos (columnas) que contienen caracteres especiales (como /, - o guiones bajos iniciales _), Cortex espera un patrón de limpieza genérico:

   • Todos los caracteres que no sean alfanuméricos se reemplazan por un guion bajo _.
   • No se permiten guiones bajos ni dígitos iniciales. Por ejemplo, /GOOG/TEST se convierte en goog_test y _DATAAGING se convierte en dataaging. Si tu herramienta de replicación transfiere datos con guiones bajos iniciales conservados, se requiere un paso de normalización (alias) en la capa de base de datos.

6. Campos de propagación de datos: Para admitir CDC (captura de datos modificados) y la propagación de datos, las tablas de SAP replicadas deben tener lo siguiente:

   • Una marca de operación llamada operation_flag (L = carga inicial, I = insertar, U = actualizar, D = borrar)
   • Una marca de tiempo llamada recordstamp (propagada con la marca de tiempo actual en el momento de la carga)
   • Opcional: Se elige un campo adicional is_deleted (BOOLEAN) en las tablas replicadas _DS_RAW (que se establece en falso de forma predeterminada en la carga inicial). Las vistas de tiempo de ejecución generadas por Cortex hacen referencia a esta columna, pero se puede quitar de las plantillas de CDC y de vista antes de la ejecución si la herramienta de replicación no la produce.

7. Tipos de datos: Asignación necesaria de tipos de datos de SAP con tipos de datos de BigQuery para la compatibilidad:

   Necesario para operaciones estándar:

   Tipo de datos SAP	Tipo de datos de BigQuery	Descripción
   DATS	DATE	Tipo de datos de fecha
   TIMS	TIME	Tipo de datos de hora

8. Muy recomendado para la precisión y la compatibilidad:

   • CURR (moneda) y QUAN (cantidad) asignados a NUMERIC o BIGNUMERIC (evita FLOAT64 para evitar errores de redondeo en los cálculos financieros)
   • NUMC (carácter numérico) asignado a STRING (para conservar los ceros iniciales de los números de documento y los números de artículo, lo que garantiza uniones exitosas)
   Nota: Por lo general, puedes suponer la asignación predeterminada siempre que se puedan aplicar las mismas operaciones en el campo de destino. Si se cambian las asignaciones, los clientes pueden CAST manualmente los tipos de datos en las plantillas.

9. Compresión de carga útil: Para evitar que las columnas de SAP vacías (valores iniciales como espacios o ceros) se completen con NULL en BigQuery, asegúrate de que la compresión de carga útil esté desactivada en la configuración del conector (o que la opción "Enviar sin comprimir" esté habilitada). Esto garantiza que las cadenas vacías o los ceros se conserven como tales en el destino en lugar de establecerse en NULL de forma predeterminada.