Partager via

Créer des fichiers de script (AccessToSQL)

Avant de démarrer l’application console de l’Assistant Migration SQL Server (SSMA), créez le fichier de script. Si nécessaire, créez le fichier de valeur de variable et le fichier de connexion du serveur.

Le fichier de script comporte trois sections :

  1. config: définissez les paramètres de configuration de l’application console.

  2. servers: définissez les définitions de serveur source et cible. Vous pouvez également placer ces définitions dans un fichier de connexion serveur distinct.

  3. script-commands: Exécutez des commandes de workflow SSMA.

Chaque section est décrite en détail dans les sections suivantes :

Configurer les paramètres de la console d’accès

Le fichier de script de console affiche les configurations d’un script.

Si vous spécifiez l’un des éléments du nœud de configuration, vous définissez le paramètre global pour toutes les commandes de script. Pour remplacer le paramètre global, définissez ces éléments de configuration dans chaque commande de la script-command section.

Vous pouvez configurer les options suivantes :

  1. Fournisseur de fenêtre de sortie : si vous définissez l’attribut suppress-messages sur true, la console n’affiche pas les messages spécifiques à la commande. Les attributs sont les suivants :

    • destination: spécifie si la sortie s’imprime dans un fichier ou stdout. Cet attribut est false par défaut.

    • file-name: chemin d’accès du fichier (facultatif).

    • suppress-messages: supprime les messages sur la console. Cet attribut est false par défaut.

    Exemple :

    <output-providers>
  <output-window
    suppress-messages="<true/false>"   (optional)
    destination="<file/stdout>"        (optional)
    file-name="<file-name>"            (optional)
   />
</output-providers>

    ou

    <...All commands...>
  <output-window
     suppress-messages="<true/false>"   (optional)
     destination="<file/stdout>"        (optional)
     file-name="<file-name>"            (optional)
   />
</...All commands...>

  2. Fournisseur de connexions de migration de données : spécifie le serveur source ou cible à utiliser pour la migration de données. source-use-last-used indique que le dernier serveur source utilisé est utilisé pour la migration de données. De même, target-use-last-used indique que le dernier serveur cible utilisé est utilisé pour la migration de données. Utilisez les attributs source-server ou target-server pour spécifier le serveur.

    Vous ne pouvez utiliser qu’un des attributs suivants :

    • source-use-last-used="true" (par défaut) ou source-server="source_servername"
    • target-use-last-used="true" (par défaut) ou target-server="target_servername"

    Exemple :

    <output-providers>
  <data-migration-connection   source-use-last-used="true"
                               target-server="target_1"/>
</output-providers>

    ou

    <migrate-data>
  <data-migration-connection   source-server="source_1"
                               target-use-last-used="true"/>
</migrate-data>

  3. Fenêtre contextuelle d’entrée utilisateur : gère les erreurs lorsque la console charge des objets à partir de la base de données. L'utilisateur fournit les modes d'entrée et, en cas d'erreur, la console agit selon les spécifications de l'utilisateur.

    Les modes sont les suivants :

    • ask-user: invite l’utilisateur à continuer (yes) ou à arrêter suite à une erreur (no).
    • error: la console affiche une erreur et arrête l’exécution.
    • continue: la console passe à l’exécution.

    Le mode par défaut est error.

    Exemple :

    <output-providers>
  <user-input-popup mode="<ask-user/continue/error>"/>
</output-providers>

    ou

    <!-- Connect to target database -->
<connect-target-database server="target_0">
  <user-input-popup mode="<ask-user/continue/error>"/>
</connect-target-database>

  4. Fournisseur de reconnexion : définit les paramètres de reconnexion s’il existe des échecs de connexion. Définissez cette option pour les serveurs source et cible.

    Les modes de reconnexion sont les suivants :

    • reconnect-to-last-used-server: si la connexion n’est pas active, elle tente de se reconnecter au dernier serveur utilisé au plus cinq fois.
    • generate-an-error: si la connexion n’est pas active, le système génère une erreur.

    Le mode par défaut est generate-an-error.

    Exemple :

    <output-providers>
  <reconnect-manager on-source-reconnect="<reconnect-to-last-used-server/generate-an-error>"
                     on-target-reconnect="<reconnect-to-last-used-server/generate-an-error>"/>
</output-providers>

    ou

    <!--synchronization-->
<synchronize-target>
  <reconnect-manager on-target-reconnect="reconnect-to-last-used-server"/>
</synchronize-target>

    ou

    <!--data migration-->
<migrate-data server="target_0">
  <reconnect-manager
    on-source-reconnect="reconnect-to-last-used-server"
    on-target-reconnect="generate-an-error"/>
</migrate-data>

  5. Fournisseur de surécriture de convertisseur : utilisez ce paramètre pour gérer les objets déjà présents sur la métabase cible. Les actions possibles sont les suivantes :

    • error: la console affiche une erreur et arrête l’exécution.
    • overwrite: remplace les valeurs d’objet existantes. Cette action est la valeur par défaut.
    • skip: la console ignore les objets qui existent déjà sur la base de données.
    • ask-user: invite l’utilisateur à entrer (yes ou no).

    Exemple :

    <output-providers>
  <object-overwrite action="<error|skip|overwrite|ask-user>"/>
</output-providers>

    ou

    <convert-schema object-name="ssma.TT1">
  <object-overwrite action="<error|skip|overwrite|ask-user>"/>
</convert-schema>

  6. Fournisseur de conditions préalables ayant échoué : utilisez ce paramètre pour gérer les conditions préalables requises pour le traitement d’une commande. Par défaut, strict-mode est false. Si vous la définissez sur true, le système génère une exception si les prérequis ne sont pas remplis.

    Exemple :

    <output-providers>
  <prerequisites strict-mode="<true|false>"/>
