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

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.

Valeurs de performance de référence observées

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 :

S/4HANA

  • Table : ACDOCA
    • 343 millions d'enregistrements
    • 477 colonnes
  • Chargement initial
    • Débit de chargement : 350 millions d'enregistrements par heure en moyenne
    • Durée de chargement : 59 minutes en moyenne
  • Réplication
    • Débit de chargement de la table source : 50 millions d'enregistrements par heure en moyenne
    • Débit de réplication maximal : 50 millions d'enregistrements par heure en moyenne

ECC

  • Table : MSEG
    • 203 millions d'enregistrements
    • 188 colonnes
  • Chargement initial
    • Débit de chargement : 385 millions d'enregistrements par heure en moyenne
    • Durée de chargement : 32 minutes en moyenne
  • Réplication
    • Débit de chargement de la table source : 50 millions d'enregistrements par heure en moyenne
    • Débit de réplication maximal : 69 millions d'enregistrements par heure en moyenne

Les valeurs de performance ci-dessus sont les références que les testeurs Google 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 :

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 la section précédente, Valeurs de performance de référence observées.

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 :

S/4HANA

  • Architecture d'installation de SAP LT Replication Server :
    • Architecture intégrée
  • Serveurs système sources :
    • Deux serveurs d'application, chacun sur un type de machine personnalisé Compute Engine sur base N2 avec les spécifications suivantes :
      • vCPU : 60
      • Mémoire : 324 Go
      • Plate-forme du processeur : Intel Cascade Lake
    • Un serveur SAP HANA sur une VM Compute Engine m1-ultramem-80 avec les spécifications suivantes :
      • vCPU : 80
      • Mémoire : 1900 Go
      • Plate-forme du processeur : Intel Broadwell
  • Versions logicielles :
    • S/4HANA 1909
    • SAP LT Replication Server : S/4CORE 104 SP00
  • Taille de la table :
    • Nom de la table : ACDOCA, données de ligne d'entrée de journal de grand livre
    • Nombre d'enregistrements : 343 millions
    • Nombre de colonnes : 477
  • Processus de travail sur chaque serveur d'application :
    • 60 processus de dialogue
    • 220 processus en arrière-plan
  • Paramètres de chargement dans SAP LT Replication Server :
    • Tâches : 99
    • Type de lecture : 1 plage
    • Calcul : plages automatiques
  • Paramètres de réplication :
    • Tâches : 99
    • Utiliser les champs de clé pour calculer des plages pour la table de journalisation
    • 128 plages

ECC

  • Architecture d'installation de SAP LT Replication Server :
    • Architecture intégrée
  • Serveurs système sources :
    • Deux serveurs d'applications, chacun sur une VM Compute Engine n2-highmem-48 avec les spécifications suivantes :
      • vCPU : 60
      • Mémoire : 348 Go
      • Plate-forme du processeur : Intel Cascade Lake
  • Versions logicielles :
    • SAP NetWeaver : 7.0 EHP2
    • SAP LT Replication Server : DMIS 2011_1_700 SP17
  • Taille de la table :
    • Table : MSEG, documents de gestion de l'inventaire des matériaux
    • Nombre d'enregistrements : 203 millions
    • Nombre de colonnes : 188
  • Processus de travail sur chaque serveur d'application :
    • 60 processus de dialogue
    • 100 processus en arrière-plan
  • Paramètres de chargement dans SAP LT Replication Server :
    • Tâches : 99
    • Type de lecture : 5 expéditeurs
    • File d'attente : plages manuelles
  • Paramètres de réplication :
    • Tâches : 99
    • Plages pour la table de journalisation : utiliser les champs de clé pour calculer des plages
    • Nombre de plages : 128

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 dynamique des fragments 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 :

