Guide d'utilisation de BigQuery Connector pour SAP

Ce guide explique aux administrateurs SAP LT Replication Server, aux ingénieurs de données SAP ou à d'autres personnes comment effectuer des tâches opérationnelles, telles que le réglage des performances et les mises à jour de version, pour la version 2.9 (dernière version) de BigQuery Connector pour SAP.

Régler les performances de réplication

Les performances de réplication peuvent être affectées par plusieurs facteurs. Les facteurs spécifiques peuvent différer d'une installation à l'autre et changer au fil du temps.

Les sections suivantes décrivent comment ajuster certains des facteurs les plus courants pouvant avoir un impact sur les performances.

Pour en savoir plus sur les performances de réplication avec BigQuery Connector pour SAP, consultez la page Planification des performances.

Définir les options de performances pour les tables

Dans SAP LT Replication Server, vous pouvez spécifier des options de réplication qui affectent les performances pour chaque table.

Pour les tables plus volumineuses nécessitant plus de temps et de ressources, il est possible d'améliorer les performances de réplication en spécifiant des plages et en augmentant le nombre maximal de tâches de réplication parallèles.

MSEG, ACDOCA et MATDOC sont des exemples de tables qui deviennent généralement volumineuses.

Lorsque vous spécifiez des tâches de réplication parallèles pour des tables volumineuses, vous devez équilibrer le nombre de tâches parallèles que vous autorisez pour une table donnée en vous basant sur le nombre total de tâches parallèles autorisées dans la configuration du transfert de masse. Votre organisation peut également limiter le nombre de tâches de réplication parallèle que vous pouvez spécifier pour un serveur donné.

Pour définir les options de performances d'une table :

1. Dans l'interface utilisateur graphique de SAP, saisissez la transaction SAP LTRS.

2. Sur l'écran Paramètres de réplication avancés, spécifiez l'ID des paramètres de transfert de masse de la table.

3. Dans la hiérarchie de dossiers des Paramètres de réplication avancés, cliquez sur le dossier Options de performances afin d'afficher les tables pour lesquelles des options de performances sont définies.

4. Si la table dont vous avez besoin n'est pas répertoriée, faites un clic droit sur le dossier Options de performances, puis sélectionnez Ajouter une table.

5. Spécifiez un nom pour la table.

6. Spécifiez les options suivantes selon vos besoins :

   • Sous Options de performance générales :
     • Nombre de tâches parallèles, pour définir le nombre maximal de tâches de réplication parallèle pour la table.
     • Numéro de séquence, pour hiérarchiser la réplication de cette table par rapport aux autres réplications de table.
   • Sous Options de chargement initial :
     • Pour Type de lecture, sélectionnez Calcul de plage pour le type de lecture 1 si votre table n'est pas trop volumineuse. Pour en savoir plus, consultez la page Performances et paramètres de réplication avancée de LTRS.
     • Dans le champ Taille du package, spécifiez la taille en octets des parties des enregistrements qui sont envoyées à SAP LT Replication Server.
     • Si vous sélectionnez un type de lecture qui utilise des plages, définissez des plages appropriées.
   • Sous Option de réplication :
     • Pour l'option Plages pour la table de journalisation, spécifiez Aucune plage pour l'option la plus fiable.
     • Si vous sélectionnez Spécifier des plages pour manuellement, définissez les plages appropriées.

7. Cliquez sur Enregistrer.

Benchmark de performance de référence

Pour vous aider à évaluer vos performances en termes de réplication, cette section fournit des valeurs de référence observées dans les systèmes de test Google Cloud , à la fois pour la réplication CDC via Pub/Sub et la réplication de données en flux continu.

En raison des divers facteurs qui peuvent affecter les performances, les valeurs que vous obtenez sont susceptibles d'être différentes.

Par exemple, si vos systèmes SAP ne s'exécutent pas sur Google Cloud, vos débits de charge et de réplication peuvent être inférieurs aux débits de référence (charge et réplication plus lentes) du fait d'éléments tels que la latence du réseau et la surcharge associée aux jetons d'accès. Si votre table source contient moins de colonnes ou si vous installez SAP LT Replication Server sur son propre serveur dans une architecture autonome, vos débits peuvent être plus rapides, car SAP LT Replication Server n'est pas en concurrence avec le système source pour obtenir des ressources.

Réplication CDC via Pub/Sub : valeurs de performance de référence observées

Pour la réplication CDC via Pub/Sub, les valeurs de performances suivantes représentent les performances de référence observées par Google Cloud pour chaque type de système source lors des tests. Dans chaque système de test, SAP LT Replication Server a été installé sur le système source SAP dans une architecture intégrée sur des VM Compute Engine. Le système source SAP s'exécutait dans la même région Google Cloud que l'ensemble de données BigQuery cible.

Pour en savoir plus sur la configuration des systèmes de test, consultez la section Configuration du système de test de performance de référence.

Pour afficher les valeurs de performance, cliquez sur votre type de système source :

Les valeurs de performances ci-dessus sont les références que les testeursGoogle Cloud ont observées.

Les performances observées étaient meilleures dans les systèmes de test possédant ces attributs :

• SAP LT Replication Server a été installé sur sa propre VM dans une architecture autonome.
  • Pour les systèmes S/4HANA, nous avons constaté qu'une architecture autonome offrait un débit de chargement initial supérieur d'environ 42 % à celui d'une architecture intégrée en raison de l'indépendance du scaling vis-à-vis des processus de SAP LT Replication Server.
  • Pour les systèmes ECC, nous avons constaté qu'une architecture autonome offrait un débit de chargement initial supérieur d'environ 10 % à celui d'une architecture intégrée en raison de l'indépendance du scaling vis-à-vis des processus de SAP LT Replication Server.
• La table source contenait moins de colonnes.
• La taille totale en octets des enregistrements était inférieure.

Pour en savoir plus sur les attributs système que vous pouvez modifier afin d'améliorer les performances, consultez les sections suivantes :

• Régler les performances de réplication
• Planification des performances

Réplication des données de flux : valeurs de performance de référence observées

Pour la réplication des données de flux, les valeurs de performances suivantes représentent les performances de référence observées par Google Cloud pour chaque type de système source lors des tests. Dans chaque système de test, SAP LT Replication Server a été installé sur le système source SAP dans une architecture intégrée sur des VM Compute Engine. Le système source SAP s'exécutait dans la même région Google Cloud que l'ensemble de données BigQuery cible.

Pour en savoir plus sur la configuration des systèmes de test, consultez la section Configuration du système de test de performance de référence.

Pour afficher les valeurs de performance, cliquez sur votre type de système source :

Les valeurs de performances ci-dessus sont les références que les testeursGoogle Cloud ont observées.

Les performances observées étaient meilleures dans les systèmes de test possédant ces attributs :

• SAP LT Replication Server a été installé sur sa propre VM dans une architecture autonome.
  • Pour les systèmes S/4HANA, nous avons constaté qu'une architecture autonome offrait un débit de chargement initial supérieur d'environ 42 % à celui d'une architecture intégrée en raison de l'indépendance du scaling vis-à-vis des processus de SAP LT Replication Server.
  • Pour les systèmes ECC, nous avons constaté qu'une architecture autonome offrait un débit de chargement initial supérieur d'environ 10 % à celui d'une architecture intégrée en raison de l'indépendance du scaling vis-à-vis des processus de SAP LT Replication Server.
• La table source contenait moins de colonnes.
• La taille totale en octets des enregistrements était inférieure.

Pour en savoir plus sur les attributs système que vous pouvez modifier afin d'améliorer les performances, consultez les sections suivantes :

• Régler les performances de réplication
• Planification des performances

Configuration du système de test de performance de référence

Les systèmes de test décrits dans cette section ont généré les valeurs de performance de référence répertoriées dans les sections précédentes, Benchmark des performances de référence.

Les systèmes de test, y compris le système source SAP, le système SAP LT Replication Server et l'ensemble de données BigQuery, étaient tous exécutés sur des VM Compute Engine dans la même région Google Cloud .

Dans chaque système, les serveurs et la charge de travail ont été conçus pour simuler une charge de travail plus lourde et un volume de réplication plus élevé que ce que vous pourriez rencontrer dans la plupart des installations réelles.

Pour afficher les attributs du système de test, cliquez sur votre type de système source :

Taille de fragment dynamique

Si vous rencontrez des erreurs, car la taille des fragments (en octets) dépasse la taille maximale des requêtes HTTP acceptées par BigQuery, vous devez réduire manuellement la taille des octets en réduisant la taille des fragments. La fonctionnalité de taille des fragments dynamiques vous permet de réduire automatiquement la taille des fragments et de relancer la réplication dans BigQuery lorsque la taille en octets d'un fragment dépasse la taille maximale en octets acceptée par BigQuery pour les requêtes HTTP. La taille des fragments dynamiques vous aide à éviter la plupart des échecs de réplication dus au dépassement de la taille en octets d'une requête. Vous pouvez recevoir une erreur uniquement si la taille des fragments atteint 1, mais que la taille des octets dépasse la limite en octets acceptée par BigQuery pour chaque requête HTTP.

