Guide de planification de BigQuery Connector pour SAP

Ce guide de planification fournit aux administrateurs SAP et Google Cloud les informations dont ils ont besoin pour planifier la réplication des données SAP dans BigQuery à l'aide de BigQuery Connector pour SAP version 2.9 (dernière version) avec SAP LT Replication Server.

Ce guide couvre les sujets suivants :

• Configuration logicielle requise
• Sécurité
• Mise en réseau
• Planification des performances
• Options de mappage de table et de champ
• Cycle de vie de l'assistance

Pour en savoir plus sur les accélérateurs de solutions pour la modélisation des données SAP dans BigQuery, consultez Google Cloud Cortex Framework.

Logiciels requis

Cette section décrit la configuration logicielle requise pour BigQuery Connector pour SAP.

Vous pouvez installer BigQuery Connector pour SAP dans SAP LT Replication Server sur Google Cloud, sur site ou sur des clouds publics, tels qu'AWS, Azure, etc.

Exigences concernant la version logicielle SAP

Les versions requises de SAP LT Replication Server et des systèmes sources SAP diffèrent selon que vous installez SAP LT Replication Server sur son propre serveur dans une architecture autonome ou dans le système d'application ABAP source d'une architecture intégrée.

Les exigences logicielles SAP sont également différentes selon le système SAP que vous utilisez comme source de données : SAP S/4HANA ou SAP ECC.

Pour afficher les versions logicielles de SAP que Google Cloud accepte avec BigQuery Connector pour SAP, sélectionnez l'onglet correspondant à votre système source SAP :

Configuration système requise

BigQuery Connector pour SAP est compatible avec tous les systèmes d'exploitation compatibles avec SAP LT Replication Server.

Pour en savoir plus sur les systèmes d'exploitation compatibles avec SAP LT Replication Server, consultez la matrice de disponibilité des produits SAP.

Exigence concernant le compte de facturation Cloud

Bien que BigQuery Connector pour SAP soit proposé sans frais, vous avez besoin d'un compte de facturation Cloud pour recevoir le package d'installation.

Évolutivité

Pour les très gros volumes, tels que des milliards d'enregistrements de données dotés de millions de deltas, BigQuery Connector pour SAP utilise les fonctions de scaling et de partitionnement de SAP LT Replication Server pour charger en parallèle l'extraction de données à grande échelle. Pour en savoir plus, consultez le guide de dimensionnement de votre version de SAP LT Replication Server sur le portail d'aide SAP.

Du côté de Google Cloud , en fonction de votre chemin de réplication, BigQuery Connector pour SAP utilise différents services Google Cloud pour adapter le chargement des données :

• Pour la réplication CDC via Pub/Sub, BigQuery Connector pour SAP utilise l'API Pub/Sub et l'API Storage Write.
• Pour la réplication des données en flux continu, BigQuery Connector pour SAP utilise l'API de streaming BigQuery.

Sources de réplication compatibles

Le connecteur BigQuery pour SAP est compatible avec la plupart des systèmes sources d'applications et de bases de données couramment utilisés par SAP LT Replication Server.

Sources d'applications SAP compatibles

Vous pouvez répliquer les données à partir des sources d'application SAP compatibles avec SAP LT Replication Server. BigQuery Connector pour SAP accepte comme sources de données les principales versions d'applications d'entreprise en cours de maintenance, ainsi que les anciennes applications. Voici quelques-unes des applications SAP compatibles :

• SAP Business Suite 7
• S/4HANA
• Applications SAP s'exécutant sur SAP NetWeaver

Pour répliquer des données à partir de SAP Business Warehouse, SAP déconseille d'utiliser SAP LT Replication Server. Pour en savoir plus sur SAP, consultez la note SAP 2525755.

Les applications SAP Cloud, telles que S/4HANA Cloud, SAP Ariba, SAP SuccessFactors et autres, ne sont pas compatibles.

Sources de données prises en charge

Vous ne pouvez répliquer que des tables transparentes ou des tables de cluster.

BigQuery Connector pour SAP n'est pas compatible avec les vues de réplication SAP Core Services (CDS).

Dans l'outil de conception d'informations, BigQuery est compatible avec SAP BusinessObjects Business Intelligence 4.3 en tant que source de données. Vous pouvez interroger les données stockées dans BigQuery à partir des outils de création de rapports SAP BusinessObjects, tels que SAP BusinessObjects Web Intelligence et SAP Crystal Reports for Enterprise, entre autres.

Pour en savoir plus sur la compatibilité, consultez la note SAP 2750723 - Assistance de Google BigQuery dans les produits de plate-forme d'informatique décisionnelle SAP.

Sécurité

Lorsque vous mettez en œuvre la sécurité pour la réplication de données de SAP LT Replication Server vers BigQuery, vous devez mettre en œuvre des contrôles de sécurité dans SAP LT Replication Server, dans le système d'exploitation hôte SAP LT Replication Server et dansGoogle Cloud.

Pour la communication entre BigQuery Connector pour SAP et BigQuery, BigQuery Connector pour SAP utilise la communication HTTPS de bout en bout et le protocole SSL.

Sécurité SAP

Pour déterminer qui peut configurer et utiliser BigQuery Connector pour SAP dans SAP LT Replication Server, vous devez utiliser l'autorisation standard basée sur les rôles SAP.

BigQuery Connector pour SAP fournit l'objet d'autorisation ZGOOG_MTID dans le cadre de l'installation du transport.

Pour configurer et exécuter des tâches de réplication de données qui utilisent BigQuery Connector pour SAP, vous pouvez définir un rôle disposant d'un accès administrateur dans SAP LT Replication Server, comme décrit dans la section Créer des rôles et des autorisations SAP pour BigQuery Connector pour SAP.

Par exemple, vous pouvez définir un rôle appelé ZGOOGLE_BIGQUERY_ADMIN qui dispose de toutes les autorisations SAP et des autorisations ZGOOG_MTID requises pour configurer et exploiter la réplication de données vers BigQuery à l'aide de BigQuery Connector pour SAP.

Pour en savoir plus sur les rôles et les autorisations, consultez le guide de sécurité pour votre version de SAP LT Replication Server sur le portail d'aide SAP.

Google Cloud sécurité

La mise en œuvre de la sécurité sur Google Cloud pour BigQuery Connector pour SAP peut impliquer les contrôles de sécurité suivants :

• Autorisations, rôles, comptes de service et clés IAM (Identity and Access Management)
• Contrôles BigQuery définis au niveau de l'ensemble de données ou de la table
• Contrôles de service de cloud privé virtuel (VPC) pour les services basés sur des API comme BigQuery
• Points de terminaison Private Service Connect qui autorisent la consommation privée de services, tels que BigQuery, sur les réseaux VPC.

Google Cloud Identity and Access Management

Pour l'authentification et l'autorisation de BigQuery Connector pour SAP, vous devez disposer d'un compte de service IAM dans le projetGoogle Cloud qui contient votre ensemble de données BigQuery.

Pour autoriser l'interaction avec les ressources Google Cloud , vous attribuez des rôles au compte de service qui contient les autorisations nécessaires pour interagir avec les services BigQuery et Pub/Sub.

