Considérations sur la migration

Avant de lancer la procédure de migration vers WebSphere Application Server Version 9.0, vous devez prendre en compte certaines considérations.

Configurations prises en charge Configurations prises en charge:

Cet article traite de la migration de configuration de profil. Pour faire migrer vos applications vers la dernière version, utilisez le kit d'outils de migration de WebSphere Application Server. Pour plus d'informations, voir Migration Toolkit on WASdev.

sptcfg

Remarques pour z/OS

Prenez en compte les informations ci-après avant de faire migrer Application Server for z/OS :
  • Le processus de migration conserve généralement les valeurs des variables définies par l'utilisateur ou des variables définies par le serveur d'applications. Toutefois, ce n'est pas le cas pour certaines variables spéciales. Il s'agit des variables suivantes :
    • WAS_INSTALL_ROOT
    • USER_INSTALL_ROOT
    • WAS_PRODUCT_ROOT
    • WAS_LIBS_DIR
    • WAS_PROPS_DIR
    • WAS_TEMP_DIR
    • APP_INSTALL_ROOT
    • DRIVER_PATH
    • WAS_INSTALL_LIBRARY
    • JAVA_HOME
    • DEPLOY_TOOL_ROOT
    • CONNECTOR_INSTALL_ROOT
    • TRANLOG_ROOT
    • MQJMS_LIB_ROOT
    • WAS_ETC_DIR
    • WEMPS_USER_ROOT
    • MQ_INSTALL_ROOT
    • WAS_DAEMON_ONLY_ICU_DATA
    • WAS_DAEMON_ONLY_CONFIG_ROOT
    • WAS_DAEMON_primordial_root
    • WAS_DAEMON_daemon_was_env_file
    Les valeurs de ces variables proviennent du modèle de profil lors de la création des profils par la migration. Si vous avez défini des valeurs personnalisées pour ces variables, celles-ci ne sont pas conservées dans l'édition de WebSphere Application Server vers laquelle vous effectuez la migration. Ces variables ne sont pas migrées car il s'agit de propriétés de WebSphere Application Server qui correspondent à des attributs de profil. Si vous devez remplacer leurs valeurs par des entrées différentes des entrées par défaut, vous devez changer les valeurs hors des processus de migration, de création de profil et d'installation du produit.
    Eviter les incidents Eviter les incidents: Faites particulièrement attention à la variable APP_INSTALL_ROOT. Même si vous avez défini un emplacement personnalisé pour cette variable, le processus de migration installe par défaut les applications à l'emplacement suivant :
    ${USER_INSTALL_ROOT}/installedApps
    gotcha
    Pour que le processus de migration applique l'emplacement d'installation des applications que vous avez défini :
    • spécifiez l'emplacement dans la zone du répertoire d'installation des applications (Application Install Directory) de zMMT,
    • sélectionnez l'option Migrer les applications et utiliser le précédent répertoire d'installation des applications durant la migration pour utiliser le chemin d'installation sans qu'il soit nécessaire de l'entrer de nouveau. Si le chemin d'installation de l'édition précédente contient des références à des variables, Application Server résout les variables avec les valeurs migrées.
  • Après avoir installé WebSphere Application Server Version 9.0 sur le système d'exploitation z/OS, vous pouvez être amené à créer une configuration de cellule WebSphere Application Server, Network Deployment complète et vouloir vérifier que celle-ci fonctionne correctement avant de tenter de migrer une cellule ou un noeud.

    Cette procédure permet de s'assurer que votre système possède tous les programmes prérequis et prend en charge le dernier niveau du produit.

  • Avant d'effectuer la migration, évaluez les éléments obsolètes dans WebSphere Application Server Version 9.0.

    Pour plus d'informations, voir Fonctions obsolètes, stabilisées, remplacées ou retirées.

  • Avant de faire migrer WebSphere Application Server Version 7.0 ou ultérieures vers la Version 9.0, connectez l'ID de région serviteur d'application à un fichier de clés et vérifiez que le certificat WebSphereCA est associé à ce fichier de clés. Sinon, des erreurs de sécurité se produisent si la sécurité globale est activée.
  • Les fonctionnalités du gestionnaire de haute disponibilité et du groupe central sont incluses dans WebSphere Application Server Version 7.0 ou ultérieures.

    Pour lire les remarques concernant la topologie et la configuration de groupe central susceptibles d'avoir un impact sur votre migration depuis la Version 7.0 ou ultérieures vers la Version 9.0, consultez Remarques sur la migration de groupe central.

  • Si vous comptez utiliser un client IIOP (Internet Inter-ORB Protocol) antérieur à la version 6.1 et que ce client doit être amené à interagir avec le serveur Version 9.0 sur la même partition logique (LPAR), la bibliothèque de procédures associée au démon de la Version 9.0 doit inclure les bibliothèques SBBOLD2 et SBBOLPA de l'édition antérieure dans son instruction STEPLIB.
  • La prise en charge de la migration exige que les configurations WebSphere Application Server source et cible résident sur la partition logique LPAR.

    Par conséquent, vous ne pouvez pas migrer une configuration existante vers une partition logique z/OS différente. De même, vous ne pouvez pas migrer vers ou depuis un système d'exploitation autre que z/OS avec les utilitaires de migration de WebSphere Application Server Version 9.0.

  • Les cellules de migration qui s'étendent sur des environnements Sysplex ou des systèmes d'exploitation ne doivent présenter aucun incident de migration unique. Vous faites migrer au niveau du noeud et vous utilisez les outils fournis basés sur la plateforme du noeud dont vous effectuez la migration.

    Pour plus d'informations sur la configuration d'une cellule à plateforme mixte, reportez-vous au livre blanc WebSphere for z/OS -- Heterogeneous Cells.

  • WebSphere Application Server sur système d'exploitation z/OS ne prend pas en charge les outils de ligne de commande WASPreUpgrade, WASPostUpgrade, and manageprofiles dont l'usage est réservé aux versions distribuées et i5/OS du produit.

    Vous devez générer les travaux de migration en utilisant l'outil z/OS Migration Management Tool ou la commande zmmt, puis les soumettre conformément aux instructions générées.

  • Le volume d'espace de stockage requis par le système lors de la migration vers Version 9.0 dépend de votre environnement.
    • La taille du système de fichiers est fournie par la valeur de l'allocation principale dans les cylindres spécifiés dans l'outil de gestion des migrations z/OS ou la commande zmmt lorsque vous générez une définition de migration. En outre, ce système de fichiers peut s'étendre automatiquement en fonction de l'allocation secondaire que vous spécifiez. Les valeurs par défaut fournies pour ces allocations par les outils de migration sont généralement suffisantes pour les données de configuration.
    • Le répertoire de sauvegarde de la migration requiert une quantité considérable d'espace temporaire. Cette quantité dépend de plusieurs facteurs, mais 100 cylindres suffisent dans la plupart des cas (y compris pour le traçage si nécessaire). Si vous n'êtes pas sûr de l'espace disponible pour votre répertoire temporaire, utilisez l'option de l'outil de gestion des migrations z/OS ou la commande zmmt pour déplacer le répertoire temporaire vers un emplacement personnalisé disposant d'espace plus important et montez-y votre propre système de fichiers temporaire. Si l'espace temporaire n'est pas suffisant, la procédure de migration peut se terminer de manière prématurée.
  • IBM® SDK, Java™ Technology Edition version 8 est la version SDK par défaut pour WebSphere Application Server Version 9.0. .
    Eviter les incidents Eviter les incidents: N'activez pas SDK Java Technology Edition version 8 tant que tous les noeuds n'ont pas été migrés vers Version 9.0.gotcha

    Pour plus d'informations, voir Migration des API et des spécifications.

  • Lorsque vous faites migrer une cellule avec plusieurs noeuds, les applications doivent rester au niveau JDK Java le plus bas jusqu'à ce que tous les noeuds aient été migrés.
  • Les rubriques consacrées à la migration supposent que WebSphere Application Server Version 9.0 est installé dans un environnement où il doit coexister avec des versions antérieures de WebSphere Application Server.
    Considérez les éléments suivants quand vous planifiez l'établissement d'une coexistence :
    • Mettez à niveau comme requis les éléments requis par WebSphere Application Server Version 9.0.

      Les versions antérieures de WebSphere Application Server continuent à s'exécuter aux niveaux prérequis plus élevés.

    • Examinez les ports qui ont été définis pour vérifier que l'installation de WebSphere Application Server Version 9.0 ne génère pas de conflits.

      Plus spécifiquement, notez que la définition de port démon par défaut pour les deux versions est la même lorsque l'installation coexiste avec WebSphere Application Server Version 7.0 ou ultérieures.

      Pour plus d'informations, voir Affectations de port par défaut.

    Pour plus d'informations, voir Exécution de serveurs d'applications coexistants.

  • Considérez les informations suivantes si vous planifiez d'avoir des cellules mixtes :
    • Vous pouvez mettre à niveau vers WebSphere Application Server Version 9.0 une partie des noeuds d'une cellule tout en conservant les autres à leur niveau de version antérieur. Cela signifie que, pendant un certain temps, vous pouvez administrer dans une même cellule des serveurs qui sont à la version antérieure et d'autres qui fonctionnent avec la nouvelle version.

      Dans cet environnement mixte, il peut exister des restrictions d'utilisation des serveurs au niveau de version antérieure. Pour plus de détails, voir Création de serveurs d'applications. La création de clusters et de membres de cluster peut également faire l'objet de restrictions. Pour plus de détails, voir Création de clusters.

  • La procédure de migration vers WebSphere Application Server Version 9.0 convertit les transports HTTP en chaînes de transport de conteneur Web de type structure de canaux.
    Pour plus d'informations sur la prise en charge de transports par WebSphere Application Server Version 9.0, voir les rubriques suivantes :
    • Configuration des chaînes de transport
    • Paramètres du canal de transport HTTP
    • Chaînes de transport
  • Prenez en compte les considérations de maintenance lors du développement de la stratégie de configuration des fichiers système.

    Si vous configurez votre environnement WebSphere Application Server, Network Deployment en utilisant la valeur par défaut pour le chemin système de fichiers du produit dans z/OS Migration Management Tool, tous les noeuds pointent directement sur le point de montage du système pour les fichiers du produit. Cette configuration rend presque impossible la maintenance sans interruption de service. Si une cellule est configurée de cette manière, la maintenance du système de fichiers du produit affecte tous les noeuds en même temps. Si plusieurs cellules sont configurées de cette manière, la maintenance du système de fichiers du produit affecte toutes les cellules en même temps.

    Vous pouvez vouloir spécifier ce qu'on appelle un "lien intermédiaire symbolique" entre le fichier système de configuration de chaque noeud et l'actuel point de montage du fichier système du produit. Cette stratégie fait l'objet d'une description dans le livre blanc WebSphere Application Server for z/OS V5 - Planning for Test, Production and Maintenance (Planification des tests, de la production et de la maintenance).

    Pour plus d'informations sur cette question et sa relation à l'application de la maintenance, reportez-vous au livre blanc Washington Systems Center Sample WebSphere for z/OS ND Configuration. Reportez-vous aux instructions WebSphere for z/OS : Updating an Existing Configuration HFS to Use Intermediate Symbolic Links pour plus d'informations sur l'obtention et l'exécution d'un utilitaire permettant de mettre à jour une configuration HFS existante afin qu'elle utilise des liens symboliques intermédiaires.

  • Les outils de migration créent un répertoire de sauvegarde qui contient une copie de la configuration de l'ancienne version. L'espace disponible pour ce répertoire doit être au moins égal à la taille du répertoire de configuration et des applications de la précédente version plus la taille de la sortie du travail de migration par lots.

    En principe, le travail de migration par lots produit peut de données en sortie, sauf si vous activez la trace. La taille de la sortie de trace varie en fonction des parties de la migration pour lesquelles vous avez activé la fonction de trace. Le plus gros fournisseur de trace est la phase de migration WASPostUpgrade. Il n'est pas rare que la sortie de trace atteigne environ 30 Mo pour cette phase.

  • WebSphere Application Server Version 9.0 ne prend pas en charge le fournisseur JDBC local DB2 for zOS (RRS).

    Si vous utilisez le fournisseur JDBC local DB2 for zOS (RRS) dans la configuration Version 7.0 ou ultérieures que vous allez faire migrer, vous devez modifier votre configuration pour qu'elle utilise le fournisseur DB2 Universal JDBC Driver Provider avant ou juste après la migration vers la Version 9.0. Les outils de migration de la Version 9.0 n'assurent pas la migration du fournisseur JDBC pour vous.

    Si vous utilisez le fournisseur JDBC local DB2 for zOS (RRS) dans la version devant migrer et ne modifiez pas votre configuration afin qu'elle utilise le fournisseur the DB2 Universal JDBC Driver Provider avant de migrer vers la Version 9.0, les événements suivants se produisent :
    • Lors de l'exécution des outils de migration, vous recevez le message suivant :
      MIGR0442W: Impossible de migrer le fournisseur jdbc DB2 pour zOS Local JDBC Provider (RRS). 
      Créez manuellement un fournisseur DB2 Universal Driver en guise de substitut. Voir la documentation 
      DB2 pour plus de détails.
    • Après la migration, l'accès à DB2 est interrompu et vous recevez le message suivant à l'exécution :
      DSRA8213W: Le fournisseur JDBC, DB2 for zOS Local JDBC Provider (RRS), n'est plus 
      pris en charge par WebSphere Application Server. Applications should use DB2 Universal 
      JDBC Driver Provider Type 2.
    Si vous estimez devoir changer votre configuration pour utiliser le fournisseur DB2 Universal JDBC Provider, vous pouvez y parvenir en accomplissant l'une des tâches suivantes :
    • Avant de procéder à la migration vers la Version 9.0, modifiez votre configuration Version 7.0 ou ultérieures pour qu'elle utilise le fournisseur DB2 Universal JDBC Driver Provider.

      Ainsi, les outils de migration de la Version 9.0 pourront traiter la migration vers le fournisseur DB2 Universal JDBC Driver Provider et aucune activité post-migratoire ne sera nécessaire.

      Effectuez l'une des actions suivantes :
      • Changez manuellement votre configuration pour qu'elle utilise le fournisseur de pilote DB2 Universal JDBC Provider.
      • Si vous effectuez la migration de la Version 7.0 ou ultérieures, exécutez l'utilitaire de migrationJDBC Migration Utility DB2 on z/OS pour migrer le fournisseur JDBC DB2 for zOS Local JDBC Provider (RRS) vers DB2 Universal JDBC Driver Provider.

        Cet outil est un script qui migre les fournisseurs DB2 for zOS Local JDBC Providers (RRS) vers les fournisseurs DB2 Universal JDBC Driver Providers noeud par noeud. Un livre blanc accompagnant l'outil explique comme installer et configurer le pilote DB2 Universal JDBC Driver avant d'exécuter l'outil pour migrer votre configuration.

    • Après la migration vers la Version 9.0, effectuez l'une des actions suivantes :
      • Changez manuellement votre configuration pour qu'elle utilise le fournisseur de pilote DB2 Universal JDBC Provider.
      • Utilisez l'utilitaire de migration JDBC pour DB2 sous z/OS afin d'effectuer une migration depuis DB2 for zOS Local JDBC Provider (RRS) vers DB2 Universal JDBC Driver Provider.

        Cet outil est un script qui migre les fournisseurs DB2 for zOS Local JDBC Providers (RRS) vers les fournisseurs DB2 Universal JDBC Driver Providers noeud par noeud.

  • Après la migration d'un serveur d'applications de base vers WebSphere Application Server Version 9.0 s'exécutant sous le système d'exploitation z/OS, les applications d'administration et utilisateur continuent à être définies sous l'hôte virtuel par défaut default_host comme elles l'étaient dans l'édition antérieure. Cependant, un gestionnaire de déploiement migré est défini sous l'hôte virtuel hôte_admin que vous avez introduit dans la version 6.1.
  • Si vous utilisez des référentiels de données isolés, en particulier des référentiels de données non partagés, tels que les journaux de transactions pour les bases de données SIB et Apache Derby, et que vous effectuez une migration depuis une édition précédente, vos bases de données et vos journaux de transactions existants sont enregistrés. Si vous possédez des informations vitales stockées dans ces référentiels de données locaux, vous devez par mesure de sécurité arrêter tous les serveurs qui interagissent avec ces référentiels avant de tenter la migration. Ces serveurs doivent rester hors ligne jusqu'à ce que la migration ait été terminée ou annulée.

    Une fois que vous avez effectué la migration ou que vous êtes retourné à la version précédente, vous pouvez redémarrer les serveurs qui interagissent avec ces référentiels de données isolés.

  • Avant de migrer une base de données Apache Derby, assurez-vous que tous les serveurs d'applications hébergeant des applications qui utilisent cette base de données sont arrêtés. Sinon, la migration de la base de données Apache Derby échouera.
  • Vous devez prendre en compte les règles suivantes relatives à la migration des domaines de sécurité :
    • Si vous migrez un gestionnaire de déploiement qui possède un domaine de sécurité avec une portée de niveau cellule, les outils de migration effectuent les actions suivantes :
      • La migration crée un domaine dans la nouvelle configuration, PassThroughToGlobalSecurity, s'il n'existe pas déjà.
      • La migration ajoute un mappage des clusters à la nouvelle configuration pour tous les clusters qui existaient dans l'ancienne configuration.
        • Les mappages à PassThroughToGlobalSecurity des clusters qui n'existaient que dans la configuration du gestionnaire de déploiement Version 9.0 avant la migration ne sont pas modifiés.
          • Si des mappages existaient pour les clusters Version 9.0 avant la migration, ces mappages existent toujours après la migration.
          • S'il n'existait pas de mappages pour les clusters de la Version 9.0 avant la migration, il n'en existe toujours pas après la migration.
        • Si un cluster existe à la fois dans la configuration précédente et dans celle de la Version 9.0 avant la migration, celui de la nouvelle configuration est ajouté au domaine PassThroughToGlobalSecurity et se comporte comme celui de la version précédente.
      • La migration ajoute un mappage des bus pour les bus qui existent dans une configuration migrée de la version 6.1.x.

        Les mappages de bus sont mis à jour en suivant les mêmes règles que celles relatives au mappage de clusters.

      • Les serveurs d'administration (gestionnaire de déploiement) ne sont pas ajoutés au domaine PassThroughToGlobalSecurity.
    • Si vous migrez un noeud fédéré qui possède un domaine de sécurité avec une portée de niveau cellule, les outils de migration effectuent les actions suivantes :
      • La migration crée un domaine dans la nouvelle configuration, PassThroughToGlobalSecurity, s'il n'existe pas déjà.
      • La migration ajoute un mappage au niveau serveur au domaine PassThroughToGlobalSecurity pour tous les serveurs qui ne sont pas en cluster dans l'ancienne configuration du noeud.
        • Les serveurs du noeud migré qui appartiennent à un cluster ne reçoivent pas les entrées du domaine PassThroughToGlobalSecurity car cela a été effectué via un mappage de clusters au cours de la migration du gestionnaire de déploiement.

          Si vous avez supprimé ce mappage, la migration conserve ce comportement.

        • Les serveurs d'administration (agents de noeud) ne sont pas ajoutés au domaine PassThroughToGlobalSecurity.

    Pour plus d'informations, voir la section relative aux domaines de sécurité dans un environnement multiversion de la rubrique Domaines de sécurité multiples.

  • Si vous avez mis à jour votre fichier java.security dans la version précédente de WebSphere Application Server, assurez-vous que vos mises à jour sont localisées dans V8WAS_HOME/properties/java.security.
  • Après avoir utilisé les outils de migration pour migrer vers WebSphere Application Server Version 9.0, vous pouvez être amené à effectuer certaines actions qui ne sont pas exécutées automatiquement par ces outils.
    • Examinez les paramètres de sécurité Lightweight Third-Party Authentication (LTPA) que vous avez éventuellement utilisés dans WebSphere Application Server Version 7.0 ou ultérieures et vérifiez que la sécurité de la Version 9.0 est définie de manière appropriée.

      Pour plus d'informations, voir Authentification LTPA.

    • Si nécessaire, créez de nouveaux profils SAF (System Authorization Facility) avant de démarrer les serveurs ayant migré vers WebSphere Application Server Version 9.0.
      A partir de la version 6.1, certaines fonctions de sécurité sont contrôlées à l'aide de profils SAF.
      • Dans la Version 7.0 ou ultérieures, le paramètre Activation des applications sécurisées est contrôlé avec un profil de sécurité SAF au lieu d'une variable interne WebSphere comme dans les versions précédentes.

        L'option Activation des applications sécurisées, qui permet à l'environnement d'exécution de WebSphere Application Server d'exécuter certaines opérations privilégiées pour le compte du code d'application, est requise pour tous les serveurs qui utilisent le registre LocalOS ou le mécanisme d'autorisation SAF.

      • Dans la Version 7.0 ou ultérieures, la fonction de synchronisation avec l'unité d'exécution du système (qui permet à une application d'accéder à des ressources à l'aide d'une identité du système d'exploitation différente de celle du serveur) est contrôlée par un profil de sécurité SAF et la variable com.ibm.websphere.security.SyncToOSThread.

        L'administrateur et le responsable de la sécurité du système peuvent déterminer si la fonction est utilisée ou non. Cette implémentation autorise également des restrictions sur les identités que l'application peut utiliser.

      Si vous effectuez une migration depuis une version antérieure de WebSphere Application Server et que vous avez besoin de ces fonctions, vous devez créer les profils SAF requis. Si ces profils ne sont pas disponibles et correctement configurés, les cellules utilisant le registre LocalOS ou le mécanisme d'autorisation échouent lors de leur démarrage sous la Version 9.0.

      Si vous utilisez RACF (Resource Access Control Facility) pour le système de sécurité, respectez les instructions suivantes. Si vous utilisez un autre système de sécurité compatible SAF, contactez le vendeur du système de sécurité pour obtenir des informations appropriées.
      • Vérifiez votre journal système MVS (Multiple Virtual Storage) ou utilisez la console d'administration pour déterminer si l'option autorisant les applications de confiance est activée pour votre serveur.
        Recherchez control_region_security_enable_trusted_applications dans le journal de démarrage. Si la valeur est 1, l'option d'autorisation des applications de confiance est activée. Dans ce cas, créez le profil SAF suivant et accordez le droit d'accès READ à l'ID utilisateur de région de contrôle du serveur d'applications :
        BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name 
        Pour cela, utilisez les commandes RACF suivantes :
        RDEFINE FACILITY
          BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name 
          UACC(NONE)
        PERMIT FACILITY
          BBO.TRUSTEDAPPS.cell_shortname.cluster_transition_name
          ID(controller_userid) ACCESS(READ)
        SETROPTS RACLIST(FACILITY) REFRESH

        Le profil de fonction SAF nom_cluster est remplacé par le nom de transition de cluster pour les serveurs non configurés en cluster. Si vous voulez que l'autorisation des applications de confiance soit activée pour tous les serveurs de la cellule, remplacez le nom de cluster par un caractère générique (*).

        Pour plus d'informations, voir Classes et profils de la fonction d'autorisation système.

      • Vérifiez votre journal système MVS (Multiple Virtual Storage) ou utilisez la console d'administration pour déterminer si l'option autorisant la synchronisation avec l'unité d'exécution du système est activée pour votre serveur.
        Si cette option est activée, créez le profil SAF suivant et accordez le droit d'accès READ ou CONTROL à l'ID utilisateur de région de contrôle du serveur d'applications :
        BBO.SYNC.cell_shortname.cluster_transition_name
        L'exemple suivant contient des commandes RACF que vous pouvez utiliser dans ce but :
        RDEFINE FACILITY 
          BBO.SYNC.cell_shortname.cluster_transition_name
          UACC(NONE) 
        PERMIT FACILITY 
        BBO.SYNC.cell_shortname.cluster_transition_name
          ID(controller_userid) ACCESS(CONTROL)
        SETROPTS RACLIST(FACILITY) REFRESH

        Le nom de cluster est remplacé par le nom de transition de cluster pour les serveurs non configurés en clusters. Si vous voulez que l'option autorisant la synchronisation avec l'unité d'exécution du système soit activée pour tous les serveurs de la cellule, remplacez le nom de cluster par un caractère générique (*).

        Important :
        • L'octroi du droit d'accès READ de la région de contrôle à l'ID utilisateur de la région de contrôle du serveur d'applications restreint les ID utilisateur que peut prendre l'identité d'unité d'exécution selon les profils SAF SURROGAT.

          Si l'ID utilisateur du contrôleur possède le droit d'accès READ sur le profil BBO.SYNC et que la variable com.ibm.websphere.security.SyncToOSThread est égale à true, des applications peuvent nécessiter l'option Synchronisation avec l'unité d'exécution. L'application présuppose que c'est l'identité de l'appelant ou d'un ID utilisateur lié à un rôle qui accède aux ressources. Toutefois, pour qu'il puisse s'exécuter avec un autre ID d'application, le servant doit avoir un accès READ au profil SURROGAT BBO.SYNC.id_utilisateur_application.

        • L'octroi du droit d'accès CONTROL à l'ID utilisateur de la région de contrôle du serveur d'applications permet à l'identité de l'unité d'exécution de basculer vers tout ID utilisateur demandant l'autorisation de synchronisation avec l'unité d'exécution du système.

          Si l'ID utilisateur du contrôleur possède le droit d'accès CONTROL sur le profil BBO.SYNC et que la variable com.ibm.websphere.security.SyncToOSThread est égale à true, des applications peuvent nécessiter l'option Synchronisation avec l'unité d'exécution. Ces applications peuvent supposer que l'identité de l'appelant ou d'un ID utilisateur lié à un rôle accède aux ressources. Les profils SURROGAT ne sont pas vérifiés.

        Pour plus d'informations, reportez-vous à la section Présentation de l'application Synchronisation autorisée avec l'unité d'exécution du système.

    • Si vous utilisez des profils SAF EJBROLE pour l'autorisation par rôle, créez des profils EJBROLE pour les deux rôles d'administration (rôle de déployeur et rôle de gestionnaire de sécurité administrative) qui ont été introduits avec la version 6.1.
    • Examinez les paramètres de la machine virtuelle Java (JVM) et vérifiez que vous utilisez une taille de segment d'au moins 50 pour obtenir de meilleures performances au démarrage.

      Pour plus d'informations, voir l'article "Paramètres de machine virtuelle Java" dans la documentation.

      Si vous avez utilisé une taille de segment plus petite auparavant, vous pouvez utiliser la taille de segment de 50 par défaut.

    • Vérifiez les résultats de la migration automatique des bases de données Apache Derby et faites migrer manuellement celles que les outils n'ont pas fait migrer automatiquement.

      Pour plus d'informations, voir Migration de bases de données Apache Derby.

    • Si plusieurs agents de noeud existent sur une même partition logique (LPAR), des conflits liés au port IPC_CONNECTOR_ADDRESS peuvent survenir après l'exécution des travaux de migration. Reconfigurez les ports conflictuels.
    • Si vous utilisez des applications qui tentent d'envoyer une requête à un URI (Uniform Resource Identifier) SIP (Session Initiation Protocol) via TLS (Transport Layer Security), sachez que le comportement est différent entre WebSphere Application Server version 6.1 et la Version 9.0.

      Lorsqu'une application SIP envoie une requête à un URI SIP sur TLS dans la version 6.1, le schéma de l'URI de requête "sip" devient "sips". Dans la Version 9.0, le schéma n'est pas modifié.

      Cette différence est visible lorsque vos applications tentent d'envoyer une requête SIP dans laquelle l'URI de requête contient un schéma "sip" et un paramètre de transport "tls". Par exemple, dans la version 6.1, si une application crée une requête avec l'URI de requête suivant :
      sip:alice@atlanta.com;transport=tls
      et l'envoie sur le réseau, le conteneur SIP modifie le schéma ainsi que le paramètre de transport afin de générer l'URI de requête suivant :
      sips:alice@atlanta.com;transport=tcp
      Dans la Version 9.0, le conteneur SIP ne modifie pas le schéma.

      Si vous désirez conserver l'ancien comportement après la migration du serveur d'applications de la version 6.1 vers la Version 9.0, vous devez modifier le code de l'application. Si l'application tente d'envoyer un URI "sips", elle doit créer l'URI de cette façon avant l'envoi du message. Si l'URI est de type "sips", le comportement est le même que dans la version 6.1.


Icône indiquant le type de rubrique Rubrique de concept



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