La taille de fragment dynamique s'active dans la configuration de transfert de masse d'une table à l'aide de la transaction /GOOG/SLT_SETTINGS. La taille de fragment dynamique est un paramètre facultatif. Pour en savoir plus sur l'activation de la taille de fragment dynamique, consultez les ressources 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.

Lorsque vous activez le dimensionnement dynamique des fragments, la taille maximale des fragments de BigQuery Connector pour SAP s'aligne sur les limites de quota de service sous-jacentes :

• Pour la réplication CDC via Pub/Sub : les limites de quota Pub/Sub, qui sont de 1 000 enregistrements.
• Pour la réplication des données en streaming : les limites de quota BigQuery, qui sont de 50 000 enregistrements.

Pour en savoir plus sur la taille des fragments, consultez la section Taille de partie et taille de fragment.

Fonctionnement de la taille de fragment dynamique

Avec la taille de fragment dynamique, si une requête HTTP pour laquelle la taille de fragment initiale dépasse la limite BigQuery exprimée en octets, BigQuery Connector pour SAP réduit la taille de fragment et tente de renvoyer les données. BigQuery Connector pour SAP continue de réduire la taille de fragment et de tenter de renvoyer les données à BigQuery, jusqu'à ce que le transfert de données aboutisse pour un fragment particulier ou que la taille de fragment atteigne la valeur 1.

La taille de fragment réduite finale, pour laquelle le transfert de données a abouti, est ensuite utilisée comme taille de fragment pour tous les fragments restants de cette partie. La taille de fragment réduite finale pour laquelle le transfert de données a abouti est consultable pour chaque partie en qualité de message d'information, en accédant aux journaux d'application de SAP LT Replication Server :

Dynamic chunking triggered. Chunk size reduced from INITIAL_CHUNK_SIZE_VALUE to FINAL_REDUCED_CHUNK_SIZE_VALUE.

Pour les parties suivantes et les réplications suivantes, BigQuery Connector pour SAP commence à envoyer des données à BigQuery avec la taille de fragment configurée en transaction /GOOG/SLT_SETTINGS et continue à réduire la taille des fragments si la fragmentation dynamique est déclenchée.

Par défaut, la taille de fragment est réduite de 50 % après chaque nouvelle tentative. Si vous souhaitez réduire la taille des fragments d'un pourcentage inférieur ou supérieur, modifiez les paramètres avancés.

Examinons un exemple qui illustre la façon dont la taille de fragment est déterminée dans le processus de réplication, lorsque la taille de fragment dynamique est activée pour une table. Dans cet exemple, la réplication CDC via Pub/Sub est utilisée. Lorsque la taille de la partie SAP LT Replication Server est supérieure à celle des fragments BigQuery Connector pour SAP et que la taille des fragments de 1 000 enregistrements est définie dans la transaction /GOOG/SLT_SETTINGS. BigQuery Connector pour SAP réplique une partie vers BigQuery comme suit :

1. Lorsque la réplication commence pour une partie contenant 2 000 enregistrements, la taille des fragments pour le premier fragment est de 1 000 enregistrements, mais si la taille des octets pour la requête HTTP est supérieure à 10 Mo, alors BigQuery Connector pour SAP réduit la taille des fragments de 50 %, et la nouvelle taille de fragments est réduite à 500 enregistrements.

2. BigQuery Connector pour SAP effectue de nouvelles tentatives pour envoyer la taille des fragments de 500 enregistrements. Toutefois, si la taille des octets pour la requête HTTP est toujours supérieure à 10 Mo, BigQuery Connector pour SAP réduit encore la taille des fragments de 50 %, les portant à 250 enregistrements.

3. BigQuery Connector pour SAP effectue de nouvelles tentatives pour envoyer la taille des fragments de 250 enregistrements. Si la taille en octets de la requête HTTP pour ce fragment est inférieure à 10 Mo, la réplication aboutit et les données sont insérées dans BigQuery.

4. La taille des fragments suivants est de 250 enregistrements tant que la taille des octets de chaque requête HTTP est inférieure à 10 Mo. Si la taille en octets de la requête HTTP d'un fragment suivant dépasse 10 Mo, BigQuery Connector pour SAP réduit à nouveau la taille des fragments et réessaie d'envoyer les données à BigQuery, jusqu'à ce que le transfert de données aboutisse pour un fragment particulier. La taille de fragment réduite n'est utilisée que pour la partie courante de la réplication en cours.

Performances avec la taille de fragment dynamique

La taille de fragment dynamique peut affecter les performances de réplication vers BigQuery. Pour chaque fragment, BigQuery Connector pour SAP calcule le nombre d'enregistrements qu'il contient et vérifie la taille en octets des requêtes HTTP. Si la taille en octets est supérieure à 10 Mo, BigQuery Connector pour SAP réduit la taille des fragments et tente de renvoyer les données à BigQuery, ce qui augmente le temps de réplication global.

N'utilisez la taille de fragment dynamique que dans des situations spécifiques, où même après avoir configuré une taille de fragment idéale pour certains enregistrements de données, la taille de la requête peut dépasser la limite acceptée par BigQuery pour les requêtes HTTP et vous ne souhaitez pas recevoir d'erreurs concernant la taille des fragments. Exemple :

• Les tables sources contenant une variance importante dans la parcimonie des données des champs, c'est-à-dire celles qui conservent un nombre de champs moindre pour certains enregistrements, et un nombre de champs important pour d'autres enregistrements.
• Les tables sources contenant des champs de texte longs tels que EDID4-SDATA, VARI-CLUSTID et REPOSRC-DATA.

Vous pouvez également utiliser la taille des fragments dynamiques pendant la phase de test pour identifier la taille de fragment idéale pour une table que vous pouvez définir dans votre système de production SAP.

Pour en savoir plus sur la configuration de la taille des fragments, consultez les pages 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.

Validation du cache

La fonctionnalité de validation du cache n'est disponible qu'avec la réplication CDC via Pub/Sub.

La fonctionnalité de validation du cache, utilisée en particulier lors des chargements de données initiaux, améliore considérablement les performances des appels de transfert de données de SAP vers Google Cloud en mettant en cache les résultats de la validation du pipeline après la première vérification réussie. Cela élimine les étapes de validation redondantes pour les transferts de données ultérieurs, ce qui permet de gagner du temps et des ressources.

Il s'agit d'un paramètre recommandé, en particulier lors de la phase de chargement initial des données. Pour activer cette fonctionnalité, cochez la case Cache Val (Cache Validations) dans la transaction /GOOG/SLT_SETTINGS. Pour savoir comment activer cette fonctionnalité, consultez Spécifier la création de table et d'autres attributs généraux.

Lorsque ce paramètre est actif, BigQuery Connector pour SAP effectue une vérification initiale pour confirmer que le pipeline Google Cloud est correctement configuré et cohérent avec le schéma de table défini dans SAP. Ce pipeline comprend le sujet Pub/Sub, son schéma, l'abonnement BigQuery et la table BigQuery cible. Après cette validation initiale et la création du pipeline, les résultats sont stockés dans la mémoire partagée SAP. Pour tous les appels de transfert de données suivants, cette étape de validation est ignorée, ce qui optimise les performances en réduisant les vérifications redondantes.

Effacer la validation mise en cache

Lorsque la fonctionnalité de validation du cache est activée et que vous mettez à jour la définition de la table SAP, les modifications structurelles ne sont mises à jour qu'après l'expiration de la validation existante mise en cache. Dans ce cas, vous pouvez supprimer manuellement les résultats de validation mis en cache. Pour effacer les résultats de validation mis en cache, exécutez la transaction SE38, puis exécutez le programme /GOOG/R_GCP_CLEAR_CACHE ou la transaction /GOOG/BQPS_CLR_CACHE.

Nettoyer les Google Cloud artefacts

Pour les environnements de développement, vous pouvez utiliser le programme /GOOG/R_CLEANUP_CPS_ARTIFACTS afin de supprimer les ressources Google Cloud associées à un ID de transfert groupé. Ce programme supprime le sujet Pub/Sub associé, son schéma Pub/Sub et l'abonnement BigQuery.

Acheminer les paramètres de transfert de masse vers l'environnement de production

Pour acheminer les paramètres de transfert de masse vers l'environnement de production, vous devez commencer par exporter les paramètres depuis un système de développement, puis les importer dans le système de production.

Vous pouvez si vous le souhaitez importer trois parties distinctes des paramètres d'un transfert de masse dans votre environnement de production :

• Les paramètres de réplication avancés, accessibles à l'aide de la transaction LTRS.
• Les paramètres de clé client de la table /GOOG/CLIENT_KEY, accessibles à l'aide de la transaction SM30.
• Les paramètres de transfert de masse de BigQuery Connector pour SAP, accessibles à l'aide de la transaction /GOOG/SLT_SETTINGS.

