Configuración de implementación

En este documento, se explican las opciones de configuración de la implementación de Cortex Framework en las siguientes áreas:

Esta guía también proporciona guías prácticas con instrucciones paso a paso para casos de uso y situaciones de implementación comunes.

Archivo de configuración: config/config.yaml

El archivo config/config.yaml, que suele inicializarse a partir de la plantilla config/config.yaml.example, sirve como configuración principal para la implementación de Cortex Framework. Define parámetros críticos, como el proyecto de Google Cloud ejecución de destino, los conjuntos de datos de BigQuery de origen y destino, y las especificaciones de Dataform, como los nombres del repositorio y del espacio de trabajo.

En las siguientes secciones, se proporciona un desglose detallado de la estructura de config/config.yaml.

Entorno de compilación

El proyecto de entorno de compilación es el proyecto al que se le facturan las acciones de compilación, como los trabajos de BigQuery (lectura de DD03L).

buildEnvironment:
  buildProjectId: YOUR_BUILD_PROJECT_ID

En la siguiente tabla, se describen los parámetros del entorno de compilación.

Parámetro Significado Valor predeterminado Descripción
buildEnvironment.buildProjectId ID del proyecto YOUR_BUILD_PROJECT_ID Google Cloud ID del proyecto en el que se ejecutan las operaciones de compilación.

Descripción general de la sección de datos

La sección data: del archivo de configuración define tus fuentes de datos, tus objetivos y los módulos específicos para la base de datos y los productos de datos. Su estructura general es la siguiente:

data:
   # Geographic location for BigQuery datasets (for example: US, EU, us-central1)
   # For full list see: https://docs.cloud.google.com/cortex/docs/supported-locations
  bigQueryLocation: US
  # List of namespaces for data foundation and product modules.
  namespaces:
    - name: cortex
      path: cortex
  # List of source datasets.
  sources:
    - ...
  # List of target datasets.
  targets:
    - ...

  # Configuration for data foundation and product modules.
  modules:
    # List of foundation modules.
    foundation:
    - ... 
    # List of data product modules.
    product:
    - ...

Datos: Ubicación de BigQuery

Define la ubicación de los conjuntos de datos de origen y destino de BigQuery.

Parámetro Significado Valor predeterminado Descripción
data.bigQueryLocation Ubicación de BigQuery US Ubicación del conjunto de datos de BigQuery (por ejemplo, US, us-central1 o europe-west1)

Datos: Espacio de nombres de Cortex

Define el espacio de nombres de Cortex Framework.

Parámetro Significado Valor predeterminado Descripción
data.namespaces.name Nombre del espacio de nombres - Es el nombre del espacio de nombres de Cortex Framework. Por ejemplo, cortex.
data.namespaces.path Ruta de acceso del espacio de nombres - Ruta del espacio de nombres del Cortex Framework para los subdirectorios que se usan en la carpeta src y config. Por ejemplo, cortex.

Datos: Conjuntos de datos de origen y destino de BigQuery

La lista de fuentes define los conjuntos de datos de BigQuery en los que se replicaron o transmitieron los datos sin procesar del sistema fuente.

Los destinos definen una lista de conjuntos de datos de BigQuery en los que se almacenarán los conjuntos de datos procesados de Dataform.

Se hace referencia a cada uno de los orígenes y destinos desde los módulos con su ID único.

# Data source and target mapping
sources:
  - id: sap_raw
    projectId: YOUR_SOURCE_PROJECT_ID
    datasetId: cortex_sap_raw

targets:
  - id: sap_foundation
    projectId: YOUR_TARGET_PROJECT_ID
    datasetId: cortex7_sap_data_foundation

En la siguiente tabla, se describen los parámetros de asignación de la fuente y el destino de datos.

