Fonte de dados do SAP ERP

Importante: As etapas descritas nesta página são necessárias para a implantação do Cortex Framework deployment. Para a implantação de demonstração, pule esta página.

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, coloque os 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 use 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 enviados ao 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: replique a tabela DD03L da sua fonte SAP. Essa tabela é essencial para o resolvedor de dependências, porque contém metadados e chaves de campo.

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 SAP MARA 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 enviar 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).
   Observação: geralmente, é possível presumir o mapeamento padrão, desde que as mesmas operações possam ser aplicadas ao campo de destino. Se os mapeamentos forem alterados, os clientes poderão CAST manualmente os tipos de dados nos modelos.

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 serem definidos como NULL por padrão.