Exporter les paramètres de transfert de masse à partir d'un système de développement

Dans le système de développement SAP LT Replication Server, exportez chaque partie des paramètres de transfert de masse :

1. Exportez les paramètres de réplication avancés :

   1. Exécutez la transaction LTRS.
   2. Sélectionnez les enregistrements de transfert de masse que vous transférez en production.
   3. Dans le menu déroulant Fichier, sélectionnez Exporter tous les paramètres.
   4. Dans la boîte de dialogue Paramètres d'exportation, sélectionnez une destination puis cliquez sur Enregistrer. Les paramètres sont enregistrés dans un fichier compressé au format CSV sur votre poste de travail local.

2. Exportez les paramètres de transfert de masse de BigQuery Connector pour SAP :

   1. Exécutez la transaction /GOOG/SLT_SETTINGS :

      /n/GOOG/SLT_SETTINGS

   2. Dans le champ Tableau des paramètres, sélectionnez Transfert de masse.

   3. Sélectionnez les enregistrements de transfert de masse que vous transférez en production.

   4. Cliquez sur Acheminer les paramètres de transfert de masse.

   5. Dans la fenêtre Invite pour une requête de poste de travail, saisissez le numéro de requête de transport puis cliquez sur l'icône Continuer. Pour chaque enregistrement de transfert de masse sélectionné, les paramètres des tables de configuration personnalisée suivantes sont inclus dans le transport :

      • /GOOG/BQ_MASTR
      • /GOOG/BQ_TABLE
      • /GOOG/BQ_FIELD

   Les paramètres de transfert de masse sont enregistrés dans une requête de transport.

3. Exportez les paramètres de clé client en incluant manuellement le contenu de la table /GOOG/CLIENT_KEY dans la requête de transport.

4. Enregistrez les fichiers sur votre poste de travail local.

Importer des paramètres de transfert de masse dans un système de production

Dans le système de production de SAP LT Replication Server, importez chaque partie des paramètres de transfert de masse :

1. Créez une configuration de réplication SAP LT Replication Server pour les paramètres de transfert de masse.

2. Importez les paramètres de réplication avancés :

   1. Exécutez la transaction LTRS.
   2. Sélectionnez le transfert de masse que vous avez créé à la première étape.
   3. Dans le menu déroulant Fichier, sélectionnez Importer tous les paramètres.
   4. Dans la boîte de dialogue Choisir un fichier, sélectionnez le fichier compressé sur votre poste de travail local puis cliquez sur Ouvrir. Les paramètres sont importés en tant que paramètres pour le transfert de masse.

3. Importez la requête de transport contenant les paramètres de transfert de masse.

4. Exécutez la transaction SM30.

5. Mettez à jour les paramètres de clé client en fonction des besoins de l'environnement de production.

6. Exécutez la transaction /GOOG/SLT_SETTINGS :

   /n/GOOG/SLT_SETTINGS

7. Vérifiez que les transferts de masse corrects s'affichent bien sur l'écran Transferts de masse.

8. Dans la colonne ID de transfert de masse, remplacez l'ID de transfert de masse du système de développement par l'ID de transfert de masse de la configuration de réplication que vous avez créée à la première étape.

9. Dans les écrans suivants des paramètres de Tables et de Champs, mettez à jour les autres valeurs de la table et le mappage des champ pour l'environnement de production, le cas échéant.

10. Testez la configuration en démarrant un chargement initial ou une réplication.

Mettre à jour BigQuery Connector pour SAP

Google Cloud fournit les nouvelles versions de BigQuery Connector pour SAP sous forme de fichiers de transport SAP.

Les administrateurs SAP peuvent mettre à jour le connecteur BigQuery pour SAP en procédant comme suit :

1. Désactivez la configuration dans SAP LT Replication Server.
2. Importez la nouvelle requête de transport SAP.
3. Une fois l'importation et l'activation de l'objet validées, activez la configuration dans SAP LT Replication Server.

Mettre à jour gcloud CLI

Vous devez maintenir Google Cloud CLI à jour sur l'hôte SAP LT Replication Server.

Pour en savoir plus sur la gestion de gcloud CLI, consultez la page Gérer les composants de gcloud CLI.

Surveillance

Vous pouvez surveiller plusieurs points sur le chemin entre la source de données SAP et la table BigQuery cible, y compris les éléments suivants :

• Infrastructure : réseau, matériel et système d'exploitation
• La couche de base de données SAP
• La couche d'application SAP
• BigQuery Connector pour SAP
• BigQuery
• Pub/Sub

Vos options de surveillance pour chacun de ces points sont présentées dans les sous-sections suivantes.

Surveiller l'infrastructure

Sur Google Cloud, vous pouvez installer l'agent Ops sur vos VM hôtes afin de bénéficier de fonctions de surveillance et de journalisation avancées. L'agent Ops envoie les données à Cloud Monitoring dans la console Google Cloud .

Pour en savoir plus, consultez les pages suivantes :

• Présentation de l'agent Ops
• Présentation de Cloud Monitoring

Pour les systèmes qui ne sont pas exécutés sur Google Cloud, vous pouvez également obtenir des informations sur le serveur en exécutant des transactions SAP comme la transaction ST06.

Surveiller la couche de base de données

Utilisez les codes de transaction SAP standard pour surveiller l'état de la base de données.

Le code de transaction DBACOCKPIT correspond à la transaction la plus courante pour surveiller la base de données. Cette transaction fournit également des journaux détaillés que vous pouvez utiliser pour résoudre les erreurs.

Pour SAP HANA, vous pouvez utiliser SAP HANA Studio pour les opérations SAP HANA. Vous pouvez installer SAP HANA Studio sur n'importe quelle machine de front-end.

Lors du dépannage des performances ou d'autres problèmes, vérifiez les points suivants dans la base de données source :

• Instructions SQL coûteuses
• Verrous
• Historique de chargement
• Index
• Processus

Surveiller la couche d'application

Vous pouvez utiliser les outils de surveillance et de dépannage des applications SAP pour surveiller et dépanner BigQuery Connector pour SAP, qui s'exécute dans la couche d'application.

La surveillance et le dépannage des applications SAP peuvent être classés dans les catégories suivantes :

• Surveillance et dépannage SAP standard
• Surveillance et dépannage de BigQuery Connector pour SAP

Pour les environnements plus développés, vous pouvez utiliser SAP Solution Manager comme outil central de surveillance.

Vous pouvez utiliser les codes de transaction SAP de la liste suivante pour surveiller et diagnostiquer les problèmes sur les systèmes d'applications SAP individuels :

• État de la configuration SLT : LTRC
• Erreurs et journaux SLT : LTRO et SLG1
• Gestionnaire de communication Internet (appels HTTP et HTTPS) : SMICM
• Sécurité et certificats : STRUST
• Transports SAP : STMS
• Connexions RFC : SM59
• Commande de système d'exploitation : SM69
• Vérification de package : SE80
• Vérifications des autorisations : SU53
• Tâches en arrière-plan : SM37
• Journaux système : SM21

Surveiller Pub/Sub

Utilisez Cloud Monitoring pour afficher les métriques Pub/Sub, et créer des graphiques et des alertes. Chaque métrique est associée à un type de ressource (pubsub_topic ou pubsub_subscription) et inclut également un ensemble de libellés qui fournissent des dimensions supplémentaires pour le filtrage et l'analyse.

Bien que vous puissiez toujours utiliser le langage de requête Monitoring (MQL) pour les configurations existantes, nous vous recommandons d'utiliser le langage de requête Prometheus (PromQL) pour créer des requêtes. PromQL offre un moyen puissant et flexible d'analyser vos données Pub/Sub, conformément aux normes du secteur en matière d'observabilité.

Pour en savoir plus sur Monitoring, consultez la documentation de Cloud Monitoring.

Surveiller le file d'attente de lettres mortes pour les messages ayant échoué

Dans Pub/Sub, un file d'attente de lettres mortes est un sujet dédié où les messages qui ne peuvent pas être traités correctement par un abonnement sont envoyés après un nombre configuré de tentatives d'envoi. Pour identifier et examiner les messages ayant échoué, éviter la perte de données et comprendre l'état du traitement des messages, vous devez surveiller votre file d'attente de lettres mortes.

Pour surveiller efficacement votre file d'attente de lettres mortes, vous configurez généralement un abonnement au file d'attente de lettres mortes que vous définissez dans votre configuration de transfert groupé. Vous pouvez ensuite surveiller cet abonnement spécifique à l'aide du même type de ressource pubsub_subscription et de ses métriques associées.

Métriques clés des file d'attente de lettres mortes

Pour comprendre comment interroger les métriques de votre abonnement file d'attente de lettres mortes, consultez les exemples PromQL suivants :