Parámetro Significado Valor predeterminado Descripción
data.sources.id ID de la fuente - Define el "id" del conjunto de datos de origen del que se extraerán los datos. Por ejemplo, sap_raw.
data.sources.projectId ID del proyecto fuente YOUR_SOURCE_PROJECT_ID Hace referencia al Google Cloud ID del proyecto con datos de origen.
data.sources.datasetId ID del conjunto de datos de BigQuery de origen - Hace referencia al ID del conjunto de datos de BigQuery con los datos de origen. Por ejemplo, cortex_sap_raw.
data.targets.id ID objetivo - Define el "id" del conjunto de datos de destino. Por ejemplo, sap_foundation.
data.targets.projectId ID del proyecto objetivo YOUR_TARGET_PROJECT_ID Hace referencia al ID del proyecto Google Cloud para los datos de destino.
data.targets.datasetId ID del conjunto de datos de BigQuery de destino - Hace referencia al ID del conjunto de datos de BigQuery para los datos de destino. Por ejemplo, cortex7_sap_data_foundation.

Datos: Módulos

Los módulos definen la estructura y los componentes de las canalizaciones de datos de Dataform.

Datos: Módulos: Foundation

En esta sección, se configuran los módulos de la capa de base de datos que procesan los datos de la capa sin procesar (transmisiones de CDC) en una representación estandarizada de los registros más recientes de los datos de origen. En caso de que la fuente proporcione una vista de los registros más recientes directamente, o si el conector del sistema fuente realiza esas transformaciones, el módulo se puede configurar como una fuente de datos externa.

modules:
  # List of foundation modules.
  foundation:
    # Unique identifier for the module instance.
    - moduleId: erp
      # Type of the module (namespaced, for example, cortex.sap).
      type: cortex.sap
      # Reference to the source dataset ID.
      dataSourceId: sap_raw
      # Reference to the target dataset ID.
      dataTargetId: sap_foundation
      # Module-specific configuration settings.
      moduleSettings:
        # SAP version (for example, ecc, s4).
        sapVersion: ecc
        # SAP client number.
        mandt: "100"
      # Whether the module is enabled.
      # enabled: true
      # Whether the foundation is external (does not create target dataset).
      # external: false
      # Custom table settings file, relative to 'config/' file directory
      # Recommended path: '{namespace}/data_foundation/{data_foundation_module_type}/table_settings.yaml'
      # Default path: '../src/data_modules/{namespace}/data_foundation/{data_foundation_module_type}/table_settings.default.yaml'
      # tableSettings: "custom_datafoundation_table_settings.yaml"

En la siguiente tabla, se describen los parámetros de los módulos de la base de datos para la configuración de modules.foundation.

Parámetro Significado Valor predeterminado Descripción
moduleId Identificador del módulo erp Es el identificador único de una instancia específica del módulo de transformación de la base de datos.
type Tipo de lógica del módulo cortex.sap Define la lógica empresarial o la plantilla aplicada (por ejemplo, cortex.sap).
dataSourceId Vínculo de la fuente sap_raw Hace referencia al "id" de la lista data.sources para extraer datos.
dataTargetId Vínculo de destino sap_foundation Hace referencia al "id" de la lista de destinos para enviar datos.
moduleSettings.sapVersion Versión del sistema SAP ecc Solo se aplica a las fuentes de datos de SAP. Determina la lógica específica de la fuente para los sistemas ecc (ECC) o s4 (S/4HANA).
moduleSettings.mandt Cliente de SAP (Mandant) 100 Solo se aplica a las fuentes de datos de SAP. Es el identificador de cliente de SAP de 3 dígitos que se usa para filtrar las filas de datos.
enabled Habilitación del módulo true Especifica si el módulo está habilitado.
external Base externa false Especifica si la base es externa (no crea un conjunto de datos de destino).
tableSettings Configuración de tabla src/data_modules/{namespace}/data_foundation/{data_foundation_module_type}/table_settings.default.yaml Ruta de acceso al archivo de configuración personalizado de Table settings, relativa a este archivo de configuración.
Ruta recomendada: Relativa al directorio "config/": "{namespace}/data_foundation/{data_foundation_module_type}/table_settings.yaml"
Ruta predeterminada: "../src/data_modules/{namespace}/data_foundation/{data_foundation_module_type}/table_settings.default.yaml"

Datos: Módulos: Productos

Los módulos de productos de datos definen las agregaciones, los cálculos y las uniones necesarios para transformar los datos sin procesar en estadísticas que satisfagan casos de uso comerciales específicos.

La configuración de los productos de datos permite establecer un ID único, definir dependencias y hacer referencia al módulo de la base de datos y al conjunto de datos de destino en el que se almacenarán los resultados.

