Resolver problemas de acesso ao SAP BDC

Nesta página, explicamos como resolver problemas comuns ao integrar o SAP Business Data Cloud (BDC) ao BigQuery. Para o fluxo de trabalho do SAP para o Google Cloud (federação), consulte a página de solução de problemas do Lakehouse.

Erros NOT_FOUND ou PERMISSION_DENIED ao consultar tabelas

Esse problema ocorre quando o acesso é revogado no lado do SAP BDC. As consultas às tabelas afetadas falham e retornam um erro "não encontrado" ou "permissão negada" originário do endpoint do Delta Sharing.

Para resolver esse problema, trabalhe com o administrador do SAP para restaurar o acesso às tabelas. Para mais informações sobre o gerenciamento de acesso no SAP, consulte Trabalhar com produtos de dados no SAP Business Data Cloud Connect na documentação do SAP (link em inglês).

Não é possível gravar dados em tabelas do SAP BDC

Esse problema ocorre quando você tenta gravar ou modificar dados nas tabelas do SAP BDC no BigQuery. Essa integração oferece acesso somente leitura aos dados do SAP BDC.

Para resolver esse problema, modifique os dados diretamente no SAP BDC.

Cobranças inesperadas de preços para chamadas da API Delta Sharing

Esse problema pode ocorrer se o catálogo do Lakehouse for sincronizado com muita frequência com o SAP BDC, que chama as APIs Delta Sharing para listar tabelas e receber metadados de tabelas. Essas chamadas de API são cobradas como operações da classe A do Lakehouse.

Para resolver esse problema, aumente o intervalo de atualização do catálogo para reduzir a frequência das chamadas de API. Para mais informações sobre preços, consulte Preços do Lakehouse.

O SAP não consegue encontrar ou consultar tabelas publicadas

Esse problema pode ocorrer se os metadados do Apache Iceberg exigidos pelo SAP BDC não tiverem sido gerados corretamente no bucket do Cloud Storage.

Para resolver esse problema, verifique se os arquivos de metadados esperados existem no caminho de armazenamento que faz backup da tabela:

  1. Liste o conteúdo da pasta metadata da tabela:

    gcloud storage ls "gs://BUCKET_NAME/NAMESPACE_NAME/TABLE_NAME/metadata/"

  2. Verifique se a saída contém arquivos de metadados padrão do Apache Iceberg, incluindo:

    • version-hint.txt
    • v*.metadata.json
    • Arquivos de manifesto (.avro). Se esses arquivos estiverem ausentes, verifique a configuração do catálogo REST do Iceberg ou as operações de gravação no BigQuery para garantir que os dados e metadados estejam sendo materializados com sucesso no bucket de armazenamento.

A publicação da tabela falha com erro de chave primária ausente ou campo anulável

Esse problema ocorre quando você publica um catálogo do Apache Iceberg ou um produto de dados no SAP BDC, mas as tabelas no catálogo ou produto de dados não têm uma chave primária definida nos metadados do Iceberg, ou uma das colunas de chave primária é definida como anulável (required: false).

Quando isso ocorre, a publicação falha com um dos seguintes erros:

  • INVALID_ARGUMENT: Failed to generate Core Schema Notation (CSN) payload: Table 'TABLE_NAME' must have a primary key constraint to be published to SAP.
  • INVALID_ARGUMENT: Field COLUMN_NAME is not required, but is referenced in the identifier-field-ids property.

O SAP BDC exige que todas as tabelas publicadas definam restrições de chave primária usando identifier-field-ids nos metadados do Iceberg. De acordo com a especificação do Apache Iceberg, todas as colunas designadas em identifier-field-ids também precisam ser configuradas como não anuláveis (required: true).

Para resolver esse problema, execute uma atualização de esquema atômica usando a API REST do BigLake Iceberg para marcar as colunas de chave primária como required: true e especifique os IDs de campo em identifier-field-ids:

  1. Consiga um token de acesso para autorização:

    TOKEN=$(gcloud auth application-default print-access-token)

  2. Envie uma confirmação de atualização do esquema REST do Iceberg usando Python:

    import requests

