Integração com o SAP

Esta página descreve os passos de integração para cargas de trabalho operacionais da SAP (SAP ECC e SAP S/4 HANA) na base de dados do Cortex Framework. O Cortex Framework pode acelerar a integração de dados SAP com o BigQuery através de modelos de processamento de dados predefinidos com pipelines do Dataflow para o BigQuery, enquanto o Cloud Composer agenda e monitoriza estes pipelines do Dataflow para obter estatísticas dos seus dados operacionais SAP.

O ficheiro config.json no repositório da base de dados do Cortex Framework configura as definições necessárias para transferir dados de qualquer origem de dados, incluindo o SAP. Este ficheiro contém os seguintes parâmetros para cargas de trabalho SAP operacionais:

  "SAP": {
        "deployCDC": true,
        "datasets": {
            "cdc": "",
            "raw": "",
            "reporting": "REPORTING"
        },
        "SQLFlavor": "ecc",
        "mandt": "100"
    }

A tabela seguinte descreve o valor de cada parâmetro operacional da SAP:

Embora não exista uma versão mínima do SAP necessária, os modelos ECC foram desenvolvidos na versão suportada mais antiga atual do SAP ECC. As diferenças nos campos entre o nosso sistema e outros sistemas são esperadas, independentemente da versão.

Modelo de dados

Esta secção descreve os modelos de dados SAP (ECC e S/4 HANA) através dos diagramas de relação entre entidades (ERD).

Visualizações de base

Estes são os objetos azuis no DRE e são vistas em tabelas de CDC sem transformações, exceto alguns alias de nomes de colunas. Veja guiões em src/SAP/SAP_REPORTING.

Visualizações de propriedade de relatórios

Estes são os objetos verdes no DER e contêm os atributos dimensionais relevantes usados pelas tabelas de relatórios. Veja guiões em src/SAP/SAP_REPORTING.

Vista de utilidade ou BQML

Estes são os objetos amarelos no DER e contêm os factos e as dimensões associados, bem como o tipo específico de vista usado para a análise de dados e a criação de relatórios. Veja scripts em src/SAP/SAP_REPORTING.

Etiquetas adicionais

As etiquetas codificadas por cores neste DER representam as seguintes caraterísticas das tabelas de relatórios:

Pré-requisitos para a replicação do SAP

Considere os seguintes pré-requisitos para os dados de replicação do SAP com a base de dados do Cortex Framework:

• Integridade dos dados: a base de dados do Cortex Framework espera que as tabelas SAP sejam replicadas com nomes de campos, tipos e estruturas de dados idênticos aos existentes no SAP. Desde que as tabelas sejam replicadas com o mesmo formato, nomes de campos e detalhe que na origem, não é necessário usar uma ferramenta de replicação específica.
• Nomenclatura de tabelas: os nomes das tabelas do BigQuery têm de ser criados em letras minúsculas.
• Configuração da tabela: a lista de tabelas usadas pelos modelos SAP está disponível e é configurável no ficheiro cdc_settings.yaml (captura de dados de alterações) do CDC. Se uma tabela não estiver listada durante a implementação, os modelos que dependem dela falham, embora outros modelos não dependentes sejam implementados com êxito.
• Considerações específicas BigQuery Connector for SAP:
  • Mapeamento de tabelas: acerca da opção de conversão, siga a documentação de mapeamento de tabelas predefinida.
  • Desativar a compressão de registos: recomendamos que desative a compressão de registos, que pode afetar a camada CDC do Cortex e o conjunto de dados de relatórios do Cortex.
• Replicação de metadados: se não estiver a implementar dados de teste e a gerar scripts DAG de CDC durante a implementação, certifique-se de que a tabela DD03L para metadados SAP é replicada do SAP no projeto de origem. Esta tabela contém metadados sobre tabelas, como a lista de chaves, e é necessária para o gerador de CDC e o resolvedor de dependências funcionarem. Esta tabela também permite adicionar tabelas não abrangidas pelo modelo, por exemplo, tabelas personalizadas ou Z, para que os scripts de CDC possam ser gerados.

