Cette rubrique décrit l'activation simultanée de plusieurs éditions de la même édition. L'activation simultanée est utilisée lors de la validation de pré-production, le contrôle d'une application pour un groupe d'utilisateurs sélectionné et le déploiement d'arborescence lorsqu'une mise à niveau d'application requiert des modifications correspondantes sur des arborescences identifiables de postes clients.
Avant de commencer
Vous devez disposer d'au moins deux éditions de la même application.
Pour ce tutoriel, l'édition d'application BeenThere 1.0 est installée sur la cible BTDC1, et l'édition 2.0 est installée sur la cible BTDC2.
Pourquoi et quand utiliser cette tâche
Chaque édition doit être active sur une cible de déploiement séparée. Lorsque plusieurs éditions de la même application sont disponibles simultanément pour les utilisateurs d'un même environnement, le routeur ODR ne peut distinguer les éditions actives que s'il dispose de certaines informations permettant de clarifier la demande et de l'acheminer vers l'édition voulue. Pour éviter cette ambiguité, vous pouvez utiliser les règles de routage ou les interfaces spécifiques à chaque édition. Pour héberger et accéder simultanément à plusieurs éditions d'application situées sur des cibles de déploiement différentes, procédez comme suit :
- Cliquez sur Applications > Centre de contrôle des éditions. Vérifiez que deux éditions de votre application sont installées mais qu'une seule édition est active.
- Cliquez sur le lien de l'application BeenThere.
- Sélectionnez l'édition 2.0, puis cliquez sur Activer.
- Pour créer la règle de routage de chaque édition d'application, procédez comme suit :
- Cliquez sur Applications > Applications d'entreprise.
- Cliquez sur le lien de l'application. Pour ce tutoriel, cliquez sur BeenThere.
- Cliquez sur l'onglet Règles de routage.
- Développez Classes de travail pour les requêtes HTTP. Aucune règle de routage n'étant spécifiée, toutes les requêtes sont acheminées vers l'édition affichée sur cette page. Pour ce tutoriel, toutes les demandes sont acheminées vers l'édition d'application BeenThere-edition2.0.
- Cliquez sur Générateur de règles.
- Sélectionnez une règle dans le liste de règles. Pour ce tutoriel, sélectionnez Hôte client (clienthost), puis cliquez sur Ajouter.
- Sélectionnez les critères de la règle. Pour ce tutoriel, sélectionnez l'opérateur Egal (=) et entrez une valeur pour le nom de l'hôte client. Cliquez sur OK.
- Cliquez à nouveau sur OK.
- Développez Classes de travail pour les requêtes HTTP.
- Définissez l'action associée à la nouvelle règle. Pour ce tutoriel, les requêtes émises par l'hôte sont acheminées vers l'édition BeenThere-edition1.0.
Sélectionnez l'action correspondante dans la liste Alors et cliquez sur Valider pour sauvegarder la règle.
- En haut de l'onglet Règles de routage, cliquez sur Valider.
- Enregistrez les modifications dans le référentiel de configuration et synchronisez les noeuds.
- Vérifiez que l'ODR est en cours d'exécution. Cliquez sur Serveurs > Routeurs ODR.
- Testez l'accès simultané aux éditions d'application. Sélectionnez les deux éditions d'application en sélectionnant les serveurs d'applications associés aux deux clusters dynamiques BTDC1 et BTDC2, puis cliquez sur Démarrer.
Résultat
Lorsque les demandes sont envoyées à l'ODR par le client au nom d'hôte que vous avez entré, les demandes sont traitées par l'edition 1.0, alors que les demandes de tous les autres clients sont traitées par l'edition 2.0.
Exemple
Par exemple, pour exécuter un test en pré-production d'une édition d'application dans l'environnement de production avec un ensemble d'utilisateurs sélectionnés, vous pouvez cloner la cible de déploiement, y compris ses ressources et définitions de sécurité, puis activer l'édition cible dans l'environnement dupliqué. Utilisez les règles de routage pour diriger l'ODR afin qu'il fasse dévier vers l'édition un sous ensemble sélectionné des utilisateurs.
De plus, si vous réalisez le contrôle en dehors de l'application, vous pouvez utiliser des règles de routage pour séparer les utilisateurs dirigés vers l'édition 2.0 de l'ensemble des utilisateurs de l'édition 1.0.
Dans le cas d'un déploiement d'arborescence, utilisez les règles de routage pour diriger chaque arborescence vers l'édition appropriée. Au fur et à mesure de la mise à jour du code client sur chaque arborescence successive, les règles de routage côté serveur peuvent être mises à jour pour qualifier les clients de la nouvelle arborescence mise à jour pour qu'ils soient envoyés à l'édition appropriée.
Dans les cas où les règles de routage sont insuffisantes pour distinguer les demandes des utilisateurs, ou lorsque l'utilisateur préfère une autre solution que les règles de routage, chaque édition peut recevoir un URI, un nom EJB (Enterprise JavaBeans) et JNDI (Java Naming and Directory
Interface) spécifiques. Contrairement aux règles de routage, les interfaces uniques de chaque édition sont exposées aux utilisateurs de l'application. Par conséquent, l'utilisateur doit choisir le nom approprié pour diriger l'édition correspondante.