Lorsque la taille de fragment dynamique est activée, la taille maximale de fragment autorisée par BigQuery Connector pour SAP reste cantonnée aux limites de quota de BigQuery, à savoir 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 taille de la partie SAP LT Replication Server est supérieure à celle des fragments BigQuery Connector pour SAP et la taille des fragments de 10 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 20 000 enregistrements, la taille des fragments pour le premier fragment est de 10 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 à 5 000 enregistrements.

  2. BigQuery Connector pour SAP effectue de nouvelles tentatives pour envoyer la taille des fragments de 5 000 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 à 2 500 enregistrements.

  3. Le connecteur BigQuery pour SAP effectue de nouvelles tentatives pour envoyer la taille des fragments de 2 500 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 2 500 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 :

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. Pour en savoir plus sur le démarrage d'un chargement initial ou d'une réplication, consultez les sections suivantes :

    • Si SAP LT Replication Server s'exécute sur une VM Compute Engine, consultez la section testez la réplication.
    • Si SAP LT Replication Server s'exécute sur un hôte externe à Google Cloud, consultez la section testez la 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. Si vous avez appliqué les correctifs pour la réplication des tables de cluster ou la configuration de l'audience par défaut pour l'authentification basée sur JWT, avant de mettre à jour BigQuery Connector pour SAP vers la version 2.6, vous devez supprimer le correctif. Pour plus d'informations sur la suppression d'un correctif, consultez la page SAP Créer, modifier et supprimer des mises en œuvre d'améliorations.
  2. Désactivez la configuration dans SAP LT Replication Server.
  3. Importez la nouvelle requête de transport SAP.
  4. 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

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 Google Cloud Console.

Pour en savoir plus, consultez :

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 BigQuery

Utilisez Cloud 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 de BigQuery Connector pour SAP

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.

Outil Créer une table

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. Si vous le souhaitez, vérifiez 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

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 à tous les champs de l'écran de mappage de champ 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 sur BigQuery.

Si une table est déjà répliquée ou si elle est 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émas. Vous ne pouvez utiliser cet outil que pour les tables SAP pour lesquelles le chargement initial ou la réplication n'a pas démarré.

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

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. L'outil fait partie du transport fourni par Google 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 sur Google 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 :

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 :

Nom Description
Clé de transfert Clé de transfert de masse correspondant à la configuration du transfert de masse.
Table SAP Nom de la table SAP en cours de réplication vers BigQuery.
Horodatage de début de l'exécution Heure de début de l'exécution d'une méthode BigQuery Connector pour SAP.
Horodatage de fin Heure de fin de l'exécution d'une méthode BigQuery Connector pour SAP.
Numéro de tâche Numéro de job unique pour chaque exécution terminée, qui est généré automatiquement à chaque exécution de l'outil de simulation de charge.
Numéro de cycle Numéro de séquence du cycle de traitement lors duquel le rapport a été généré. Le nombre d'enregistrements par cycle fourni dans l'entrée de simulation est transféré vers BigQuery pour chaque cycle.
Numéro de la partie Numéro de séquence de la partie. Le nombre d'enregistrements par cycle fourni dans l'entrée de simulation est divisé en parties en fonction de la taille de la partie spécifiée. L'implémentation de Business Add-Ins (BADI) associée à BigQuery Connector pour SAP est appelée pour chaque partie.
Nom du cours Nom du cours de la méthode BigQuery Connector pour SAP.
Nom de la méthode Nom de la méthode BigQuery Connector pour SAP. Les méthodes appelées par BigQuery Connector pour SAP sont consignées dans une séquence. Si l'option Journal détaillé est sélectionnée dans l'entrée de simulation, toutes les méthodes sont consignées. Sinon, seules les méthodes importantes sont consignées.
Appelée par la méthode Dernière méthode ayant appelé la méthode BigQuery Connector pour SAP actuelle.
Durée Temps total nécessaire à l'exécution d'une méthode BigQuery Connector pour SAP.
Nombre d'enregistrements Nombre d'enregistrements transmis à une méthode BigQuery Connector pour SAP. Ce champ ne s'affiche que pour les méthodes auxquelles les enregistrements sont transmis.
Méthode URI Nom de la méthode HTTP, dans le cas où la méthode ABAP effectue un appel d'API BigQuery.
Chaîne URI L'URL HTTP, dans le cas où la méthode ABAP effectue un appel d'API BigQuery.
Source du jeton Source du jeton d'authentification utilisé par l'outil de simulation de charge. Ne s'applique que si la mise en cache de jetons est activée dans la table /GOOG/CLIENT_KEY. Les valeurs possibles sont les suivantes :
  • A : valeur d'attribut statique issue d'un processus spécifique.
  • M : valeur de mémoire partagée, obtenue de la mémoire partagée entre plusieurs processus.
  • L : nouvelle valeur avec verrouillage de mémoire. S'il existe un verrouillage de mémoire et que le jeton mis en cache ne peut pas être lu, un nouveau jeton est généré.
  • N : nouvelle valeur sans verrouillage de mémoire. Si un jeton expire ou est introuvable dans la mémoire, un nouveau jeton est généré.
