Fuente de datos de SAP ERP

Importante: Los pasos que se describen en esta página son obligatorios para el Deployment del 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 fuente. Se admiten tanto SAP ECC como SAP S/4HANA.

Antes de implementar el contenido de Cortex Framework, las tablas pertinentes del ERP de SAP deben replicarse en BigQuery. Para lograrlo, puedes transferir los datos a un conjunto de datos de capa sin procesar dedicado para el procesamiento de la 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 y cuando pueda replicar datos en formato de tabla sin procesar en BigQuery. Por ejemplo, las soluciones deGoogle Cloud incluyen BigQuery Connector para SAP (requiere SAP SLT) y el kit de herramientas de BigQuery para SAP.

Para garantizar la compatibilidad entre los conjuntos de datos sin procesar replicados del ERP de SAP 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 llegar a BigQuery con la misma estructura que las tablas base en SAP y sin transformaciones comerciales. Las tablas se deben replicar con los nombres, los tipos y la granularidad de los campos 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 la tabla DD03L de tu fuente de SAP. Esta tabla es fundamental para el solucionador de dependencias, ya que contiene metadatos y claves de campos.

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 no 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 (creación de alias) en la capa de Data Foundation.

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

   • Es una marca de operación llamada operation_flag (L = carga inicial, I = inserción, U = actualización, D = eliminación).
   • Una marca de tiempo llamada recordstamp (que se completa con la marca de tiempo actual en el momento de la carga).
   • Opcional: Se elige un campo adicional is_deleted (BOOLEANO) en las tablas _DS_RAW replicadas (el valor predeterminado es falso 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: Es necesaria la asignación de tipos de datos de SAP con tipos de datos de BigQuery para la compatibilidad:

   Necesario para las 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 recomendable 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 documentos y artículos, lo que garantiza combinaciones 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 esté habilitada la opción "Enviar sin comprimir"). Esto garantiza que las cadenas vacías o los ceros se conserven como tales en el destino en lugar de establecerse de forma predeterminada en NULL.