Résoudre les problèmes liés au Lakehouse sans bordure pour SAP BDC

Cette page explique comment résoudre les problèmes courants lorsque vous intégrez SAP Business Data Cloud (BDC) à BigQuery. Pour le workflow SAP vers Google Cloud (fédération) à l'aide de Lakehouse sans bordure, consultez la page de dépannage de Lakehouse sans bordure .

Erreurs NOT_FOUND ou PERMISSION_DENIED lors de l'interrogation de tables

Ce problème se produit lorsque l'accès est révoqué côté SAP BDC. Les requêtes adressées aux tables concernées échouent et renvoient une erreur "not found" (introuvable) ou "permission denied" (autorisation refusée) provenant du point de terminaison Delta Sharing.

Pour résoudre ce problème, contactez votre administrateur SAP afin de rétablir l'accès aux tables. Pour en savoir plus sur la gestion des accès dans SAP, consultez la section Working with Data Products in SAP Business Data Cloud Connect de la documentation SAP.

Impossible d'écrire des données dans des tables SAP BDC

Ce problème se produit lorsque vous tentez d'écrire ou de modifier des données dans vos tables SAP BDC à partir de BigQuery. Cette intégration fournit un accès en lecture seule aux données SAP BDC.

Pour résoudre ce problème, modifiez les données directement dans SAP BDC.

Frais de tarification inattendus pour les appels d'API Delta Sharing

Ce problème peut se produire si votre catalogue Lakehouse se synchronise trop fréquemment avec SAP BDC, qui appelle les API Delta Sharing pour lister les tables et obtenir les métadonnées de table. Ces appels d'API sont facturés en tant qu'opérations de classe A Lakehouse.

Pour résoudre ce problème, augmentez l'intervalle d'actualisation du catalogue afin de réduire la fréquence des appels d'API. Pour en savoir plus sur la tarification, consultez la page Tarification de Lakehouse.

SAP ne trouve pas les tables publiées ou ne peut pas les interroger

Ce problème peut se produire si les métadonnées Apache Iceberg requises par SAP BDC n'ont pas été générées correctement dans votre bucket Cloud Storage.

Pour résoudre ce problème, vérifiez que les fichiers de métadonnées attendus existent dans le chemin de stockage qui sauvegarde votre table :

  1. Répertoriez le contenu du dossier metadata de votre table :

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

  2. Vérifiez que la sortie contient des fichiers de métadonnées Apache Iceberg standards, y compris les suivants :

    • version-hint.txt
    • v*.metadata.json
    • Fichiers manifestes (.avro). Si ces fichiers sont manquants, vérifiez la configuration de votre catalogue REST Iceberg ou les opérations d'écriture dans BigQuery pour vous assurer que les données et les métadonnées sont correctement matérialisées dans le bucket de stockage.

Échec de la publication de la table en raison d'une clé primaire manquante ou d'une erreur de champ pouvant accepter la valeur nulle

Ce problème se produit lorsque vous publiez un catalogue Apache Iceberg ou un produit de données dans SAP BDC, mais que les tables du catalogue ou du produit de données ne comportent pas de clé primaire définie dans leurs métadonnées Iceberg, ou que l'une des colonnes de clé primaire est définie comme pouvant accepter la valeur nulle (required: false).

Dans ce cas, la publication échoue et l'une des erreurs suivantes s'affiche :

  • 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.

SAP BDC exige que toutes les tables publiées définissent des contraintes de clé primaire à l'aide de identifier-field-ids dans les métadonnées Iceberg. Conformément à la spécification Apache Iceberg, toutes les colonnes désignées dans identifier-field-ids doivent également être configurées comme ne pouvant pas accepter la valeur nulle (required: true).

Pour résoudre ce problème, effectuez une mise à jour atomique du schéma à l'aide de l'API REST BigLake Iceberg afin de marquer les colonnes de clé primaire comme required: true et de spécifier leurs ID de champ dans identifier-field-ids :

  1. Obtenez un jeton d'accès pour l'autorisation :

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

  2. Envoyez un commit de mise à jour du schéma REST Iceberg à l'aide de 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()

    Remplacez les éléments suivants :

    • PROJECT_ID: ID de votre Google Cloud projet.
    • ICEBERG_CATALOG_ID : ID de votre catalogue REST Iceberg.
    • NAMESPACE_NAME : nom de votre espace de noms Iceberg.
    • TABLE_NAME : nom de votre table Iceberg.
    • PRIMARY_KEY_COLUMN_NAME : nom de la colonne à définir comme clé primaire.
    • PRIMARY_KEY_FIELD_ID : ID de champ entier de la colonne de clé primaire (par exemple, 1).

Les requêtes sur SAP échouent avec des erreurs d'autorisation ou de non-existence

Ce problème peut se produire si l'accès est révoqué ou si les autorisations sont modifiées dans BigQuery après la publication d'un catalogue ou d'un produit de données dans SAP BDC. Les requêtes adressées aux tables concernées échoueront côté SAP, généralement avec une erreur "not found" (introuvable) ou "permission denied" (autorisation refusée) provenant de BigQuery.

Pour résoudre ce problème, vérifiez que le principal de la fédération d'identité de charge de travail conserve les rôles requis (comme Lecteur BigLake) et que l'accès standard aux ensembles de données ou aux tables BigQuery est accordé. Pour en savoir plus sur l'installation et l'utilisation de produits de données dans SAP, consultez la section Installing Data Products de la documentation SAP.

Les nouvelles tables ou les modifications de métadonnées n'apparaissent pas dans SAP BDC

Ce problème peut se produire lorsque vous ajoutez des tables ou mettez à jour des métadonnées de table existantes dans votre catalogue REST Apache Iceberg ou votre produit de données Knowledge Catalog, mais que les modifications ne sont pas visibles pour les consommateurs SAP. Bien que les données sous-jacentes restent à jour, les mises à jour des métadonnées peuvent nécessiter une action explicite.

Pour résoudre ce problème, exécutez une nouvelle action de publication (gcloud biglake data-product-sharing publish) pour le catalogue ou le produit de données afin de rendre les nouvelles métadonnées détectables dans SAP BDC.

Impossible d'écrire des données de SAP vers BigQuery

Ce problème se produit lorsque vous tentez d'utiliser l'intégration SAP publiée pour écrire ou modifier des données dans BigQuery à partir de SAP BDC. Cette intégration fournit un accès en lecture seule aux données BigQuery à partir de SAP BDC afin d'éviter l'écrasement accidentel de données ou les violations de sécurité.

Pour résoudre ce problème, manipulez et écrivez vos données sources directement à l'aide de BigQuery ou de pipelines Google Cloud standards.

Erreurs RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER lors de l'interrogation de tables

Ce problème peut se produire si VPC Service Controls est appliqué à votre environnement et que le périmètre appliqué au projet limite le service storage.googleapis.com. Étant donné que Dremel doit lire les buckets Cloud Storage entrants dans le projet SAP lors de l'interrogation de tables, la requête est interdite, car le projet SAP se trouve en dehors de votre périmètre.

Pour résoudre ce problème, configurez une règle de sortie VPC Service Controls. Pour en savoir plus sur la configuration, consultez la page Configuration de VPC Service Controls pour SAP BDC.