Date/Heure d'expiration Heure d'expiration du jeton d'authentification.
Ne s'applique que si la mise en cache de jetons est activée dans la table /GOOG/CLIENT_KEY.
Valeur du jeton Valeur du jeton d'authentification utilisé par l'outil de simulation de charge pour accéder à BigQuery.
Code renvoyé Code renvoyé par l'exécution de la méthode. Les valeurs possibles sont les suivantes :
  • 0 : indique une exécution réussie.
  • Un code d'erreur. En cas d'échec, le code d'erreur correspondant de BigQuery Connector pour SAP s'affiche. Pour en savoir plus sur les codes d'erreur, consultez le guide de dépannage de BigQuery Connector pour SAP.
Texte de l'erreur Titre de l'erreur, le cas échéant.
Description de l'erreur Informations détaillées sur l'erreur.
Taille de la charge utile Taille de la charge utile HTTP transmise vers l'API BigQuery Insert. Si l'exécution de la méthode comporte une erreur et que la taille de la charge utile est supérieure à 10 Mo, vous pouvez ajuster la taille de fragment afin de réduire la taille de la charge utile.
Texte d'information Tout message d'information pertinent généré par l'objet BAdI de BigQuery Connector pour SAP. Par exemple, lorsque la fragmentation dynamique est déclenchée, le message d'information suivant s'affiche : Dynamic chunking triggered. Chunk size reduced from INITIAL_CHUNK_SIZE_VALUE to FINAL_REDUCED_CHUNK_SIZE_VALUE.
Status État de l'exécution de la méthode. En cas d'échec de l'exécution d'une méthode, consultez le guide de dépannage de BigQuery Connector pour SAP afin de résoudre le problème.

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 :

Requêtes SQL pour le nombre d'enregistrements

Sur la page Éditeur SQL de BigQuery dans la console Google 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.

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

Outil de validation de réplication

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 les pages suivantes :

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.

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.

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 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
    • Élément de données externe
    • Nom du champ externe
    • Description du champ

  5. Une fois les cinq 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,External Data Element,External Field Name,Field Description
SAP_TABLE_NAME,SAP_FIELD_NAME1,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME1,BIGQUERY_FIELD_DESCRIPTION1
SAP_TABLE_NAME,SAP_FIELD_NAME2,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME2,BIGQUERY_FIELD_DESCRIPTION2
SAP_TABLE_NAME,SAP_FIELD_NAME3,BIGQUERY_DATA_TYPE,BIGQUERY_FIELD_NAME3,BIGQUERY_FIELD_DESCRIPTION3

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.

Gérer les 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 l'option SKIP n'est pas spécifiée lorsque BigQuery trouve un enregistrement avec une erreur de données, l'intégralité du fragment est supprimée 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.

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 s'agit du comportement par défaut.

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'option BREAK est activée 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 :

Option SKIP Option BREAK Comportement
FALSE TRUE

BigQuery supprime le fragment actuel sans insérer le moindre enregistrement dans la table BigQuery.

BigQuery Connector pour SAP n'envoie plus aucun fragment de la partie actuelle et indique à SAP LT Replication Server d'interrompre la tâche de réplication.

Il s'agit de la configuration recommandée.

FALSE FALSE

BigQuery supprime le fragment actuel sans insérer le moindre enregistrement dans la table BigQuery.

BigQuery Connector pour SAP envoie tous les fragments restants de la partie actuelle et récupère la partie suivante. BigQuery Connector pour SAP n'indique pas à SAP LT Replication Server d'interrompre le job de réplication.

Il s'agit de l'option par défaut.

TRUE TRUE

BigQuery ne supprime que l'enregistrement contenant l'erreur et insère les autres enregistrements du fragment actuel dans la table BigQuery.

BigQuery Connector pour SAP n'envoie plus aucun fragment de la partie actuelle et indique à SAP LT Replication Server d'interrompre le job de réplication.

VRAI FALSE

BigQuery ne supprime que l'enregistrement contenant l'erreur et insère les autres enregistrements du fragment actuel dans la table BigQuery.