La configuración detallada de los productos de datos determinados se define en los archivos a los que hace referencia la clave: tableSettings.

modules:
  # List of data product modules.
  product:
    # Unique identifier for the data product instance.
    - moduleId: sap_purchasing_organizational_structure
      # Type of the data product (namespaced).
      type: cortex.purchasing_organizational_structure
      # Map of module dependencies.
      dependsOn:
        sapModule: erp
      # Reference to the target dataset ID.
      dataTargetId: product_target
      # Whether the module is enabled.
      # enabled: true

      # Custom table settings file, relative to 'config/' file directory
      # Recommended path: '{namespace}/data_product/{data_product_module_type}/table_settings.yaml'
      # If omitted, defaults to '../src/data_modules/{namespace}/data_product/{data_product_module_type}/table_settings.default.yaml'
      # tableSettings: "custom_dataproduct_table_settings.yaml"

En la siguiente tabla, se describen los parámetros de los módulos de productos de datos para la configuración de modules.product.

Parámetro Significado Valor predeterminado Descripción
moduleId Identificador del módulo - Es el identificador único de una instancia de módulo de transformación específica.
type Tipo de lógica del módulo - Define la lógica empresarial o la plantilla aplicada, que se define en la carpeta src/data_modules/{namespace}/data_product/{data_product_module_type}.
dataTargetId Vínculo de destino product_target Hace referencia al "id" de la lista de destinos para enviar datos.
dependsOn Dependencia upstream sapModule: erp Especifica qué módulo de base debe existir antes de que se pueda compilar el módulo del producto.
enabled Habilitación del módulo true Especifica si el módulo está habilitado.
tableSettings Configuración de tabla src/data_modules/{namespace}/data_product/{data_product_module_type}/table_settings.default.yaml Ruta de acceso al archivo de configuración personalizado de Table settings, relativa a este archivo de configuración.
Ruta recomendada: Relativa al directorio "config/": "{namespace}/data_product/{data_product_module_type}/table_settings.yaml"
Ruta predeterminada: "../src/data_modules/{namespace}/data_product/{data_product_module_type}/table_settings.default.yaml"

Entorno de implementación

Cortex Framework usa Dataform para coordinar las transformaciones de SQL en BigQuery. El bloque deployment: define la configuración de Dataform, que es responsable de la ejecución de las canalizaciones de datos, incluido el proyecto del repositorio, la ubicación, el nombre del repositorio y el nombre del espacio de trabajo de Dataform.

deployment:
  targets:
    - type: dataform
      enabled: true
      targetSettings:
        repositoryProjectId: YOUR_REPO_PROJECT_ID
        repositoryRegion: us-central1
        repositoryName: cortex-repository
        workspaceName: dev
        # serviceAccount: "example@example.com"

En la siguiente tabla, se describen los parámetros de ubicación de los destinos de implementación (deployment.targets:).

Parámetro Significado Valor predeterminado Descripción
type Tipo de implementación dataform Es el tipo de destinos de implementación.
enabled Habilitado/ Inhabilitado true Especifica si el destino de la implementación determinado está habilitado o inhabilitado.
targetSettings.repositoryProjectId ID del proyecto del repositorio YOUR_REPO_PROJECT_ID ID del proyecto Google Cloud en el que se administra el repositorio de Dataform.
targetSettings.repositoryRegion Región del repositorio us-central1 Es la región Google Cloud del repositorio de Dataform (por ejemplo, us-central1 o europe-west1).
targetSettings.repositoryName Nombre del repositorio cortex-repository Nombre específico del repositorio de Dataform.
targetSettings.workspaceName Nombre del espacio de trabajo dev Es el espacio de trabajo específico de Dataform que se usa para el ciclo de implementación.
targetSettings.serviceAccount Correo electrónico de la cuenta de servicio - Es la dirección de correo electrónico de la cuenta de servicio predeterminada para la ejecución del repositorio de Dataform.

Archivo de configuración: table_settings.yaml

En esta guía, se explica cómo usar el archivo table_settings.yaml para configurar las tablas de la base de datos y los productos de datos en Google Cloud Cortex Framework.

