Personnalisation et liaison de profils SQLJ à l'aide de l'outil db2sqljcustomize

Personnalisez et liez les profils SQLJ à l'aide de l'outil db2sqljcustomize avant d'installer l'application SQLJ dans le serveur d'applications.

Avant de commencer

Pour cela, vous devez disposer d'une application SQLJ qui a été déployée mais elle ne doit pas être installée dans le serveur d'applications. Si l'application est déjà installée dans le serveur d'applications, vous devez la réinstaller une fois que vous avez personnalisé les profils. Vous avez également besoin de profils sérialisés pour l'application SQL pour Java.
Pour les applications SQL pour Java qui utilisent la persistance gérée par conteneur, vous pouvez déployer l'application de deux manières :
  • Déployez l'application SQL pour Java sur le serveur d'applications. Consultez la rubrique relative au déploiement d'applications SQL pour Java qui utilisent la persistance gérée par conteneur pour plus d'informations.
  • Déployez des applications SQL pour Java avec l'outil ejbdeploy. Consultez la rubrique relative au déploiement d'applications SQL pour Java qui utilisent la persistance gérée par conteneur avec l'outil ejbdeploy.
Pour les applications SQL pour Java qui utilisent la persistance gérée par le bean, consultez la rubrique relative au déploiement d'applications SQL pour Java qui utilisent la persistance gérée par le bean, des servlets ou des beans session.

Pourquoi et quand exécuter cette tâche

Pour profiter des avantages offerts par les applications SQL pour Java dans le serveur d'applications, vous devez personnaliser les profils SQL pour Java. Le processus de personnalisation ajoute aux profils des informations spécifiques à la base de données DB2. La base de données utilise ces informations à l'exécution. Par défaut, quatre packages DB2 sont créés dans la base de données, un par niveau d'isolation.
Le serveur d'applications prend en charge la personnalisation et la liaison des profils SQL pour Java dans la console d'administration ou avec les scripts :
  • Pour la prise en charge de la console d'administration, consultez la rubrique relative à la personnalisation et à la liaison des profils dans les applications SQL pour Java™ (SQLJ).
  • Pour la prise en charge des scripts, consultez la rubrique relative au groupe de commandes de gestion des applications de l'objet AdminTask.