Pour la réplication des données en flux continu (insertion uniquement), les autorisations dont BigQuery Connector pour SAP a besoin pour accéder à BigQuery sont contenues dans les rôles IAM suivants :

• Éditeur de données BigQuery
• Utilisateur de job BigQuery

Pour la réplication Change Data Capture (CDC), les autorisations dont BigQuery Connector pour SAP a besoin pour accéder à Pub/Sub et BigQuery sont contenues dans les rôles IAM suivants :

• Éditeur de données BigQuery
• Utilisateur de job BigQuery
• Éditeur Pub/Sub

Si SAP LT Replication Server s'exécute sur une VM Compute Engine, vous devez également attribuer le rôle Créateur de jetons de compte de service au compte de service de la VM hôte.

Si SAP LT Replication Server est exécuté sur site ou sur une autre plate-forme cloud, en plus de créer un compte de service, vous devez également créer une clé de compte de service pour BigQuery Connector pour SAP. Votre administrateur SAP installe la clé sur l'hôte SAP LT Replication Server. Lorsque BigQuery Connector pour SAP se connecte à Pub/Sub ou BigQuery, SAP LT Replication Server utilise la clé de compte de service pour s'authentifier auprès deGoogle Cloud.

Une clé de compte de service n'est pas requise lorsque SAP LT Replication Server s'exécute sur Google Cloud.

Pour en savoir plus sur les comptes de service, les rôles et les autorisations IAM, consultez les pages suivantes :

• Comptes de service
• Authentification en tant que compte de service
• Bonnes pratiques relatives aux comptes de service
• Présentation de l'API BigQuery pour l'authentification

Contrôles de l'accès aux ensembles de données et aux tables BigQuery

En plus des contrôles IAM, vous pouvez contrôler l'accès à l'aide de BigQuery. Pour BigQuery Connector pour SAP, vous pouvez définir des contrôles d'accès sur les ensembles de données et les tables.

Pour en savoir plus, consultez :

• Contrôler l'accès aux ensembles de données
• Contrôler l'accès aux tables.

VPC Service Controls

Sur Google Cloud, les règles de pare-feu VPC ne sont pas applicables aux interactions basées sur une API avec BigQuery. À la place, vous pouvez utiliser Virtual Private Cloud (VPC) Service Controls pour limiter le trafic.

Si votre charge de travail SAP s'exécute sur Google Cloud, vous pouvez mettre en œuvre VPC Service Controls en définissant des périmètres de service. Pour en savoir plus, consultez Périmètres de service.

Si votre charge de travail SAP ne s'exécute pas sur Google Cloud, vous pouvez mettre en œuvre VPC Service Controls dans le cadre de la configuration de l'accès privé à Google pour les hôtes sur site.

Pour en savoir plus sur la sécurité réseau pour BigQuery, consultez la page Sécurité réseau.

Points de terminaison Private Service Connect

Si vous souhaitez configurer des points de terminaison dans votre réseau VPC qui autorisent la consommation privée de services gérés par Google tels que BigQuery, vous pouvez utiliser Private Service Connect.

Private Service Connect vous permet de créer des points de terminaison privés qui utilisent des adresses IP internes d'une plage CIDR de VPC pour accéder aux API et services Google. Vous pouvez également utiliser Private Service Connect pour créer un nom DNS personnalisé pour l'API d'insertion en flux continu de BigQuery. Pour plus d'informations, consultez la page Private Service Connect.

Pour BigQuery Connector pour SAP exécuté sur un hôte extérieur àGoogle Cloud, Private Service Connect n'est pas compatible.

En savoir plus sur la sécurité de Google Cloud

Pour en savoir plus sur les comptes de sécurité, les rôles et les autorisations, consultez les pages suivantes :

• Comptes de service
• Créer et activer des comptes de service pour les instances
• Présentation de la sécurité et de la gouvernance des données
• Authentification et autorisation BigQuery

Gestion de réseaux

Lorsque vous planifiez le chemin d'accès réseau pour la réplication vers BigQuery, tenez compte des points suivants :

• Bande passante
• Latence et impact sur la consommation des ressources sur l'hôte SAP LT Replication Server
• Volume de données et impact sur la charge réseau existante
• Si votre charge de travail SAP ne s'exécute pas sur Google Cloud, type de connexion à utiliser : Cloud Interconnect ou Cloud VPN

Connexion à Google Cloud

Si vos systèmes SAP ne s'exécutent pas sur Google Cloud et que vous n'avez pas encore connecté les systèmes SAP à Google Cloud, vous devez établir une connexion et configurer un accès privé aux API Google Cloud .

Vous pouvez établir une connexion à Google Cloud à l'aide de Cloud Interconnect ou de Cloud VPN.

Cloud Interconnect fournit généralement une bande passante plus élevée, une latence plus faible et des conflits réseau moins nombreux en comparaison à Cloud VPN. Pour les tâches de réplication volumineuses et sensibles aux performances, Google Cloud recommande Cloud Interconnect pour BigQuery Connector pour SAP.

Avec Cloud VPN, vos données de réplication sont acheminées sur l'Internet public, ce qui implique une contention réseau moins prévisible et des latences généralement plus élevées.

Quelle que soit l'option de connexion choisie, vous devez prendre en considération tout le trafic attendu par la connexion. Déterminez si la connexion dispose d'une bande passante et d'une vitesse réseau suffisantes pour traiter les tâches de réplication et autres charge de travail sans dégradation des performances.

Des connexions lentes peuvent augmenter la consommation de ressources sur le serveur source SAP et sur l'hôte SAP LT Replication Server en prolongeant le temps nécessaire à l'exécution des tâches de ressources, ce qui maintient les ressources requises pour la réplication rattachées pour des périodes plus longues.

Pour en savoir plus sur les options de connexion, consultez les articles suivants :

• Connexion à Google Cloud
• Présentation de Cloud Interconnect
• Présentation de Cloud VPN

Pour utiliser un serveur proxy afin d'envoyer les requêtes HTTP à Google Cloud, nous vous recommandons d'utiliser les destinations RFC définies dans la transaction SM59.

Destinations RFC

Les fichiers de transport de BigQuery Connector pour SAP contiennent les exemples de destinations RFC suivants dans la transaction SM59. Ces destinations RFC sont des connexions HTTP aux serveurs externes (type G) et se connectent au point de terminaison de l'API publique du service concerné.