• Processamento de pequenas variações nos nomes das tabelas: se existirem pequenas diferenças no nome de uma tabela, algumas vistas podem não encontrar os campos necessários, porque os sistemas SAP podem ter pequenas variações devido a versões ou suplementos, ou porque algumas ferramentas de replicação podem ter um processamento ligeiramente diferente dos carateres especiais. Recomendamos que execute a implementação com turboMode : false para detetar a maioria das falhas numa tentativa. Seguem-se alguns problemas comuns:

  • Os campos que começam por _ (por exemplo, _DATAAGING) têm o _ removido.
  • Os campos não podem começar com / no BigQuery.

  Nesta situação, pode ajustar a vista com falhas para selecionar o campo tal como é apresentado pela ferramenta de replicação à sua escolha.

Replicação de dados não processados do SAP

O objetivo da base de dados é expor dados e modelos de estatísticas para relatórios e aplicações. Os modelos consomem os dados replicados de um sistema SAP através de uma ferramenta de replicação preferencial, como as indicadas nos guias de integração de dados para SAP.

Os dados do sistema SAP (ECC ou S/4 HANA) são replicados na forma não processada. Os dados são copiados diretamente do SAP para o BigQuery sem alterações à respetiva estrutura. É essencialmente uma imagem espelhada das tabelas no seu sistema SAP. O BigQuery usa nomes de tabelas em letras minúsculas para o respetivo modelo de dados. Assim, embora as tabelas SAP possam ter nomes em maiúsculas (como MANDT), são convertidas em minúsculas (como mandt) no BigQuery.

Processamento de captura de dados de alterações (CDC)

Escolha um dos seguintes modos de processamento de CDC que o Cortex Framework oferece para que as ferramentas de replicação carreguem registos do SAP:

• Anexar sempre: insere todas as alterações num registo com uma data/hora e um indicador de operação (inserir, atualizar, eliminar), para que a última versão possa ser identificada.
• Update when landing (merge or upsert): crie uma versão atualizada de um registo quando este for carregado no change data capture processed. Executa a operação de CDC no BigQuery.

A base de dados do Cortex Framework suporta ambos os modos, embora, para a opção de anexar sempre, forneça modelos de processamento de CDC. Algumas capacidades têm de ser comentadas para atualização na página de destino. Por exemplo, OneTouchOrder.sql e todas as respetivas consultas dependentes. A capacidade pode ser substituída por tabelas como CDPOS.

Configure modelos de CDC para ferramentas de replicação no modo de anexação sempre

Recomendamos vivamente que configure o cdc_settings.yaml de acordo com as suas necessidades. Algumas frequências predefinidas podem resultar num custo desnecessário se a empresa não precisar desse nível de atualização dos dados. Se usar uma ferramenta que é executada no modo de anexação sempre, a base de dados do Cortex Framework fornece modelos de CDC para automatizar as atualizações e criar uma versão mais recente da verdade ou do gémeo digital no conjunto de dados processado de CDC.

Pode usar a configuração no ficheiro cdc_settings.yaml se precisar de gerar scripts de processamento de CDC. Consulte o artigo Configure o processamento de CDC para ver as opções. Para dados de teste, pode deixar este ficheiro como predefinição.

Faça todas as alterações necessárias aos modelos DAG de acordo com a sua instância do Airflow ou do Cloud Composer. Para mais informações, consulte o artigo Recolher definições do Cloud Composer.

Opcional: se quiser adicionar e processar tabelas individualmente após a implementação, pode modificar o ficheiro cdc_settings.yaml para processar apenas as tabelas de que precisa e voltar a executar o módulo especificado chamando src/SAP_CDC/cloudbuild.cdc.yaml diretamente.

Configure o processamento de CDC

Durante a implementação, pode optar por unir as alterações em tempo real através de uma vista no BigQuery ou agendando uma operação de união no Cloud Composer (ou qualquer outra instância do Apache Airflow). O Cloud Composer pode agendar os scripts para processar as operações de união periodicamente. Os dados são atualizados para a versão mais recente sempre que as operações de união são executadas. No entanto, as operações de união mais frequentes traduzem-se em custos mais elevados. Personalize a frequência agendada de acordo com as necessidades da sua empresa. Para mais informações, consulte o artigo Programação suportada pelo Apache Airflow.

O script de exemplo seguinte mostra um extrato do ficheiro de configuração:

  data_to_replicate:
    - base_table: adrc
      load_frequency: "@hourly"
    - base_table: adr6
      target_table: adr6_cdc
      load_frequency: "@daily"