• Nombre de messages transférés vers le sujet de lettres mortes : il s'agit de la métrique la plus importante pour comprendre si des messages échouent.

  
  sum(rate(pubsub_googleapis_com:subscription_dead_letter_message_count{subscription_id="DEAD_LETTER_TOPIC_SUBSCRIPTION_ID"}[5m]))
  

• Nombre de messages non confirmés dans le sujet de la file d'attente de lettres mortes : indique les messages en attente de traitement ou d'examen dans la file d'attente de lettres mortes. Un nombre élevé ou en augmentation constante suggère un problème qui nécessite votre attention.

  
  pubsub_googleapis_com:subscription_num_unacked_messages{subscription_id="DEAD_LETTER_TOPIC_SUBSCRIPTION_ID"}
  

• Âge du plus ancien message non confirmé dans la file d'attente de lettres mortes : une valeur en hausse indique une augmentation des messages non distribués qui ne sont pas traités.

  
  pubsub_googleapis_com:subscription_oldest_unacked_message_age{subscription_id="DEAD_LETTER_TOPIC_SUBSCRIPTION_ID"}
  

• Taille du backlog (en octets) dans le sujet des lettres mortes : fournit des informations sur le volume de données dans votre file d'attente de lettres mortes.

  
  pubsub_googleapis_com:subscription_backlog_bytes{subscription_id="DEAD_LETTER_TOPIC_SUBSCRIPTION_ID"}
  

Bonnes pratiques pour la surveillance des file d'attente de lettres mortes

Pour surveiller les file d'attente de lettres mortes, appliquez les bonnes pratiques suivantes :

• Créez des alertes dédiées : configurez des alertes pour les augmentations de pubsub_googleapis_com:subscription_num_unacked_messages ou de pubsub_googleapis_com:subscription_oldest_unacked_message_age dans votre abonnement file d'attente de lettres mortes.

• Tableau de bord pour le sujet de lettres mortes : créez un tableau de bord dédié dans Monitoring pour visualiser l'état de votre file d'attente de lettres mortes dans votre projet.