headers = {
    "Authorization": f"Bearer {TOKEN}",
    "x-goog-user-project": "PROJECT_ID",
    "X-Iceberg-Access-Delegation": "vended-credentials",
    "Content-Type": "application/json",
}
url = "https://biglake.googleapis.com/iceberg/v1/restcatalog/v1/projects/PROJECT_ID/catalogs/ICEBERG_CATALOG_ID/namespaces/NAMESPACE_NAME/tables/TABLE_NAME"

# 1. Fetch current metadata
meta = requests.get(url, headers=headers).json()["metadata"]
schema = meta["schemas"][0].copy()
schema["fields"] = [f.copy() for f in schema["fields"]]

# 2. Mark primary key column as required (non-nullable) and set identifier-field-ids
for f in schema["fields"]:
  if f["name"] == "PRIMARY_KEY_COLUMN_NAME":
    f["required"] = True
schema["identifier-field-ids"] = [PRIMARY_KEY_FIELD_ID]
schema["schema-id"] = meta.get("last-schema-id", 0) + 1

# 3. Commit the updated schema
update_payload = {
    "requirements": [{"type": "assert-table-uuid", "uuid": meta["table-uuid"]}],
    "updates": [
        {
            "action": "add-schema",
            "schema": schema,
            "last-column-id": meta.get("last-column-id", 0),
        },
        {"action": "set-current-schema", "schema-id": -1},
    ],
}
response = requests.post(url, headers=headers, json=update_payload)
response.raise_for_status()

    Substitua:

    • PROJECT_ID: o ID do Google Cloud projeto.
    • ICEBERG_CATALOG_ID: o ID do catálogo REST do Iceberg.
    • NAMESPACE_NAME: o nome do namespace do Iceberg.
    • TABLE_NAME: o nome da tabela do Iceberg.
    • PRIMARY_KEY_COLUMN_NAME: o nome da coluna a ser definida como chave primária.
    • PRIMARY_KEY_FIELD_ID: o ID do campo inteiro da coluna de chave primária (por exemplo, 1).

As consultas no SAP falham com erros de permissão ou não encontrado

Esse problema pode ocorrer se o acesso for revogado ou as permissões forem modificadas no BigQuery depois que um catálogo ou produto de dados for publicado no SAP BDC. As consultas às tabelas afetadas vão falhar no lado do SAP, normalmente com um erro "não encontrado" ou "permissão negada" originário do BigQuery.

Para resolver esse problema, verifique se o principal da federação de identidade da carga de trabalho mantém os papéis necessários (como Leitor do BigLake) e se o acesso padrão ao conjunto de dados ou à tabela do BigQuery é concedido. Para mais informações sobre como instalar e consumir produtos de dados no SAP, consulte Instalar produtos de dados na documentação do SAP (link em inglês).

Novas tabelas ou mudanças de metadados não aparecem no SAP BDC

Esse problema pode ocorrer quando você adiciona novas tabelas ou atualiza os metadados de tabelas atuais no catálogo REST do Apache Iceberg ou no produto de dados do Knowledge Catalog, mas as mudanças não ficam visíveis para os consumidores do SAP. Embora os dados subjacentes permaneçam atualizados, as atualizações de metadados podem exigir uma ação explícita.

Para resolver esse problema, execute uma nova ação de publicação (gcloud biglake data-product-sharing publish) para o catálogo ou produto de dados para que os novos metadados possam ser descobertos no SAP BDC.

Não é possível gravar dados do SAP de volta no BigQuery

Esse problema ocorre quando você tenta usar a integração do SAP publicada para gravar ou modificar dados no BigQuery do SAP BDC. Essa integração oferece acesso somente leitura aos dados do BigQuery do SAP BDC para evitar a substituição acidental de dados ou violações de segurança.

Para resolver esse problema, manipule e grave os dados de origem diretamente usando BigQuery ou pipelines padrão Google Cloud .

Erros RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER ao consultar tabelas

Esse problema pode ocorrer se o ambiente tiver o VPC Service Controls aplicado e o perímetro aplicado ao projeto restringir o serviço storage.googleapis.com. Como o Dremel precisa ler os buckets do Cloud Storage recebidos no projeto do SAP ao consultar tabelas, a solicitação é proibida porque o projeto do SAP está fora do perímetro.

Para resolver esse problema, configure uma regra de saída do VPC Service Controls. Para mais informações sobre a configuração, consulte Configuração do VPC Service Controls para o SAP BDC.