Procédure

  1. Assurez-vous que les tables de base de données nécessaires existent, comme décrit dans la rubrique relative au déploiement d'applications d'accès aux données.
  2. Transférez les profils sérialisés dans l'environnement dans lequel vous avez installé votre application. Vous pouvez également utiliser la commande Java jar pour extraire les profils sérialisés du fichier JAR du répertoire du fichier EAR installé.
  3. Ajoutez l'emplacement des profils SQL pour Java et le fichier JAR de l'application dans le chemin d'accès aux classes de votre environnement.
  4. Assurez-vous que les tables de base de données nécessaires existent, comme décrit dans la rubrique relative au déploiement d'applications d'accès aux données.
  5. Facultatif : Si votre application ne s'exécute pas dans un environnement groupé, vous pouvez utiliser le script Ant pour simplifier la personnalisation. Si vous exécutez la personnalisation SQL pour Java par lots sur un fichier EAR à l'aide de l'outil ejbdeploy, cet outil génère un script Ant nommé nom_application.ear.xml. Vous pouvez utiliser ce fichier script pour exécuter le personnaliseur DB2 sur chaque profil sérialisé dans tous les fichiers EAR de bean enterprise du fichier EAR associé. Le script met à jour le fichier JAR de chaque bean enterprise avec un profil sérialisé et remplace les fichiers JAR du fichier EAR existant par les versions modifiées.
    [AIX Solaris HP-UX Linux Windows]L'outil est le suivant :
    • [AIX][HP-UX][Solaris][Linux]ws_ant
    • [Windows]ws_ant.bat
    1. Modifiez les valeurs de l'URL de la base de données, ainsi que l'utilisateur de base de données et le mot de passe dans ejbdeploy.sqlj.properties. Ce fichier est commun à tous les scripts Ant générés par la commande ejbdeploy. Le script ejbdeploy.sqlj.properties définit les propriétés générales suivantes :
      • URL de la base de données - db.url
      • Utilisateur - db.user
      • Mot de passe - db.password
      Le script Ant personnalise le profil à l'aide des propriétés URL, utilisateur et mot de passe du profil sérialisé. Par défaut, les propriétés du profil sérialisées sont créées à partir des propriétés générales.
    2. Exécutez le script Ant, en indiquant la cible properties. Par exemple :
      ws_ant -buildfile nom_application.ear.xml properties
      Ce script permet de créer le fichier de propriétés, nom_application.ear.properties. Le fichier nom_application.ear.properties contient des propriétés qui indiquent les noms par défaut des modules correspondant à chaque profil sérialisé dans le fichier EAR. Voici un exemple de fichier de propriétés :
      url.MyEJB1.jar.DB2UDBNT_V8_1=jdbc:db2://localhost:50000/MyDB1
      user.MyEJB1.jar.DB2UDBNT_V8_1=dbuser
      password.MyEJB1.jar.DB2UDBNT_V8_1=dbpassword
      pkg.MyEJB1.jar.DB2UDBNT_V8_1=TEST
      url.MyEJB2.jar.DB2UDBNT_V8_1=jdbc:db2://localhost:50000/MyDB2
      user.MyEJB2.jar.DB2UDBNT_V8_1=dbuser  
      password.MyEJB2.jar.DB2UDBNT_V8_1=dbpassword
      pkg.MyEJB2.jar.DB2UDBNT_V8_1=WORK
    3. Dans le Centre de contrôle DB2, identifiez les modules installés dans la base de données. Le personnaliseur SQLJ de DB2 requiert une URL de base de données de type 4 au format suivant :
      jdbc:db2://nom_hôte:port/nom-base de données
      Un ID utilisateur et un mot de passe sont également nécessaires. La valeur du port est 50000, sauf si vous la modifiez lors de l'installation de DB2.
    4. Modifiez les noms utilisés par le fichier script pour éviter que le nom de chaque profil de personnalisation n'entre en conflit avec les noms des modules existants dans la base de données. Les scripts Ant, générés pour différents fichiers EAR, utilisent par défaut les mêmes noms de module et remplacent les modules existants si leurs noms ne sont pas modifiés. Le remplacement des modules entraîne des erreurs d'exécution.

      DB2 utilise les sept premiers caractères du nom du module. Le personnaliseur de DB2 utilise ce nom pour créer quatre modules dans la base de données. Par exemple, si vous indiquez le nom TEST, le personnaliseur DB2 crée les modules appelés TEST1, TEST2, TEST3 et TEST4.

    5. Exécutez le script Ant. Le script Ant met à jour le fichier EAR d'origine avec les profils sérialisés modifiés.
      Eviter les incidents Eviter les incidents: Assurez-vous que vous disposez du fichier db2jcc.jar dans le chemin d'accès aux classes. Il doit être ajouté à la variable d'environnement du chemin d'accès aux classes lors de l'installation de DB2 V8 FixPak1. gotcha
      Voici un exemple de commande Ant :
      ws_ant -Dwork.dir=tmp 
             -Dscript.property.file=other.properties
             -buildfile nom_application.ear.xml
      où :
      • -buildfile indique le nom du fichier XML à créer.
      • -Dscript.property.file indique un autre fichier de propriétés. Ce paramètre est facultatif. Si vous souhaitez que votre script Ant utilise un autre fichier au lieu du fichier nom_application.ear.properties, spécifiez la propriété Dscript.property.file lorsque vous exécutez le script.
      • -Dwork.dir indique un répertoire temporaire du script. Ce script va créer et supprimer des fichiers et des sous-répertoires dans ce répertoire. Si le répertoire de travail contient des fichiers et des répertoires de même nom que les fichiers et répertoires utilisés par le script, ce dernier les efface. Ce script crée et utilise un répertoire tmp comme répertoire de travail.
    6. Effectuez l'installation de l'application dans le serveur d'applications..
  6. Exécutez l'outil db2sqljcustomize pour personnaliser les profils SQL pour Java qui correspondent au fichier JAR de chaque bean enterprise. Lorsque vous générez votre code de déploiement, les profils sérialisés (fichiers avec extension .ser) propres à votre application sont créés. Ces profils se trouvent dans le même répertoire que vos fichiers SQLJ et doivent être personnalisés dans l'environnement avant d'être utilisés. Lorsque vous exécutez le personnaliseur SQLJ DB2 sur les profils sérialisés, vous créez dans la base de données un SQL statique que DB2 utilisera en phase d'exécution. La phase de personnalisation crée quatre modules de base de données contenant un SQL statique, à raison d'un par niveau d'isolement.
    1. Facultatif : Prévoyez d'utiliser l'outil de personnalisation SQLJ pour activer la mise en cache de contexte des connexions aux sources de données de votre application. Le groupe de correctifs 6 de DB2 version 8.1 propose la nouvelle option de mise en cache db2optimize avec l'outil db2sqljcustomize. Vous pouvez l'exécuter si votre application utilise un contexte de connexion explicite à la place du contexte par défaut.
      Eviter les incidents Eviter les incidents:
      • La prise en charge de la mise en cache du contexte SQLJ requiert DB2 avec le pilote JCC IBM® ou la version 2.2 ou ultérieure du pilote JDBC DB2 Universal avec l'application de l'APAR PQ87786.
      • Si vous voulez activer la mise en cache de contexte pour une application ou un bean BMP qui place en cache des connexions pour les limites des transactions, vous ne pouvez pas utiliser de connexions partageables. Vous devez utiliser le modèle d'utilisation des connexions obtenir/utiliser/fermer lorsque vous appelez l'option db2optimize. Sinon, une exception liée à un objet fermé se produira. Le code suivant donne un exemple d'utilisation incorrecte des connexions pour la mise en cache de contexte :
        utx.begin(); 
             cons =ds.getConnection( 
             request.getParameter("db.user"), 
             request.getParameter("db.password"));         
                 cmctx1 = new CM_context(cons);                       
                 #sql [cmctx1] {DELETE FROM cmtest WHERE id=1};     
         utx.commit(); 
               //L'instruction suivante vérifie le résultat : 
                 #sql [cmctx1] cursor1 = {SELECT id, name FROM cmtest WHERE id=1};
        Dans ce cas, l'instruction Select obtient une exception d'objet fermé. Pour empêcher que cette exception ne survienne, fermez la connexion avant de valider la transaction. Obtenez ensuite une nouvelle connexion et un nouveau contexte avant d'exécuter l'instruction Select.
      gotcha
      L'exemple de code suivant indique la syntaxe appropriée pour l'exécution de l'option sur le profil sérialisé :
      sqlj -db2optimize SQLJTransactionTest.sqlj
      db2sqljcustomize -url jdbc:db2://localhost:50000/nom_base de données -user NOM_UTILISATEUR -password MOT DE PASSE
      SQLJTransactionTest_SJProfile0.ser
    2. Exécutez l'outil db2sqljcustomize pour personnaliser les profils SQL pour Java. Après l'exécution de la commande db2sqljcustomize, les profils personnalisés se trouvent dans le répertoire à partir duquel vous avez lancé la commande. Si vous exécutez la commande db2sqljcustomize à partir du répertoire qui contient les profils sérialisés non personnalisés, les versions personnalisées remplacent les versions précédentes portant le même nom.
      La syntaxe recommandée pour exécuter la commande db2sqljcustomize est la suivante :
      db2sqljcustomize -url URL_JDBC -user NOM_UTILISATEUR  -password MOT DE PASSE [-rootpkgname NOM_MODULE] PROFIL1_SERIALISE PROFIL2_SERIALISE ...
      où :
      • URL_JDBC est l'URL JDBC utilisée pour accéder au système DB2 sur lequel résident vos tables.
      • NOM_UTILISATEUR est un nom d'utilisateur valide du système DB2 sur lequel résident vos tables.
      • MOT DE PASSE est le mot de passe du nom d'utilisateur spécifié.
      • NOM_MODULE est le nom de membre d'un ensemble de données partitionnées (PDS) valide, ne pouvant pas dépasser sept caractères. Chacun des quatre modules créés par le personnaliseur de profil commence par ce nom, accolé à un chiffre compris entre 1 et 4. Si vous personnalisez un seul profil sérialisé, cette valeur est, par défaut, une version abrégée du nom du profil sérialisé et le paramètre -rootpkgname n'est pas requis. Si vous personnalisez plusieurs profils sérialisés avec la même commande, il n'existe pas de valeur par défaut et le paramètre -rootpkgname est requis.
      • PROFIL#_SERIALISE est le nom du profil sérialisé que vous personnalisez.
        • Pour personnaliser plusieurs profils sérialisés avec la même commande, indiquez plusieurs fichiers en les séparant par un espace.
        • Sinon, vous pouvez spécifier le paramètre -rootpkgname pour personnaliser plusieurs profils sérialisés avec la même commande.
      Remarque : Les options suivantes permettent de mieux contrôler le processus de personnalisation :
      • -automaticbind yes indique que le personnaliseur SQLJ DB2 doit être exécuté sur les profils sérialisés pour créer dans la base de données le SQL statique que cette dernière utilisera lors de la phase d'exécution. La phase de personnalisation crée quatre modules de base de données contenant un SQL statique, à raison d'un par niveau d'isolement.
      • -onlinecheck NO et -bindoptions "VALIDATE RUN" indiquent les paramètres pour contourner les erreurs lors de la personnalisation d'un profil et pour garantir la réussite de la personnalisation.
  7. Mettez à jour le fichier JAR des beans enterprise avec les profils sérialisés.
  8. Utilisez la commande jar pour remplacer les profils sérialisés dans votre fichier JAR par les profils personnalisés.
    Eviter les incidents Eviter les incidents: Les fichiers personnalisés doivent se trouver à un emplacement du chemin de classe de l'application, en amont des profils sérialisés non personnalisés qui se trouvent dans votre fichier JAR. Si vous décidez de remplacer les profils sérialisés dans votre fichier JAR, veillez à conserver la structure de répertoires dans laquelle se trouvent les profils.gotcha
  9. Placez le fichier JAR du bean enterprise, des servlets et des profils sérialisés dans un fichier EAR (archive d'entreprise).
  10. Installez l'application dans le serveur d'applications.
    Eviter les incidents Eviter les incidents: Ne sélectionnez pas Déploiement de beans enterprise lors du processus d'installation de l'application dans la console d'administration. Si vous redéployez les beans enterprise à partir de la console d'administration, vous perdrez les modifications de personnalisation que vous avez apportées.gotcha

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_sqljcustwithtool
Nom du fichier : tdat_sqljcustwithtool.html