Version 2.0 : Guide d'utilisation de BigQuery Connector pour SAP

Ce guide présente 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 versions, pour BigQuery Connector pour SAP versions 2.0 et 2.1.

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

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

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 :

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.

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.

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.

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

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 des enregistrements, puis indique à SAP LT Replication Server d'interrompre la tâche de réplication.

Il s'agit de la valeur 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 de fragments 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.

TRUE FAUX

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 anciens journaux si vous en avez.

  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 anciens journaux si vous en avez.

  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.

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