El archivo table_settings.yaml específico del módulo de datos controla cómo se ajustan las tablas de origen sin procesar y cómo se materializan los modelos de datos analíticos en BigQuery. Con este archivo, puedes configurar etiquetas, estrategias de materialización y funciones avanzadas de rendimiento de BigQuery, como la partición o el agrupamiento en clústeres.

Resolución de dependencias dinámica

De forma predeterminada, Cortex Framework optimiza la huella de implementación y el tiempo de ejecución implementando y compilando solo las tablas de base que se requieren como dependencias de los productos de datos habilitados. Si una tabla configurada en table_settings.yaml no tiene ningún producto de datos activo que dependa de ella, se omite en la implementación.

Para anular esta optimización y forzar la implementación de una tabla de base, puedes establecer el atributo deployAlways en true (consulta la referencia del parámetro de estilo de la base de datos).

En Google Cloud Cortex Framework, a cada módulo (de base o de producto) se le puede asignar un archivo de configuración de tabla específico en el archivo de configuración de implementación: config/config.yaml con la propiedad tableSettings.

Rutas de configuración

  • Configuración personalizada (recomendada): Para personalizar el comportamiento de la tabla, copia el archivo predeterminado en tu directorio de configuración, modifícalo y haz referencia a su ruta de acceso en config/config.yaml. Las rutas de acceso recomendadas para usar (relativas al directorio config/) son las siguientes:
    • Módulos de base: namespace/data_foundation/data_foundation/custom_table_settings.yaml (p.ej., config/cortex/data_foundation/sap/table_settings.yaml)
    • Módulos de productos: namespace/data_product/data_product/custom_table_settings.yaml (p.ej., config/cortex/data_product/accounting_documents/table_settings.yaml)
  • Respaldo predeterminado: Si se omite tableSettings, el framework recurre automáticamente a lo siguiente:
    • Módulos de base: ../src/data_modules/namespace/data_foundation/data_foundation/table_settings.default.yaml
    • Módulos de productos: ../src/data_modules/namespace/data_product/data_product/table_settings.default.yaml

Estilos de configuración

Hay dos estilos de esquema distintos para table_settings.yaml según la categoría del módulo:

  1. Estilo de la base de datos: Es un mapeo basado en listas que define las relaciones del esquema de origen a destino, el control de CDC (captura de datos modificados) y el diseño de BigQuery.
  2. Estilo del producto de datos: Es una asignación basada en mapas (diccionario) que define cómo se materializan las vistas o tablas analíticas (p.ej., como vistas, tablas o tablas incrementales) y cómo se optimizan.

Ambos estilos admiten tres secciones de nivel raíz para separar las configuraciones por versión del sistema fuente (se usan principalmente para SAP Data Foundation y los productos que dependen de SAP):

  • ecc: Parámetros de configuración que se aplican solo cuando se implementa un sistema fuente de SAP ECC.
  • s4: Parámetros de configuración que se aplican solo cuando se implementa un sistema de origen de SAP S/4HANA.
  • common: Se aplica la configuración independientemente de la versión de SAP (se usa para la configuración universal o conforme).

Estilo de la base de datos

En un módulo de Data Foundation, el archivo table_settings.yaml se estructura como una lista de elementos de tabla en las claves ecc, s4 y common. Cada elemento asigna una tabla de origen sin procesar a una tabla de destino conforme y configura sus parámetros de BigQuery.

Ejemplo de sintaxis de YAML

common:
  - source:
      tableName: bkpf
      isCdc: true
    target:
      tableName: bkpf # Optional: defaults to source tableName if omitted
      tags: [sap, common, finance, hourly]
      clusterDetails:
        columns: [bukrs, gjahr]
      partitionDetails:
        column: budat
        partitionType: time
        timeGrain: day
    deployAlways: false

Referencia del parámetro

Parámetro Tipo Obligatorio Predeterminado / ejemplo Descripción
ecc | s4 | common string No [] Versión o dialecto del sistema de origen
[].deployAlways boolean No false Si es true, la tabla siempre se implementa y compila, incluso si las reglas de optimización podrían omitirla. Consulta también Resolución de dependencias dinámicas
Configuración de las fuentes

Define las características de la tabla de entrada sin procesar.