BigQuery Connector pour SAP envoie tous les fragments restants de la partie actuelle et récupère la partie suivante. BigQuery Connector pour SAP n'indique pas à SAP LT Replication Server d'interrompre la tâche de réplication.

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.

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

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

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

  6. 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".

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

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

  9. 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. Par exemple, si le type de données d'une colonne passe de INT1 à INT2 dans une table source, les deux types de données sont compatibles avec le type de données INTEGER dans la table BigQuery cible.

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. Dans BigQuery, supprimez la table cible.
  3. Modifiez le type de données dans le système source.
  4. 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.

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.

Fonction Classe Méthode Spot Option
Mettre à jour le mappage pour un champ (nom de champ externe, type de données, etc…). /GOOG/CL_IUUC_REPL_RUNTIME CREATE_FLD_MAPPINGS /GOOG/ES_IUUC_REPL_RUNTIME /GOOG/UPDATE_FIELD_MAPPING
Mettre à jour le mappage de la table de champs en ajoutant ou en supprimant des champs. /GOOG/CL_IUUC_REPL_RUNTIME CREATE_FLD_MAPPINGS /GOOG/ES_IUUC_REPL_RUNTIME /GOOG/UPDATE_FIELD_MAPPINGS
Modifier la valeur d'un champ source avant qu'il ne soit converti en champ cible. /GOOG/CL_IUUC_REPL_RUNTIME_BQ FILL_TARGET_RECORDS /GOOG/ES_IUUC_REPL_RUNTIME_BQ /GOOG/CHANGE_SOURCE_FIELD
Après avoir converti un champ source en champ cible dans la table cible, modifier la valeur du champ cible. /GOOG/CL_IUUC_REPL_RUNTIME_BQ FILL_TARGET_RECORDS /GOOG/ES_IUUC_REPL_RUNTIME_BQ /GOOG/FILL_TARGET_FIELD
Ajouter un champ à la table cible qui n'existe pas dans la table source, au moment de la conversion de la table source vers la table cible. /GOOG/CL_IUUC_REPL_RUNTIME_BQ FILL_TARGET_RECORDS /GOOG/ES_IUUC_REPL_RUNTIME_BQ /GOOG/FILL_EXTRA_FIELD
Préparer un champ de schéma BigQuery avant la création de la table BigQuery. /GOOG/CL_GCP_CLIENT_BQ PREP_BQ_TABLE_SCHEMA /GOOG/ES_GCP_CLIENT_BQ /GOOG/PREPARE_SCHEMA_FIELD
En cas d'erreurs HTTP, collectez les données de journalisation après les appels HTTP à l'API BigQuery, afin de résoudre le problème. /GOOG/CL_GCP_CLIENT_BQ_SLT INSERT_TABLEDATA /GOOG/ES_GCP_CLIENT_BQ_SLT /GOOG/LOG_INSERT_ERROR

Paramètres avancés

Vous pouvez également modifier les paramètres avancés de BigQuery Connector pour SAP. Google Cloud vous 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. Vous devez 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.

Nom du paramètre Description Valeur par défaut Valeur valide
CHUNK_SIZE_DEF Il s'agit de la taille de fragment par défaut acceptée par BigQuery Connector pour SAP.
Si aucune taille de fragment n'est définie dans les paramètres, c'est la taille de fragment par défaut qui est utilisée.		 10 000 La valeur doit respecter les limites de quota BigQuery.
PERC_REDUC_DEF La réduction de la taille de fragment, exprimée en pourcentage.
Si la taille des fragments dynamiques est activée, leur taille est réduite de ce pourcentage jusqu'à ce qu'une taille idéale soit atteinte et que les données contenues dans les fragments soient transférées vers BigQuery.		 50 La valeur doit être comprise entre 1 et 99.
CMD_EXEC_TRIES Pour les systèmes SAP qui ne s'exécutent pas sur Google Cloud, si la commande du système d'exploitation que vous avez créée dans la transaction SM69 ne parvient pas à récupérer un jeton d'accès de Google Cloud, il s'agit du nombre de fois où BigQuery Connector pour SAP effectue une nouvelle tentative de récupération des jetons. 5 La valeur minimale que vous pouvez attribuer à ce paramètre est 1. Pour effectuer au moins une nouvelle tentative, définissez la valeur 2. La valeur maximale de ce paramètre doit être définie après analyse de l'impact des tentatives de récupération de jetons sur les performances de la réplication.
CMD_SECS_DEFLT Si vous avez activé la mise en cache des jetons, il s'agit de la durée, exprimée en secondes, après laquelle le jeton mis en cache expire. 3 500 La valeur doit être comprise entre 1 et 3599.