• Intervention humaine : les messages du file d'attente de lettres mortes nécessitent souvent une inspection et une intervention manuelles pour comprendre la cause première de l'échec (par exemple, données mal formées, bugs d'application et pannes de service externe).

• Retraitement automatisé (avec prudence) : pour certains échecs prévisibles, vous pouvez implémenter des processus automatisés, tels que des fonctions Cloud Run ou des jobs Dataflow, afin de consommer les messages du file d'attente de lettres mortes, de tenter de les corriger et de les republier dans le sujet d'origine. Gérez cela avec une extrême prudence pour éviter les boucles infinies.

Surveiller BigQuery

Utilisez Monitoring pour afficher les métriques BigQuery, et créer des graphiques et des alertes. Chaque métrique comporte un type de ressource, bigquery_dataset, bigquery_project ou global, ainsi qu'un ensemble de libellés.

Utilisez les types de ressources et les libellés pour créer des requêtes dans le langage de requête de Monitoring (MQL).

Vous pouvez regrouper ou filtrer chaque métrique à l'aide des libellés.

Pour en savoir plus sur Monitoring, consultez la documentation de Cloud Monitoring.

Afficher les paramètres du connecteur

Pour afficher les paramètres de transfert de masse de BigQuery Connector pour SAP, exécutez la transaction /GOOG/SLT_SETT_DISP dans l'IUG de SAP.

Afficher la version du connecteur

Pour afficher la version de BigQuery Connector pour SAP installée sur votre système, exécutez la transaction /GOOG/BQC_VERSION dans l'IUG de SAP.

Utilitaires de connecteurs

BigQuery Connector pour SAP fournit les utilitaires suivants qui vous aident à simplifier les opérations sur les données et à optimiser les performances grâce à des fonctionnalités telles que la préparation, la validation et la transformation des données, ainsi que la simulation de charge :

Outil Créer une table

Cet outil n'est pas compatible avec la réplication CDC via Pub/Sub.

Pour les tables sources vides dans SAP, SAP SLT empêche la création de tables cibles dans BigQuery. Si vous devez créer les tables cibles dans l'ensemble de données BigQuery pour les tables sources vides, vous pouvez utiliser l'outil Créer une table.

Pour exécuter l'outil Créer une table, procédez comme suit :

1. Dans l'IUG de SAP, exécutez la transaction /GOOG/CREATE_BQ_TAB précédée de /n :

   /n/GOOG/CREATE_BQ_TAB

2. Sur l'écran Créer des tables cibles à partir des paramètres BQ, indiquez des valeurs pour les champs suivants :

   • Clé de transfert de masse : clé de transfert de masse contenant les tables SAP
   • Nom de la table SAP : noms de la table SAP que vous devez créer

3. Cliquez sur l'icône Exécuter. Les tables cibles sont créées dans l'ensemble de données BigQuery.

4. Vous pouvez également vérifier dans l'ensemble de données BigQuery si la table a été créée avec le schéma approprié.

Outil de conversion de champ de masse

Cet outil n'est pas compatible avec la réplication CDC via Pub/Sub.

Bien que BigQuery Connector pour SAP suggère automatiquement les types de données BigQuery pour la plupart des champs, vous devrez peut-être mapper les champs manuellement. Plutôt que d'attribuer manuellement le type de données à chaque champ, vous pouvez utiliser l'outil de conversion de champ de masse pour mapper l'attribution de type de données pour tous les champs sur l'écran de mappage des champs de la transaction /GOOG/SLT_SETTINGS. L'outil de conversion de champ de masse convertit tous les mappages de champs d'une table au type STRING dans BigQuery.

Si une table est déjà répliquée ou ajoutée pour le chargement initial dans la transaction LTRC, n'utilisez pas l'outil de conversion de champ de masse pour ces tables, car cela peut entraîner des problèmes d'incompatibilité de schéma. Vous ne pouvez utiliser cet outil que pour les tables SAP pour lesquelles le chargement ou la réplication initiale n'a pas commencé.

Pour exécuter l'outil de conversion de champ de masse, procédez comme suit :

1. Dans l'IUG de SAP, exécutez la transaction /GOOG/MASS_CNVT_FMAP précédée de /n :

   /n/GOOG/MASS_CNVT_FMAP

2. Sur l'écran Conversion des champs de masse, indiquez des valeurs pour les champs suivants :

   • Clé de transfert de masse : clé de transfert de masse contenant les tables SAP
   • Nom de la table SAP : noms de la table SAP pour lesquelles tous les mappages de champs doivent être convertis au type STRING.

3. Cliquez sur l'icône Exécuter. Pour les tables sélectionnées, tous les mappages de champs sont convertis au type STRING.

Outil de simulation de charge

Cet outil n'est pas compatible avec la réplication CDC via Pub/Sub.

Cette section présente l'outil de simulation de charge et ce que vous pouvez faire avec ce dernier.

L'outil de simulation de charge est un outil d'assistance pour BigQuery Connector pour SAP qui vous permet de simuler la réplication des données SAP dans BigQuery. Cet outil fait partie du transport fourni parGoogle Cloud pour BigQuery Connector pour SAP. L'outil de simulation de charge permet de répliquer les données SAP sources dans BigQuery en appelant directement le module BAdI (Business Add In) de BigQuery Connector pour SAP. Étant donné que l'outil de simulation de charge n'utilise pas le framework SLT sous-jacent, les déclencheurs SLT ne sont pas impactés. N'utilisez pas l'outil de simulation de charge pour la réplication de données dans des environnements de production.

L'outil de simulation de charge fournit un rapport que vous pouvez analyser pour évaluer les performances de réplication, identifier les problèmes potentiels, comprendre la cause première des problèmes et les résoudre avant la réplication réelle des données SAP dans BigQuery à l'aide de BigQuery Connector pour SAP.

Voici quelques cas d'utilisation courants de l'outil de simulation de charge :

• Reproduire et résoudre les problèmes de connectivité réseau, d'autorisation ou d'authentification.
• Générer des journaux améliorés des appels d'API BigQuery pour résoudre les problèmes.
• Pour obtenir de l'aide concernant le dépannage auprès du Cloud Customer Care, exécutez l'outil de simulation de charge et fournissez les journaux à l'équipe du Service client.
• Mesurer les métriques de performances en évaluant le temps nécessaire à chaque étape du processus de réplication.
• Dans le contexte de SAP LT Replication Server dans une architecture intégrée, déterminer une taille de fragment optimale pour les tables SAP.

Vous allez utiliser un exemple de configuration de transfert de masse avec l'outil de simulation de charge, que vous allez créer à l'aide de la transaction personnalisée /GOOG/SLT_SETTINGS. N'utilisez pas votre ensemble de données de production ni vos tables BigQuery pour exécuter l'outil de simulation de charge.

Si SAP LT Replication Server se trouve dans une architecture intégrée, vous exécutez l'outil de simulation de charge avec les tables SAP standards, telles que MARA et T001.

Lorsque SAP LT Replication Server se trouve dans une architecture autonome, vous exécutez l'outil de simulation de charge avec l'exemple de table /GOOG/TEST_REPL fourni par Google Cloud avec BigQuery Connector pour SAP. L'outil de simulation de charge ne permet pas de lire des tables sources à partir d'un système distant.

Pour en savoir plus sur les architectures des sources de données SAP surGoogle Cloud, consultez la page Architecture d'installation.

Prérequis

Avant d'exécuter l'outil de simulation de charge, assurez-vous que les conditions préalables suivantes sont remplies :

• BigQuery Connector pour SAP est installé et configuré. Pour en savoir plus sur les étapes d'installation et de configuration, consultez Installer BigQuery Connector pour SAP et Configurer le connecteur pour la réplication des données en streaming.

• Les utilisateurs prévus ont accès à la transaction personnalisée /GOOG/LOAD_SIMULATE fournie par Google Cloud. Pour en savoir plus, consultez Créer des rôles et des autorisations SAP pour BigQuery Connector pour SAP.

Comment exécuter l'outil de simulation de charge

Procédez comme suit pour exécuter l'outil de simulation de charge :

1. Dans l'interface utilisateur graphique de SAP, saisissez la transaction /GOOG/LOAD_SIMULATE précédée de /n :

   /n/GOOG/LOAD_SIMULATE

2. Cliquez sur l'icône Exécuter. L'écran Simulation de charge SLT s'affiche.

3. Dans la section Options de traitement, assurez-vous que l'option Exécuter une simulation est sélectionnée.

4. Dans la section Options de sélection, saisissez les spécifications suivantes :

   • Dans le menu déroulant du champ Partenaire Google Cloud, sélectionnez BigQuery.

   • Dans le champ Mass Transfer Key (Clé de transfert de masse), saisissez la clé de transfert de masse pour la configuration du transfert de masse.

     Utilisez un exemple de configuration de transfert de masse avec l'outil de simulation de charge. N'utilisez pas votre ensemble de données de production ni vos tables BigQuery.

   • Dans le champ Nom de la table, saisissez le nom de la table SAP source que vous avez fournie dans l'exemple de configuration de transfert de masse.

   • Vous pouvez éventuellement saisir une condition pour la sélection de données de la table source dans le champ Condition WHERE.

     Celui-ci peut contenir jusqu'à 255 caractères. Par exemple, si vous exécutez l'outil de simulation de charge pour la table SAP MARA et que vous devez sélectionner le numéro matériel à partir d'une plage spécifique, spécifiez une valeur telle que MATNR GE '000000000400000001' AND MATNR LE '000000000600000001' pour la condition WHERE.

   • Dans le champ Nombre de cycles, saisissez le nombre de cycles de traitement exécutés par l'outil de simulation de charge.

     Cela est utile lorsque vous devez comparer le fonctionnement du rapport de simulation sur plusieurs cycles. La valeur doit être supérieure à 1.

   • Dans le champ Nombre d'enregistrements par cycle, saisissez le nombre d'enregistrements que vous souhaitez envoyer à BigQuery à chaque cycle de traitement. La valeur doit être supérieure à 1.

   • Dans le champ Taille de la partie, saisissez le nombre d'enregistrements du champ nombre d'enregistrements par cycle que SAP LT Replication Server envoie au BAdI de BigQuery Connector pour SAP dans chaque partie.

   • Sélectionnez une ou plusieurs options, le cas échéant :

     • Nombre d'enregistrements exact : indique que le nombre d'enregistrements envoyés à BigQuery lors de chaque cycle de traitement est exactement le même que celui fourni par le champ Nombre d'enregistrements par cycle. Si la table ne possède pas suffisamment d'enregistrements, l'outil de simulation de charge duplique les enregistrements existants pour atteindre le nombre requis. Les enregistrements ne sont dupliqués que pour insérer des données dans BigQuery, et non pour insérer des données dans la table source.

     • Utiliser la structure cible SLT : utilise la structure de la table de journalisation SLT pour obtenir les champs de la table source. Si cette option n'est pas définie, la génération de la structure cible s'effectue en lisant directement les champs à partir de la table source. Pour en savoir plus sur le flux de données SAP LT Replication Server, consultez la page Vue architecturale détaillée du flux de données.

     • Detailed Log (Journal détaillé) : indique que les enregistrements de journal sont créés pour toutes les méthodes définies dans le connecteur BigQuery pour SAP. Si cette option n'est pas définie, seules les méthodes importantes sont consignées.

     • Effacer les résultats précédents : efface les enregistrements de journal créés précédemment pour le même transfert de masse et la même table SAP. Si cette option n'est pas définie, les journaux sont ajoutés aux résultats précédents.

5. Pour exécuter l'outil de simulation de charge, cliquez sur l'icône Exécuter.

6. Une fois la simulation de charge terminée, dans la section Processing Options (Options de traitement), cochez la case d'option Display Report (Afficher le rapport).

7. Dans la section Options de sélection, saisissez les spécifications suivantes :

   • Dans le menu déroulant du champ Partenaire Google Cloud, sélectionnez BigQuery.
   • Dans le champ Clé de transfert de masse, saisissez la clé de transfert de masse correspondant à la configuration du transfert de masse.
   • Dans le champ Nom de la table, saisissez le nom de la table SAP source.
   • Si vous souhaitez afficher le rapport par date d'exécution de la simulation de charge, spécifiez une plage de dates dans le champ Date du rapport.
   • Si vous le souhaitez, vous pouvez afficher le dernier rapport exécuté conjointement avec le rapport actuel, en sélectionnant l'option Dernière exécution uniquement.

8. Pour afficher le rapport, cliquez sur l'icône Exécuter.

Le tableau suivant décrit les colonnes affichées dans le rapport de simulation :

Programmer l'outil de simulation de charge

Vous pouvez planifier l'exécution automatique de l'outil de simulation de charge en tant que tâche d'arrière-plan sur SAP LT Replication Server en utilisant le nom de programme /GOOG/R_LOAD_SIMULATION. Pour en savoir plus sur la planification des tâches en arrière-plan, consultez la section Planifier des tâches en arrière-plan.

Validation de la réplication

Si vous sélectionnez l'options pour les champs supplémentaires lorsque vous créez la table BigQuery cible avec la transaction /GOOG/SLT_SETTINGS, des colonnes sont ajoutées au schéma de la table pour stocker le type de modification de chaque enregistrement ayant déclenché la réplication et pour un un horodatage qui reflète l'heure à laquelle SAP LT Replication Server a reçu la partie contenant l'enregistrement.

Vous pouvez utiliser les types de modification et l'horodatage pour interroger les types de décompte d'enregistrements suivants :

• Nombre d'enregistrements chargés dans une table BigQuery lors d'un chargement initial.
• Nombre d'enregistrements répliqués dans une table BigQuery pendant un jour spécifié.
• Nombre total d'enregistrements uniques dans une table BigQuery.

Pour obtenir ces nombres, vous pouvez interroger directement la table BigQuery en envoyant des requêtes SQL dans la console Google Cloud ou exécuter l'outil de validation de réplication, qui génère des rapports qui comparent le nombre d'enregistrements BigQuery avec les statistiques SAP LT Replication Server ou le nombre d'enregistrements de la table source.

Pour obtenir une présentation de l'option pour les champs supplémentaires, consultez la section Champs supplémentaires pour les modifications d'enregistrements et le décompte des requêtes.

Pour en savoir plus sur la spécification de l'option pour les champs supplémentaires, consultez Spécifier la création de table et d'autres attributs généraux.

Requêtes SQL pour le nombre d'enregistrements

Sur la page Éditeur SQL de BigQuery dans la consoleGoogle Cloud , vous pouvez exécuter des requêtes SQL pour vérifier le nombre d'enregistrements dans vos tables BigQuery.

Vous pouvez ensuite comparer le nombre d'enregistrements BigQuery avec ceux de la table source ou des statistiques SAP LT Replication Server.

Interroger le nombre d'enregistrements insérés en mode de chargement initial

Lorsqu'un schéma de table BigQuery inclut la colonne facultative operation_flag, les enregistrements insérés dans la table en mode de chargement initial incluent l'option d'opération L.

Pour obtenir le nombre d'enregistrements reçus par BigQuery lors d'un chargement initial, exécutez la requête suivante :

SELECT COUNT(*)
  FROM
      `PROJECT.DATASET.TABLE`
  WHERE operation_flag = 'L'

Interroger le nombre d'enregistrements insérés en mode de réplication

Lorsqu'un schéma de table BigQuery inclut la colonne operation_flag facultative, les enregistrements insérés dans la table en mode réplication incluent l'une des options d'opération suivantes :

• I : l'enregistrement a été inséré dans la table source.
• D : l'enregistrement a été supprimé de la table source.
• U : l'enregistrement a été mis à jour dans la table source.

Pour obtenir le nombre d'enregistrements reçus par BigQuery en mode de réplication, exécutez la requête suivante :

SELECT COUNT(*)
  FROM
      `PROJECT.DATASET.TABLE`
  WHERE operation_flag = 'I' | 'D' | 'U'

Interroger le nombre total d'enregistrements dans une table BigQuery

Lorsqu'un schéma de table BigQuery inclut la colonne facultative recordstamp, le champ recordstamp correspondant de chaque enregistrement inséré dans la table contient un horodatage indiquant à quel moment l'enregistrement a été envoyé par SAP LT Replication Server vers BigQuery.

Lorsque la CDC n'est pas activée, pour obtenir le nombre total d'enregistrements dans une table BigQuery que vous pouvez comparer avec le nombre total d'enregistrements dans une table source, vous pouvez utiliser les champs recordstamp et is_deleted pour compter le nombre d'enregistrements uniques de la table BigQuery qui n'ont pas été supprimés de la table source.

Si la table source est activement mise à jour ou si la réplication est active lorsque vous interrogez les enregistrements, le nombre d'enregistrements dans les tables sources et cibles peut ne pas correspondre exactement.

Pour obtenir le nombre actuel d'enregistrements uniques dans la table cible BigQuery, exécutez la requête suivante :

SELECT COUNT(*)
  FROM (
    SELECT
      *,
      ROW_NUMBER() OVER (PARTITION BY KEY_FIELD_1, ..., KEY_FIELD_N ORDER BY recordstamp DESC) row_num
    FROM
      `PROJECT.DATASET.TABLE` )
  WHERE row_num = 1 AND is_deleted = false

Lorsque la CDC est activée, pour obtenir le nombre actuel d'enregistrements uniques dans la table cible BigQuery, exécutez la requête suivante :

SELECT COUNT(*) FROM `PROJECT.DATASET.TABLE`;

Outil de validation de réplication

Cet outil n'est pas compatible avec la réplication CDC via Pub/Sub.

Cette section présente l'outil de validation de réplication et ce que vous pouvez faire avec ce dernier.

L'outil de validation de la réplication génère des rapports qui comparent les décomptes d'enregistrements de la table BigQuery aux statistiques SAP LT Replication Server, ainsi qu'aux nombres d'enregistrements de la table source. Si les nombres ne correspondent pas exactement, l'outil signale le rapport avec un cercle rouge.

Pour compter les enregistrements dans BigQuery, l'outil utilise les requêtes SQL présentées dans la section précédente, Requêtes SQL pour le nombre d'enregistrements.

Exécutez régulièrement l'outil de validation de la réplication pour vérifier que SAP LT Replication Server et BigQuery Connector pour SAP répliquent les enregistrements vers BigQuery comme prévu.

Pour exécuter l'outil de validation de réplication, saisissez la transaction personnalisée /GOOG/REPLIC_VALID précédée de /n dans l'IUG de SAP. Pour obtenir des instructions détaillées, consultez Exécuter l'outil de validation de réplication.

Rapports de validation de réplication

Vous pouvez générer les rapports de validation suivants à l'aide de l'outil de validation de réplication :

• Nombre de chargements initiaux : comparaison du nombre d'enregistrements envoyés par SAP LT Replication Server en mode de chargement et du nombre d'enregistrements chargés dans BigQuery.
• Nombre de réplications : comparaison du nombre d'enregistrements envoyés par SAP LT Replication Server en mode réplication et du nombre d'enregistrements insérés dans BigQuery à pendant un jour spécifié.
• Nombre actuel : comparaison à un moment précis du nombre d'enregistrements dans la table source et du nombre d'enregistrements uniques dans BigQuery. Le nombre actuel dans la table source ne peut pas afficher un nombre supérieur à la limite de nombre entier de 32 bits (de -2 147 483 648 à 2 147 483 647).

Vous pouvez générer chaque rapport individuellement ou, en sélectionnant Toutes les vérifications lorsque vous exécutez l'outil, vous pouvez générer les trois rapports en une seule exécution. Avec le champ Noms des tables, vous pouvez générer les rapports de validation de réplication pour des tables spécifiques dans la configuration de transfert de masse.

Afficher les rapports de validation de réplication

Après avoir généré un rapport, vous pouvez l'afficher en sélectionnant la case d'option Afficher le rapport dans la section Options de traitement de l'interface de l'outil de validation de réplication.

Les informations affichées par l'outil de validation de réplication dans chaque rapport diffèrent légèrement selon le type de rapport.

Tous les rapports incluent les types d'informations suivants :

• Nombre d'enregistrements sources à partir des statistiques de SAP LT Replication Server et de la table source.
• Nombre d'enregistrements cibles à partir de la table BigQuery cible.
• Toute différence entre les deux décomptes. La différence est calculée en soustrayant les décomptes BigQuery des décomptes d'enregistrements sources. Une valeur positive indique un problème probable, car elle suggère que tous les enregistrements source n'arrivent pas dans BigQuery.
• Différence entre les décomptes affichés sous forme de pourcentage du nombre d'enregistrements sources.
• Un indicateur visuel spécifiant si le nombre de sources et de cibles est égal ou différent.

Nombre d'enregistrements inégal

L'outil de validation de réplication inclut un champ d'état avec chaque rapport affiché.

Un carré vert dans le champ d'état signifie que le nombre d'enregistrements source est égal au nombre d'enregistrements cible dans BigQuery.

Un cercle rouge dans le champ d'état signifie que les nombres d'enregistrements ne sont pas égaux.

Un nombre d'enregistrements inégal n'indique pas toujours un problème. Les indicateurs suivants suggèrent un problème possible :

• Pour un rapport "Nombres actuels", une valeur inégale indique toujours un problème.

• Pour un rapport initial sur le nombre de charges ou le nombre de réplications, une valeur positive indique un problème probable.

  Une valeur négative relativement faible n'est pas un problème. Le nombre dans une table BigQuery cible peut parfois être légèrement supérieur au nombre d'enregistrements source en raison d'événements tels que des interruptions de connectivité momentanée qui entraînent le renvoi des données par SAP LT Replication Server.

Si vous constatez un nombre inégal, exécutez à nouveau le rapport pour vous assurer qu'il n'est pas causé par un problème transitoire. Un nombre d'enregistrements inégal peut être dû au traitement de la réplication au moment où l'outil a généré le rapport.

Pour une très grande table source ou une table dont les filtres sont définis dans SAP LT Replication Server pour le chargement ou la réplication initiaux, l'outil de validation de réplication risque de ne pas compter tous les enregistrements requis pour un nombre égal.

Planifier des contrôles de validation

Vous pouvez programmer l'outil de validation de réplication pour qu'il s'exécute automatiquement à intervalles réguliers en utilisant la fonctionnalité de tâche d'arrière-plan SAP.

Outil "Enregistrements en flux continu"

Cet outil n'est pas compatible avec la réplication des données de streaming.

L'outil "Diffuser des enregistrements" vous permet de diffuser des enregistrements de SAP vers Pub/Sub en fonction de critères spécifiques. Par défaut, il crée un abonnement avec un filtre pour diffuser en streaming uniquement les enregistrements supprimés de la table SAP source vers BigQuery à l'aide de l'API Storage Write via Pub/Sub. Toutefois, vous pouvez personnaliser les options de filtrage selon vos besoins.

Pour exécuter l'outil Diffuser des enregistrements, procédez comme suit :

1. Dans l'interface utilisateur graphique de SAP, exécutez la transaction /GOOG/BQPS_FLT_SUBS précédée de /n :

   /n/GOOG/BQPS_FLT_SUBS

2. Sur l'écran "Enregistrer le flux", indiquez des valeurs pour les champs suivants :

   • Clé de transfert de masse : clé de transfert de masse contenant les tables SAP.
   • Nom de la table SAP : noms de la table SAP pour lesquelles tous les mappages de champs doivent être convertis au type STRING.
   • Filtrer l'ID d'abonnement : nom de l'abonnement au sujet existant que vous devez créer.
   • Condition de filtre : condition avec laquelle l'abonnement est créé. Le filtre par défaut est défini pour diffuser uniquement les enregistrements supprimés. Pour en savoir plus sur la syntaxe permettant de créer un filtre, consultez Filtrer des messages.

3. Cliquez sur l'icône Exécuter. Un abonnement est créé pour le tableau sélectionné avec la condition de filtre spécifiée.

Modifier le mappage de champ BigQuery dans un fichier CSV

Les sections suivantes décrivent comment exporter le mappage de champ par défaut afin que les ingénieurs de données ou les administrateurs BigQuery puissent modifier les valeurs des champs cibles sans avoir besoin d'accéder à SAP LT Replication Server.

Lorsque vous modifiez les valeurs du champ cible, respectez les règles suivantes :

• Ne modifiez pas les valeurs des colonnes Nom de la table SAP et Nom du champ SAP.
• Dans la colonne Envoyer un indicateur non compressé, pour activer la compression des enregistrements, indiquez uniquement X. Sinon, laissez le champ vide.

Créer une feuille de calcul ou un fichier texte des mappages de champs par défaut

Pour créer un fichier CSV à modifier en dehors de SAP LT Replication Server, procédez comme suit :

1. Exécutez la transaction /GOOG/SLT_SETTINGS.

2. Dans l'écran Maintenance des paramètres SLT, spécifiez les valeurs suivantes :

   • Dans le champ Partenaire Google Cloud, sélectionnez votre option de réplication.
   • Dans le champ Paramètres de la table, spécifiez Champs.
   • Dans le champ Clé de transfert de masse, spécifiez l'ID du transfert de masse que vous mettez à jour.
   • Dans le champ Nom de la table, laissez le champ vide pour utiliser tous les champs de toutes les tables ou spécifiez un nom de table pour utiliser une table spécifique.
   • Laissez tous les autres champs vides.

3. Cliquez sur l'icône Exécuter. L'écran Maintenance des paramètres BigQuery – Champs s'affiche.

4. Dans l'écran Maintenance des paramètres BigQuery – Champs, masquez toutes les colonnes sauf celles de la liste suivante en effectuant un clic droit sur les en-têtes de colonne et en sélectionnant Masquer dans le menu déroulant :

   • Nom de la table SAP
   • Nom du champ SAP
   • Type Avro, applicable à la réplication CDC via Pub/Sub
   • Élément de données externe
   • Nom du champ externe
   • Description du champ
   • Indicateur "Envoyer sans compression"

5. Une fois les colonnes restantes affichées, cliquez sur l'icône Exporter.

6. Dans le menu Exporter, sélectionnez l'une des options suivantes :

   • Spreadsheet
   • Fichier local. Pour faciliter la conversion du contenu du fichier au format CSV, nous vous recommandons de l'enregistrer au format Texte avec tabulations.

7. Enregistrez les mappages de champs par défaut en cliquant sur l'icône Case à cocher.

Convertir la feuille de calcul ou le fichier texte au format CSV

Pour importer des mappages de champs modifiés à l'aide de la transaction personnalisée /GOOG/SLT_SETTINGS, les mappages de champs doivent être au format CSV.

Si vous utilisez une feuille de calcul, enregistrez-la au format CSV avant d'importer le fichier.

Si vous utilisez un fichier local séparé par des tabulations ou un autre format, vous devez le modifier pour qu'il soit conforme au format CSV.

Exemple :

SAP Table,SAP Field Name,AVRO Type,External Data Element,External Field Name,Field Description, Send Uncompressed Flag
SAP_TABLE_NAME,SAP_FIELD_NAME1,AVRO_TYPE,EXTERNAL_DATA_ELEMENT,EXTERNAL_FIELD_NAME,FIELD_DESCRIPTION, SEND_UNCOMPRESSED_FLAG
SAP_TABLE_NAME,SAP_FIELD_NAME2,AVRO_TYPE,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME2,BIGQUERY_FIELD_DESCRIPTION2, SEND_UNCOMPRESSED_FLAG2
SAP_TABLE_NAME,SAP_FIELD_NAME3,AVRO_TYPE,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME3,BIGQUERY_FIELD_DESCRIPTION3, SEND_UNCOMPRESSED_FLAG3

Importer le fichier CSV

Pour importer un fichier CSV modifié :

1. Exécutez la transaction /GOOG/SLT_SETTINGS.

2. Dans l'écran Maintenance des paramètres SLT, spécifiez les valeurs suivantes :

   • Dans le champ Paramètres de la table, spécifiez Champs.
   • Dans le champ Clé de transfert de masse, spécifiez l'ID du transfert de masse que vous mettez à jour.
   • Cochez la case Importer depuis un fichier.

3. Cliquez sur l'icône Exécuter. La boîte de dialogue Sélectionner un fichier à importer s'ouvre.

4. Dans la boîte de dialogue Sélectionner un fichier à importer, sélectionnez le fichier CSV contenant les valeurs de champ modifiées.

5. Cliquez sur Ouvrir.

6. Si vous recevez un avertissement de sécurité, cliquez sur Autoriser. Le fichier se charge et les valeurs modifiées apparaissent dans les lignes correspondantes de l'écran Maintenance des paramètres BigQuery – Champs.

7. Cliquez sur l'icône Enregistrer.

8. Pour confirmer que les valeurs sont appliquées, comparez les valeurs du fichier CSV avec les valeurs affichées par SAP LT Replication Server.

Gestion des erreurs dans les données sources

Lors de la réception d'un fragment d'enregistrements de BigQuery Connector pour SAP, l'API de streaming BigQuery recherche les erreurs de données avant d'insérer des enregistrements dans la table BigQuery.

Pour contrôler la manière dont l'API BigQuery et BigQuery Connector pour SAP réagissent lorsque des erreurs de données sont détectées, spécifiez les options suivantes dans les configurations de transfert de masse :

• L'option Skip Invalid Records (SKIP)
• L'option Break at First Error Flag (BREAK)

L'option SKIP

Si l'option SKIP est spécifiée, lorsque l'API BigQuery reçoit un fragment d'enregistrements et trouve un enregistrement avec une erreur de données, elle supprime ou ignore l'enregistrement contenant l'erreur et continue d'insérer tous les autres enregistrements du fragment dans la table BigQuery.

Si vous ne spécifiez pas l'option SKIP, lorsque BigQuery trouve un enregistrement avec une erreur de données, il supprime l'intégralité du fragment sans insérer d'enregistrements de cette table dans la table BigQuery. Il s'agit du comportement par défaut.

L'option SKIP est préférable pour les environnements de développement et de contrôle qualité, mais elle n'est pas recommandée pour les environnements de production.

Vous pouvez spécifier l'option SKIP dans la transaction /GOOG/SLT_SETTINGS lorsque vous configurez la réplication. Les spécifications sont stockées dans la table de configuration /GOOG/BQ_MASTR.

Pour savoir comment les spécifications SKIP interagissent avec les spécifications BREAK, consultez la page Table de matrice pour les interactions SKIP et BREAK.

L'option BREAK

Si vous spécifiez l'option BREAK, lorsque BigQuery Connector pour SAP est informé par l'API BigQuery qu'une erreur de données a été détectée dans un enregistrement, BigQuery Connector pour SAP cesse d'envoyer des enregistrements à BigQuery et met fin à la tâche de réplication. Il s'agit du comportement par défaut.

Si vous ne spécifiez pas l'option BREAK, lorsque BigQuery Connector pour SAP est informé par BigQuery qu'une erreur de données a été détectée dans un enregistrement, BigQuery Connector pour SAP continue d'envoyer des enregistrements à BigQuery en passant au fragment suivant afin de ne pas interrompre la tâche de réplication.

Il est recommandé de spécifier l'option BREAK dans les environnements de production.

Vous pouvez spécifier l'option BREAK dans la transaction /GOOG/SLT_SETTINGS lorsque vous configurez la réplication. Lorsque vous créez une clé de transfert de masse, l'indicateur BREAK est activé par défaut.

La spécification est stockée dans la table de configuration /GOOG/BQ_MASTR.

Pour savoir comment les spécifications BREAK interagissent avec les spécifications SKIP, consultez la page Table de matrice pour les interactions SKIP et BREAK.

Table de matrice pour les interactions SKIP et BREAK

Vous pouvez configurer BigQuery Connector pour SAP afin de gérer les erreurs de données de différentes manières :

Modifications de la structure des tables

Cette section explique comment modifier la structure d'une table source SAP, pour laquelle une réplication LTRC existante est en cours.

Pour la réplication CDC via Pub/Sub, le schéma Pub/Sub intermédiaire est révisé en fonction des modifications apportées à la structure de la table. Lorsque le schéma Pub/Sub est mis à jour, il peut s'écouler quelques minutes avant que les modifications ne prennent effet. Toutefois, aucune donnée n'est perdue.

Ajouter une colonne à une table source

Pour ajouter une colonne à une table source, procédez comme suit :

1. Ajoutez une colonne à la table source. Suite à cette étape, l'état de réplication devient Load/Replication blocked.

2. Dans votre système SLT, réinitialisez l'état de la réplication à l'aide de la transaction LTRC. Pour en savoir plus sur la réinitialisation de l'état de la réplication, consultez la note SAP 2204955 - Les tables SLT sont à l'état "Chargement /Réplication bloqués".

3. Ajoutez, mettez à jour ou supprimez une entrée dans la table source.

4. Validez le résultat de la réplication dans BigQuery.

Supprimer une colonne d'une table source

Pour supprimer une colonne existante d'une table source, procédez comme suit :

1. Dans votre système SLT, suspendez la réplication à l'aide de la transaction LTRC.

2. Supprimez une colonne de la table source. Suite à cette étape, les déclencheurs SLT existants sont supprimés ou présentent un état incohérent.

3. Pour la réplication CDC via Pub/Sub, supprimez manuellement la colonne du schéma Pub/Sub cible en créant une révision. Pour en savoir plus sur la procédure à suivre pour supprimer une colonne d'un schéma existant, consultez Réviser un schéma dans la documentation Pub/Sub.

4. Dans BigQuery, supprimez la colonne de la table BigQuery cible. Pour en savoir plus sur la procédure à suivre pour supprimer une colonne d'une table existante, consultez la documentation BigQuery.

5. Dans votre système SLT, reprenez la réplication à l'aide de la transaction LTRC.

6. Dans votre système SLT, recréez les déclencheurs SLT. Pour en savoir plus sur la recréation de déclencheurs SLT, consultez la note SAP 2254376 - Un ou plusieurs déclencheurs SLT présentent un état incohérent.

7. Si l'état de la réplication est Load /Replication blocked, réinitialisez l'état de la réplication à l'aide de la transaction LTRC. Pour en savoir plus sur la réinitialisation de l'état de la réplication, consultez la note SAP 2204955 - Les tables SLT sont à l'état "Chargement /Réplication bloqués".

8. Effacez les journaux, le cas échéant.

9. Ajoutez, mettez à jour ou supprimez une entrée dans la table source.

10. Validez le résultat de la réplication dans BigQuery.

Modifier le type de données d'une colonne existante

Lorsque vous modifiez le type de données d'une colonne existante dans la table source SAP, vous devez suivre des étapes spécifiques selon s'il s'agit d'un type de données compatible ou non avec la table BigQuery cible.

Un type de données est compatible avec le type de données de la table BigQuery cible lorsque le type de données existant et le nouveau type de données d'une colonne existante correspondent au même type de données dans la table BigQuery cible et, par conséquent, dans le schéma Avro Pub/Sub.

Par exemple, si le type de données d'une colonne passe de INT1 à INT2 dans une table source, ces deux types de données SAP sont considérés comme compatibles, car ils sont mappés sur le type de données INTEGER dans BigQuery et correspondent au type int dans le schéma Avro Pub/Sub.

BigQuery Connector pour SAP gère ce mappage en interne. La compatibilité signifie que le type BigQuery et Pub/Sub sous-jacent n'a pas besoin d'être modifié. Pour en savoir plus, consultez Compatibilité des schémas.

Pour en savoir plus sur le mappage des types de données dans BigQuery Connector pour SAP, consultez la section Mappage des types de données.

Modifier le type de données pour le remplacer par un type de données compatible

Pour remplacer le type de données d'une colonne existante par un type de données compatible, procédez comme suit :

1. Remplacez le type de données par un type compatible dans le système source. Suite à cette étape, les déclencheurs SLT existants sont supprimés ou présentent un état incohérent.

2. Dans votre système SLT, recréez les déclencheurs SLT. Pour en savoir plus sur la recréation de déclencheurs SLT, consultez la note SAP 2254376 - Un ou plusieurs déclencheurs SLT présentent un état incohérent.

3. Si l'état de la réplication est Load /Replication blocked, réinitialisez l'état de la réplication à l'aide de la transaction LTRC. Pour en savoir plus sur la réinitialisation de l'état de la réplication, consultez la note SAP 2204955 - Les tables SLT sont à l'état "Chargement /Réplication bloqués".

4. Effacez les journaux, le cas échéant.

5. Ajoutez, mettez à jour ou supprimez une entrée dans la table source.

6. Validez le résultat de la réplication dans BigQuery.

Modifier le type de données pour le remplacer par un type de données non compatible

Pour remplacer le type de données d'une colonne existante par un type de données non compatible, procédez comme suit :

1. Dans votre système SLT, arrêtez la réplication à l'aide de la transaction LTRC.
2. Pour la réplication CDC via Pub/Sub, supprimez le schéma cible, l'abonnement BigQuery et le sujet Pub/Sub dans Pub/Sub.
3. Dans BigQuery, supprimez la table cible.
4. Modifiez le type de données dans le système source.
5. Dans votre système SLT, démarrez la réplication à l'aide de la transaction LTRC.

Pour en savoir plus sur les modifications de structure de table, consultez la page BigQuery Connector pour SAP : gérer les modifications de structure de table comme un pro.

Gérer le schéma Pub/Sub pour les modifications de la structure des tables

Lorsque la structure de votre table change, le schéma Pub/Sub intermédiaire est également mis à jour pour refléter les modifications apportées à la structure de la table pour la réplication CDC via Pub/Sub. Cela entraîne la création d'une nouvelle révision du schéma.

Pub/Sub conserve un historique de ces révisions, qu'il utilise ensuite pour interpréter correctement les messages. Pub/Sub autorise un maximum de 20 révisions de schéma par sujet. Le dépassement de cette limite peut entraîner des erreurs et empêcher d'autres mises à jour du schéma.

Lorsque la limite de 20 révisions de schéma est atteinte, le système SAP SLT reçoit des messages d'erreur indiquant qu'il est impossible de créer de nouvelles révisions de schéma. Dans ce cas, vous recevez les erreurs suivantes :

• Journaux SAP : erreurs dans les journaux SLT liées aux opérations Pub/Sub, par exemple :

  • /GOOG/MSG : 429 - You have exceeded your revisions per schema quota (schema = SCHEMA_NAME)
  • Cannot create more schema revisions

• État de la réplication : l'état de la réplication des tables concernées peut passer à "Chargement/Réplication bloqués".

• Erreurs Pub/Sub : erreurs côté Pub/Sub indiquant que le schéma ne peut pas être mis à jour.

Lorsque vous constatez ces erreurs, vous pouvez effectuer les opérations suivantes :

• Analysez et supprimez les anciennes révisions de schéma : si les anciennes révisions de schéma ne sont plus nécessaires, supprimez-les à l'aide de la console Google Cloud ou de gcloud CLI. Pour en savoir plus, consultez Supprimer une révision de schéma.

• Créer un schéma : si vous ne pouvez pas supprimer les anciennes révisions de schéma, vous pouvez créer un schéma Pub/Sub. Pour créer un schéma Pub/Sub, procédez comme suit :

  1. Dans votre système SLT, arrêtez la réplication à l'aide de la transaction LTRC.
  2. Dans les attributs de table, mettez à jour le nouveau nom de schéma dans le champ Schéma Pub/Sub.
  3. Dans votre système SLT, démarrez la réplication à l'aide de la transaction LTRC.
  4. Le connecteur crée automatiquement un schéma en fonction de la définition de la table source.
  5. Une fois la réplication vérifiée, vous pouvez supprimer l'ancien schéma.

Sorties optimisées

BigQuery Connector pour SAP fournit plusieurs points d'amélioration dans son code afin de permettre aux développeurs ABAP d'insérer du code pour ajouter des fonctionnalités personnalisées.

Le tableau suivant répertorie les fonctions compatibles avec les points d'amélioration, les méthodes et la classe contenant ce point d'amélioration.

Paramètres avancés

Vous pouvez également modifier les paramètres avancés de BigQuery Connector pour SAP. Google Cloud recommande de modifier les paramètres avancés uniquement après avoir effectué une analyse complète et mesuré l'impact des nouvelles valeurs sur les performances. Il vous incombe de vous assurer que les nouveaux paramètres avancés de BigQuery Connector pour SAP n'entraînent pas d'échecs ni de problèmes de performances.

Les paramètres avancés de BigQuery Connector pour SAP sont appliqués au niveau du système et sont communs à toutes les clés de transfert de masse. Si les paramètres avancés ne sont pas modifiés, BigQuery Connector pour SAP fonctionne avec les paramètres par défaut.

Procédez comme suit pour modifier les paramètres avancés :

1. Dans l'interface utilisateur graphique de SAP, saisissez la transaction /GOOG/SLT_SETTINGS précédée de /n :

   /n/GOOG/SLT_SETTINGS

2. Dans le menu déroulant Tableau des paramètres de l'écran de lancement de la transaction /GOOG/SLT_SETTINGS, sélectionnez Paramètres.

3. Cliquez sur l'icône Exécuter. L'écran Maintenance des paramètres BigQuery – Champs s'affiche.

4. Cliquez sur l'icône Insérer une ligne.

5. Sur la ligne affichée, spécifiez les paramètres suivants :

   1. Dans le champ Nom du paramètre, saisissez le nom du paramètre. La description du paramètre est renseignée automatiquement.

   2. Dans le champ Valeur du paramètre, saisissez une valeur.

      Pour en savoir plus sur les paramètres avancés, consultez la section Paramètres avancés.

6. Cliquez sur Enregistrer.

   Vos paramètres avancés sont stockés sous forme d'enregistrement dans la table de configuration /GOOG/BQ_PARAM et les champs Modifié par, Modifié le et Modifié à sont automatiquement renseignés.

Paramètres avancés

Le tableau suivant présente les paramètres avancés pour BigQuery Connector pour SAP.