Parámetro Tipo Obligatorio Predeterminado / ejemplo Descripción
tableName string Yes bkpf Nombre de la tabla de origen sin procesar en BigQuery (no distingue mayúsculas de minúsculas).
isCdc boolean No true Indica si la tabla de origen contiene registros de captura de datos modificados (CDC).

• true (predeterminado): El framework procesa los registros de CDC (con marcas de tiempo de registros y marcas de operación) para reconstruir el estado confirmado más reciente.

• false: La tabla se procesa como una instantánea completa.
Configuración del objetivo

Define el diseño de la tabla de salida conforme en el conjunto de datos de destino.

Parámetro Tipo Obligatorio Predeterminado / ejemplo Descripción
tableName string No *(Igual que la fuente)* Es el nombre de la tabla de destino que se creará. Si se omite, el framework usa de forma predeterminada la fuente tableName.
tags array[string] No [sap, finance] Es una lista de etiquetas de metadatos adjuntas a la acción conforme en Dataform. Son cadenas arbitrarias y no es necesario registrarlas previamente ni definirlas en otras configuraciones. Se pueden usar de inmediato para filtrar las ejecuciones de la canalización (p. ej., con dataform run --tags ...).
clusterDetails map No — Es opcional. Es la configuración del agrupamiento en clústeres de BigQuery. Consulta Detalles del agrupamiento en clústeres.
partitionDetails map No — Es opcional. Es la configuración de la partición de BigQuery. Consulta los detalles de la partición.

Estilo del producto de datos

En un módulo de producto de datos, el archivo table_settings.yaml se estructura como un diccionario (mapa) en las claves ecc, s4 y common. Las claves del diccionario representan los nombres de la tabla o vista analítica, y los valores definen su materialización y configuración de rendimiento.

Ejemplo de sintaxis de YAML

s4:
  customers:
    materializationType: incremental
    tags: [sap, dataproduct, masterdata]
    clusterDetails:
      columns: [mandt, ktokd]

Referencia del parámetro

Parámetro Tipo Obligatorio Predeterminado / ejemplo Descripción
ecc | s4 | common map No {} Es un mapa de los recursos analíticos de destino (tablas o vistas) y sus configuraciones.
[table_name].materializationType string No incremental Cómo se compila el activo analítico en BigQuery

Valores permitidos:

  • incremental: Solo procesa los registros nuevos o actualizados desde la última ejecución. Se recomienda para grandes conjuntos de datos transaccionales para ahorrar costos.
  • table: Vuelve a crear la tabla desde cero en cada ejecución.
  • view: Implementa el activo como una vista de SQL de BigQuery (tabla virtual).
[table_name].tags array[string] No [sap, dataproduct] Son las etiquetas de metadatos adjuntas al recurso analítico en Dataform. Son cadenas arbitrarias y no es necesario registrarlas previamente. Se pueden usar de inmediato para ejecuciones de canalizaciones selectivas.
[table_name].clusterDetails map No — Es opcional. Es la configuración del agrupamiento en clústeres de BigQuery. Consulta Detalles del agrupamiento en clústeres.
[table_name].partitionDetails map No — Es opcional. Es la configuración de la partición de BigQuery. Consulta los detalles de la partición.

Configuraciones avanzadas de BigQuery

Ambos estilos comparten la misma estructura para optimizar el almacenamiento y el rendimiento de las consultas de BigQuery a través del agrupamiento en clústeres y la partición.

Detalles del agrupamiento en clústeres

La agrupación en clústeres coloca los datos en la misma ubicación según los valores de columnas específicas. BigQuery ordena los datos dentro de cada bloque de almacenamiento con estas columnas, lo que acelera drásticamente las consultas que filtran (WHERE) o unen (JOIN) en ellas.

clusterDetails:
  columns: [bukrs, gjahr]
Referencia del parámetro
Parámetro Tipo Obligatorio Ejemplo Descripción
columns array[string] Yes [bukrs, gjahr] Es una lista ordenada de hasta cuatro nombres de columnas por las que se agrupará la tabla en clústeres.

Restricción: Las columnas deben ser alfanuméricas y contener solo guiones bajos. El orden de las columnas en la lista determina la jerarquía de clasificación.

Detalles de la partición