Exemple de nom de destination RFC	Hôte cible (point de terminaison de l'API)	Remarques
GOOG_BIGQUERY	https://bigquery.googleapis.com	Cette destination RFC cible l'API BigQuery.
GOOG_PUBSUB	https://pubsub.googleapis.com	Cette destination RFC cible l'API Pub/Sub.
GOOG_IAMCREDENTIALS	https://iamcredentials.googleapis.com	Cette destination RFC cible l'API Cloud IAM.
GOOG_OAUTH2_TOKEN	https://googleapis.com/oauth2	Cette destination RFC cible le point de terminaison Google Cloud pour l'authentification basée sur OAuth 2.0. Vous l'utilisez pour les charges de travail SAP exécutées en dehors de Google Cloud et uniquement lorsque vous souhaitez vous authentifier sur Google Cloud à l'aide d'un jeton Web JSON (JWT).

L'utilisation de destinations RFC pour se connecter à Google Cloud offre les avantages suivants :

• Si vous utilisez un serveur proxy dans votre environnement SAP et que vous souhaitez utiliser le même serveur pour envoyer des requêtes HTTP à Google Cloud, vous pouvez le configurer dans la destination RFC.

• Si vous souhaitez activer l'accès aux API et aux services Google Cloud via les points de terminaison Private Service Connect, vous pouvez créer ces points de terminaison dans votre projetGoogle Cloud , puis les spécifier dans vos destinations RFC.

• Vous pouvez utiliser la compression HTTP, queGoogle Cloud recommande pour les réplications interrégionales, où votre système source SAP et votre ensemble de données BigQuery sont placés dans différentes régions Compute Engine.

Pour utiliser des destinations RFC pour vous connecter aux API ou services Google Cloud , vous devez créer des entrées dans la table /GOOG/SERVIC_MAP qui mappent les destinations RFC à la table /GOOG/CLIENT_KEY. Pour connaître la procédure de configuration, consultez le guide d'installation et de configuration de BigQuery Connector pour SAP.

Compression HTTP

Lorsque vous utilisez des destinations RFC pour configurer la connexion entre BigQuery Connector pour SAP et les API Google Cloud , vous pouvez utiliser l'option Compression pour compresser le corps de la requête HTTP. La compression HTTP n'est disponible que lorsque vous configurez vos destinations RFC pour utiliser HTTP 1.1.

Avant d'activer la compression HTTP dans votre environnement de production, analysez les paramètres de profil qui ont une incidence sur la compression HTTP dans un environnement de test. Pour en savoir plus sur SAP, consultez la note SAP 1037677 - La compression HTTP ne compresse que certains documents.

Bande passante

Assurez-vous que votre connexion réseau entre SAP LT Replication Server etGoogle Cloud dispose d'une bande passante suffisante pour accepter votre volume de données à la vitesse requise.

Les connexions réseau plus lentes augmentent la latence de réplication des données, et donc la quantité de ressources utilisées par la réplication dans le système SAP source.

Pour une productivité optimale de vos installations, Google Cloud recommande une connexion Cloud Interconnect. Vous pouvez également utiliser Cloud VPN.

Latence

Pour réduire la latence de votre connexion réseau, créez un ensemble de données BigQuery cible aussi proche que possible du système SAP LT Replication Server et du système source SAP. Si le système SAP source s'exécute sur Google Cloud, créez votre ensemble de données BigQuery dans la même région Google Cloud que le système SAP source.

Testez la latence avant de migrer votre installation vers un environnement de production.

Pour en savoir plus sur les performances réseau, consultez la page Performances des connexions réseau.

Contrôle des accès au réseau

Vous pouvez mettre en œuvre des contrôles d'accès réseau des deux côtés de la connexion entre SAP LT Replication Server et Google Cloud.

Google Cloud Contrôles des accès au réseau

BigQuery Connector pour SAP communique avec BigQuery via un point de terminaison d'API, qui n'est pas soumis aux règles de pare-feu VPC de Google Cloud.

Utilisez plutôt VPC Service Controls pour limiter le trafic.

Pour en savoir plus sur la sécurité réseau pour BigQuery, consultez la page Sécurité réseau.

Contrôles des accès au réseau hôte SAP LT Replication

Sur l'hôte SAP LT Replication Server, vous devez vous assurer que tous les pare-feu ou proxys autorisent le trafic sortant du serveur vers les points de terminaison des API BigQuery et Pub/Sub. Plus précisément, assurez-vous que votre serveur SAP LT Replication Server peut accéder aux API Google Cloud suivantes :

• https://bigquery.googleapis.com
• https://pubsub.googleapis.com
• https://iamcredentials.googleapis.com

Si vous souhaitez utiliser des points de terminaison Private Service Connect pour accéder aux API BigQuery et Pub/Sub, vous devez configurer les points de terminaison Private Service Connect dans le tableau /GOOG/SERVIC_MAP.

Planification des performances

Les performances des chargements initiaux et des tâches de réplication entre SAP LT Replication Server et BigQuery sont affectées par plusieurs facteurs à différents moments du chemin de réplication.

Cependant, certains facteurs de base, tels que la distance entre SAP LT Replication Server et votre ensemble de données BigQuery ou la bande passante de votre connexion à Google Cloud, ont un impact plus important sur les performances que la plupart des autres facteurs.

Bonnes pratiques générales en matière de performances

Pour des performances optimales, intégrez les recommandations suivantes dans votre configuration SAP LT Replication Server :

• Exécutez votre charge de travail SAP, y compris le système source SAP et SAP LT Replication Server, sur Google Cloud.
• Si votre charge de travail SAP se trouve sur Google Cloud, créez votre ensemble de données BigQuery dans la même région que votre charge de travail SAP.
• Si vous ne pouvez pas exécuter votre charge de travail SAP sur Google Cloud :
  • Créez votre ensemble de données BigQuery dans la région Google Cloudla plus proche de votre charge de travail SAP.
  • Connectez-vous à Google Cloud à l'aide de Cloud Interconnect.
• Pour éviter les conflits de ressources, utilisez des hôtes dédiés distincts pour le système source SAP et SAP LT Replication Server.
• Dimensionnez correctement votre système SAP LT Replication Server pour votre charge de travail en fonction du guide de dimensionnement de votre version de SAP LT Replication Server, sur le portail d'aide SAP.
• Utilisez les paramètres de réplication SAP LT Replication Server suivants :
  • Tâches en parallèle
  • Type de lecture 1, si possible. Pour en savoir plus, consultez la page Performances et paramètres de réplication avancée de LTRS.
• Configurez BigQuery Connector pour SAP avec :
  • Compression d'enregistrements par défaut.
  • Taille de fragment par défaut.
• Lorsque vous mappez des champs sur votre table BigQuery, évitez les noms personnalisés, si possible.

Pour en savoir plus, consultez :

• Considérations sur les performances de SAP LT Replication Server
• Performances des connexions réseau
• Transmission de données
• Compression d'enregistrement

Caractéristiques supplémentaires susceptibles d'affecter les performances

De nombreuses caractéristiques de votre configuration et de vos données peuvent affecter les performances. Il est possible que certaines de ces caractéristiques ne soient pas modifiables. Ces caractéristiques incluent les suivantes :

• Sur le serveur source :
  • Le nombre de processeurs.
  • La quantité de mémoire
  • La base de données utilisée, telle que SAP HANA, SAP ASE, IBM Db2 ou autres
  • Le nombre de colonnes de la table source
  • La quantité de données que chaque enregistrement contient
  • Les métadonnées de la table, telles que la longueur des noms de champs
  • Le nombre de processus de dialogue.
• Sur SAP LT Replication Server :
  • Le nombre de processeurs.
  • La quantité de mémoire.
  • Le autres charges de travail que l'hôte peut exécuter
  • La boîte de dialogue SAP et les processus en arrière-plan
  • Type d'architecture d'installation de SAP LT Replication Server. Pour plus d'informations, consultez la section Configuration autonome (recommandée) ou installation intégrée de SAP LT Replication Server.
  • Le nombre de tâches en arrière-plan en cours d'exécution sur le système SAP LT Replication Server.
  • Le nombre de tâches en arrière-plan allouées au transfert de masse dans l'onglet Administration de la transaction LTRC.
  • Les paramètres de performances de transaction LTRS, y compris Type de lecture et Taille de partie.
• Dans la configuration de la réplication BigQuery (transaction /GOOG/SLT_SETTINGS) :
  • Indique si des noms personnalisés sont spécifiés ou non pour les champs cibles. Le traitement des noms de champs BigQuery cibles peut avoir un léger impact sur les performances.
  • Si la compression des enregistrements est activée.
  • La taille de fragment, qui peut affecter le nombre total de requêtes HTTP envoyées.

Considérations sur les performances de SAP LT Replication Server

Les sections suivantes présentent les options de performances liées à la configuration de SAP LT Replication Server.

Performances et architecture d'installation de SAP LT Replication Server

Une architecture autonome, dans laquelle SAP LT Replication Server est installé sur son propre serveur dédié, offre généralement de meilleures performances qu'une architecture intégrée, dans laquelle SAP LT Replication Server est installé sur le même serveur que le système source.

Dans une architecture intégrée, SAP LT Replication Server doit partager les ressources du serveur avec le système source SAP.

Même avec une architecture autonome, le processeur et la mémoire de l'hôte, ainsi que toutes les autres charges de travail susceptibles d'être exécutées sur le serveur, peuvent avoir une incidence sur les performances d'une instance SAP LT Replication Server.

Performances et paramètres de réplication avancés LTRS

Les performances des chargements initiaux et de la réplication sont affectées par les paramètres que vous spécifiez pour la table source dans la transaction LTRS, sous Paramètres de réplication avancés.

Pour obtenir des conseils sur le réglage des performances, en particulier pour optimiser la réplication ou les chargements initiaux à volume élevé, consultez le guide d'optimisation des performances de SAP LT Replication Server dans le portail d'aide SAP.

Google Cloud recommande les spécifications suivantes dans la section Paramètres de réplication avancés > Performances générales de la transaction LTRS :

Pour les chargements initiaux de la plupart des types de table, spécifiez 1 - Calcul de plage en tant que Type de lecture. Pour les tables trop volumineuses pour 1 - Calcul de plage, spécifiez Type de lecture 5.

Pour les réplications, sous Paramètres actifs :

• Pour des réplications plus rapides, spécifiez des Plages automatiques.
• Pour des réplications plus fiables, ne spécifiez Aucune plage.

Le tableau suivant suggère des paramètres pour quelques scénarios courants.

Type de table	Type de lecture recommandé
Transparence (petite à moyenne)	Type de lecture 1 – Calcul de plage
Transparence (grande)	Uniquement si le type de lecture 1 ne fonctionne pas, type de lecture 5 – Calcul de la plage
Table du cluster	Type de lecture 4 – File d'attente des expéditeurs

Performances des connexions réseau

La bande passante et la latence de la connexion entre le système SAP LT Replication Server et Google Cloud peuvent affecter les performances globales de réplication vers BigQuery.

L'impact affecte non seulement la vitesse de réplication, mais également la quantité de ressources utilisées par SAP LT Replication Server et le système source, car plus il faut de temps pour recevoir la confirmation de réplication de BigQuery, plus la durée de détention des ressources hôtes par SAP LT Replication Server et le système source est longue.

Si votre charge de travail SAP s'exécute sur site ou sur un autre fournisseur cloud,Google Cloud recommande d'utiliser une connexion Cloud Interconnect, qui offre une bande passante élevée et une faible latence sans devoir être en concurrence avec le trafic sur l'Internet public.

Vous pouvez utiliser Cloud VPN pour vous connecter à Google Cloud et à BigQuery. Cependant, avec une connexion VPN, vos réplications doivent être en concurrence avec le trafic Internet général.

Si votre charge de travail SAP s'exécute sur Google Cloud, Google Cloud vous recommande de localiser SAP LT Replication Server et votre ensemble de données BigQuery dans la même région. Si SAP LT Replication Server et BigQuery se trouvent dans des régions différentes, la latence est généralement plus élevée et les performances sont généralement inférieures. Pour en savoir plus sur le choix d'une région, consultez Choisir une région et une zone.

Transmission de données

En règle générale, vous souhaitez envoyer autant de données que possible dans chaque requête HTTP afin de réduire le nombre total de requêtes HTTP et les frais de traitement associés.

Toutefois, dans certains cas, vous devrez peut-être réduire la quantité de données envoyées, soit en raison de la taille des enregistrements dans une table particulière, soit parce que vous atteignez une limite de quota ou une autre limite dans Pub/Sub ou BigQuery.

Vous pouvez contrôler la quantité de données envoyées dans chaque requête de différentes manières :

• Ajustez la quantité de données (la portion) que SAP LT Replication Server envoie à BigQuery Connector pour SAP.
• Ajustez la quantité de données (la taille des fragments) que BigQuery Connector pour SAP envoie à BigQuery.
• Ajustez les quotas pour les insertions en flux continu dans votre projet BigQuery.

Ajuster la quantité de données envoyées par SAP LT Replication Server

SAP LT Replication Server envoie les enregistrements du système source à BigQuery Connector pour SAP en parties. Chaque partie est traitée comme une tâche de chargement ou de réplication distincte qui consomme des ressources de serveur jusqu'à ce qu'elle soit terminée.

En règle générale, si vous augmentez la taille de la partie SAP LT Replication Server, vous réduisez le nombre de processus SAP LT Replication Server, ainsi que les frais associés.

Taille de partie et taille de fragment

Les parties de SAP LT Replication Server sont dimensionnées en octets ou en tant que produit du nombre d'octets et du nombre d'enregistrements. La taille des fragments BigQuery Connector pour SAP est dimensionnée en fonction du nombre d'enregistrements qu'ils peuvent contenir. La taille en octets d'un fragment varie en fonction de plusieurs facteurs, y compris le nombre de champs dans les enregistrements et la quantité de données contenues dans chaque enregistrement.

Si la taille de la partie SAP LT Replication Server est supérieure à celle du fragment BigQuery Connector pour SAP, BigQuery Connector pour SAP envoie plusieurs fragments pour chaque partie, jusqu'à ce que tous les enregistrements de la partie soient envoyés.

Si la taille de la partie est inférieure à la taille du fragment, BigQuery Connector pour SAP n'envoie qu'un seul fragment par partie. Chaque fragment ne contient que le nombre d'enregistrements envoyés dans chaque partie, quelle que soit la taille des fragments définie dans BigQuery Connector pour SAP.

Idéalement, définissez une taille de partie dans SAP LT Replication Server qui permet à BigQuery Connector pour SAP de créer les fragments les plus volumineux possibles sans dépasser la limite Pub/Sub ou BigQuery sur le nombre d'octets dans chaque requête HTTP.

Pour plus d'informations sur la spécification d'une taille de fragment, consultez la section Taille des fragments dans BigQuery Connector pour SAP.

Taille de partie dans SAP LT Replication Server

Pour modifier la taille de partie par défaut utilisée par SAP LT Replication Server, exécutez la transaction LTRS et ajustez la valeur du champ Taille du package dans Paramètres de réplication avancés sous Options de performances.

Pour en savoir plus, consultez le guide d'optimisation des performances de SAP LT Replication Server sur le portail d'aide SAP.

Taille des fragments dans BigQuery Connector pour SAP

BigQuery Connector pour SAP envoie les données à BigQuery sous forme de fragments d'enregistrements.

Pour la réplication CDC via Pub/Sub, nous vous recommandons d'utiliser la taille de fragment par défaut avec BigQuery Connector pour SAP, soit 1 000 enregistrements. Il s'agit du nombre maximal d'enregistrements autorisés par Pub/Sub.

Pour la réplication des données en flux continu, nous vous recommandons d'utiliser la taille de fragment par défaut avec BigQuery Connector pour SAP, soit 10 000 enregistrements. Toutefois, si les enregistrements d'une table source contiennent très peu de champs ou si les champs contiennent des valeurs de données de très petite taille, vous pouvez utiliser une taille de fragment plus grande jusqu'à la taille de fragment maximale autorisée par BigQuery, à savoir 50 000 enregistrements.

Si le nombre d'enregistrements dans un fragment donné atteint une taille d'octet dépassant la limite autorisée pour les requêtes HTTP, vous pouvez recevoir une erreur quotaExceeded ou une erreur invalid.

Cela peut se produire si les enregistrements d'une table source contiennent beaucoup de champs ou si les champs contiennent beaucoup de données.

Si vous obtenez une erreur liée à la taille des fragments, essayez de réduire la taille de fragment spécifiée dans la configuration de transfert de masse de cette table. Vous pouvez également activer la taille dynamique des fragments pour cette table afin d'ajuster automatiquement la taille des fragments. Pour en savoir plus, consultez la section Taille dynamique des fragments.

Si vous n'avez pas activé la taille dynamique des fragments, les tables sources SAP telles que MSEG, ACDOCA et MATDOC, peuvent comporter des enregistrements volumineux avec de nombreux champs par enregistrement. Vous devrez peut-être spécifier une taille de fragment inférieure.

Vous pouvez spécifier une taille de fragment en exécutant la transaction /GOOG/SLT_SETTINGS. La taille des fragments est spécifiée dans le champ Taille du segment de l'écran des attributs de table.

Pour plus d'informations sur la spécification d'une taille de fragment, consultez les sections suivantes :

• Pour la réplication CDC via Pub/Sub, consultez Spécifier la création de table et d'autres attributs généraux.
• Pour la réplication des données en flux continu, consultez Spécifier la création de table et d'autres attributs généraux.

Pour en savoir plus sur les messages d'erreur BigQuery, consultez la page Messages d'erreur.

Surcharge de traitement associée à l'envoi de parties

Chaque partie envoyée déclenche les actions suivantes, chacune entraînant une surcharge de traitement ou une consommation des ressources :

1. Une collection des enregistrements modifiés dans la table de journalisation du système source est envoyée à SAP LT Replication Server en une seule partie. Les enregistrements modifiés ne sont pas encore supprimés de la table de journalisation.
2. SAP LT Replication Server demande un nouveau jeton d'accès à Google Cloud.
3. BigQuery Connector pour SAP envoie une requête HTTP à Google Cloudpour vérifier la structure de la table cible.
4. BigQuery Connector pour SAP envoie les enregistrements à Google Clouden autant de fragments que nécessaire pour envoyer tous les enregistrements reçus en une seule partie. Chaque fragment est envoyé dans une requête HTTP distincte.
5. Google Cloud traite chaque fragment reçu.
6. Un code d'état HTTP OK est renvoyé à SAP LT Replication Server pour chaque fragment.
7. Une fois que Google Cloud a reçu tous les enregistrements, SAP LT Replication Server supprime les enregistrements envoyés de la table de journalisation, ce qui libère des ressources sur le système source.

Pour en savoir plus sur les parties et la configuration de SAP LT Replication Server pour améliorer les performances, consultez le guide d'optimisation des performances de SAP LT Replication Server sur le portail d'aide SAP.

Quotas BigQuery

Les quotas de l'API d'insertion en flux continu de BigQuery qui s'appliquent à votre projet limitent le volume de données que vous pouvez insérer dans BigQuery au fil du temps et dans une même requête HTTP.

Par exemple, BigQuery définit des limites de métriques telles que :

• Nombre d'octets par seconde et par projet que vous pouvez envoyer.
• Nombre maximal d'enregistrements ou de lignes que vous pouvez envoyer dans une seule requête HTTP.
• Taille maximale de requête HTTP que vous pouvez envoyer.

Pour les insertions en flux continu, BigQuery limite la taille des requêtes HTTP à 10 Mo et le nombre d'enregistrements que vous pouvez envoyer dans une seule requête HTTP à 50 000.

Dans la plupart des cas, vous pouvez modifier les quotas mais pas les limites.

Vous pouvez consulter et modifier les quotas en vigueur pour votre projet dans la consoleGoogle Cloud , sur la page Quotas.

Pour en savoir plus sur les quotas et les limites de BigQuery pour les insertions en flux continu, consultez les pages suivantes :

• Quotas et limites
• Insertions en flux continu

Quotas Pub/Sub

Les quotas de l'API Pub/Sub qui s'appliquent à votre projet limitent le volume de données que vous pouvez insérer dans BigQuery au fil du temps et dans une même requête HTTP.

Par exemple, Pub/Sub définit des limites de métriques telles que :

• Nombre d'octets par seconde et par projet que vous pouvez envoyer.
• Nombre maximal d'enregistrements ou de lignes que vous pouvez envoyer dans une seule requête HTTP.
• Taille maximale de requête HTTP que vous pouvez envoyer.

Pour les données CDC, Pub/Sub limite la taille des requêtes HTTP à 10 Mo et le nombre d'enregistrements que vous pouvez envoyer dans une seule requête HTTP à 1 000.

Dans la plupart des cas, vous pouvez modifier les quotas mais pas les limites.

Vous pouvez consulter et modifier les quotas en vigueur pour votre projet dans la consoleGoogle Cloud , sur la page Quotas.

Pour en savoir plus sur les quotas et les limites de ressources Pub/Sub, consultez les pages suivantes :

• Quotas et limites
• Limites de ressources

Compression d'enregistrement

La fonctionnalité de compression des enregistrements n'est pas compatible avec la réplication CDC via Pub/Sub.

Pour la réplication des données en streaming, BigQuery Connector pour SAP améliore par défaut les performances de réplication en compressant les enregistrements qu'il envoie à BigQuery. À partir de la version 2.8 de BigQuery Connector pour SAP, l'option de compression des enregistrements est disponible au niveau de la table et au niveau du champ.

Lorsque la compression des enregistrements est activée au niveau de la table (paramètre par défaut), BigQuery Connector pour SAP omet tous les champs vides de l'enregistrement source lors de l'envoi des enregistrements à BigQuery. Lorsque l'enregistrement est inséré dans BigQuery, les champs qui ont été omis des données envoyées sont initialisés avec null dans la table cible de BigQuery.

Toutefois, si vous devez répliquer certains champs vides avec leurs valeurs initiales dans BigQuery tout en continuant à utiliser la compression des enregistrements au niveau de la table, vous pouvez modifier le paramètre de compression des enregistrements pour ces champs spécifiques. Cela signifie que les valeurs vides des champs spécifiés ne sont pas omises des données envoyées et conservent la valeur avec laquelle elles sont initialisées dans la table source.

Vous pouvez contrôler le comportement de compression des enregistrements à l'aide du paramètre Envoyer un indicateur non compressé disponible au niveau de la table et du champ. Le tableau suivant récapitule le comportement de la compression des enregistrements :

Indicateur "Envoyer non compressé" au niveau de la table	Indicateur "Envoyer non compressé" au niveau du champ	Comportement de la compression des enregistrements
Oui	Non	Tous les champs sont envoyés sans compression.
Oui	Oui	Tous les champs sont envoyés sans compression.
Non	Oui	Seuls les champs sélectionnés au niveau du champ sont envoyés sans compression.
Non	Non	Tous les champs sont envoyés sous forme compressée.

Lorsque les données non compressées sont envoyées pour la réplication, les champs vides conservent la valeur avec laquelle ils ont été initialisés dans la table source, à l'exception des champs de date et d'horodatage. La valeur initialisée pour les champs de date et d'horodatage reçoit les valeurs suivantes :

• Valeur d'initialisation de champ de date : DATE 1970-01-01
• Valeur d'initialisation de champ d'horodatage : TIMESTAMP 1970-01-01 00:00:00 UTC

La capture d'écran suivante montre un exemple du comportement de compression des enregistrements :

• Ligne 1 : tous les champs sont non compressés. L'option Envoyer un indicateur non compressé est sélectionnée au niveau de la table.
• Ligne 2 : tous les champs sont compressés. L'indicateur d'envoi non compressé est désactivé au niveau de la table.
• Ligne 3 : les champs suivants ne sont pas compressés : int2_value, curr_value_154, currency, float_value et lang_value. Pour ces champs, l'option Envoyer un indicateur non compressé est sélectionnée au niveau du champ.

Pour de meilleures performances, ne désactivez pas la compression des enregistrements en sélectionnant l'option Envoyer un indicateur non compressé au niveau de la table. Cela peut avoir un impact négatif sur les performances de la réplication. Si vous devez envoyer des données non compressées uniquement pour des champs spécifiques, sélectionnez Envoyer un indicateur non compressé pour ces champs spécifiques au niveau du champ. Pour en savoir plus sur la manière dont la compression d'enregistrements affecte vos données transférées de SAP LT Replication Server vers BigQuery, consultez Comprendre la fonctionnalité de compression de BigQuery Connector pour SAP.

Configurations de réplication BigQuery

Lorsque vous configurez la réplication avec BigQuery Connector pour SAP, vous utilisez différentes transactions SAP, y compris une transaction personnalisée fournie par Google Cloud :

• SM30 : définit les propriétés de connexion à Google Cloud, qui sont stockées sous forme d'enregistrement dans la table de configuration personnalisée /GOOG/CLIENT_KEY. Si vous utilisez des destinations RFC pour vous connecter aux API et servicesGoogle Cloud , certaines propriétés de connexion sont éventuellement stockées dans la table de configuration personnalisée /GOOG/SERVIC_MAP.
• LTRC : définit l'application de réplication et l'ID de transfert de masse de BigQuery Connector pour SAP, entre autres propriétés.
• SM59 : définit les destinations RFC permettant d'établir des connexions aux API et services Google Cloudtels que BigQuery et IAM.
• /GOOG/SLT_SETTINGS : définit les propriétés de l'ensemble de données, de la table et des champs BigQuery cibles. Lorsque vous saisissez /GOOG/SLT_SETTINGS dans SAP LT Replication Server, vous devez ajouter /n pour échapper la barre oblique initiale dans le nom de la transaction.

Langues acceptées

BigQuery Connector pour SAP n'est compatible qu'avec les configurations de réplication en anglais. Lorsque vous configurez la réplication à l'aide des transactions SAP et de la transaction personnalisée fournie par Google Cloud, utilisez l'anglais comme langue de connexion sur l'écran de connexion SAP.

Cependant, BigQuery Connector pour SAP accepte l'exécution de tâches en arrière-plan qui s'exécutent sur SAP LT Replication Server, dans tous les langages compatibles avec SAP SLT.

Tous les messages d'erreur que vous pouvez rencontrer lors de l'utilisation de BigQuery Connector pour SAP sont générés en anglais, quel que soit le langage d'exécution de la tâche en arrière-plan.

Propriétés de la table cible

Lorsque vous configurez la réplication dans SAP LT Replication Server en exécutant la transaction /GOOG/SLT_SETTINGS, vous pouvez spécifier les paramètres qui s'appliquent lorsque BigQuery Connector pour SAP crée la table cible dans BigQuery.

Par exemple, vous pouvez spécifier les propriétés suivantes pour une table BigQuery cible :

• Nom du tableau
• Options de dénomination par défaut des champs
• Champs supplémentaires pour capturer les modifications d'enregistrements et activer les requêtes de comptage des enregistrements
• Partitionnement de table

Options de nommage par défaut des champs

Vous pouvez configurer BigQuery Connector pour SAP afin de créer les noms des champs de la table BigQuery cible à partir des noms des champs sources, ou à partir des libellés et des descriptions des champs sources. Les libellés et les descriptions sont généralement plus informatifs sur le contenu du champ.

Par défaut, BigQuery Connector pour SAP utilise les noms des champs sources. Vous pouvez modifier la valeur par défaut en spécifiant l'option Noms personnalisés lorsque vous spécifiez des attributs de création de table dans la configuration de transfert de masse de la transaction /GOOG/SLT_SETTINGS. La spécification est stockée dans la table de configuration /GOOG/BQ_MASTR.

Lors de la création des noms, BigQuery Connector pour SAP les modifie pour respecter la convention de dénomination BigQuery.

Avant de créer une table, vous pouvez modifier les noms de champ dans l'écran de mappage de champ de la transaction /GOOG/SLT_SETTINGS.

Lorsque l'indicateur Noms personnalisés est spécifié, les noms que BigQuery Connector pour SAP utilisera lors de la création de la table cible s'affichent dans la colonne Nom du champ externe de l'écran de mappage de champ.

BigQuery Connector pour SAP crée les noms dans la colonne Nom du champ externe à partir du libellé de champ medium de chaque champ source. Si un libellé de champ "medium" n'est pas spécifié dans la définition du champ source, la description courte du champ est utilisée. Si la description courte n'est pas non plus spécifiée, le libellé le plus court est utilisé. Si aucun de ces éléments n'est spécifié, le nom du champ source est utilisé.

Pour en savoir plus sur la personnalisation des noms de champs cibles, consultez la section Personnaliser les noms de champs cibles.

Capturer les modifications des enregistrements et activer le comptage des enregistrements

Pour capturer le type de modification dans la table source qui a déclenché la réplication et pour pouvoir interroger le nombre d'enregistrements dans la table BigQuery à des fins de comparaison avec SAP LT Replication Server ou le nombre d'enregistrements dans la table source, spécifiez l'option Option pour les champs supplémentaires dans la transaction /GOOG/SLT_SETTINGS lorsque vous configurez la réplication.

Lorsque l'option Option pour les champs supplémentaires est spécifiée, les colonnes suivantes sont ajoutées au schéma de la table BigQuery cible :

Nom du champ	Type de données	Description
operation_flag	STRING	Identifie le type de modification dans la table source qui a déclenché le chargement ou la réplication de l'enregistrement dans BigQuery. Pour compter les enregistrements insérés en mode de réplication, interrogez les enregistrements dont la valeur est I, U ou D dans le champ operation_flag. Pour obtenir un exemple de requête, consultez la section Interroger le nombre d'enregistrements insérés en mode de réplication. Pour compter les enregistrements insérés en mode de chargement initial, interrogez les enregistrements dont la valeur est L dans le champ operation_flag. Pour obtenir un exemple de requête, consultez la section Interroger le nombre d'enregistrements insérés en mode de chargement initial.
is_deleted	BOOLEAN	Si la valeur est true, cela indique que l'enregistrement source a été supprimé de la table source. Pour ne comptabiliser que les enregistrements d'une table BigQuery qui n'ont pas été supprimés de la table source, utilisez le champ is_deleted pour exclure les enregistrements sources supprimés. Pour obtenir un exemple de requête, consultez la section Interroger le nombre total d'enregistrements dans une table BigQuery.
recordstamp	TIMESTAMP	Heure à laquelle SAP LT Replication Server a envoyé l'enregistrement à BigQuery. Pour compter les enregistrements uniques dans une table BigQuery, interrogez uniquement la dernière instance insérée de chaque enregistrement. Pour obtenir un exemple de requête, consultez la section Interroger le nombre total d'enregistrements dans une table BigQuery.

Le paramètre actuel de l'option Option pour les champs supplémentaires est stocké dans la table de configuration /GOOG/BQ_MASTR.

Pour en savoir plus sur la spécification de l'option pour les champs supplémentaires, consultez :

• Pour la réplication CDC via Pub/Sub, consultez Spécifier la création de table et d'autres attributs généraux.
• Pour la réplication des données en flux continu, consultez Spécifier la création de table et d'autres attributs généraux.

Partitionnement de table

Vous pouvez créer des tables BigQuery partitionnées par un champ d'horodatage dans la table source, qui crée une table partitionnée par colonne d'unité de temps, ou par l'heure/la date auxquelles les enregistrements sont insérés dans BigQuery, ce qui crée une table partitionnée par date/heure d'ingestion.

Pour activer le partitionnement, spécifiez un type de partition dans le champ Type de partition du fichier /GOOG/BQ_TABLE lorsque vous configurez les propriétés de réplication.

Les types de partition que vous pouvez spécifier ajustent la précision du partitionnement à l'échelle de l'heure, du jour, du mois ou de l'année.

Pour utiliser un horodatage de la table source pour le partitionnement de la colonne d'unité de temps, spécifiez le nom du champ source dans le champ Champ de partitionnement.

Pour utiliser un temps d'insertion BigQuery pour le partitionnement par date/heure d'ingestion, vous pouvez laisser le champ de partition vide. BigQuery Connector pour SAP crée un champ dans la table cible pour stocker la date/heure d'insertion.

Propriétés du champ cible

Par défaut, BigQuery Connector pour SAP utilise les noms de champs et les types de données de la table source SAP comme noms de champs et types de données dans la cible BigQuery.

Vous pouvez éventuellement personnaliser les noms des champs ou modifier le type de données BigQuery avant de créer la table cible.

Personnaliser les noms des champs cibles

Avant de créer une table, vous pouvez personnaliser les noms des champs cibles.

Si nécessaire, BigQuery Connector pour SAP modifie les noms personnalisés que vous spécifiez afin de respecter la convention de dénomination BigQuery.

Lorsque vous configurez la réplication, vous pouvez afficher les noms des champs sur l'écran de mappage des champs de la transaction /GOOG/SLT_SETTINGS. BigQuery Connector pour SAP stocke vos paramètres dans la table de configuration /GOOG/BQ_FIELD.

Avant de créer une table, vous pouvez spécifier un nom de champ personnalisé en modifiant le nom généré dans la colonne Nom de champ temporaire de l'écran de mappage de champ. Si vous supprimez une valeur et laissez le champ Nom de champ temporaire vide, BigQuery Connector pour SAP utilise le nom du champ source comme nom pour ce champ cible.

Une fois le nom de champ temporaire modifié, lorsque vous cliquez sur Enregistrer, BigQuery Connector pour SAP valide la valeur, applique les conventions de nommage BigQuery nécessaires et enregistre les modifications. Vous pouvez valider une valeur sans l'enregistrer en appuyant sur Entrée.

Pour en savoir plus sur le paramétrage de la méthode de nommage par défaut des champs cibles, consultez la section Options de nommage par défaut pour les champs.

Utiliser une feuille de calcul ou un fichier texte pour modifier le mappage des champs BigQuery

Avant de créer une table BigQuery cible, vous pouvez éventuellement enregistrer les types de données, les noms et les descriptions par défaut des champs cibles dans une feuille de calcul ou un fichier texte, afin que les ingénieurs de données ou les administrateurs BigQuery puissent les modifier, sans avoir besoin d'accéder à SAP LT Replication Server.

Une fois les valeurs modifiées, vous devez convertir le fichier et son contenu au format CSV (valeurs séparées par une virgule). Vous pouvez ensuite appliquer les mises à jour aux paramètres de transfert de masse en important le fichier CSV avec la transaction personnalisée /GOOG/SLT_SETTINGS.

Le processus de modification du mappage de champs BigQuery à l'aide d'un fichier CSV comprend les étapes suivantes :

1. Créez une feuille de calcul ou un fichier texte contenant les mappages de champs par défaut.
2. Modifiez les valeurs.
3. Convertissez le fichier texte ou la feuille de calcul au format CSV.
4. Importez le fichier CSV.

Pour obtenir des instructions détaillées sur chacune de ces étapes, consultez l'article Modifier le mappage de champs BigQuery avec un fichier CSV.

Convention de dénomination BigQuery pour les champs

La convention de dénomination BigQuery n'utilise que des lettres minuscules, des chiffres et des traits de soulignement.

BigQuery Connector pour SAP applique les conventions de dénomination de BigQuery à toute valeur d'entrée à utiliser pour le nom d'un champ cible.

Par exemple, si vous saisissez FIELD-@#!*123 en tant que nom de champ personnalisé, BigQuery Connector pour SAP remplace le nom par field_123.

Pour en savoir plus sur la convention de dénomination BigQuery pour les champs, consultez la section Noms de colonnes.

Mappage des types de données

Par défaut, BigQuery Connector pour SAP attribue des types de données aux champs BigQuery cibles en fonction du genre de type SAP ou du type de données SAP du champ SAP source.

Pour la réplication CDC via Pub/Sub, le processus implique une étape intermédiaire dans le mappage des types de données :

1. BigQuery Connector pour SAP vers Pub/Sub : lorsque BigQuery Connector pour SAP envoie des données à un sujet Pub/Sub, les types de données SAP sont d'abord convertis en types de données Pub/Sub Avro.

2. Pub/Sub vers BigQuery : les données au format Avro Pub/Sub sont ensuite diffusées en streaming vers BigQuery à l'aide d'un abonnement BigQuery. À ce stade, Pub/Sub attribue les types de données BigQuery finaux.

Pour assurer un flux de données fluide et une interprétation précise, les types de données Avro Pub/Sub et les types de données BigQuery finaux doivent être compatibles. Pour en savoir plus sur la compatibilité des schémas entre un sujet Pub/Sub et une table BigQuery, consultez Compatibilité des schémas.

Lorsque vous configurez la réplication, vous pouvez afficher les types de données sur l'écran de mappage des champs de la transaction /GOOG/SLT_SETTINGS. BigQuery Connector pour SAP stocke vos paramètres dans la table de configuration /GOOG/BQ_FIELD.

Avant de créer une table, vous pouvez remplacer la spécification de type de données par défaut par un autre type de données BigQuery et un autre type de données Avro Pub/Sub.

Types de données nécessitant un traitement spécial

Plusieurs types de données SAP nécessitent un traitement spécial afin d'être représentés avec précision dans la table BigQuery cible.

Vous devez gérer vous-même certains de ces types de données. BigQuery Connector pour SAP se charge des autres pour vous.

Valeurs booléennes

Pour les valeurs booléennes, SAP utilise le type de données CHAR que BigQuery Connector pour SAP mappe par défaut au type de données STRING dans la table BigQuery cible.

Par conséquent, pour les valeurs booléennes, lorsque vous configurez la réplication à l'aide de la transaction /GOOG/SLT_SETTINGS, vous devez redéfinir l'attribution de type de données par défaut des champs de valeurs booléennes de STRING à BOOLEAN dans l'écran de mappage des champs.

Horodatages

Pour les horodatages, SAP utilise les types de données P (décimaux compressés) ou DEC (décimaux), que par défaut BigQuery Connector mappe sur NUMERIC dans la table BigQuery cible.

Par conséquent, pour les horodatages, lorsque vous configurez la réplication à l'aide de la transaction /GOOG/SLT_SETTINGS, vous devez redéfinir l'attribution de type de données par défaut pour les champs d'horodatage de NUMERIC à TIMESTAMP ou TIMESTAMP (LONG) dans l'écran de mappage des champs.

Genre de type SAP X

Le genre de type SAP X est hexadécimal et est représenté par les types de données SAP RAW, RAWSTRING ou LRAW. Par défaut, BigQuery Connector pour SAP mappe ces types de données sur STRING dans la table BigQuery source.

Si vous avez besoin d'un champ source avec le genre de type SAP X pour effectuer le mappage sur BYTES à la place, vous devez modifier l'attribution de type de données par défaut pour le champ sur l'écran de mappage des champs de la transaction /GOOG/SLT_SETTINGS.

Le genre de type SAP X est aussi parfois utilisé dans SAP pour représenter les entiers. Dans ce cas, BigQuery Connector pour SAP vérifie le type de données du champ source pour l'un des types de données SAP afin de rechercher des entiers, INT1, INT2, INT4 et INT8 et attribue le type de données INTEGER dans la table BigQuery cible.

Genre de type SAP y

Le genre de type SAP y est une chaîne d'octets et est représenté par les types de données SAP RAW, RAWSTRING ou LRAW. Par défaut, BigQuery Connector pour SAP mappe ces types de données sur STRING dans la table BigQuery source.

Si vous avez besoin d'un champ source avec le genre de type SAP y pour effectuer le mappage sur BYTES à la place, vous devez modifier l'attribution de type de données par défaut pour le champ sur l'écran de mappage des champs de la transaction /GOOG/SLT_SETTINGS.

Type de données SAP LRAW

BigQuery Connector pour SAP stocke les types de données LRAW dans BigQuery sous forme de chaînes encodées Base64.

Si vous utilisez la réplication CDC via Pub/Sub, le connecteur convertit les champs LRAW en encodage UTF-8 avant de les envoyer à Pub/Sub. Malgré cette conversion, le connecteur stocke toujours les données au format Base64 dans BigQuery.

La conversion UTF-8 par le connecteur de la valeur d'un champ LRAW ne tient compte que des octets initiaux indiqués par la colonne de longueur précédente. Cela respecte les normes SAP, où le champ de longueur précédent (de type INT2 ou INT4) définit la longueur valide du contenu LRAW.

Mappage par défaut des types de données

Le tableau suivant indique la conversion de type de données de BigQuery Connector pour SAP :

Genre de type SAP	Type de données SAP	Type de données BigQuery	Type de données Pub/Sub Avro	Remarques
b (entier de 1 octet) s (entier de 2 octets) I (entier de 4 octets) 8 (entier de 8 octets)	INT1 INT2 INT4 INT8	INTEGER	INT
F (nombre à virgule flottante)	FLTP	FLOAT	FLOAT
P (emballé)	CURR DEC QUAN	NUMERIC	DOUBLE	Par défaut, le genre de type SAP P est mappé sur le type de données BigQuery NUMERIC et converti en un nombre au format externe.
a (nombre flottant décimal, 16 emplacements)	DECFLOAT16	NUMERIC	DOUBLE
e (nombre flottant décimal, 16 emplacements)	DECFLOAT34	NUMERIC	DOUBLE
N (numérique)	NUMC	STRING	STRING
X (hexadécimal) y (chaîne d'octets)	RAW RAWSTRING LRAW	STRING	STRING	Si le genre de type SAP est X, mais que le nom de type de données couvre le modèle 'INT*' (INT1, INT2, INT4), un élément de données source est remplacé par un nouvel élément de données TYPINT8 avec TYPEKIND '8', qui est mappé sur le type de données BigQuery INTEGER.
C (caractère) g (chaîne de caractères) ? (csequence) & (clike)	CHARSTRING	STRING	STRING
D (date)	DATS	DATE	STRING
T (time)	TIMS	TIME	STRING

Licences

BigQuery Connector pour SAP est disponible en tant que "Logiciel" dans le cadre du contrat régissant votre utilisation de la plate-forme Google Cloud , y compris les Conditions spécifiques au service disponibles à l'adresse https://cloud.google.com/terms/service-terms. Sans limiter la généralité des termes ci-dessus, vous ne pouvez ni modifier ni distribuer BigQuery Connector pour SAP sans l'autorisation écrite préalable de Google.

Le logiciel BigQuery Connector pour SAP est proposé gratuitement. Par souci de clarté, l'utilisation d'autres "Logiciels" et "Services" (par exemple, BigQuery, Pub/Sub, l'API Pub/Sub, l'API Storage Write et l'API de streaming BigQuery) conformément au contrat régissant votre utilisation de la plate-forme Google Cloud peut entraîner des coûts.

BigQuery Connector pour SAP n'inclut aucune licence pour les logiciels SAP, y compris, mais sans s'y limiter, SAP LT Replication Server. Vous devez obtenir séparément une licence appropriée pour le logiciel SAP.

Cycle de vie de l'assistance

Google Cloud assure l'assistance et le maintien de la dernière version majeure de BigQuery Connector pour SAP pendant au moins les 12 mois suivant la publication d'une notification d'abandon sur la page des notes de version de SAP sur Google Cloud, qui correspond à la version majeure précédente.

Étapes suivantes

Pour savoir comment installer BigQuery Connector pour SAP, consultez Installer BigQuery Connector pour SAP.