Tópicos avançados de CDC do SAP

APLICA-SE A: Azure Data Factory Azure Synapse Analytics

Saiba mais sobre tópicos avançados do conector de CDC do SAP, como integração de dados controlada por metadados, depuração e muito mais.

Parametrizando um fluxo de dados de mapeamento de CDC do SAP

Um dos principais pontos fortes dos pipelines e fluxos de dados de mapeamento no Azure Data Factory e no Azure Synapse Analytics é o suporte à integração de dados controlada por metadados. Com esse recurso, é possível projetar um único (ou poucos) pipeline parametrizado que pode ser usado para lidar com a integração de centenas ou até milhares de fontes. O conector de CDC do SAP foi projetado com esse princípio em mente: todas as propriedades relevantes, seja o objeto de origem, o modo de execução, as colunas de chave etc., podem ser fornecidas por meio de parâmetros para maximizar a flexibilidade e o potencial de reutilização dos fluxos de dados de mapeamento de CDC do SAP.

Para entender os conceitos básicos de parametrização de fluxos de dados de mapeamento, leia Parametrização de fluxos de dados de mapeamento.

Na galeria de modelos do Azure Data Factory e do Azure Synapse Analytics, você encontra um modelo de pipeline e fluxo de dados que mostra como parametrizar a ingestão de dados de CDC do SAP.

Parametrização da origem e do modo de execução

Os fluxos de dados de mapeamento não exigem necessariamente um artefato de conjunto de dados: as transformações de origem e de coletor oferecem um Tipo de origem (ou Tipo de coletor) embutido. Nesse caso, todas as propriedades de origem definidas de outra forma em um conjunto de dados do ADF podem ser configuradas nas Opções de origem da transformação de origem (ou na guia Configurações da transformação do coletor). O uso de um conjunto de dados embutido oferece uma melhor visão geral e simplifica a parametrização de um fluxo de dados de mapeamento, uma vez que a configuração completa de origem (ou coletor) é mantida em um único local.

Para CDC do SAP, as propriedades que são mais comumente definidas por meio de parâmetros são encontradas nas guias Opções de origem e Otimizar. Quando Tipo de origem é Embutido, as seguintes propriedades podem ser parametrizadas nas Opções de origem.

• Contexto ODP: os valores de parâmetro válidos são
  • ABAP_CDS para Exibições de Serviços de Dados Principais de ABAP
  • BW para SAP BW ou SAP BW/4HANA InfoProviders
  • HANA para Exibições de informações de SAP HANA
  • SAPI para Fontes de Dados/Extratores SAP
  • quando o SAP Landscape Transformation Replication Server (SLT) é usado como uma origem, o nome do contexto ODP é SLT~<Alias de Fila>. O valor do Alias de Fila pode ser encontrado em Dados de Administração na configuração do SLT no cockpit do SLT (transação de LTRC do SAP).
  • ODP_SELF e RANDOM são contextos de ODP usados para validação técnica e testes, e normalmente não são relevantes.
• Nome ODP: forneça o nome do ODP do qual você deseja extrair os dados.
• Modo de execução: os valores de parâmetro válidos são
  • fullAndIncrementalLoad para Completo na primeira execução e, em seguida, incremental, que inicia um processo de captura de dados de alterações e extrai um instantâneo de dados completos atuais
  • fullLoad para Completo em cada execução, que extrai um instantâneo de dados completos atuais sem iniciar um processo de captura de dados de alterações.
  • incrementalLoadpara somente alterações incrementais, que inicia um processo de captura de dados de alterações sem extrair um instantâneo completo atual.
• Colunas de chave: as colunas de chave são fornecidas como uma matriz de cadeias de caracteres (entre aspas duplas). Por exemplo, ao trabalhar com a tabela VBAP (itens de ordem de vendas) do SAP, a definição de chave teria que ser ["VBELN", "POSNR"] (ou ["MANDT","VBELN","POSNR"] caso o campo do cliente também seja levado em consideração).

Parametrização das condições de filtro para particionamento de origem

Na guia Otimizar, um esquema de particionamento de origem (consulte otimização do desempenho para cargas completas ou iniciais) pode ser definido por meio de parâmetros. Normalmente, são necessárias duas etapas:

1. Definir um parâmetro para o esquema de particionamento de origem no nível do pipeline.
2. Ingerir o parâmetro de particionamento no fluxo de dados de mapeamento.

Formato JSON de um esquema de particionamento

O formato na etapa 1 segue o padrão JSON, que consiste em uma matriz de definições de partição, cada uma das quais é uma matriz de condições de filtro individuais. Essas condições são objetos JSON com uma estrutura alinhada com as chamadas opções de seleção no SAP. De fato, o formato exigido pela estrutura do ODP do SAP é basicamente o mesmo dos filtros de DTP dinâmicos no SAP BW:

{ "fieldName": <>, "sign": <>, "option": <>, "low": <>, "high": <> }

Por exemplo

{ "fieldName": "VBELN", "sign": "I", "option": "EQ", "low": "0000001000" }

corresponde a uma cláusula SQL WHERE ... WHERE "VBELN" = '0000001000', ou

{ "fieldName": "VBELN", "sign": "I", "option": "BT", "low": "0000000000", "high": "0000001000" }

corresponde a uma cláusula SQL WHERE ... WHERE "VBELN" BETWEEN '0000000000' AND '0000001000'

Uma definição JSON de um esquema de particionamento contendo duas partições tem a seguinte aparência

[
    [
        { "fieldName": "GJAHR", "sign": "I", "option": "BT", "low": "2011", "high": "2015" }
    ],
    [
        { "fieldName": "GJAHR", "sign": "I", "option": "BT", "low": "2016", "high": "2020" }
    ]
]

em que a primeira partição contém anos fiscais (GJAHR) de 2011 a 2015, e a segunda partição contém os anos fiscais de 2016 a 2020.

As condições de partição podem ser mais complexas, consistindo em várias condições de filtro elementares. Não há conjunções lógicas que definam explicitamente como combinar várias condições elementares em uma partição. A definição implícita no SAP é a seguinte (somente para seleções deinclusão, ou seja, "sign": "I" - para exclusão):

1. condições de inclusão ("sign": "I") para o mesmo nome de campo são combinadas com OR (mentalmente, coloque colchetes ao redor da condição resultante)
2. condições de exclusão ("sign": "E") para o mesmo nome de campo são combinadas com OR (novamente, mentalmente, coloque colchetes ao redor da condição resultante)
3. as condições resultantes das etapas 1 e 2 são
   • combinadas com AND para condições de inclusão,
   • combinadas com AND NOT para condições de exclusão.

Por exemplo, a condição de partição

    [
        { "fieldName": "BUKRS", "sign": "I", "option": "EQ", "low": "1000" },
        { "fieldName": "GJAHR", "sign": "I", "option": "BT", "low": "2020", "high": "2025" },
        { "fieldName": "GJAHR", "sign": "E", "option": "EQ", "low": "2023" }
    ]

corresponde a uma cláusula SQL WHERE ... WHERE ("BUKRS" = '1000') AND ("GJAHR" BETWEEN '2020' AND '2025') AND NOT ("GJAHR" = '2023')

Ingestão do parâmetro de particionamento no fluxo de dados de mapeamento

Para ingerir o esquema de particionamento em um fluxo de dados de mapeamento, crie um parâmetro de fluxo de dados (por exemplo, "sapPartitions"). Para passar o formato JSON para esse parâmetro, ele deve ser convertido em uma cadeia de caracteres usando a função @string():

Por fim, na guia otimizar da transformação de origem em seu fluxo de dados de mapeamento, selecione o Tipo de partição "Origem" e insira o parâmetro de fluxo de dados na propriedade Condições de partição.

Parametrização da Chave de Ponto de Verificação

Ao usar um fluxo de dados parametrizado para extrair dados de várias origens de CDC do SAP, é importante parametrizar a Chave de Ponto de Verificação na atividade de fluxo de dados do pipeline. A chave de ponto de verificação é usada pelo Azure Data Factory para gerenciar o status de um processo de captura de dados de alterações. Para evitar que o status de um processo de CDC substitua o status de outro, certifique-se de que os valores da chave de ponto de verificação sejam exclusivos para cada conjunto de parâmetros usado em um fluxo de dados.

Para obter mais informações sobre a chave de ponto de verificação, consulte Transformar dados com o conector de CDC do SAP.

Depuração

Azure Data Factory pipelines podem ser executados por meio de execuções disparadas ou de depuração. Uma diferença fundamental entre essas duas opções é que as execuções de depuração executam o fluxo de dados e o pipeline com base na versão atual modelada na interface do usuário, enquanto as execuções disparadas executam a última versão publicada de um fluxo de dados e pipeline.

Para CDC do SAP, há mais um aspecto que precisa ser reconhecido: para evitar o impacto das execuções de depuração em um processo existente de captura de dados de alterações, as execuções de depuração usam um valor de "processo de assinante" (consulte Monitorar fluxos de dados de CDC do SAP) das execuções disparadas. Assim, eles criam assinaturas separadas (ou seja, processos de captura de dados de alterações) dentro do sistema SAP. Além disso, o valor do "processo de assinante" para execuções de depuração tem um tempo de vida limitado à sessão da interface do usuário do navegador.