</output-providers>

  7. Arrêt de l’opération : pour arrêter l’opération pendant l’opération intermédiaire, utilisez le raccourci clavier Ctrl+C . La console SSMA attend que l’opération se termine avant de mettre fin à son exécution.

    Si vous souhaitez arrêter immédiatement l’exécution, appuyezde nouveau sur le raccourci clavier Ctrl +C pour arrêter brusquement l’application console SSMA.

  8. Fournisseur de progression : fournit des informations sur la progression de chaque commande de console. Ce paramètre est désactivé par défaut. Les attributs de rapport de progression sont les suivants :

    • off
    • every-1%
    • every-2%
    • every-5%
    • every-10%
    • every-20%

    Exemple :

    <output-providers>
  <progress-reporting enable="<true|false>"           (optional)
                      report-messages="<true|false>"  (optional)
                      report-progress="every-1%|every-2%|every-5%|every-10%|every-20%|off" (optional)/>
</output-providers>

    ou

    <...All commands...>
  <progress-reporting
    enable="<true|false>"              (optional)
    report-messages="<true|false>"     (optional)
    report-progress="every-1%|every-2%|every-5%|every-10%|every-20%|off"     (optional)/>
</...All commands...>

  9. Verbosité du journal : définit le niveau de verbosité du journal. Ce paramètre correspond à l’option Toutes les catégories dans l’interface utilisateur. Par défaut, le niveau de verbosité du journal est error.

    Les options au niveau de l’enregistreur d’événements sont les suivantes :

    • fatal-error: journalise uniquement les messages d'erreur fatale.
    • error: enregistre uniquement les messages d'erreur et d'erreur fatale.
    • warning : enregistre tous les niveaux, à l’exception des messages de débogage et du message d’information.
    • info: journalise tous les niveaux à l’exception des messages de débogage.
    • debug: enregistre tous les niveaux de messages.

    Remarque

    SSMA consigne les messages obligatoires à n’importe quel niveau.

    Exemple :

    <output-providers>
  <log-verbosity level="fatal-error/error/warning/info/debug"/>
</output-providers>

    ou

    <...All commands...>
  <log-verbosity level="fatal-error/error/warning/info/debug"/>
</...All commands...>

  10. Remplacer le mot de passe chiffré : si true, la section définition du serveur du fichier de connexion du serveur ou le fichier de script utilise le mot de passe de texte clair pour remplacer le mot de passe chiffré stocké dans le stockage protégé, s’il existe. Si le mot de passe de texte clair n’est pas spécifié, l’utilisateur est invité à entrer le mot de passe.

    Deux cas se produisent :

    1. Si l'option de remplacement est false, l'ordre de recherche est Stockage protégé > Fichier de script > Fichier de connexion au serveur > Invite de l'utilisateur.

    2. Si l’option de remplacement est true, l’ordre de recherche est fichier de script > fichier de connexion au serveur > demander à l’utilisateur.

    Exemple :

    <output-providers>
  <encrypted-password override="<true/false>"/>
</output-providers>

L’option non configurable est la suivante :

  • Nombre maximal de tentatives de reconnexion : lorsqu’une connexion établie expire ou s’arrête en raison d’une défaillance réseau, le serveur doit se reconnecter. La console autorise jusqu’à cinq5 () nouvelles tentatives de reconnexion. Une fois ces nouvelles tentatives effectuées, la console effectue automatiquement la reconnexion. La fonctionnalité de reconnexion automatique réduit vos efforts en réexécutant le script.

Paramètres de connexion du serveur

Vous pouvez définir des paramètres de connexion de serveur dans le fichier de script ou dans le fichier de connexion du serveur. Pour plus d’informations, consultez Créer les fichiers de connexion du serveur.

Commandes de script

Le fichier de script contient une séquence de commandes de flux de travail de migration au format XML. L’application console SSMA traite la migration dans l’ordre des commandes apparaissant dans le fichier de script.

Par exemple, une migration de données classique d’une table spécifique dans une base de données Access suit la hiérarchie de : Table de base de données > .

Lorsque toutes les commandes du fichier de script s’exécutent correctement, l’application console SSMA quitte et retourne le contrôle à l’utilisateur. Le contenu d’un fichier de script est plus ou moins statique, avec des informations de variable contenues dans des fichiers de valeurs de variable ou dans une section distincte dans le fichier de script pour les valeurs de variable.

Exemple :

<!--Sample of script file commands -->
<ssma-script-file>
  <script-commands>
    <create-new-project project-folder="$project_folder$"
                        project-name="$project_name$"
                        overwrite-if-exists="true"/>
    <connect-source-database server="source_2"/>
    <save-project/>
    <close-project/>
  </script-commands>
</ssma-script-file>

Le dossier Exemples de scripts de console du répertoire produit fournit des modèles qui se composent de trois fichiers de script (pour l’exécution de différents scénarios), d’un fichier de valeur variable et d’un fichier de connexion de serveur :

  • AssessmentReportGenerationSample.xml
  • ConversionAndDataMigrationSample.xml
  • VariableValueFileSample.xml
  • ServersConnectionFileSample.xml

Vous pouvez exécuter les modèles après avoir modifié les paramètres pour la pertinence.

Pour obtenir la liste complète des commandes de script, consultez Exécuter la console SSMA.

Validation du fichier de script

Vous pouvez valider votre fichier de script par rapport au fichier A2SSConsoleScriptSchema.xsd de définition de schéma dans le Schemas dossier.

Contenu connexe

  • Last updated on