La partición divide una tabla grande en segmentos físicos más pequeños según los valores de una columna de fecha, marca de tiempo o número entero. Esto evita que BigQuery analice la tabla completa cuando una consulta solo solicita un rango específico de días, meses o IDs.

partitionDetails:
  column: budat
  partitionType: time
  timeGrain: day
Referencia del parámetro
Parámetro Tipo Obligatorio Ejemplo Descripción
column string Yes budat Nombre de la columna que se usa para particionar la tabla. Solo debe contener caracteres alfanuméricos y guiones bajos. El tipo de columna debe coincidir con el partitionType.
partitionType string Yes time Es la estrategia de partición.

Valores permitidos:

  • time: Particiona por una unidad de tiempo (columna de fecha, marca de tiempo o fecha y hora).
  • DATE: Particiona de forma explícita por una columna de fecha.
  • integer: Particiona por un rango de números enteros.
timeGrain string No day Obligatorio si partitionType es time o DATE. Define la granularidad de las particiones de tiempo.

Valores permitidos: hour, day, month, year (no distingue mayúsculas de minúsculas).
rangeStart integer No 1 Obligatorio si partitionType es integer. Es el valor inicial de la primera partición (inclusivo).
rangeEnd integer No 1000 Obligatorio si partitionType es integer. Es el valor final de la última partición (exclusivo).
rangeInterval integer No 10 Obligatorio si partitionType es integer. Es el ancho de cada intervalo de partición.

Ejemplos

En los siguientes ejemplos, se muestran plantillas de configuración para los módulos de la base de datos y del producto de datos, en las que se describe cómo personalizar las tablas de destino, optimizar el diseño de almacenamiento en BigQuery y configurar los tipos de materialización.

1. Ejemplo de configuración de la tabla de datos personalizada

En este ejemplo, se muestra cómo configurar una capa de base con tablas transaccionales particionadas y agrupadas (como bseg y ekbe) junto con tablas de datos estándares:

# ==============================================================================
# S/4HANA-Specific Tables
# ==============================================================================
s4:
  # ACDOCA is a massive table in S/4HANA; clustering is vital
  - source:
      tableName: acdoca
    target:
      tags: [sap, s4, finance, transactional, hourly]
      clusterDetails:
        columns: [rclnt, rbukrs, gjahr]

# ==============================================================================
# ECC-Specific Tables
# ==============================================================================
ecc:
  - source:
      tableName: faglflexa
    target:
      tags: [sap, ecc, finance, transactional, hourly]

# ==============================================================================
# Common Tables (ECC & S/4HANA)
# ==============================================================================
common:
  # Financial document header (partitioned by posting date)
  - source:
      tableName: bkpf
      isCdc: true
    target:
      tags: [sap, common, finance, hourly]
      clusterDetails:
        columns: [bukrs, gjahr]
      partitionDetails:
        column: budat
        partitionType: time
        timeGrain: day

  # Purchasing document items (partitioned by creation date)
  - source:
      tableName: ekpo
    target:
      tags: [sap, common, logistics, purchasing, hourly]
      clusterDetails:
        columns: [mandt, ebeln]
      partitionDetails:
        column: aedat
        partitionType: time
        timeGrain: month

  # Standard master data table (no partitioning/clustering needed)
  - source:
      tableName: lfa1
    target:
      tags: [sap, common, masterdata, vendor, daily]

2. Ejemplo de configuración personalizada de la tabla de productos de datos

En este ejemplo, se muestra cómo configurar los tipos de materialización para los productos de datos analíticos posteriores. Establecemos sales_documents transaccional como incremental para optimizar el rendimiento de la compilación y ahorrar costos, mientras que las tablas de datos no transaccionales, como customers, se compilan como tablas estándar:

# settings applied for both ECC and S/4HANA pipelines
common:
  # Transactional data product - incremental build
  sales_documents:
    materializationType: incremental
    tags: [sap, dataproduct, sales, transactional]
    clusterDetails:
      columns: [vkorg, vbeln]
    partitionDetails:
      column: audat
      partitionType: time
      timeGrain: day

  # Master data product - full table rebuild
  customers:
    materializationType: table
    tags: [sap, dataproduct, masterdata]
    clusterDetails:
      columns: [mandt, ktokd]

  # Aggregated reporting view - virtual view
  sales_performance_summary:
    materializationType: view
    tags: [sap, dataproduct, sales, reporting]

