Fonte de dados do SAP ERP

A camada de base de dados do Google Cloud Cortex Framework para SAP ERP exige conectividade com os dados brutos do sistema de origem. O SAP ECC e o SAP S/4HANA são compatíveis.

Antes de implantar o conteúdo do Cortex Framework, as tabelas relevantes do SAP ERP precisam ser replicadas no BigQuery. Para isso, você pode inserir dados em um conjunto de dados de camada bruta dedicado para o processamento de captura de dados alterados (CDC, na sigla em inglês) ou usar pipelines de CDC estabelecidos para alimentar a camada de base de dados diretamente. Para mais informações, consulte Requisitos técnicos para replicar dados do SAP ERP.

Você pode usar qualquer ferramenta de replicação de sua escolha, desde que ela possa replicar dados no formato de tabela bruta para o BigQuery. Por exemplo, Google Cloud as soluções incluem o BigQuery Connector para SAP (requer o SAP SLT), e o BigQuery Toolkit para SAP.

Para garantir a compatibilidade entre os conjuntos de dados brutos replicados do SAP ERP e a camada de base de dados do Cortex Framework, atenda aos seguintes requisitos.

Requisitos técnicos para replicar dados do SAP ERP

Analise e conclua os seguintes requisitos técnicos para replicar dados do SAP no Cortex Framework no BigQuery.

  1. Estrutura de dados brutos: os dados do ECC ou do S/4HANA precisam ser inseridos no BigQuery com a mesma estrutura das tabelas de base no SAP e sem transformações comerciais. As tabelas precisam ser replicadas com os nomes de campos, tipos e granularidade necessários, conforme existem no SAP.

  2. Configuração da tabela: a lista de tabelas a serem transformadas é definida no arquivo table_settings.yaml (localizado em config/cortex/data_foundation/sap). Se uma tabela necessária estiver ausente durante a implantação, os produtos de dados específicos que dependem dela vão falhar.

  3. Requisitos de metadados: é necessário replicar tabelas de metadados, como DD03L, da sua origem SAP para o conjunto de dados brutos (configurado como a origem do módulo de base em config/config.yaml). Embora essas tabelas de metadados precisem existir no conjunto de dados brutos, elas não podem ser incluídas no arquivo table_settings.yaml da base de dados e não são processadas pela camada de base de dados. Verifique se a tabela DD03L replicada contém os registros de metadados de campo para todas as tabelas que você planeja ingerir (como tabelas personalizadas ou complementares, como sflight). Os scripts de build do Cortex Framework e o resolvedor de dependências leem essas linhas de metadados para identificar listas de colunas, tipos de dados e relações de chave primária entre tabelas.

  4. Maiúsculas e minúsculas: os nomes das tabelas SAP replicadas no BigQuery precisam estar em letras minúsculas para a compatibilidade do modelo de dados do Cortex Framework (por exemplo, a tabela MARA do SAP se torna mara no BigQuery).

  5. Nomes de objetos (colunas) e caracteres especiais: para nomes de objetos (colunas) que contêm caracteres especiais (como /, -, ou sublinhados iniciais _), o Cortex espera um padrão de higienização genérico:

    • Todos os caracteres não alfanuméricos são substituídos por um sublinhado _.
    • Sublinhados e dígitos iniciais não são permitidos. Por exemplo, /GOOG/TEST se torna goog_test, e _DATAAGING se torna dataaging. Se a ferramenta de replicação inserir dados com sublinhados iniciais preservados, uma etapa de normalização (alias) será necessária na camada de base de dados.

  6. Campos de propagação de dados: para oferecer suporte à CDC (captura de dados alterados) e à propagação de dados, as tabelas SAP replicadas precisam ter:

    • Um flag de operação chamado operation_flag (L = carregamento inicial, I = inserir, U = atualizar, D = excluir).
    • Um carimbo de data/hora chamado recordstamp (preenchido com o carimbo de data/hora atual no momento do carregamento).
    • Opcional: um campo adicional is_deleted (BOOLEANO) é escolhido em tabelas _DS_RAW replicadas (com valor padrão "false" no carregamento inicial). As visualizações de execução geradas pelo Cortex referenciam essa coluna, mas ela pode ser removida dos modelos de CDC e de visualização antes da execução se a ferramenta de replicação não a produzir.

  7. Tipos de dados: mapeamento necessário de tipos de dados SAP com tipos de dados do BigQuery para compatibilidade:

    Necessário para operações padrão :

    Tipo de dados SAP Tipo de dados do BigQuery Descrição
    DATS DATE Tipo de dados de data
    TIMS TIME Tipo de dados de hora

  8. Altamente recomendado para precisão e compatibilidade :

    • CURR (moeda) e QUAN (quantidade) mapeados para NUMERIC ou BIGNUMERIC (evite FLOAT64 para evitar erros de arredondamento em cálculos financeiros).
    • NUMC (caractere numérico) mapeado para STRING (para preservar zeros à esquerda para números de documentos e itens, garantindo junções bem-sucedidas).

  9. Compactação de payload: para evitar que colunas SAP vazias (valores iniciais como espaços ou zeros) sejam preenchidas com NULL no BigQuery, verifique se a compactação de payload está desativada na configuração do conector (ou se a opção "Enviar descompactado" está ativada). Isso garante que strings vazias ou zeros sejam preservados como tal no destino, em vez de usar NULL como padrão.