Este ficheiro de exemplo de configuração faz o seguinte:

1. Crie uma cópia de SOURCE_PROJECT_ID.REPLICATED_DATASET.adrc para TARGET_PROJECT_ID.DATASET_WITH_LATEST_RECORDS.adrc, se este último não existir.
2. Crie um script de CDC no contentor especificado.
3. Crie uma cópia de SOURCE_PROJECT_ID.REPLICATED_DATASET.adr6 em TARGET_PROJECT_ID.DATASET_WITH_LATEST_RECORDS.adr6_cdc, se este último não existir.
4. Crie um script de CDC no contentor especificado.

Se quiser criar DAGs ou vistas de tempo de execução para processar alterações a tabelas que existem no SAP e não estão listadas no ficheiro, adicione-as a este ficheiro antes da implementação. Isto funciona desde que a tabela DD03L seja replicada no conjunto de dados de origem e o esquema da tabela personalizada esteja presente nessa tabela. Por exemplo, a seguinte configuração cria um script de CDC para a tabela personalizada zztable_customer e uma vista de tempo de execução para analisar alterações em tempo real para outra tabela personalizada denominada zzspecial_table:

    - base_table: zztable_customer
      load_frequency: "@daily"
    - base_table: zzspecial_table
      load_frequency: "RUNTIME"

Modelo gerado de exemplo

O modelo seguinte gera o processamento de alterações. As modificações, como o nome do campo de data/hora ou operações adicionais, podem ser modificadas neste ponto:

  MERGE `${target_table}` T
  USING (
     SELECT *
     FROM `${base_table}`
     WHERE
        recordstamp > (
            SELECT IF(
                MAX(recordstamp) IS NOT NULL,
                MAX(recordstamp),
                TIMESTAMP("1940-12-25 05:30:00+00"))
            FROM `${target_table}` )
  ) S
  ON ${p_key}
  WHEN MATCHED AND S.operation_flag='D' AND S.is_deleted = true THEN
    DELETE
  WHEN NOT MATCHED AND S.operation_flag='I' THEN
    INSERT (${fields})
    VALUES
    (${fields})
  WHEN MATCHED AND S.operation_flag='U' THEN
  UPDATE SET
      ${update_fields}

Em alternativa, se a sua empresa precisar de estatísticas quase em tempo real e a ferramenta de replicação o suportar, a ferramenta de implementação aceita a opção RUNTIME. Isto significa que não é gerado um guião de CDC. Em alternativa, uma vista analisaria e obteria o registo disponível mais recente no tempo de execução para consistência imediata.

Estrutura de diretórios para DAGs e scripts do CDC

A estrutura do contentor do Cloud Storage para os DAGs do SAP CDC espera que os ficheiros SQL sejam gerados em /data/bq_data_replication, como no exemplo seguinte. Pode modificar este caminho antes da implementação. Se ainda não tiver um ambiente do Cloud Composer disponível, pode criar um posteriormente e mover os ficheiros para o contentor de DAGs.

with airflow.DAG("CDC_BigQuery_${base table}",
                template_searchpath=['/home/airflow/gcs/data/bq_data_replication/'], ##example
                default_args=default_dag_args,
                schedule_interval="${load_frequency}") as dag:
    start_task = DummyOperator(task_id="start")
    copy_records = BigQueryOperator(
      task_id='merge_query_records',
        sql="${query_file}",
        create_disposition='CREATE_IF_NEEDED',
        bigquery_conn_id="sap_cdc_bq", ## example
        use_legacy_sql=False)
    stop_task = DummyOperator (task_id="stop")
    start_task >> copy_records >> stop_task

Os scripts que processam dados no Airflow ou no Cloud Composer são gerados intencionalmente em separado dos scripts específicos do Airflow. Isto permite-lhe transferir esses scripts para outra ferramenta à sua escolha.

Campos de CDC obrigatórios para operações MERGE

Especifique os seguintes parâmetros para a geração automática de processos em lote de CDC:

• Projeto de origem + conjunto de dados: conjunto de dados onde os dados SAP são transmitidos ou replicados. Para que os scripts de CDC funcionem por predefinição, as tabelas têm de ter um campo de data/hora (denominado recordstamp) e um campo de operação com os seguintes valores, todos definidos durante a replicação:
  • I: para inserir.
  • U: para atualizar.
  • D: para eliminação.
• Projeto de destino + conjunto de dados para o processamento de CDC: o script gerado gera por predefinição as tabelas a partir de uma cópia do conjunto de dados de origem se não existirem.
• Tabelas replicadas: tabelas para as quais os scripts têm de ser gerados
• Frequência de processamento: seguindo a notação Cron, a frequência com que se espera que os DAGs sejam executados:
• Contentor do Cloud Storage de destino para onde os ficheiros de saída da CDC são copiados.
• Nome da ligação: o nome da ligação usada pelo Cloud Composer.
• (Opcional) Nome da tabela de destino: disponível se o resultado do processamento de CDC permanecer no mesmo conjunto de dados que o destino.

Otimização do desempenho para tabelas de CDC

Para determinados conjuntos de dados de CDC, pode querer tirar partido da partição de tabelas do BigQuery, agrupamento de tabelas ou ambos. Esta escolha depende dos seguintes fatores:

• Tamanho e dados da tabela.
• Colunas disponíveis na tabela.
• Necessidade de dados em tempo real com visualizações.
• Dados materializados como tabelas.

Por predefinição, as definições de CDC não aplicam a partição de tabelas nem o agrupamento de tabelas. A escolha é sua para a configurar com base no que funciona melhor para si. Para criar tabelas com partições ou clusters, atualize o ficheiro cdc_settings.yaml com as configurações relevantes. Para mais informações, consulte os artigos Partição de tabelas e Definições de cluster.

1. Esta funcionalidade só se aplica quando um conjunto de dados no cdc_settings.yaml está configurado para replicação como uma tabela (por exemplo, load_frequency = "@daily") e não definido como uma vista (load_frequency = "RUNTIME").
2. Uma tabela pode ser uma tabela particionada e uma tabela agrupada.

Se estiver a usar uma ferramenta de replicação que permita partições no conjunto de dados não processado, como o conetor do BigQuery para SAP, recomenda-se definir partições baseadas no tempo nas tabelas não processadas. O tipo de partição funciona melhor se corresponder à frequência dos DAGs de CDC na configuração.cdc_settings.yaml Para mais informações, consulte o artigo Considerações de design para a modelagem de dados SAP no BigQuery.

Opcional: configurar o módulo de inventário da SAP

O módulo de inventário SAP do Cortex Framework inclui vistas InventoryKeyMetrics e InventoryByPlant que fornecem estatísticas importantes sobre o seu inventário. Estas visualizações são suportadas por tabelas de instantâneos mensais e semanais que usam DAGs especializados. Ambos podem ser executados ao mesmo tempo e não interferem um com o outro.

Para atualizar uma ou ambas as tabelas de instantâneos, siga estes passos:

1. Atualize SlowMovingThreshold.sql e StockCharacteristicsConfig.sql para definir o limite de movimentação lenta e as caraterísticas de stock para diferentes tipos de materiais, com base nos seus requisitos.

2. Para o carregamento inicial ou a atualização completa, execute os DAGs Stock_Monthly_Snapshots_Initial e Stock_Weekly_Snapshots_Initial.

3. Para atualizações subsequentes, agende ou execute os seguintes DAGs:

   • Atualizações mensais e semanais:
     • Stock_Monthly_Snapshots_Periodical_Update
     • Stock_Weekly_Snapshots_periodical_Update
   • Atualização diária:
     • Stock_Monthly_Snapshots_Daily_Update
     • Stock_Weekly_Snapshots_Update_Daily

4. Atualize as vistas StockMonthlySnapshots e StockWeeklySnapshots intermédias, seguidas das vistas InventoryKeyMetrics e InventoryByPlants, respetivamente, para expor os dados atualizados.

Opcional: configurar a vista de textos da hierarquia de produtos

A vista Textos da hierarquia de produtos reduz os materiais e as respetivas hierarquias de produtos. A tabela resultante pode ser usada para fornecer ao suplemento Trends uma lista de termos para obter o interesse ao longo do tempo. Configure esta vista com os seguintes passos:

1. Ajuste os níveis da hierarquia e o idioma no ficheiro prod_hierarchy_texts.sql, sob os marcadores de ## CORTEX-CUSTOMER.

2. Se a hierarquia de produtos contiver mais níveis, pode ter de adicionar uma declaração SELECT adicional semelhante à expressão de tabela comum h1_h2_h3.

   Podem existir personalizações adicionais consoante os sistemas de origem. Recomendamos que envolva os utilizadores empresariais ou os analistas no início do processo para ajudar a identificá-los.

Opcional: configurar vistas de redução da hierarquia

A partir da versão v6.0, a framework Cortex suporta o achatamento da hierarquia como vistas de relatórios. Esta é uma melhoria significativa em relação ao processador de hierarquias antigo, uma vez que agora processa toda a hierarquia, otimiza melhor para o S/4 ao usar tabelas específicas do S/4 em vez de tabelas ECC antigas e também melhora significativamente o desempenho.

Resumo das visualizações de propriedade de relatórios

Encontre as seguintes vistas relacionadas com a redução da hierarquia:

Tenha em consideração o seguinte quando usar vistas de redução da hierarquia:

• As vistas apenas da hierarquia reduzida são funcionalmente equivalentes às tabelas geradas pela solução de redução da hierarquia antiga.
• As vistas gerais não são implementadas por predefinição, uma vez que destinam-se a apresentar apenas a lógica de inteligência empresarial. Encontre o código-fonte no diretório src/SAP/SAP_REPORTING.

Configurar o achatamento da hierarquia

Com base na hierarquia com a qual está a trabalhar, são necessários os seguintes parâmetros de entrada:

Se não tiver a certeza dos parâmetros exatos, pergunte a um consultor de finanças ou de controlo do SAP.

Depois de os parâmetros serem recolhidos, atualize os comentários ## CORTEX-CUSTOMER em cada um dos diretórios correspondentes, com base nos seus requisitos:

Se aplicável, certifique-se de que atualiza os ## CORTEX-CUSTOMERcomentários nas vistas de relatórios relevantes no diretório src/SAP/SAP_REPORTING.

Detalhes da solução

As seguintes tabelas de origem são usadas para o achatamento da hierarquia:

Visualizar as hierarquias

A solução de nivelamento da hierarquia SAP da Cortex nivela toda a hierarquia. Se quiser criar uma representação visual da hierarquia carregada que seja comparável ao que o SAP mostra na IU, consulte uma das vistas para visualizar hierarquias simplificadas com a condição IsLeafNode=True.

Migrar da solução de redução da hierarquia antiga

Para migrar da solução de redução da hierarquia antiga anterior ao Cortex v6.0, substitua as tabelas, conforme mostrado na tabela seguinte. Certifique-se de que verifica a precisão dos nomes dos campos, uma vez que alguns nomes dos campos foram ligeiramente modificados. Por exemplo, prctr em cepc_hier é agora profitcenter na tabela profit_centers.

Opcional: configurar o módulo de finanças do SAP

O módulo de finanças SAP do Cortex Framework inclui vistas FinancialStatement, BalanceSheet e ProfitAndLoss que fornecem estatísticas financeiras importantes.

Para atualizar estas tabelas de finanças, siga estes passos:

Para visualizar os dados destas tabelas, consulte as seguintes vistas de vista geral:

• ProfitAndLossOverview.sql se estiver a usar a hierarquia de FSV.
• ProfitAndLossOverview_CostCenter.sql se estiver a usar a hierarquia do centro de custos.
• ProfitAndLossOverview_ProfitCenter.sql se estiver a usar a hierarquia do centro de custos.

Opcional: ativar DAGs dependentes de tarefas

O Cortex Framework fornece opcionalmente definições de dependências recomendadas para a maioria das tabelas SQL da SAP (ECC e S/4 HANA), em que todas as tabelas dependentes podem ser atualizadas por um único DAG. Pode personalizá-los ainda mais. Para mais informações, consulte o artigo DAGs dependentes de tarefas.

O que se segue?

• Para mais informações sobre outras origens de dados e cargas de trabalho, consulte o artigo Origens de dados e cargas de trabalho.
• Para mais informações sobre os passos de implementação em ambientes de produção, consulte os Pré-requisitos de implementação da base de dados do Cortex Framework.