Guías prácticas

En esta sección, se proporcionan guías paso a paso para tareas de configuración comunes y situaciones de implementación personalizadas.

Personaliza el alcance de la tabla en un módulo de la base de datos

Para agregar o quitar tablas dentro de un módulo de base de datos existente sin crear módulos nuevos ni ejecutar instancias de canalización separadas, haz lo siguiente:

  • Copia la configuración predeterminada de table_settings.default.yaml en el directorio de configuración de tu espacio de trabajo (por ejemplo, config/cortex/data_foundation/sap/custom_table_settings.yaml).
  • En tu archivo nuevo, agrega tus tablas personalizadas o quita las tablas estándar que no se usen en las claves ecc, s4 o common según sea necesario:
common:
  - source:
      tableName: custom_table_name
    target:
      tags: [custom_tag]
  • Actualiza config/config.yaml para que haga referencia a la ruta de acceso de la configuración de tu tabla personalizada en la propiedad tableSettings del módulo:
data:
  modules:
    foundation:
      - moduleId: erp
        type: cortex.sap
        # Custom table settings file, relative to configuration file directory
        # Recommended path: '{namespace}/data_foundation/{data_foundation_module_type}/table_settings.yaml'
        tableSettings: 'cortex/data_foundation/sap/custom_table_settings.yaml'

Configura varias instancias de un módulo de base de datos

Para implementar dos o más instancias de canalización separadas del mismo tipo de módulo (por ejemplo, para admitir varias instancias de SAP, segmentar tablas, aislar entornos o segmentar diferentes conjuntos de datos de destino), haz lo siguiente:

Antes de comenzar: * Asegúrate de que las tablas de origen existan en tu conjunto de datos sin procesar de origen. * Asegúrate de que los esquemas del conjunto de datos de destino estén configurados. * Cuando trabajes con módulos de la base de datos de SAP, verifica que la tabla de metadatos DD03L contenga columnas y la información del descriptor para las tablas personalizadas que deseas transferir. Consulta los requisitos de SAP ERP para obtener más detalles.

Instrucciones:

  • En el archivo config/config.yaml, agrega configuraciones de destino en data.targets para definir conjuntos de datos de destino para cada instancia de canalización:
data:
  targets:
    - id: data_foundation_core
      projectId: target_project_id
      datasetId: data_foundation_sap_core
    - id: data_foundation_custom
      projectId: target_project_id
      datasetId: data_foundation_sap_custom
  • Define varias instancias del módulo en la lista data.modules.foundation. Asigna a cada instancia un moduleId único, sus propios IDs de conjunto de datos objetivo y, de manera opcional, la configuración de tableSettings:
data:
  modules:
    foundation:
      # Core SAP ERP foundation module instance
      - moduleId: erp_core
        type: cortex.sap
        dataSourceId: sap_raw
        dataTargetId: data_foundation_core
        # If omitted, defaults to "../src/data_modules/{namespace}/data_foundation/{data_foundation_module_type}/table_settings.default.yaml"
        # tableSettings: "../src/data_modules/cortex/data_foundation/sap/table_settings.default.yaml"
      # Custom tables pipeline instance
      - moduleId: erp_custom
        type: cortex.sap
        dataSourceId: sap_raw
        dataTargetId: data_foundation_custom
        # Custom table settings file, relative to configuration file directory
        # Recommended path: 'config/{namespace}/data_foundation/{data_foundation_module_type}/table_settings.yaml'
        tableSettings: "cortex/data_foundation/sap/custom_datafoundation_table_settings.yaml"
  • Crea el archivo config/cortex/data_foundation/sap/custom_datafoundation_table_settings.yaml que especifica el alcance personalizado. P. ej.:
common:
  - source:
      tableName: custom_sap_table_name
    target:
      tags: [sap, s4, hourly]
      clusterDetails:
        columns: [carrid, connid]
      partitionDetails:
        column: fldate
        partitionType: time
        timeGrain: day
  • Aplica los cambios ejecutando la secuencia de comandos de implementación (uv run cortex-build-and-deploy) y, luego, ejecuta las acciones de Dataform como se describe en Pasos posteriores a la implementación.