Installation de MobileFirst Server sur un serveur d'applications

improve this page | report issue

Présentation

Vous pouvez installer les composants à l’aide de tâches Ant, avec l’outil de configuration de serveur ou manuellement. Prenez connaissance des éléments prérequis et des détails relatifs au processus d’installation avant d’installer les composants sur le serveur d’applications.

Avant d’installer les composants sur le serveur d’applications, vérifiez que les bases de données et les tables pour les composants sont préparées et prêtes à l’emploi. Pour plus d’informations, voir Configuration des bases de données.

La topologie de serveur dans laquelle installer les composants doit également être définie. Voir Topologies et flots réseau.

Aller à

Prérequis pour le serveur d’applications

Selon le serveur d’applications que vous avez choisi, reportez-vous à l’une des rubriques suivantes pour prendre connaissance des prérequis que vous devez remplir avant d’installer les composants MobileFirst Server :

Prérequis pour Apache Tomcat

Les exigences de MobileFirst Server relatives à la configuration d’Apache Tomcat sont détaillées dans les rubriques ci-dessous.
Assurez-vous de remplir les critères suivants :

  • Utilisez une version prise en charge d’Apache Tomcat. Voir Configuration système requise.
  • Apache Tomcat doit être exécuté avec JRE 7.0 ou version ultérieure.
  • La configuration de JMX doit être activée pour permettre la communication entre le service d’administration et le composant d’exécution. La communication utilise RMI comme décrit dans Configuration de la connexion JMX pour Apache Tomcat ci-après.

Vous devez configurer une connexion JMX sécurisée pour le serveur d'applications Apache Tomcat.

L'outil de configuration de serveur et les tâches Ant peuvent configurer une connexion JMX sécurisée par défaut qui inclut la définition d'un port distant JMX et de propriétés d'authentification. Ils modifient rép_install_tomcat/bin/setenv.bat et rép_install_tomcat/bin/setenv.sh pour ajouter les options suivantes dans CATALINA_OPTS :

-Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.port=8686
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

Remarque : 8686 est la valeur de port par défaut. Elle peut être changée si le port n'est pas disponible sur l'ordinateur.

  • Le fichier setenv.bat est utilisé si vous démarrez Apache Tomcat avec rép_install_tomcat/bin/startup.bat ou rép_install_tomcat/bin/catalina.bat.
  • Le fichier setenv.sh est utilisé si vous démarrez Apache Tomcat avec rép_install_tomcat/bin/startup.sh ou rép_install_tomcat/bin/catalina.sh.

Il se peut que ce fichier ne soit pas utilisé si vous démarrez Apache Tomcat avec une autre commande. Si vous avez installé le programme d'installation du service Windows Apache Tomcat, le programme de lancement des services n'utilise pas setenv.bat.

Important : cette configuration n'est pas sécurisée par défaut. Pour la sécuriser, vous devez effectuer manuellement les étapes 2 et 3 de la procédure ci-dessous.

Configuration manuelle d'Apache Tomcat :

  1. Pour une configuration simple, ajoutez les options suivantes dans CATALINA_OPTS :
    -Djava.rmi.server.hostname=localhost
    -Dcom.sun.management.jmxremote.port=8686
    -Dcom.sun.management.jmxremote.authenticate=false
    -Dcom.sun.management.jmxremote.ssl=false
  2. Pour savoir comment activer l'authentification, voir la documentation utilisateur d'Apache Tomcat SSL Support - BIO and NIO et SSL Configuration HOW-TO.
  3. Pour une configuration JMX avec SSL activé, ajoutez les options suivantes :
    -Dcom.sun.management.jmxremote=true
    -Dcom.sun.management.jmxremote.port=8686
    -Dcom.sun.management.jmxremote.ssl=true
    -Dcom.sun.management.jmxremote.authenticate=false
    -Djava.rmi.server.hostname=localhost  
    -Djavax.net.ssl.trustStore=<emplacement_magasin_clés_confiance>
    -Djavax.net.ssl.trustStorePassword=<mot_de_passe_magasin_clés_confiance>
    -Djavax.net.ssl.trustStoreType=<type_magasin_clés_confiance>
    -Djavax.net.ssl.keyStore=<emplacement_magasin_clés>
    -Djavax.net.ssl.keyStorePassword=<mot_de_passe_magasin_clés>
    -Djavax.net.ssl.keyStoreType=<type_magasin_clés>
    Remarque : le port 8686 peut être changé.
  4. Si l'instance Tomcat s'exécute derrière un pare-feu, le programme d'écoute de cycle de vie distant JMX doit être configuré. Voir la documentation d'Apache Tomcat JMX Remote Lifecycle Listener.

    Vous devez également ajouter les propriétés d'environnement suivantes dans la section Context de l'application de service d'administration dans le fichier server.xml, conformément à l'exemple suivant :

    <Context docBase="mfpadmin" path="/mfpadmin ">
        <Environment name="mfp.admin.rmi.registryPort" value="portRegistre" type="java.lang.String" override="false"/>
        <Environment name="mfp.admin.rmi.serverPort" value="portServeur" type="java.lang.String" override="false"/>
    </Context>
    Dans l'exemple précédent :
    • portRegistre doit avoir la même valeur que l'attribut rmiRegistryPortPlatform du programme d'écoute de cycle de vie distant JMX.
    • portServeur doit avoir la même valeur que l'attribut rmiServerPortPlatform du programme d'écoute de cycle de vie distant JMX.
  5. Si vous avez installé Apache Tomcat avec le programme d'installation des services Windows Apache Tomcat au lieu d'ajouter les options dans CATALINA_OPTS, exécutez rép_install_tomcat/bin/Tomcat7w.exe et ajoutez les options dans l'onglet Java de la fenêtre des propriétés. Propriétés Apache Tomcat 7

Prérequis pour WebSphere Application Server Liberty

Les exigences d’IBM Mobile Foundation relatives à la configuration du serveur Liberty sont détaillées dans les rubriques ci-dessous.

Assurez-vous de remplir les critères suivants :

  • Utilisez une version prise en charge de Liberty. Voir Configuration système requise.
  • Liberty doit être exécuté avec JRE 7.0 ou version ultérieure. JRE 6.0 n’est pas pris en charge.
  • Certaines versions de Liberty prennent en charge les fonctions de Java EE 6 et les fonctions de Java EE 7. Par exemple, la fonction Liberty jdbc-4.0 provient de Java EE 6, alors que la fonction Liberty jdbc-4.1 provient de Java EE 7. MobileFirst Server version 8.0.0 peut être installé avec des fonctions Java EE 6 ou Java EE 7. Toutefois, si vous voulez exécuter une version plus ancienne de MobileFirst Server sur le même serveur Liberty, vous devez utiliser les fonctions Java EE 6. La version 7.1.0 et les versions précédentes de MobileFirst Server ne prennent pas en charge les fonctions Java EE 7.
  • JMX doit être configuré comme décrit dans Configuration de la connexion JMX pour le profil Liberty de WebSphere Application Server ci-après.
  • Pour une installation dans un environnement de production, il est recommandé de démarrer le serveur Liberty en tant que service sur les systèmes Windows, Linux ou UNIX pour que les composants MobileFirst Server soient démarrés automatiquement lorsque l’ordinateur démarre et le processus qui exécute le serveur Liberty ne s’arrête pas lorsque l’utilisateur qui a démarré le processus se déconnecte.
  • MobileFirst Server version 8.0.0 ne peut pas être déployé sur un serveur Liberty contenant les composants MobileFirst Server déployés pour des versions précédentes.
  • Pour l’installation dans un environnement de collectivité Liberty, le contrôleur de collectivité Liberty et les membres de cluster de collectivité Liberty doivent être configurés comme décrit dans Configuration d’une collectivité Liberty.

MobileFirst Server requiert la configuration de la connexion JMX sécurisée.

  • L'outil de configuration de serveur et les tâches Ant peuvent configurer une connexion JMX sécurisée par défaut qui inclut la génération d'un certificat SSL autosigné dont la période de validité est de 365 jours. Cette configuration ne peut pas être utilisée en production.
  • Afin de configurer la connexion JMX sécurisée pour un usage en production, suivez les instructions décrites dans Configuration d'une connexion JMX sécurisée dans le profil Liberty.
  • La fonction rest-connector est disponible pour WebSphere Application Server, Liberty Core et d'autres éditions de Liberty ; toutefois, il est possible de conditionner un serveur Liberty avec un sous-ensemble seulement des fonctions disponibles. Pour vérifier que la fonction rest-connector est disponible dans votre installation de Liberty, entrez la commande suivante :
                        
    rép_install_liberty/bin/productInfo featureInfo
    Remarque : vérifiez que la sortie de cette commande répertorie restConnector-1.0.

Prérequis pour WebSphere Application Server et WebSphere Application Server Network Deployment

Les exigences de MobileFirst Server relatives à la configuration de WebSphere Application Server et WebSphere Application Server Network Deployment sont détaillées dans les rubriques ci-dessous.
Assurez-vous de remplir les critères suivants :

  • Utilisez une version prise en charge de WebSphere Application Server. Voir Configuration système requise.
  • Le serveur d’applications doit être exécuté avec JRE 7.0. Par défaut, WebSphere Application Server utilise le logiciel SDK Java 6.0. Pour utiliser le logiciel SDK Java 7.0, voir Basculement vers le SDK Java 7.0 dans WebSphere Application Server.
  • La sécurité administrative doit être activée. MobileFirst Operations Console, le service d’administration de MobileFirst Server et le service de configuration de MobileFirst Server sont protégés par des rôles de sécurité. Pour plus d’informations, voir Activation de la sécurité.
  • La configuration de JMX doit être activée pour permettre la communication entre le service d’administration et le composant d’exécution. La communication utilise SOAP. RMI peut être utilisé pour WebSphere Application Server Network Deployment. Pour plus d’informations, voir Configuration de la connexion JMX pour WebSphere Application Server et WebSphere Application Server Network Deployment ci-après.

MobileFirst Server requiert la configuration de la connexion JMX sécurisée.

  • MobileFirst Server requiert l'accès au port SOAP ou au port RMI pour effectuer des opérations JMX. Par défaut, le port SOAP est actif sur un serveur WebSphere Application Server. MobileFirst Server utilise le port SOAP par défaut. Si le port SOAP et le port RMI sont désactivés, MobileFirst Server ne s'exécute pas.
  • RMI n'est pris en charge que par WebSphere Application Server Network Deployment. Il n'est pas pris en charge par les profils autonomes ni par les parcs de serveurs WebSphere Application Server.
  • Vous devez activer la sécurité administrative et la sécurité des applications.

Prérequis pour le système de fichiers

Pour installer MobileFirst Server sur un serveur d’applications, les outils d’installation de MobileFirst doivent être exécutés par un utilisateur disposant de droits spécifiques dans le système de fichiers.
Les outils d’installation sont :

  • IBM Installation Manager
  • L’outil de configuration de serveur
  • Les tâches Ant permettant de déployer MobileFirst Server

Pour le profil Liberty de WebSphere Application Server, vous devez disposer des droits permettant d’effectuer les actions suivantes :

  • Lire les fichiers dans le répertoire d’installation de Liberty.
  • Créer des fichiers dans le répertoire de configuration du serveur Liberty, en général usr/servers/nom-serveur, pour créer des copies de sauvegarde et modifier server.xml et jvm.options.
  • Créer des fichiers et des répertoires dans le répertoire de ressources partagées, en général usr/shared.
  • Créer des fichiers dans le répertoire des applications du serveur Liberty, en général usr/servers/nom-serveur/apps.

Pour le profil complet de WebSphere Application Server et WebSphere Application Server Network Deployment, vous devez disposer des droits permettant d’effectuer les actions suivantes :

  • Lire les fichiers dans le répertoire d’installation de WebSphere Application Server.
  • Lire le fichier de configuration du profil complet de WebSphere Application Server ou du profil Deployment Manager sélectionné.
  • Exécuter la commande wsadmin.
  • Créer des fichiers dans le répertoire de configuration des profils. Les outils d’installation placent les ressources telles que les bibliothèques partagées ou les pilotes JDBC dans ce répertoire.

Pour Apache Tomcat, vous devez disposer des droits permettant d’effectuer les actions suivantes :

  • Lire le répertoire de configuration.
  • Créer des fichiers de sauvegarde et modifier les fichiers dans le répertoire de configuration, comme server.xml et tomcat-users.xml.
  • Créer des fichiers de sauvegarde et modifier les fichiers dans le répertoire bin, comme setenv.bat.
  • Créer des fichiers dans le répertoire lib.
  • Créer des fichiers dans le répertoire webapps.

Pour tous ces serveurs d’applications, l’utilisateur qui exécute le serveur d’applications doit pouvoir lire les fichiers qui ont été créés par l’utilisateur qui a exécuté les outils d’installation de MobileFirst.

Installation avec l’outil de configuration de serveur

Utilisez l’outil de configuration de serveur pour installer les composants MobileFirst Server sur votre serveur d’applications.

L’outil de configuration de serveur peut configurer la base de données et installer les composants sur un serveur d’applications. Il a été conçu pour un seul utilisateur. Les fichiers de configuration sont stockés sur le disque. Vous pouvez changer le répertoire dans lequel ils sont stockés avec le menu File Preferences. Les fichiers ne doivent être utilisés que par une instance de l’outil de configuration de serveur à la fois. L’outil ne gère pas l’accès simultané à un même fichier. Si plusieurs instances de l’outil accèdent à un même fichier, vous risquez de perdre les données. Pour plus d’informations sur la façon dont l’outil crée et configure les bases de données, voir Création des tables de base de données avec l’outil de configuration de serveur. Si les bases de données existent, l’outil peut les détecter en testant leur présence ainsi que le contenu de certaines tables de test, mais ne les modifie pas.

Systèmes d’exploitation pris en charge

Vous pouvez utiliser l’outil de configuration de serveur si vous utilisez les systèmes d’exploitation suivants :

  • Windows x86 ou x86-64
  • macOS x86-64
  • Linux x86 ou Linux x86-64

L’outil n’est pas disponible sur les autres systèmes d’exploitation. Vous devez utiliser des tâches Ant pour installer les composants MobileFirst Server comme décrit dans Installation à l’aide de tâches Ant.

Topologies prises en charge

L’outil de configuration de serveur installe les composants MobileFirst Server avec les topologies suivantes :

  • Tous les composants (MobileFirst Operations Console, le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et l’environnement d’exécution de MobileFirst) se trouvent sur le même serveur d’applications. Toutefois, sur WebSphere Application Server Network Deployment, lorsque vous procédez à l’installation dans un cluster, vous pouvez spécifier un cluster différent pour les services d’administration et Live Update et pour l’environnement d’exécution. Dans la collectivité Liberty, MobileFirst Operations Console, le service d’administration et le service Live Update sont installés sur un contrôleur de collectivité, et l’environnement d’exécution sur un membre de collectivité.
  • Si le service push de MobileFirst Server est installé, il l’est sur le même serveur. Toutefois, sur WebSphere Application Server Network Deployment, lorsque vous procédez à l’installation dans un cluster, vous pouvez spécifier un cluster différent pour le service push. Dans la collectivité Liberty, le service push est installé sur un membre Liberty qui peut être celui sur lequel est installé l’environnement d’exécution.
  • Tous les composants utilisent le même système de base de données et le même utilisateur. Pour DB2, tous les composants utilisent également le même schéma.
  • L’outil de configuration de serveur installe les composants pour un serveur unique, sauf pour la collectivité Liberty et WebSphere Application Server Network Deployment dans le cas d’un déploiement asymétrique. Pour une installation sur plusieurs serveurs, vous devez configurer un parc de serveurs après l’exécution de l’outil. La configuration du parc de serveurs n’est pas requise sur WebSphere Application Server Network Deployment.

Pour les autres topologies ou les autres paramètres de base de données, vous pouvez installer les composants à l’aide de tâches Ant ou manuellement.

Exécution de l’outil de configuration de serveur

Avant d’exécuter l’outil de configuration de serveur, vérifiez que les exigences suivantes sont satisfaites :

  1. Démarrez l'outil de configuration de serveur.
    • Sous Linux, cliquez sur les raccourcis d'application Applications → IBM MobileFirst Platform Server → Server Configuration Tool.
    • Sous Windows, cliquez sur Démarrer → Programmes → IBM MobileFirst Platform Server → Server Configuration Tool.
    • Sous macOS, ouvrez une console d'interpréteur de commandes. Accédez à rép_install_serveur_mfp/shortcuts et entrez ./configuration-tool.sh.
    • Le répertoire rép_install_serveur_mfp est l'emplacement auquel vous avez installé MobileFirst Server.
  2. Sélectionnez File → New Configuration pour créer une configuration MobileFirst Server.
    • Dans le panneau Configuration Details, entrez la racine de contexte du service d'administration et du composant d'exécution. Il est recommandé d'entrer un ID d'environnement. Ce dernier est utilisé dans les cas d'utilisation avancés, par exemple lorsque plusieurs installations de MobileFirst Server sont effectuées sur un même serveur d'applications ou dans une même cellule WebSphere Application Server.
    • Dans le panneau Console Settings, indiquez si MobileFirst Operations Console doit être installé ou non. Si la console n'est pas installée, vous devez utiliser des outils de ligne de commande (mfpdev ou mfpadm) ou l'API REST pour interagir avec le service d'administration de MobileFirst Server.
    • Dans le panneau Database Selection, sélectionnez le système de gestion de base de données que vous prévoyez d'utiliser. Tous les composants utilisent le même type de base de données et la même instance de base de données. Pour plus d'informations sur les sous-fenêtres de base de données, voir Création des tables de base de données avec l'outil de configuration de serveur.
    • Dans le panneau Application Server Selection, sélectionnez le type de serveur d'applications sur lequel déployer MobileFirst Server.
  3. Dans le panneau Application Server Settings, choisissez le serveur d'applications et effectuez les opérations suivantes :
    • Pour une installation sur un serveur WebSphere Application Server Liberty :
      • Entrez le répertoire d'installation de Liberty et le nom du serveur sur lequel installer MobileFirst Server.
      • Vous pouvez créer un utilisateur par défaut pour la connexion à la console. Cet utilisateur est créé dans le registre de base Liberty. Pour une installation de production, il est recommandé de désélectionner l'option Create a default user et de configurer l'accès utilisateur après l'installation. Pour plus d'informations, voir Configuration de l'authentification d'utilisateur pour l'administration de MobileFirst Server.
      • Sélectionnez le type de déploiement : Standalone deployment (par défaut), Server farm deployment ou Liberty collective deployment.
      Si l'option Liberty collective deployment est sélectionnée, procédez comme suit :
      • Spécifiez le serveur de collectivité Liberty :
        • Sur lequel le service d'administration, MobileFirst Operations Console et le service Live Update sont installés. Le serveur doit être un contrôleur de collectivité Liberty.
        • Sur lequel l'environnement d'exécution est installé. Le serveur doit être un membre de collectivité Liberty.
        • Sur lequel le service push est installé. Le serveur doit être un membre de collectivité Liberty.
      • Entrez l'ID de serveur du membre. Cet identificateur doit être différent pour chaque membre dans la collectivité.
      • Entrez le nom de cluster des membres de collectivité.
      • Entrez le nom d'hôte du contrôleur et le numéro de port HTTPS. Les valeurs doivent être identiques à celles qui sont définies dans l'élément variable du fichier server.xml du contrôleur de collectivité Liberty.
      • Entrez le nom d'utilisateur et le mot de passe de l'administrateur du contrôleur.
    • Pour une installation sur un serveur WebSphere Application Server ou WebSphere Application Server Network Deployment :
      • Entrez le répertoire d'installation de WebSphere Application Server.
      • Sélectionnez le profil WebSphere Application Server dans lequel installer MobileFirst Server. Si vous procédez à l'installation sur un serveur WebSphere Application Server Network Deployment, sélectionnez le profil du gestionnaire de déploiement. Dans le profil du gestionnaire de déploiement, vous pouvez sélectionner une portée (Server ou Cluster). Si vous sélectionnez Cluster, vous devez spécifier le cluster :
        • Dans lequel l'environnement d'exécution est installé.
        • Dans lequel le service d'administration, MobileFirst Operations Console et le service Live Update sont installés.
        • Dans lequel le service push est installé.
      • Entrez l'ID de connexion et le mot de passe d'un administrateur. Cet utilisateur doit posséder un rôle d'administrateur.
      • Si vous sélectionnez l'option Declare the WebSphere Administrator as an administrator user in MobileFirst Operations Console, l'utilisateur qui installe MobileFirst Server est mappé au rôle de sécurité d'administration de la console et peut se connecter à la console avec des privilèges d'administrateur. Il est également mappé au rôle de sécurité du service Live Update. Le nom d'utilisateur et le mot de passe sont définis sous forme de propriétés JNDI (mfp.config.service.user et mfp.config.service.password) du service d'administration.
      • Si vous ne sélectionnez pas l'option Declare the WebSphere Administrator as an administrator user in MobileFirst Operations Console, vous devez effectuer les tâches suivantes avant d'utiliser MobileFirst Server :
        • Activez la communication entre le service d'administration et le service Live Update en :
          • Mappant un utilisateur au rôle de sécurité configadmin du service Live Update.
          • Ajoutant l'ID de connexion et le mot de passe de cet utilisateur dans les propriétés JNDI (mfp.config.service.user et mfp.config.service.password) du service d'administration.
          • Mappant un ou plusieurs utilisateurs aux rôles de sécurité du service d'administration et de MobileFirst Operations Console. Voir Configuration de l'authentification d'utilisateur pour l'administration de MobileFirst Server.
    • Pour une installation sur Apache Tomcat :
      • Entrez le répertoire d'installation d'Apache Tomcat.
      • Entrez le port utilisé pour la communication JMX avec RMI. Par défaut, la valeur est 8686. L'outil de configuration de serveur modifie le fichier rép_install_tomcat/bin/setenv.bat ou rép_install_tomcat/bin/setenv.sh pour ouvrir ce port. Si vous voulez ouvrir le port manuellement ou si setenv.bat ou setenv.sh comporte déjà un code qui ouvre le port, n'utilisez pas l'outil. A la place, procédez à l'installation à l'aide de tâches Ant. Une option permettant d'ouvrir le port RMI manuellement est proposée dans le cadre d'une installation à l'aide de tâches Ant.
      • Créez un utilisateur par défaut pour la connexion à la console. Cet utilisateur est également créé dans le fichier de configuration tomcat-users.xml. Pour une installation de production, il est recommandé de désélectionner l'option Create a default user et de configurer l'accès utilisateur après l'installation. Pour plus d'informations, voir Configuration de l'authentification d'utilisateur pour l'administration de MobileFirst Server.
  4. Dans le panneau Push Service Settings, sélectionnez l'option Install the Push service si vous voulez que le service push soit installé sur le serveur d'applications. La racine de contexte est imfpush. Pour activer la communication entre le service push et le service d'administration, vous devez définir les paramètres suivants :
    • Entrez l'adresse URL du service push et l'adresse URL de l'environnement d'exécution. L'adresse URL peut être calculée automatiquement si vous procédez à l'installation sur un serveur Liberty, Apache Tomcat ou WebSphere Application Server autonome. Elle utilise l'adresse URL du composant (l'environnement d'exécution ou le service push) sur le serveur local. Si vous procédez à l'installation sur un serveur WebSphere Application Server Network Deployment ou si les communications passent par un proxy Web ou un équilibreur de charge, vous devez la saisir manuellement.
    • Entrez les ID des clients confidentiels et les valeurs confidentielles correspondantes pour la communication OAuth entre les services. Si vous n'indiquez pas ces données, l'outil génère des valeurs par défaut et des mots de passe aléatoires.
  5. Dans le panneau Analytics Settings, sélectionnez l'option Enable the connection to the Analytics server si MobileFirst Analytics est installé. Entrez les paramètres de connexion suivants :
    • L'adresse URL de la console Analytics.
    • L'adresse URL du serveur Analytics (le service de données Analytics).
    • L'ID de connexion et le mot de passe de l'utilisateur autorisé à publier des données sur le serveur Analytics.
    L'outil configure l'environnement d'exécution et le service push pour l'envoi de données au serveur Analytics.
  6. Cliquez sur Deploy pour effectuer l'installation.

Une fois l’installation terminée, redémarrez le serveur d’applications dans le cas d’Apache Tomcat ou du profil Liberty.

Si Apache Tomcat est démarré en tant que service, il se peut que le fichier setenv.bat ou setenv.sh contenant l’instruction d’ouverture de RMI ne soit pas lu. En conséquence, il se peut que MobileFirst Server ne fonctionne pas correctement. Pour définir les variables requises, voir Configuration de la connexion JMX pour Apache Tomcat.

Sur un serveur WebSphere Application Server Network Deployment, les applications sont installées mais ne sont pas démarrées. Vous devez les démarrer manuellement. Vous pouvez effectuer cette opération depuis la console d’administration WebSphere Application Server.

Conservez le fichier de configuration dans l’outil de configuration de serveur. Vous pourrez être amené à le réutiliser afin d’installer les correctifs temporaires. Pour appliquer un correctif temporaire, sélectionnez Configurations > Replace the deployed WAR files.

Application d’un groupe de correctifs avec l’outil de configuration de serveur

Si MobileFirst Server a été installé avec l’outil de configuration et que le fichier de configuration a été conservé, vous pouvez appliquer un groupe de correctifs ou un correctif temporaire en réutilisant le fichier de configuration.

  1. Démarrez l’outil de configuration de serveur.
    • Sous Linux, cliquez sur les raccourcis d’application Applications → IBM MobileFirst Platform Server → Server Configuration Tool.
    • Sous Windows, cliquez sur Démarrer → Programmes → IBM MobileFirst Platform Server → Server Configuration Tool.
    • Sous macOS, ouvrez une console d’interpréteur de commandes. Accédez à rép_install_mfp_serveur/shortcuts et entrez ./configuration-tool.sh.
    • Le répertoire rép_install_mfp_serveur est l’emplacement auquel vous avez installé MobileFirst Server.
  2. Cliquez sur Configurations → Replace the deployed WAR files et sélectionnez une configuration existante pour appliquer le groupe de correctifs ou un correctif temporaire.

Installation à l’aide de tâches Ant

Utilisez des tâches Ant pour installer les composants MobileFirst Server sur votre serveur d’applications.

Les exemples de fichier de configuration pour l’installation de MobileFirst Server se trouvent dans le répertoire rép_install_mfp/MobileFirstServer/configuration-samples.

Vous pouvez aussi créer une configuration avec l’outil de configuration de serveur et exporter les fichiers Ant en sélectionnant File → Export Configuration as Ant Files…. Les exemples de fichier Ant présentent les mêmes limitations que l’outil de configuration de serveur :

  • Tous les composants (MobileFirst Operations Console, service d’administration de MobileFirst Server, service Live Update de MobileFirst Server, artefacts de MobileFirst Server et environnement d’exécution de MobileFirst) se trouvent sur le même serveur d’applications. Toutefois, sur WebSphere Application Server Network Deployment, lorsque vous procédez à l’installation dans un cluster, vous pouvez spécifier un cluster différent pour les services d’administration et Live Update et pour l’environnement d’exécution.
  • Si le service push de MobileFirst Server est installé, il l’est sur le même serveur. Toutefois, sur WebSphere Application Server Network Deployment, lorsque vous procédez à l’installation dans un cluster, vous pouvez spécifier un cluster différent pour le service push.
  • Tous les composants utilisent le même système de base de données et le même utilisateur. Pour DB2, tous les composants utilisent également le même schéma.
  • L’outil de configuration de serveur installe les composants sur un seul serveur. Pour une installation sur plusieurs serveurs, vous devez configurer un parc de serveurs après l’exécution de l’outil. La configuration d’un parc de serveurs n’est pas prise en charge sur WebSphere Application Server Network Deployment.

Vous pouvez configurer les services de MobileFirst Server pour qu’ils s’exécutent dans un parc de serveurs à l’aide de tâches Ant. Pour inclure votre serveur dans un parc de serveurs, vous devez spécifier des attributs spécifiques qui configurent votre serveur d’applications en conséquence. Pour plus d’informations sur la configuration d’un parc de serveurs à l’aide de tâches Ant, voir Installation d’un parc de serveurs à l’aide de tâches Ant.

Pour les autres topologies présentées dans Topologies et flots réseau, vous pouvez modifier les exemples de fichier Ant.

Les références aux tâches Ant sont les suivantes :

Pour une présentation de l’installation à l’aide de l’exemple de fichier de configuration et de tâches, voir Installation de MobileFirst Server en mode de ligne de commande.

Vous pouvez exécuter un fichier Ant avec la distribution Ant proposée avec l’installation du produit. Par exemple, si vous disposez d’un cluster WebSphere Application Server Network Deployment et que votre base de données est IBM DB2, vous pouvez utiliser le fichier Ant rép_install_mfp/MobileFirstServer/configuration-samples/configure-wasnd-cluster-db2.xml. Après avoir édité le fichier et entré toutes les propriétés requises, vous pouvez exécuter les commandes suivantes depuis le répertoire rép_install_mfp/MobileFirstServer/configuration-samples :

  • rép_install_mfp/shortcuts/ant -f configure-wasnd-cluster-db2.xml help - Cette commande affiche la liste de toutes les cibles possibles du fichier Ant pour installer, désinstaller ou mettre à jour des composants.
  • rép_install_mfp/shortcuts/ant -f configure-wasnd-cluster-db2.xml install - Cette commande installe MobileFirst Server dans le cluster WebSphere Application Server Network Deployment avec DB2 comme source de données en utilisant les paramètres que vous avez entrés dans les propriétés du fichier Ant.


Après l’installation, faites une copie du fichier Ant afin de pouvoir le réutiliser pour appliquer un groupe de correctifs.

Application d’un groupe de correctifs à l’aide des fichiers Ant

Mise à jour à l’aide de l’exemple de fichier Ant

Si vous utilisez l’un des exemples de fichier Ant fournis dans le répertoire rép_install_mfp/MobileFirstServer/configuration-samples pour installer MobileFirst Server, vous pouvez réutiliser une copie de ce fichier Ant afin d’appliquer un groupe de correctifs. Pour les valeurs de mot de passe, vous pouvez entrer 12 astérisques (*) à la place de la valeur réelle pour être invité à la saisir de manière interactive lorsque le fichier Ant est exécuté.

  1. Vérifiez la valeur de la propriété mfp.server.install.dir dans le fichier Ant. Elle doit désigner le répertoire contenant le produit auquel est appliqué le groupe de correctifs. Cette valeur permet d’extraire les fichiers WAR MobileFirst Server mis à jour.
  2. Exécutez la commande suivante : rép_install_mfp/shortcuts/ant -f votre_fichier_ant update

Mise à jour à l’aide de votre propre fichier Ant

Si vous utilisez votre propre fichier Ant, assurez-vous que pour chaque tâche d’installation (installmobilefirstadmin, installmobilefirstruntime et installmobilefirstpush), votre fichier Ant comporte une tâche de mise à jour correspondante avec les mêmes paramètres. Les tâches de mise à jour correspondantes sont updatemobilefirstadmin, updatemobilefirstruntime et updatemobilefirstpush.

  1. Vérifiez le chemin d’accès aux classes de l’élément taskdef pour le fichier mfp-ant-deployer.jar. Il doit désigner le fichier mfp-ant-deployer.jar dans une installation de MobileFirst Server à laquelle le groupe de correctifs est appliqué. Par défaut, les fichiers WAR mis à jour de MobileFirst Server sont extraits de l’emplacement dans lequel se trouve mfp-ant-deployer.jar.
  2. Exécutez les tâches de mise à jour (updatemobilefirstadmin, updatemobilefirstruntime et updatemobilefirstpush) de votre fichier Ant.

Modification des exemples de fichier Ant

Vous pouvez modifier les exemples de fichier Ant fournis dans le répertoire rép_install_mfp/MobileFirstServer/configuration-samples afin de les adapter à la configuration requise pour votre installation.
Les sections suivantes expliquent en détail comment modifier les exemples de fichier Ant afin d’adapter l’installation à vos besoins :

  1. Spécification de propriétés JNDI supplémentaires
  2. Spécification d’utilisateurs existants
  3. Spécification du niveau Java EE de Liberty
  4. Spécification des propriétés JDBC de source de données
  5. Exécution des fichiers Ant sur un ordinateur sur lequel MobileFirst Server n’est pas installé
  6. Spécification des cibles WebSphere Application Server Network Deployment
  7. Configuration manuelle du port RMI sur Apache Tomcat

Spécification de propriétés JNDI supplémentaires

Les tâches Ant installmobilefirstadmin, installmobilefirstruntime et installmobilefirstpush déclarent les valeurs pour les propriétés JNDI qui sont requises pour que les composants fonctionnent. Ces propriétés JNDI sont utilisées pour définir la communication JMX ainsi que les liens vers d’autres composants (comme le service Live Update, le service push, le service d’analyse ou le serveur d’autorisation). Toutefois, vous pouvez aussi définir des valeurs pour d’autres propriétés JNDI. Utilisez l’élément <property> qui existe pour ces trois tâches. Pour la liste des propriétés JNDI, voir :

Exemple :

<installmobilefirstadmin ..>
    <property name="mfp.admin.actions.prepareTimeout" value="3000000"/>
</installmobilefirstadmin>

Spécification d’utilisateurs existants

Par défaut, la tâche Ant installmobilefirstadmin crée des utilisateurs :

  • Dans WebSphere Application Server Liberty afin de définir un administrateur Liberty pour la communication JMX.
  • Sur tout serveur d’applications afin de définir un utilisateur servant pour la communication avec le service Live Update.

Pour vous servir d’un utilisateur existant au lieu de créer un utilisateur, vous pouvez effectuer les deux opérations suivantes :

  1. Dans l’élément <jmx>, spécifiez un utilisateur et un mot de passe et associez l’attribut createLibertyAdmin à la valeur false. Exemple :

    <installmobilefirstadmin ...>
        <jmx libertyAdminUser="myUser" libertyAdminPassword="password" createLibertyAdmin="false" />
        ...
    
  2. Dans l’élément <configuration>, spécifiez un utilisateur et un mot de passe et associez l’attribut createConfigAdminUser à la valeur false. Exemple :

     <installmobilefirstadmin ...>
         <configuration configAdminUser="myUser" configAdminPassword="password" createConfigAdminUser="false" />
         ...
    

De plus, l’utilisateur créé par les fichiers d’exemple Ant est mappé aux rôles de sécurité du service d’administration et de la console. Avec ce paramètre, vous pouvez utiliser cet utilisateur pour vous connecter à MobileFirst Server après l’installation. Pour changer ce comportement, supprimez l’élément <user> des exemples de fichier Ant. Vous pouvez aussi supprimer l’attribut password de l’élément <user> pour ne pas créer l’utilisateur dans le registre local du serveur d’applications.

Spécification du niveau Java EE de Liberty

Certaines distributions de WebSphere Application Server Liberty prennent en charge des fonctions de Java EE 6 ou de Java EE 7. Par défaut, les tâches Ant détectent automatiquement les fonctions à installer. Par exemple, la fonction Liberty jdbc-4.0 est installée pour Java EE 6 et la fonction jdbc-4.1 est installée pour Java EE 7. Si l’installation Liberty prend en charge les deux fonctions (Java EE 6 et Java EE 7), vous pouvez imposer un certain niveau de fonctions. Imaginez par exemple que vous prévoyez d’exécuter la version 8.0.0 et la version 7.1.0 de MobileFirst Server sur le même serveur Liberty. MobileFirst Server version 7.1.0 ou antérieure ne prend en charge que les fonctions Java EE 6.

Pour imposer un certain niveau de fonctions Java EE 6, utilisez l’attribut jeeversion de l’élément <websphereapplicationserver>. Exemple :

<installmobilefirstadmin execute="${mfp.process.admin}" contextroot="${mfp.admin.contextroot}">
    [...]
    <applicationserver>
      <websphereapplicationserver installdir="${appserver.was.installdir}"
        profile="Liberty" jeeversion="6">

Spécification des propriétés JDBC de source de données

Vous pouvez spécifier les propriétés pour la connexion JDBC. Utilisez l’élément <property> d’un élément <database>. L’élément est disponible dans les tâches Ant configureDatabase, installmobilefirstadmin, installmobilefirstruntime et installmobilefirstpush. Exemple :

<configuredatabase kind="MobileFirstAdmin">
    <db2 database="${database.db2.mfpadmin.dbname}"
        server="${database.db2.host}"
        instance="${database.db2.instance}"
        user="${database.db2.mfpadmin.username}"
        port= "${database.db2.port}"
        schema = "${database.db2.mfpadmin.schema}"
        password="${database.db2.mfpadmin.password}">

       <property name="commandTimeout" value="10"/>
    </db2>

Exécution des fichiers Ant sur un ordinateur sur lequel MobileFirst Server n’est pas installé

Pour exécuter les tâches Ant sur un ordinateur sur lequel MobileFirst Server n’est pas installé, vous avez besoin :

  • D’une installation Ant
  • D’une copie du fichier mfp-ant-deployer.jar sur l’ordinateur distant. Cette bibliothèque contient la définition des tâches Ant.
  • De spécifier les ressources à installer. Par défaut, les fichiers WAR sont extraits depuis un emplacement proche de mfp-ant-deployer.jar, mais vous pouvez spécifier cet emplacement. Exemple :
<installmobilefirstadmin execute="true" contextroot="/mfpadmin" serviceWAR="/usr/mfp/mfp-admin-service.war">
  <console install="true" warFile="/usr/mfp/mfp-admin-ui.war"/>

Pour plus d’informations, voir les tâches Ant permettant d’installer chaque composant MobileFirst Server dans Référence d’installation.

Spécification des cibles WebSphere Application Server Network Deployment

Pour procéder à l’installation sur WebSphere Application Server Network Deployment, le profil WebSphere Application Server spécifié doit être le gestionnaire de déploiement. Vous pouvez effectuer le déploiement dans les configurations suivantes :

  • Un cluster
  • Un serveur unique
  • Une cellule (tous les serveurs d’une cellule)
  • Un noeud (tous les serveurs d’un noeud)

Les exemples de fichier tels que configure-wasnd-cluster-dbms-name.xml, configure-wasnd-server-dbms-name.xml et configure-wasnd-node-dbms-name.xml contiennent une déclaration pour le déploiement de chaque type de cible. Pour plus d’informations, voir les tâches Ant permettant d’installer chaque composant MobileFirst Server dans Référence d’installation.

Remarque : depuis la version 8.0.0, l’exemple de fichier de configuration pour la cellule WebSphere Application Server Network Deployment n’est plus fourni.

Configuration manuelle du port RMI sur Apache Tomcat

Par défaut, les tâches Ant modifient le fichier setenv.bat ou setenv.sh en vue de l’ouverture du port RMI. Si vous préférez ouvrir le port RMI manuellement, ajoutez l’attribut tomcatSetEnvConfig avec la valeur false dans l’élément <jmx> des tâches installmobilefirstadmin, updatemobilefirstadmin et uninstallmobilefirstadmin.

Installation manuelle des composants MobileFirst Server

Vous pouvez également installer les composants MobileFirst Server sur votre serveur d’applications manuellement.
Les rubriques suivantes vous guideront tout au long du processus d’installation des composants sur les applications prises en charge en production :

Installation manuelle sur WebSphere Application Server Liberty

Assurez-vous d’avoir également satisfait les exigences décrites dans Prérequis pour WebSphere Application Server Liberty.

Contraintes liées à la topologie

Le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et l’environnement d’exécution de MobileFirst doivent être installés sur un même serveur d’applications. La racine de contexte du service Live Update doit être racine-contexteadminconfig. La racine de contexte du service push doit être imfpush. Pour plus d’informations sur les contraintes, voir Contraintes sur les composants MobileFirst Server et MobileFirst Analytics.

Paramètres de serveur d’applications

Vous devez configurer l’élément webContainer pour le chargement immédiat des servlets. Ce paramètre est requis pour l’initialisation via JMX. Par exemple : <webContainer deferServletLoad="false"/>.

Si vous le souhaitez, pour éviter tout problème de dépassement de délai d’attente interrompant la séquence de démarrage de l’environnement d’exécution et du service d’administration dans certaines versions de Liberty, changez l’élément executor par défaut. Définissez des valeurs élevées pour les attributs coreThreads et maxThreads. Exemple :

<executor id="default" name="LargeThreadPool"
  coreThreads="200" maxThreads="400" keepAlive="60s"
  stealPolicy="STRICT" rejectedWorkPolicy="CALLER_RUNS"/>

Vous pouvez aussi configurer l’élément tcpOptions et associer l’attribut soReuseAddr à la valeur true: <tcpOptions soReuseAddr="true"/>.

Fonctions Liberty requises par les applications MobileFirst Server

Vous pouvez utiliser les fonctions ci-dessous pour Java EE 6 ou Java EE 7.

Service d’administration de MobileFirst Server

  • jdbc-4.0 (jdbc-4.1 pour Java EE 7)
  • appSecurity-2.0
  • restConnector-1.0
  • usr:MFPDecoderFeature-1.0

Service push de MobileFirst Server

  • jdbc-4.0 (jdbc-4.1 pour Java EE 7)
  • servlet-3.0 (servlet-3.1 pour Java EE 7)
  • ssl-1.0
  • usr:MFPDecoderFeature-1.0

Environnement d’exécution de MobileFirst

  • jdbc-4.0 (jdbc-4.1 pour Java EE 7)
  • servlet-3.0 (servlet-3.1 pour Java EE 7)
  • ssl-1.0
  • usr:MFPDecoderFeature-1.0

Entrées JNDI globales

Les entrées JNDI globales suivantes sont requises pour configurer la communication JMX entre l’environnement d’exécution et le service d’administration :

  • mfp.admin.jmx.host
  • mfp.admin.jmx.port
  • mfp.admin.jmx.user
  • mfp.admin.jmx.pwd
  • mfp.topology.platform
  • mfp.topology.clustermode

Ces entrées JNDI globales sont définies avec la syntaxe ci-après et ne sont pas préfixées avec une racine de contexte. Par exemple : <jndiEntry jndiName="mfp.admin.jmx.port" value="9443"/>.

Remarque : pour empêcher toute conversion automatique des valeurs JNDI, de sorte que 075 ne soit pas converti en 61 ou 31.500 en 31.5, utilisez la syntaxe ‘“075”’ lorsque vous définissez la valeur.

Pour plus d’informations sur les propriétés JNDI pour le service d’administration, voir Liste des propriétés JNDI pour le service d’administration de MobileFirst Server.

Pour une configuration de parc de serveurs, voir aussi les rubriques suivantes :

Chargeur de classe

Pour toutes les applications, l’attribut delegation du chargeur de classe doit avoir la valeur parentLast (parent en dernier). Exemple :

<application id="mfpadmin" name="mfpadmin" location="mfp-admin-service.war" type="war">
  [...]
  <classloader delegation="parentLast">
  </classloader> </application>

Fonction utilisateur de décodage de mot de passe

Copiez la fonction utilisateur de décodage de mot de passe dans votre profil Liberty. Exemple :

  • Sur les systèmes UNIX et Linux :

    mkdir -p LIBERTY_HOME/wlp/usr/extension/lib/features
    cp product_install_dir/features/com.ibm.websphere.crypto_1.0.0.jar LIBERTY_HOME/wlp/usr/extension/lib/
    cp product_install_dir/features/MFPDecoderFeature-1.0.mf LIBERTY_HOME/wlp/usr/extension/lib/features/
    
  • Sur les systèmes Windows :

    mkdir LIBERTY_HOME\wlp\usr\extension\lib
    copy /B product_install_dir\features\com.ibm.websphere.crypto_1.0.0.jar
    LIBERTY_HOME\wlp\usr\extension\lib\com.ibm.websphere.crypto_1.0.0.jar
    mkdir LIBERTY_HOME\wlp\usr\extension\lib\features
    copy /B product_install_dir\features\MFPDecoderFeature-1.0.mf
    LIBERTY_HOME\wlp\usr\extension\lib\features\MFPDecoderFeature-1.0.mf
    

Détails de configuration

Le service d'administration est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml. Le fichier WAR du service d'administration est rép_install_mfp/MobileFirstServer/mfp-admin-service.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit généralement de /mfpadmin.

Propriétés JNDI obligatoires

Lorsque vous définissez les propriétés JNDI, les noms JNDI doivent être préfixés avec la racine de contexte du service d'administration. L'exemple suivant est une déclaration de mfp.admin.push.url selon laquelle le service d'administration est installé avec la racine de contexte /mfpadmin :

 <jndiEntry jndiName="mfpadmin/mfp.admin.push.url" value="http://localhost:9080/imfpush"/>

Si le service push est installé, vous devez configurer les propriétés JNDI suivantes :

  • mfp.admin.push.url
  • mfp.admin.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.admin.authorization.client.id
  • mfp.admin.authorization.client.secret

Les propriétés JNDI pour la communication avec le service de configuration sont les suivantes :

  • mfp.config.service.user
  • mfp.config.service.password

Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour le service d'administration de MobileFirst Server.

Source de données

Le nom JNDI de la source de données pour le service d'administration doit être jndiName=racine-contexte/jdbc/mfpAdminDS. L'exemple suivant illustre le cas où le service d'administration est installé avec la racine de contexte /mfpadmin et utilise une base de données relationnelle :

 <dataSource jndiName="mfpadmin/jdbc/mfpAdminDS" transactional="false">
  [...]
</dataSource>

Déclarez les rôles suivants dans l'élément application-bnd de l'application :

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator

Le service Live Update est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml. Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server Liberty pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR du service Live Update est rép_install_mfp/MobileFirstServer/mfp-live-update.war. La racine de contexte du service Live Update doit être définie comme suit : /racine-contexteadminconfig. Par exemple, si la racine de contexte du service d'administration est /mfpadmin, la racine de contexte du service Live Update doit être /mfpadminconfig.

Source de données

Le nom JNDI de la source de données pour le service Live update doit être racine-contexte/jdbc/ConfigDS. L'exemple suivant illustre le cas où le service Live Update est installé avec la racine de contexte /mfpadminconfig et utilise une base de données relationnelle :

<dataSource jndiName="mfpadminconfig/jdbc/ConfigDS" transactional="false">
  [...]
</dataSource>

Déclarez le rôle configadmin dans l'élément application-bnd de l'application. Un utilisateur au moins doit être mappé à ce rôle. L'utilisateur et son mot de passe doivent être fournis dans les propriétés JNDI suivantes du service d'administration :

  • mfp.config.service.user
  • mfp.config.service.password

La console est conditionnée sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml. Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server Liberty pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR de la console est rép_install_mfp/MobileFirstServer/mfp-admin-ui.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit généralement de /mfpconsole.

Propriétés JNDI obligatoires

Lorsque vous définissez les propriétés JNDI, les noms JNDI doivent être préfixés avec la racine de contexte de la console. L'exemple suivant est une déclaration de mfp.admin.endpoint selon laquelle la console est installée avec la racine de contexte /mfpconsole :

 <jndiEntry jndiName="mfpconsole/mfp.admin.endpoint" value="*://*:*/mfpadmin"/>

La valeur habituelle pour la propriété mfp.admin.endpoint est *://*:*/the-adminContextRoot.
Pour plus d'informations sur les propriétés JNDI, voir Propriétés JNDI pour MobileFirst Operations Console.

Rôles de sécurité

Déclarez les rôles suivants dans l'élément application-bnd de l'application :

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator
Tout utilisateur mappé à un rôle de sécurité de la console doit également être mappé au même rôle de sécurité du service d'administration.

L'environnement d'exécution est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml. Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server Liberty pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR de l'environnement d'exécution est rép_install_mfp/MobileFirstServer/mfp-server.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit par défaut de /mfp.

Propriétés JNDI obligatoires

Lorsque vous définissez les propriétés JNDI, les noms JNDI doivent être préfixés avec la racine de contexte de l'environnement d'exécution. L'exemple suivant est une déclaration de mfp.analytics.url selon laquelle l'environnement d'exécution est installé avec la racine de contexte /mobilefirst :

 <jndiEntry jndiName="mobilefirst/mfp.analytics.url" value="http://localhost:9080/analytics-service/rest"/>

Vous devez définir la propriété mobilefirst/mfp.authorization.server. Exemple :

 <jndiEntry jndiName="mobilefirst/mfp.authorization.server" value="embedded"/>

Si MobileFirst Analytics est installé, vous devez définir les propriétés JNDI suivantes :

  • mfp.analytics.url
  • mfp.analytics.console.url
  • mfp.analytics.username
  • mfp.analytics.password

Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour l'environnement d'exécution de MobileFirst.

Source de données

Le nom JNDI de la source de données pour l'environnement d'exécution doit être jndiName=racine-contexte/jdbc/mfpDS. L'exemple suivant illustre le cas où l'environnement d'exécution est installé avec la racine de contexte /mobilefirst et utilise une base de données relationnelle :

 <dataSource jndiName="mobilefirst/jdbc/mfpDS" transactional="false">
  [...]
</dataSource> 

Le service push est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml. Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server Liberty pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR du service push est rép_install_mfp/PushService/mfp-push-service.war. Vous devez définir la racine de contexte /imfpush. Sinon, les appareils client ne pourront pas se connecter au service car la racine de contexte est codée en dur dans le logiciel SDK.

Propriétés JNDI obligatoires

Lorsque vous définissez les propriétés JNDI, les noms JNDI doivent être préfixés avec la racine de contexte du service push. L'exemple suivant est une déclaration de mfp.push.analytics.user selon laquelle le service push est installé avec la racine de contexte /imfpush :

 <jndiEntry jndiName="imfpush/mfp.push.analytics.user" value="admin"/>
Vous devez définir les propriétés suivantes :
  • mfp.push.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.push.services.ext.security - La valeur doit être com.ibm.mfp.push.server.security.plugin.OAuthSecurityPlugin.
  • mfp.push.db.type - Pour une base de données relationnelle, la valeur doit être DB.
Si MobileFirst Analytics est configuré, définissez les propriétés JNDI suivantes :
  • mfp.push.analytics.endpoint
  • mfp.analytics.username
  • mfp.analytics.password
  • mfp.push.services.ext.analytics - La valeur doit être com.ibm.mfp.push.server.analytics.plugin.AnalyticsPlugin.
Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour le service push de MobileFirst Server.

Le composant des artefacts est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml. Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server Liberty pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR pour ce composant est rép_install_mfp/MobileFirstServer/mfp-dev-artifacts.war. Vous devez définir la racine de contexte /mfp-dev-artifacts.

Installation manuelle dans la collectivité Liberty WebSphere Application Server Liberty

Assurez-vous d’avoir également satisfait les exigences décrites dans Prérequis pour WebSphere Application Server Liberty.

Contraintes liées à la topologie

Le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et MobileFirst Operations Console doivent être installés sur un contrôleur de collectivité Liberty. L’environnement d’exécution MobileFirst et le service push de MobileFirst Server doivent être installés sur chaque membre de cluster de collectivité Liberty.

La racine de contexte du service Live Update doit être racine-contexteadminconfig. La racine de contexte du service push doit être imfpush. Pour plus d’informations sur les contraintes, voir Contraintes sur les composants MobileFirst Server et MobileFirst Analytics.

Paramètres de serveur d’applications

Vous devez configurer l’élément webContainer pour le chargement immédiat des servlets. Ce paramètre est requis pour l’initialisation via JMX. Par exemple : <webContainer deferServletLoad="false"/>.

Si vous le souhaitez, pour éviter tout problème de dépassement de délai d’attente interrompant la séquence de démarrage de l’environnement d’exécution et du service d’administration dans certaines versions de Liberty, changez l’élément executor par défaut. Définissez des valeurs élevées pour les attributs coreThreads et maxThreads. Exemple :

<executor id="default" name="LargeThreadPool"
  coreThreads="200" maxThreads="400" keepAlive="60s"
  stealPolicy="STRICT" rejectedWorkPolicy="CALLER_RUNS"/>

Vous pouvez aussi configurer l’élément tcpOptions et associer l’attribut soReuseAddr à la valeur true: <tcpOptions soReuseAddr="true"/>.

Fonctions Liberty requises par les applications MobileFirst Server

Vous devez ajouter les fonctions ci-dessous pour Java EE 6 ou Java EE 7.

Service d’administration de MobileFirst Server

  • jdbc-4.0 (jdbc-4.1 pour Java EE 7)
  • appSecurity-2.0
  • restConnector-1.0
  • usr:MFPDecoderFeature-1.0

Service push de MobileFirst Server

  • jdbc-4.0 (jdbc-4.1 pour Java EE 7)
  • servlet-3.0 (servlet-3.1 pour Java EE 7)
  • ssl-1.0
  • usr:MFPDecoderFeature-1.0

Environnement d’exécution de MobileFirst

  • jdbc-4.0 (jdbc-4.1 pour Java EE 7)
  • servlet-3.0 (servlet-3.1 pour Java EE 7)
  • ssl-1.0
  • usr:MFPDecoderFeature-1.0

Entrées JNDI globales

Les entrées JNDI globales suivantes sont requises pour configurer la communication JMX entre l’environnement d’exécution et le service d’administration :

  • mfp.admin.jmx.host
  • mfp.admin.jmx.port
  • mfp.admin.jmx.user
  • mfp.admin.jmx.pwd
  • mfp.topology.platform
  • mfp.topology.clustermode
  • mfp.admin.serverid

Ces entrées JNDI globales sont définies avec la syntaxe ci-après et ne sont pas préfixées avec une racine de contexte. Par exemple : <jndiEntry jndiName="mfp.admin.jmx.port" value="9443"/>.

Remarque : pour empêcher toute conversion automatique des valeurs JNDI, de sorte que 075 ne soit pas converti en 61 ou 31.500 en 31.5, utilisez la syntaxe ‘“075”’ lorsque vous définissez la valeur.

Chargeur de classe

Pour toutes les applications, l’attribut delegation du chargeur de classe doit avoir la valeur parentLast (parent en dernier). Exemple :

<application id="mfpadmin" name="mfpadmin" location="mfp-admin-service.war" type="war">
  [...]
  <classloader delegation="parentLast">
  </classloader> </application>

Fonction utilisateur de décodage de mot de passe

Copiez la fonction utilisateur de décodage de mot de passe dans votre profil Liberty. Exemple :

  • Sur les systèmes UNIX et Linux :

    mkdir -p LIBERTY_HOME/wlp/usr/extension/lib/features
    cp product_install_dir/features/com.ibm.websphere.crypto_1.0.0.jar LIBERTY_HOME/wlp/usr/extension/lib/
    cp product_install_dir/features/MFPDecoderFeature-1.0.mf LIBERTY_HOME/wlp/usr/extension/lib/features/
    
  • Sur les systèmes Windows :

    mkdir LIBERTY_HOME\wlp\usr\extension\lib
    copy /B product_install_dir\features\com.ibm.websphere.crypto_1.0.0.jar
    LIBERTY_HOME\wlp\usr\extension\lib\com.ibm.websphere.crypto_1.0.0.jar
    mkdir LIBERTY_HOME\wlp\usr\extension\lib\features
    copy /B product_install_dir\features\MFPDecoderFeature-1.0.mf
    LIBERTY_HOME\wlp\usr\extension\lib\features\MFPDecoderFeature-1.0.mf
    

    Détails de configuration

Le service d'administration est conditionné sous forme d'application WAR en vue de son déploiement sur le contrôleur de collectivité Liberty. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml du contrôleur de collectivité Liberty.

Avant de continuer, consultez la section Installation manuelle dans la collectivité WebSphere Application Server Liberty pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR du service d'administration se trouve dans mfp_install_dir/MobileFirstServer/mfp-admin-service-collective.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit généralement de /mfpadmin.

Propriétés JNDI obligatoires

Lorsque vous définissez les propriétés JNDI, les noms JNDI doivent être préfixés avec la racine de contexte du service d'administration. L'exemple suivant est une déclaration de mfp.admin.push.url selon laquelle le service d'administration est installé avec la racine de contexte /mfpadmin :

 <jndiEntry jndiName="mfpadmin/mfp.admin.push.url" value="http://localhost:9080/imfpush"/>

Si le service push est installé, vous devez configurer les propriétés JNDI suivantes :

  • mfp.admin.push.url
  • mfp.admin.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.admin.authorization.client.id
  • mfp.admin.authorization.client.secret

Les propriétés JNDI pour la communication avec le service de configuration sont les suivantes :

  • mfp.config.service.user
  • mfp.config.service.password

Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour le service d'administration de MobileFirst Server.

Source de données

Le nom JNDI de la source de données pour le service d'administration doit être jndiName=racine-contexte/jdbc/mfpAdminDS. L'exemple suivant illustre le cas où le service d'administration est installé avec la racine de contexte /mfpadmin et utilise une base de données relationnelle :

 <dataSource jndiName="mfpadmin/jdbc/mfpAdminDS" transactional="false">
  [...]
</dataSource>

Rôles de sécurité

Déclarez les rôles suivants dans l'élément application-bnd de l'application :

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator

Le service Live Update est conditionné sous forme d'application WAR en vue de son déploiement sur le contrôleur de collectivité Liberty. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml du contrôleur de collectivité Liberty.

Avant de continuer, consultez la section Installation manuelle dans la collectivité WebSphere Application Server Liberty pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR du service Live Update est rép_install_mfp/MobileFirstServer/mfp-live-update.war. La racine de contexte du service Live Update doit être définie comme suit : /racine-contexteadminconfig. Par exemple, si la racine de contexte du service d'administration est /mfpadmin, la racine de contexte du service Live Update doit être /mfpadminconfig.

Source de données

Le nom JNDI de la source de données pour le service Live Update doit être racine-contexte/jdbc/ConfigDS. L'exemple suivant illustre le cas où le service Live Update est installé avec la racine de contexte /mfpadminconfig et utilise une base de données relationnelle :

<dataSource jndiName="mfpadminconfig/jdbc/ConfigDS" transactional="false">
  [...]
</dataSource>

Rôles de sécurité

Déclarez le rôle configadmin dans l'élément application-bnd de l'application. Un utilisateur au moins doit être mappé à ce rôle. L'utilisateur et son mot de passe doivent être fournis dans les propriétés JNDI suivantes du service d'administration :

  • mfp.config.service.user
  • mfp.config.service.password

La console est conditionnée sous forme d'application WAR en vue de son déploiement sur le contrôleur de collectivité Liberty. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml du contrôleur de collectivité Liberty.

Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server Liberty pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR de la console est rép_install_mfp/MobileFirstServer/mfp-admin-ui.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit généralement de /mfpconsole.

Propriétés JNDI obligatoires

Lorsque vous définissez les propriétés JNDI, les noms JNDI doivent être préfixés avec la racine de contexte de la console. L'exemple suivant est une déclaration de mfp.admin.endpoint selon laquelle la console est installée avec la racine de contexte /mfpconsole :

 <jndiEntry jndiName="mfpconsole/mfp.admin.endpoint" value="*://*:*/mfpadmin"/>

La valeur habituelle pour la propriété mfp.admin.endpoint est *://*:*/the-adminContextRoot.
Pour plus d'informations sur les propriétés JNDI, voir Propriétés JNDI pour MobileFirst Operations Console.

Rôles de sécurité

Déclarez les rôles suivants dans l'élément application-bnd de l'application :

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator
Tout utilisateur mappé à un rôle de sécurité de la console doit également être mappé au même rôle de sécurité du service d'administration.

L'environnement d'exécution est conditionné sous forme d'application WAR en vue de son déploiement sur les membres de cluster de collectivité Liberty. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml de chaque membre de cluster de collectivité Liberty.

Avant de continuer, consultez la section Installation manuelle dans la collectivité WebSphere Application Server Liberty pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR de l'environnement d'exécution est rép_install_mfp/MobileFirstServer/mfp-server.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit par défaut de /mfp.

Propriétés JNDI obligatoires

Lorsque vous définissez les propriétés JNDI, les noms JNDI doivent être préfixés avec la racine de contexte de l'environnement d'exécution. L'exemple suivant est une déclaration de mfp.analytics.url selon laquelle l'environnement d'exécution est installé avec la racine de contexte /mobilefirst :

 <jndiEntry jndiName="mobilefirst/mfp.analytics.url" value="http://localhost:9080/analytics-service/rest"/>

Vous devez définir la propriété mobilefirst/mfp.authorization.server. Exemple :

 <jndiEntry jndiName="mobilefirst/mfp.authorization.server" value="embedded"/>

Si MobileFirst Analytics est installé, vous devez définir les propriétés JNDI suivantes :

  • mfp.analytics.url
  • mfp.analytics.console.url
  • mfp.analytics.username
  • mfp.analytics.password

Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour l'environnement d'exécution de MobileFirst.

Source de données

Le nom JNDI de la source de données pour l'environnement d'exécution doit être jndiName=racine-contexte/jdbc/mfpDS. L'exemple suivant illustre le cas où l'environnement d'exécution est installé avec la racine de contexte /mobilefirst et utilise une base de données relationnelle :

 <dataSource jndiName="mobilefirst/jdbc/mfpDS" transactional="false">
  [...]
</dataSource> 

Le service push est conditionné sous forme d'application WAR en vue de son déploiement sur un membre de cluster de collectivité Liberty ou un serveur Liberty. Si vous installez le service push sur un serveur Liberty, reportez-vous à Détails de configuration du service push de MobileFirst Server sous Installation manuelle sur WebSphere Application Server Liberty.

Lorsque le service push de MobileFirst Server est installé dans une collectivité Liberty, il peut être installé dans le même cluster que l'exécution ou dans un autre cluster.

Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml de chaque membre de cluster de collectivité Liberty. Avant de continuer, consultez la section Installation manuelle dans la collectivité WebSphere Application Server Liberty pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR du service push est rép_install_mfp/PushService/mfp-push-service.war. Vous devez définir la racine de contexte /imfpush. Sinon, les appareils client ne pourront pas se connecter au service car la racine de contexte est codée en dur dans le logiciel SDK.

Propriétés JNDI obligatoires

Lorsque vous définissez les propriétés JNDI, les noms JNDI doivent être préfixés avec la racine de contexte du service push. L'exemple suivant est une déclaration de mfp.push.analytics.user selon laquelle le service push est installé avec la racine de contexte /imfpush :

 <jndiEntry jndiName="imfpush/mfp.push.analytics.user" value="admin"/>
Vous devez définir les propriétés suivantes :
  • mfp.push.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.push.services.ext.security - La valeur doit être com.ibm.mfp.push.server.security.plugin.OAuthSecurityPlugin.
  • mfp.push.db.type - Pour une base de données relationnelle, la valeur doit être DB.
Si MobileFirst Analytics est configuré, définissez les propriétés JNDI suivantes :
  • mfp.push.analytics.endpoint
  • mfp.analytics.username
  • mfp.analytics.password
  • mfp.push.services.ext.analytics - La valeur doit être com.ibm.mfp.push.server.analytics.plugin.AnalyticsPlugin.
Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour le service push de MobileFirst Server.

Le composant des artefacts est conditionné sous forme d'application WAR en vue de son déploiement sur le contrôleur de collectivité Liberty. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml du contrôleur de collectivité Liberty. Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server Liberty pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR pour ce composant est rép_install_mfp/MobileFirstServer/mfp-dev-artifacts.war. Vous devez définir la racine de contexte /mfp-dev-artifacts.

Installation manuelle sur Apache Tomcat

Assurez-vous d’avoir satisfait les exigences décrites dans Prérequis pour Apache Tomcat.

Contraintes liées à la topologie

Le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et l’environnement d’exécution de MobileFirst doivent être installés sur un même serveur d’applications. La racine de contexte du service Live Update doit être racine-contexteadminconfig. La racine de contexte du service push doit être imfpush. Pour plus d’informations sur les contraintes, voir Contraintes sur les composants MobileFirst Server et MobileFirst Analytics.

Paramètres de serveur d’applications

Vous devez activer la valve de connexion unique. Exemple :

<Valve className="org.apache.catalina.authenticator.SingleSignOn"/>

Si vous le souhaitez, vous pouvez activer le domaine de mémoire (MemoryRealm) si les utilisateurs sont définis dans tomcat-users.xml. Exemple :

<Realm className="org.apache.catalina.realm.MemoryRealm"/>

Détails de configuration

Le service d'administration est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml du serveur d'applications.

Avant de continuer, consultez la section Installation manuelle sur Apache Tomcat pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR du service d'administration est rép_install_mfp/MobileFirstServer/mfp-admin-service.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit généralement de /mfpadmin.

Propriétés JNDI obligatoires

Les propriétés JNDI sont définies dans l'élément Environment dans le contexte d'application. Exemple :

<Environment name="mfp.admin.push.url" value="http://localhost:8080/imfpush" type="java.lang.String" override="false"/>

Pour activer la communication JMX avec l'environnement d'exécution, définissez les propriétés JNDI suivantes :

  • mfp.topology.platform
  • mfp.topology.clustermode

Si le service push est installé, vous devez configurer les propriétés JNDI suivantes :

  • mfp.admin.push.url
  • mfp.admin.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.admin.authorization.client.id
  • mfp.admin.authorization.client.secret

Les propriétés JNDI pour la communication avec le service de configuration sont les suivantes :

  • mfp.config.service.user
  • mfp.config.service.password

Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour le service d'administration de MobileFirst Server.

Source de données

La source de données (jdbc/mfpAdminDS) est déclarée comme ressource dans l'élément **Context**. Exemple :

<Resource name="jdbc/mfpAdminDS" type="javax.sql.DataSource" .../>

Rôles de sécurité

Les rôles de sécurité disponibles pour l'application de service d'administration sont :

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator

Le service Live Update est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml.

Avant de continuer, consultez la section Installation manuelle sur Apache Tomcat pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR du service Live Update est rép_install_mfp/MobileFirstServer/mfp-live-update.war. La racine de contexte du service Live Update doit être définie comme suit : /racine-contexteadmin/config. Par exemple, si la racine de contexte du service d'administration est /mfpadmin, la racine de contexte du service Live Update doit être /mfpadminconfig.

Source de données

Le nom JNDI de la source de données pour le service Live Update doit être jdbc/ConfigDS. Déclarez-le comme ressource dans l'élément Context.

Rôles de sécurité

Le rôle de sécurité disponible pour l'application de service Live Update est configadmin.

Un utilisateur au moins doit être mappé à ce rôle. L'utilisateur et son mot de passe doivent être fournis dans les propriétés JNDI suivantes du service d'administration :

  • mfp.config.service.user
  • mfp.config.service.password

La console est conditionnée sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml du serveur d'applications.

Avant de continuer, consultez la section Installation manuelle sur Apache Tomcat pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR de la console est rép_install_mfp/MobileFirstServer/mfp-admin-ui.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit généralement de /mfpconsole.

Propriétés JNDI obligatoires

Vous devez définir la propriété mfp.admin.endpoint. En général, la valeur de cette propriété est *://*:*/racine-contexteadmin.

Pour plus d'informations sur les propriétés JNDI, voir Propriétés JNDI pour MobileFirst Operations Console.

Rôles de sécurité

Les rôles de sécurité disponibles pour l'application sont :

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator

L'environnement d'exécution est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml.

Avant de continuer, consultez la section Installation manuelle sur Apache Tomcat pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR de l'environnement d'exécution est rép_install_mfp/MobileFirstServer/mfp-server.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit par défaut de /mfp.

Propriétés JNDI obligatoires

Vous devez définir la propriété mfp.authorization.server. Exemple :

<Environment name="mfp.authorization.server" value="embedded" type="java.lang.String" override="false"/>

Pour activer la communication JMX avec le service d'administration, définissez les propriétés JNDI suivantes :

  • mfp.topology.platform
  • mfp.topology.clustermode

Si MobileFirst Analytics est installé, vous devez définir les propriétés JNDI suivantes :

  • mfp.analytics.url
  • mfp.analytics.console.url
  • mfp.analytics.username
  • mfp.analytics.password

Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour l'environnement d'exécution de MobileFirst.

Source de données

Le nom JNDI de la source de données pour l'environnement d'exécution doit être jdbc/mfpDS. Déclarez-le comme ressource dans l'élément Context.

Le service push est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application. Avant de continuer, consultez la section Installation manuelle sur Apache Tomcat pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR du service push est rép_install_mfp/PushService/mfp-push-service.war. Vous devez définir la racine de contexte /imfpush. Sinon, les appareils client ne pourront pas se connecter au service car la racine de contexte est codée en dur dans le logiciel SDK.

Propriétés JNDI obligatoires

Vous devez définir les propriétés suivantes :

  • mfp.push.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.push.services.ext.security - La valeur doit être com.ibm.mfp.push.server.security.plugin.OAuthSecurityPlugin.
  • mfp.push.db.type - Pour une base de données relationnelle, la valeur doit être DB.

Si MobileFirst Analytics est configuré, définissez les propriétés JNDI suivantes :

  • mfp.push.analytics.endpoint
  • mfp.analytics.username
  • mfp.analytics.password
  • mfp.push.services.ext.analytics - La valeur doit être com.ibm.mfp.push.server.analytics.plugin.AnalyticsPlugin.
Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour le service push de MobileFirst Server.

Le composant des artefacts est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml du serveur d'applications. Avant de continuer, consultez la section Installation manuelle sur Apache Tomcat pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR pour ce composant est rép_install_mfp/MobileFirstServer/mfp-dev-artifacts.war. Vous devez définir la racine de contexte /mfp-dev-artifacts.

Installation manuelle sur WebSphere Application Server et WebSphere Application Server Network Deployment

Assurez-vous d’avoir satisfait les exigences décrites dans Prérequis pour WebSphere Application Server et WebSphere Application Server Network Deployment.

Contraintes liées à la topologie

Sur un serveur WebSphere Application Server autonome
Le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et l’environnement d’exécution de MobileFirst doivent être installés sur un même serveur d’applications. La racine de contexte du service Live Update doit être racine-contexteadminConfig. La racine de contexte du service push doit être imfpush. Pour plus d’informations sur les contraintes, voir Contraintes sur les composants MobileFirst Server et MobileFirst Analytics.

Sur WebSphere Application Server Network Deployment
Le gestionnaire de déploiement doit s’exécuter lorsque MobileFirst Server s’exécute. Il est utilisé pour la communication JMX entre l’environnement d’exécution et le service d’administration. Le service d’administration et le service Live Update doivent être installés sur le même serveur d’applications. L’environnement d’exécution peut être installé sur un serveur différent de celui du service d’administration, mais doit se trouver dans la même cellule.

Paramètres de serveur d’applications

La sécurité administrative et la sécurité des applications doivent être activées. Vous pouvez activer la sécurité des applications dans la console d’administration WebSphere Application Server :

  1. Connectez-vous à la console d’administration WebSphere Application Server.
  2. Sélectionnez Sécurité → Sécurité globale. Assurez-vous que l’option Activer la sécurité administrative est sélectionnée.
  3. Ensuite, assurez-vous que l’option Activer la sécurité des applications est sélectionnée. La sécurité des applications ne peut être activée que si la sécurité administrative est activée.
  4. Cliquez sur OK.
  5. Sauvegardez les modifications.

Pour plus d’informations, voir Activation de la sécurité dans la documentation de WebSphere Application Server.

Les règles de chargeur de classe du serveur doivent prendre en charge la valeur d’attribut delegation parentLast (parent en dernier). Les fichiers WAR de MobileFirst Server doivent être installés en mode de chargeur de classe “parent en dernier”. Prenez connaissance de la règle de chargeur de classe du serveur :

  1. Connectez-vous à la console d’administration WebSphere Application Server.
  2. Sélectionnez Serveurs → Types de serveurs → Serveurs d’applications WebSphere et cliquez sur le serveur qui est utilisé pour Mobile Foundation.
  3. Si la règle de chargeur de classe est Plusieurs, ne faites rien.
  4. Si la règle de chargeur de classe est Un seul et si le mode de chargement des classes a pour valeur Classes chargées en premier avec un chargeur de classe local (dernier parent), ne faites rien.
  5. Si la règle de chargeur de classe est Un seul et si le mode de chargement des classes a pour valeur Classes chargées en premier avec un chargeur de classes parent (parent en premier), remplacez la règle de chargeur de classe par Plusieurs. De plus, associez l’ordre de chargeur de classe de toutes les applications autres que les applications MobileFirst Server à Classes chargées en premier avec un chargeur de classes parent (parent en premier).

Chargeur de classe

Pour toutes les applications MobileFirst Server, l’attribut delegation du chargeur de classe doit avoir la valeur parentLast (parent en dernier).

Pour définir la valeur de l’attribut delegation parentLast (parent en dernier) après l’installation d’une application, procédez comme suit :

  1. Sélectionnez Applications → Types d’application → Applications d’entreprise WebSphere.
  2. Cliquez sur l’application MobileFirst Server. Par défaut, le nom de l’application est le nom du fichier WAR.
  3. Dans la section Propriétés du détail, cliquez sur le lien Chargement de classes et détection de mise à jour.
  4. Dans la sous-fenêtre Ordre du chargeur de classes, sélectionnez l’option Classes chargées en premier avec un chargeur de classe local (dernier parent).
  5. Cliquez sur OK.
  6. Dans la section Modules, cliquez sur le lien Gestion des modules.
  7. Cliquez sur le module.
  8. Dans la zone Ordre du chargeur de classes, sélectionnez l’option Classes chargées en premier avec un chargeur de classe local (dernier parent).
  9. Cliquez sur OK deux fois pour confirmer la sélection et revenir au panneau Configuration de l’application.
  10. Cliquez sur Sauvegarder pour sauvegarder les modifications.

Détails de configuration

Le service d'administration est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml du serveur d'applications.

Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server et WebSphere Application Server Network Deployment pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR du service d'administration est rép_install_mfp/MobileFirstServer/mfp-admin-service.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit généralement de /mfpadmin.

Propriétés JNDI obligatoires

Vous pouvez définir des propriétés JNDI depuis la console d'administration WebSphere Application Server. Sélectionnez Applications → Types d'application → Applications d'entreprise WebSphere → nom_application → Entrées d'environnement pour les modules Web et définissez les entrées.

Pour activer la communication JMX avec l'environnement d'exécution, définissez les propriétés JNDI suivantes :

Sur WebSphere Application Server Network Deployment
  • mfp.admin.jmx.dmgr.host
  • mfp.admin.jmx.dmgr.port - Port SOAP sur le gestionnaire de déploiement.
  • mfp.topology.platform - Définissez la valeur WAS.
  • mfp.topology.clustermode - Définissez la valeur Cluster.
  • mfp.admin.jmx.connector - Définissez la valeur SOAP.
Sur un serveur WebSphere Application Server autonome
  • mfp.topology.platform - Définissez la valeur WAS.
  • mfp.topology.clustermode - Définissez la valeur Standalone.
  • mfp.admin.jmx.connector - Définissez la valeur SOAP.

Si le service push est installé, vous devez configurer les propriétés JNDI suivantes :

  • mfp.admin.push.url
  • mfp.admin.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.admin.authorization.client.id
  • mfp.admin.authorization.client.secret

Les propriétés JNDI pour la communication avec le service de configuration sont les suivantes :

  • mfp.config.service.user
  • mfp.config.service.password

Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour le service d'administration de MobileFirst Server.

Source de données

Créez une source de données pour le service d'administration et mappez-la à jdbc/mfpAdminDS.

Ordre de lancement

L'application de service d'administration doit démarrer avant l'application d'environnement d'exécution. Vous pouvez définir l'ordre dans la section Comportement de lancement. Par exemple, définissez l'ordre de lancement 1 pour le service d'administration et 2 pour l'environnement d'exécution.

Rôles de sécurité

Les rôles de sécurité disponibles pour l'application de service d'administration sont :

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator

Le service Live Update est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml.

Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server et WebSphere Application Server Network Deployment pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR du service Live Update est rép_install_mfp/MobileFirstServer/mfp-live-update.war. La racine de contexte du service Live Update doit être définie comme suit : /racine-contexteadmin/config. Par exemple, si la racine de contexte du service d'administration est /mfpadmin, la racine de contexte du service Live Update doit être /mfpadminconfig.

Source de données

Créez une source de données pour le service Live Update et mappez-la à jdbc/ConfigDS.

Rôles de sécurité

Le rôle configadmin est défini pour cette application.

Un utilisateur au moins doit être mappé à ce rôle. L'utilisateur et son mot de passe doivent être fournis dans les propriétés JNDI suivantes du service d'administration :

  • mfp.config.service.user
  • mfp.config.service.password

La console est conditionnée sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml du serveur d'applications.

Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server et WebSphere Application Server Network Deployment pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR de la console est rép_install_mfp/MobileFirstServer/mfp-admin-ui.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit généralement de /mfpconsole.

Propriétés JNDI obligatoires

Vous pouvez définir des propriétés JNDI depuis la console d'administration WebSphere Application Server. Sélectionnez Applications → Types d'application → Applications d'entreprise WebSphere → nom_application → Entrées d'environnement pour les modules Web et définissez les entrées.

Vous devez définir la propriété mfp.admin.endpoint. En général, la valeur de cette propriété est *://*:*/racine-contexteadmin.

Pour plus d'informations sur les propriétés JNDI, voir Propriétés JNDI pour MobileFirst Operations Console.

Rôles de sécurité

Les rôles de sécurité disponibles pour l'application sont :

  • mfpadmin
  • mfpdeployer
  • mfpmonitor
  • mfpoperator
Tout utilisateur mappé à un rôle de sécurité de la console doit également être mappé au même rôle de sécurité du service d'administration.

L'environnement d'exécution est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml.

Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server et WebSphere Application Server Network Deployment pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR de l'environnement d'exécution est rép_install_mfp/MobileFirstServer/mfp-server.war. Vous pouvez définir la racine de contexte de votre choix. Toutefois, il s'agit par défaut de /mfp.

Propriétés JNDI obligatoires

Vous pouvez définir des propriétés JNDI depuis la console d'administration WebSphere Application Server. Sélectionnez Applications → Types d'application → Applications d'entreprise WebSphere → nom_application → Entrées d'environnement pour les modules Web et définissez les entrées.

Vous devez définir la propriété mfp.authorization.server avec la valeur intégrée.
De même, définissez les propriétés JNDI ci-dessous pour permettre la communication JMX avec le service d'administration :

Sur WebSphere Application Server Network Deployment
  • mfp.admin.jmx.dmgr.host - Nom d'hôte du gestionnaire de déploiement.
  • mfp.admin.jmx.dmgr.port - Port SOAP du gestionnaire de déploiement.
  • mfp.topology.platform - Définissez la valeur WAS.
  • mfp.topology.clustermode - Définissez la valeur Cluster.
  • mfp.admin.jmx.connector - Définissez la valeur SOAP.
Sur un serveur WebSphere Application Server autonome
  • mfp.topology.platform - Définissez la valeur WAS.
  • mfp.topology.clustermode - Définissez la valeur Standalone.
  • mfp.admin.jmx.connector - Définissez la valeur SOAP.

Si MobileFirst Analytics est installé, vous devez définir les propriétés JNDI suivantes :

  • mfp.analytics.url
  • mfp.analytics.console.url
  • mfp.analytics.username
  • mfp.analytics.password

Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour l'environnement d'exécution de MobileFirst.

Ordre de lancement

L'application d'environnement d'exécution doit démarrer après l'application de service d'administration. Vous pouvez définir l'ordre dans la section Comportement de lancement. Par exemple, définissez l'ordre de lancement 1 pour le service d'administration et 2 pour l'environnement d'exécution.

Source de données

Créez une source de données pour l'environnement d'exécution et mappez-la à jdbc/mfpDS.

Le service push est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application. Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server et WebSphere Application Server Network Deployment pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR du service push est rép_install_mfp/PushService/mfp-push-service.war. Vous devez définir la racine de contexte /imfpush. Sinon, les appareils client ne pourront pas se connecter au service car la racine de contexte est codée en dur dans le logiciel SDK.

Propriétés JNDI obligatoires

Vous pouvez définir des propriétés JNDI depuis la console d'administration WebSphere Application Server. Sélectionnez Applications → Types d'application → Applications d'entreprise WebSphere → nom_application → Entrées d'environnement pour les modules Web et définissez les entrées.

Vous devez définir les propriétés suivantes :

  • mfp.push.authorization.server.url
  • mfp.push.authorization.client.id
  • mfp.push.authorization.client.secret
  • mfp.push.services.ext.security - La valeur doit être com.ibm.mfp.push.server.security.plugin.OAuthSecurityPlugin.
  • mfp.push.db.type - Pour une base de données relationnelle, la valeur doit être DB.

Si MobileFirst Analytics est configuré, définissez les propriétés JNDI suivantes :

  • mfp.push.analytics.endpoint
  • mfp.analytics.username
  • mfp.analytics.password
  • mfp.push.services.ext.analytics - La valeur doit être com.ibm.mfp.push.server.analytics.plugin.AnalyticsPlugin.

Pour plus d'informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour le service push de MobileFirst Server.

Source de données

Créez la source de données pour le service push et mappez-la à jdbc/imfPushDS.

Le composant des artefacts est conditionné sous forme d'application WAR en vue de son déploiement sur le serveur d'applications. Vous devez effectuer des configurations spécifiques pour cette application dans le fichier server.xml du serveur d'applications. Avant de continuer, consultez la section Installation manuelle sur WebSphere Application Server et WebSphere Application Server Network Deployment pour prendre connaissance des détails de configuration communs à tous les services.

Le fichier WAR pour ce composant est rép_install_mfp/MobileFirstServer/mfp-dev-artifacts.war. Vous devez définir la racine de contexte /mfp-dev-artifacts.

Installation d’un parc de serveurs

Vous pouvez installer votre parc de serveurs en exécutant des tâches Ant, avec l’outil de configuration de serveur ou manuellement.

Planification de la configuration d’un parc de serveurs

Pour planifier la configuration d’un parc de serveurs, choisissez le serveur d’applications, configurez les bases de données MobileFirst, et déployez les fichiers WAR des composants MobileFirst Server sur chaque serveur du parc de serveurs. Vous pouvez utiliser l’outil de configuration de serveur, des tâches Ant ou des opérations manuelles afin de configurer un parc de serveurs.

Si vous prévoyez d’installer un parc de serveurs, reportez-vous d’abord à Contraintes sur le service d’administration de MobileFirst Server, le service Live Update de MobileFirst Server et l’environnement d’exécution de MobileFirst, et en particulier à Topologie de parc de serveurs.

Dans Mobile Foundation, un parc de serveurs se compose de plusieurs serveurs d’applications autonomes qui ne sont pas fédérés ni administrés par le composant de gestion d’un serveur d’applications. MobileFirst Server fournit en interne un plug-in de parc de serveurs afin d’améliorer le serveur d’applications de sorte qu’il puisse faire partie d’un parc de serveurs.

Quand déclarer un parc de serveurs ?

Déclarez un parc de serveurs dans les cas suivants :

  • MobileFirst Server est installé sur plusieurs serveurs d’applications Tomcat.
  • MobileFirst Server est installé sur plusieurs serveurs WebSphere Application Server, mais pas sur WebSphere Application Server Network Deployment.
  • MobileFirst Server est installé sur plusieurs serveurs WebSphere Application Server Liberty.

Ne déclarez pas de parc de serveurs dans les cas suivants :

  • Votre serveur d’applications est autonome.
  • Plusieurs serveurs d’applications sont fédérés par WebSphere Application Server Network Deployment.

Eléments obligatoires pour déclarer un parc de serveurs

A chaque fois qu’une opération de gestion est effectuée par le biais de MobileFirst Operations Console ou de l’application de service d’administration de MobileFirst Server, elle doit être répliquée sur toutes les instances d’un environnement d’exécution. Par exemple, il peut s’agir d’une opération de gestion telle que le téléchargement d’une nouvelle version d’une application ou d’un adaptateur. La réplication est assurée via des appels JMX effectués par l’instance d’application de service d’administration qui gère l’opération. Le service d’administration doit contacter toutes les instances d’exécution dans le cluster. Dans les environnements répertoriés sous Quand déclarer un parc de serveurs ? ci-dessus, l’environnement d’exécution peut être contacté via JMX seulement si un parc de serveurs est configuré. Si un serveur est ajouté à un cluster alors qu’un parc de serveurs n’est pas configuré correctement, l’état de l’environnement d’exécution sur ce serveur sera incohérent après chaque opération de gestion et jusqu’à ce que l’environnement d’exécution soit redémarré.

Installation d’un parc de serveurs avec l’outil de configuration de serveur

Utilisez l’outil de configuration de serveur pour configurer chaque serveur du parc de serveurs conformément aux exigences du type unique de serveur d’applications qui est utilisé pour chaque membre du parc de serveurs.

Lorsque vous planifiez un parc de serveurs avec l’outil de configuration de serveur, créez d’abord des serveurs autonomes et configurez leurs magasins de clés de confiance respectifs de sorte qu’ils puissent communiquer les uns avec les autres de façon sécurisée. Ensuite, exécutez l’outil qui effectue les opérations suivantes :

  • Configuration de l’instance de base de données qui est partagée par les composants MobileFirst Server
  • Déploiement des composants MobileFirst Server sur chaque serveur
  • Modification de la configuration du serveur pour qu’il devienne membre d’un parc de serveurs

MobileFirst Server requiert la configuration de la connexion JMX sécurisée.

  1. Préparez les serveurs d'applications qui doivent être configurés en tant que membres du parc de serveurs.
    • Choisissez le type de serveur d'applications à utiliser pour configurer les membres du parc de serveurs. Mobile Foundation prend en charge les serveurs d'applications suivants dans les parcs de serveurs :
      • Profil complet de WebSphere Application Server
        Remarque : dans une topologie de parc de serveurs, vous ne pouvez pas utiliser le connecteur JMX RMI. Dans ce type de topologie, le connecteur SOAP seulement est pris en charge par Mobile Foundation.
      • Profil Liberty de WebSphere Application Server
      • Apache Tomcat
      Pour prendre connaissance des versions des serveurs d'applications prises en charge, voir Configuration système requise.
      Important : Mobile Foundation ne prend en charge que des parcs de serveurs homogènes. Un parc de serveurs est homogène lorsqu'il connecte le même type de serveur d'applications. Si vous tentez d'associer des types différents de serveur d'applications, le comportement à l'exécution risque d'être imprévisible. Par exemple, un parc de serveurs comportant un mélange de serveurs Apache Tomcat et de serveurs WebSphere Application Server (profil complet) constitue une configuration non valide.
    • Configurez autant de serveurs autonomes que vous voulez de membres dans le parc de serveurs.
    • Echangez les certificats de signataire entre tous les serveurs dans leurs magasins de clés de confiance respectifs.

      Cette étape est obligatoire pour les parcs de serveurs qui utilise le profil complet de WebSphere Application Server ou Liberty doit être activé. De plus, pour les parcs de serveurs Liberty, la même configuration LTPA doit être répliquée sur chaque serveur afin d'activer la fonction de connexion unique. Pour effectuer cette configuration, suivez les instructions présentées à l'étape 6 de la section Configuration manuelle d'un parc de serveurs.
  2. Exécutez l'outil de configuration de serveur pour chaque serveur du parc de serveurs. Tous les serveurs doivent partager les mêmes bases de données. Assurez-vous de sélectionner le type de déploiement Server farm deployment dans le panneau Application Server Settings. Pour plus d'informations sur l'outil, voir Exécution de l'outil de configuration de serveur.

Installation d’un parc de serveurs à l’aide de tâches Ant

Utilisez des tâches Ant pour configurer chaque serveur du parc de serveurs conformément aux exigences du type unique de serveur d’applications qui est utilisé pour chaque membre du parc de serveurs.

Lorsque vous planifiez un parc de serveurs à l’aide de tâches Ant, créez d’abord des serveurs autonomes et configurez leurs magasins de clés de confiance respectifs de sorte qu’ils puissent communiquer les uns avec les autres de façon sécurisée. Ensuite, exécutez des tâches Ant pour configurer l’instance de base de données qui est partagée par les composants MobileFirst Server. Enfin, exécutez des tâches Ant pour déployer les composants MobileFirst Server sur chaque serveur et modifier la configuration des serveurs pour qu’ils deviennent membres d’un parc de serveurs.

MobileFirst Server requiert la configuration de la connexion JMX sécurisée.

  1. Préparez les serveurs d'applications qui doivent être configurés en tant que membres du parc de serveurs.
    • Choisissez le type de serveur d'applications à utiliser pour configurer les membres du parc de serveurs. Mobile Foundation prend en charge les serveurs d'applications suivants dans les parcs de serveurs :
      • Profil complet de WebSphere Application Server. Remarque : dans une topologie de parc de serveurs, vous ne pouvez pas utiliser le connecteur JMX RMI. Dans ce type de topologie, le connecteur SOAP seulement est pris en charge par Mobile Foundation.
      • Profil Liberty de WebSphere Application Server
      • Apache Tomcat
      Pour prendre connaissance des versions des serveurs d'applications prises en charge, voir Configuration système requise.
      Important : Mobile Foundation ne prend en charge que des parcs de serveurs homogènes. Un parc de serveurs est homogène lorsqu'il connecte le même type de serveur d'applications. Si vous tentez d'associer des types différents de serveur d'applications, le comportement à l'exécution risque d'être imprévisible. Par exemple, un parc de serveurs comportant un mélange de serveurs Apache Tomcat et de serveurs WebSphere Application Server (profil complet) constitue une configuration non valide.
    • Configurez autant de serveurs autonomes que vous voulez de membres dans le parc de serveurs.

      Chacun de ces serveurs autonomes doit communiquer avec la même base de données. Vous devez vous assurer qu'aucun port utilisé par l'un de ces serveurs n'est utilisé par ailleurs par un autre serveur configuré sur le même hôte. Cette contrainte concerne les ports utilisés par les protocoles HTTP, HTTPS, REST, SOAP et RMI.

      Le service d'administration de MobileFirst Server, le service Live Update de MobileFirst Server et un ou plusieurs environnements d'exécution de MobileFirst doivent être déployés sur chacun de ces serveurs.

      Pour plus d'informations sur la configuration d'un serveur, voir Contraintes sur le service d'administration de MobileFirst Server, le service Live Update de MobileFirst Server et l'environnement d'exécution de MobileFirst.
    • Echangez les certificats de signataire entre tous les serveurs dans leurs magasins de clés de confiance respectifs.

      Cette étape est obligatoire pour les parcs de serveurs qui utilise le profil complet de WebSphere Application Server ou Liberty doit être activé. De plus, pour les parcs de serveurs Liberty, la même configuration LTPA doit être répliquée sur chaque serveur afin d'activer la fonction de connexion unique. Pour effectuer cette configuration, suivez les instructions présentées à l'étape 6 de la section Configuration manuelle d'un parc de serveurs.
  2. Configurez la base de données pour le service d'administration, le service Live Update et l'environnement d'exécution.
    • Choisissez la base de données à utiliser ainsi que le fichier Ant permettant de créer et de configurer la base de données dans le répertoire rép_install_mfp/MobileFirstServer/configuration-samples :
      • Pour DB2 , utilisez create-database-db2.xml.
      • Pour MySQL, utilisez create-database-mysql.xml.
      • Pour Oracle, utilisez create-database-oracle.xml.
      Remarque : n'utilisez pas la base de données Derby dans une topologie de parc de serveurs car elle n'autorise qu'une seule connexion à la fois.
    • Editez le fichier Ant et entrez toutes les propriétés requises pour la base de données.

      Pour activer la configuration de la base de données utilisée par les composants MobileFirst Server, définissez les valeurs des propriétés suivantes :
      • Associez mfp.process.admin à la valeur true afin de configurer la base de données pour le service d'administration et le service Live Update.
      • Associez mfp.process.runtime à la valeur true afin de configurer la base de données pour l'environnement d'exécution.
    • Exécutez les commandes ci-dessous depuis le répertoire rép_install_mfp/MobileFirstServer/configuration-samplesfichier-ant-création-base-données.xml doit être remplacé par le nom de fichier Ant réel de votre choix : rép_install_mfp/shortcuts/ant -f fichier-ant-création-base-données.xml admdatabases et rép_install_mfp/shortcuts/ant -f fichier-ant-création-base-données.xml rtmdatabases.

      Comme les bases de données MobileFirst Server sont partagées entre les serveurs d'application dans un parc de serveurs, ces deux commandes ne doivent être exécutées qu'une seule fois, quel que soit le nombre de serveurs dans le parc de serveurs.
    • Si vous voulez installer un autre environnement d'exécution, vous devez configurer une autre base de données avec un autre nom ou un autre schéma de base de données. Pour ce faire, éditez le fichier Ant, modifiez les propriétés et exécutez la commande suivante une seule fois, quel que soit le nombre de serveurs dans le parc de serveurs : rép_install_mfp/shortcuts/ant -f fichier-ant-création-base-données.xml rtmdatabases.
  3. Déployez le service d'administration, le service Live Update et l'environnement d'exécution sur les serveurs et configurez ces serveurs comme membres d'un parc de serveurs.
    • Choisissez le fichier Ant qui correspond à votre serveur d'applications et à votre base de données dans le répertoire rép\_install\_mfp/MobileFirstServer/configuration-samples afin de déployer le service d'administration, le service Live Update et l'environnement d'exécution sur les serveurs.

      Par exemple, sélectionnez le fichier configure-liberty-db2.xml pour un déploiement sur le srveur Liberty avec la base de données DB2. Effectuez autant de copies de ce fichier que vous voulez de membres dans le parc de serveurs.

      Remarque : Conservez ces fichiers après la configuration, car ils peuvent être réutilisés pour la mise à niveau des composants MobileFirst Server déjà déployés ou pour les désinstaller sur chaque membre du parc de serveurs.
    • Editez chaque copie du fichier Ant, entrez les propriétés de base de données indiquées à l'étape 2, et entrez également les autres propriétés requises pour le serveur d'applications.

      Pour configurer le serveur comme membre d'un parc de serveurs, définissez les valeurs des propriétés suivantes :
      • Associez mfp.farm.configure à la valeur true.
      • mfp.farm.server.id : identificateur que vous définissez pour ce membre de parc de serveurs. Veillez à ce que chaque serveur dans le parc de serveurs possède un identificateur unique. Si deux serveurs dans le parc de serveurs possèdent le même identificateur, le comportement du parc de serveurs risque d'être imprévisible.
      • mfp.config.service.user : nom d'utilisateur indiqué pour accéder au service Live Update. Il doit être identique pour tous les membres du parc de serveurs.
      • mfp.config.service.password : mot de passe indiqué pour accéder au service Live Update. Il doit être identique pour tous les membres du parc de serveurs.
      Pour permettre le déploiement des fichiers WAR des composants MobileFirst Server sur le serveur, définissez les valeurs des propriétés suivantes :
      • Associez mfp.process.admin à la valeur true pour déployer les fichiers WAR du service d'administration et du service Live Update.
      • Associez mfp.process.runtime à la valeur true pour déployer le fichier WAR de l'environnement d'exécution.

      Remarque : Si vous envisagez d'installer plusieurs exécutions sur les serveurs du parc de serveurs, spécifiez le l'ID d'attribut et définissez une valeur qui doit être unique pour chaque exécution dans les tâches Ant installmobilefirstruntime, updatemobilefirstruntime et uninstallmobilefirstruntime.
      Par exemple,
      <target name="rtminstall">
          <installmobilefirstruntime execute="true" contextroot="/runtime1" id="rtm1">
    • Pour chaque serveur, exécutez les commandes ci-dessous, où fichier-ant-configuration-base-données-serveur-app.xml doit être remplacé par le nom de fichier Ant réel de votre choix : rép_install_mfp/shortcuts/ant -f fichier-ant-configuration-base-données-serveur-app.xml adminstall et rép_install_mfp/shortcuts/ant -f fichier-ant-configuration-base-données-serveur-app.xml rtminstall.

      Ces commandes exécutent les tâches Ant installmobilefirstadmin et installmobilefirstruntime. Pour plus d'informations sur ces tâches, voir Tâches Ant pour l'installation de MobileFirst Operations Console, des artefacts de MobileFirst Server, et des services d'administration et Live Update de MobileFirst Server et Tâches Ant pour l'installation des environnements d'exécution de MobileFirst.
    • Si vous voulez installer un autre environnement d'exécution, procédez comme suit :
      • Effectuez une copie du fichier Ant que vous avez configuré à l'étape 3.b.
      • Editez la copie, définissez une racine de contexte distincte et définissez une valeur pour l'attribut id de installmobilefirstruntime, updatemobilefirstruntime et uninstallmobilefirstruntime qui est différente de celle définie dans l'autre configuration d'environnement d'exécution.
      • Exécutez la commande suivante sur chaque serveur du parc de serveurs où fichier_ant_configuration_base_données_serveur_app2.xml doit être remplacé par le nom réel du fichier Ant qui est édité : rép_install_mfp/shortcuts/ant -f >fichier_ant_configuration_base_données_serveur_app2.xml rtminstall.
      • Répétez cette étape pour chaque serveur du parc de serveurs.
  4. Redémarrez tous les serveurs.

Configuration manuelle d’un parc de serveurs

Vous devez configurer chaque serveur du parc de serveurs conformément aux exigences du type unique de serveur d’applications qui est utilisé pour chaque membre du parc de serveurs.

Lorsque vous planifiez un parc de serveurs, créez d’abord des serveurs autonomes qui communiquent avec la même instance de base de données. Ensuite, modifiez la configuration de ces serveurs pour qu’ils deviennent membres d’un parc de serveurs.

  1. Choisissez le type de serveur d'applications à utiliser pour configurer les membres du parc de serveurs. Mobile Foundation prend en charge les serveurs d'applications suivants dans les parcs de serveurs :
    • Profil complet de WebSphere Application Server
      Remarque : dans une topologie de parc de serveurs, vous ne pouvez pas utiliser le connecteur JMX RMI. Dans ce type de topologie, le connecteur SOAP seulement est pris en charge par Mobile Foundation.
    • Profil Liberty de WebSphere Application Server
    • Apache Tomcat
    Pour prendre connaissance des versions des serveurs d'applications prises en charge, voir Configuration système requise.
    Important : Mobile Foundation ne prend en charge que des parcs de serveurs homogènes. Un parc de serveurs est homogène lorsqu'il connecte le même type de serveur d'applications. Si vous tentez d'associer des types différents de serveur d'applications, le comportement à l'exécution risque d'être imprévisible. Par exemple, un parc de serveurs comportant un mélange de serveurs Apache Tomcat et de serveurs WebSphere Application Server (profil complet) constitue une configuration non valide.
  2. Choisissez la base de données à utiliser. Vous pouvez choisir :
    • DB2
    • MySQL
    • Oracle
    Les bases de données MobileFirst Server sont partagées entre les serveurs d'applications d'un parc de serveurs, ce qui signifie que :
    • Vous ne créez la base de données qu'une fois, quel que soit le nombre de serveurs dans le parc de serveurs.
    • Vous ne pouvez pas utiliser la base de données Derby dans une topologie de parc de serveurs car elle n'autorise qu'une seule connexion à la fois.
    Pour plus d'informations sur les bases de données, voir Configuration des bases de données.
  3. Configurez autant de serveurs autonomes que vous voulez de membres dans le parc de serveurs.
    • Chacun de ces serveurs autonomes doit communiquer avec la même base de données. Vous devez vous assurer qu'aucun port utilisé par l'un de ces serveurs n'est utilisé par ailleurs par un autre serveur configuré sur le même hôte. Cette contrainte concerne les ports utilisés par les protocoles HTTP, HTTPS, REST, SOAP et RMI.
    • Le service d'administration de MobileFirst Server, le service Live Update de MobileFirst Server et un ou plusieurs environnements d'exécution de MobileFirst doivent être déployés sur chacun de ces serveurs.
    • Lorsque chacun de ces serveurs fonctionne correctement dans une topologie autonome, vous pouvez les transformer en membres d'un parc de serveurs.
  4. Arrêtez tous les serveurs devant devenir membres du parc de serveurs.
  5. Configurez chaque serveur de façon appropriée pour le type de serveur d'application.
    Vous devez définir correctement certaines propriétés JNDI. Dans une topologie de parc de serveurs, les valeurs des propriétés JNDI mfp.config.service.user et mfp.config.service.password doivent être identiques pour tous les membres du parc de serveurs. Pour Apache Tomcat, vous devez aussi vérifier que les arguments JVM sont définis correctement.
    • Profil Liberty de WebSphere Application Server
      Dans le fichier server.xml, définissez les propriétés JNDI affichées dans l'exemple de code ci-dessous.
      <jndiEntry jndiName="mfp.topology.clustermode" value="Farm"/>
      <jndiEntry jndiName="mfp.admin.serverid" value="membre_parc_1"/>
      <jndiEntry jndiName="mfp.admin.jmx.user" value="monUtilisateurConnecteurREST"/>
      <jndiEntry jndiName="mfp.admin.jmx.pwd" value="motdepasse-utilisateur-connecteur-rest"/>
      <jndiEntry jndiName="mfp.admin.jmx.host" value="93.12.0.12"/>
      <jndiEntry jndiName="mfp.admin.jmx.port" value="9443"/>
      Ces propriétés doivent être associées à des valeurs appropriées :
      • mfp.admin.serverid : identificateur que vous avez défini pour ce membre de parc de serveurs. Cet identificateur doit être unique parmi tous les membres du parc de serveurs.
      • mfp.admin.jmx.user et mfp.admin.jmx.pwd : ces valeurs doivent correspondre aux données d'identification d'un utilisateur telles que déclarées dans l'élément administrator-role.
      • mfp.admin.jmx.host : pour ce paramètre, définissez l'adresse IP ou le nom d'hôte qui est utilisé par les membres distants pour accéder à ce serveur. Vous ne pouvez donc pas indiquer localhost. Ce nom d'hôte est utilisé par les autres membres du parc de serveurs et doit être accessible pour tous les membres du parc de serveurs.
      • mfp.admin.jmx.port : pour ce paramètre, définissez le port HTTPS du serveur qui est utilisé pour la connexion REST JMX. La valeur se trouve dans l'élément httpEndpoint du fichier server.xml.
    • Apache Tomcat
      Modifiez le fichier conf/server.xml pour définir les propriétés JNDI ci-dessous dans le contexte de service d'administration et dans chaque contexte d'exécution.
      <Environment name="mfp.topology.clustermode" value="Farm" type="java.lang.String" override="false"/>
      <Environment name="mfp.admin.serverid" value="membre_parc_1" type="java.lang.String" override="false"/>
      La propriété mfp.admin.serverid doit avoir pour valeur l'identificateur que vous avez défini pour ce membre de parc de serveurs. Cet identificateur doit être unique parmi tous les membres du parc de serveurs.
      Vous devez vous assurer que l'argument JVM -Djava.rmi.server.hostname est défini sur l'adresse IP ou le nom d'hôte utilisé par les membres distants pour accéder à ce serveur. Vous ne pouvez donc pas indiquer localhost. De plus, assurez-vous que l'argument JVM -Dcom.sun.management.jmxremote.port ait pour valeur un port qui n'est pas déjà utilisé pour activer les connexions JMX RMI. Les deux arguments sont définis dans la variable d'environnement CATALINA_OPTS.
    • Profil complet de WebSphere Application Server
      Vous devez déclarer les propriétés JNDI suivantes dans le service d'administration et dans chaque application déployée sur le serveur.
      • mfp.topology.clustermode
      • mfp.admin.serverid
      Dans la console WebSphere Application Server :
      • Sélectionnez Applications → Types d'application → Applications d'entreprise WebSphere.
      • Sélectionnez l'application de service d'administration.
      • Dans Propriétés du module Web, cliquez sur Entrées d'environnement pour les modules Web pour afficher les propriétés JNDI.
      • Définissez les valeurs des propriétés ci-dessous.
        • Associez mfp.topology.clustermode à la valeur Farm.
        • Associez mfp.admin.serverid à l'identificateur que vous avez choisi pour ce membre de parc de serveurs. Cet identificateur doit être unique parmi tous les membres du parc de serveurs.
        • Associez mfp.admin.jmx.user à un nom d'utilisateur ayant accès au connecteur SOAP.
        • Associez mfp.admin.jmx.pwd au mot de passe de l'utilisateur déclaré dans mfp.admin.jmx.user.
        • Associez mfp.admin.jmx.port à la valeur du port SOAP.
      • Vérifiez que mfp.admin.jmx.connector a pour valeur SOAP.
      • Cliquez sur OK et sauvegardez la configuration.
      • Apportez les mêmes modifications pour chaque application d'environnement d'exécution MobileFirst déployée sur le serveur.
  6. Echangez les certificats serveur entre les membres du parc de serveurs dans leurs magasins de clés de confiance respectifs. L'échange des certificats serveur dans les magasins de clés de confiance est obligatoire pour les parcs de serveurs qui utilisent le profil complet et le profil Liberty de WebSphere Application Server car dans ces parcs de serveurs, la communication entre les serveurs est sécurisée par SSL.
    • Profil Liberty de WebSphere Application Server
      Vous pouvez configurer le magasin de clés de confiance en utilisant des utilitaires IBM, comme Keytool ou iKeyman.
      • Pour plus d'informations sur Keytool, voir Keytool dans IBM SDK, Java Technology Edition.
      • Pour plus d'informations sur iKeyman, voir iKeyman dans IBM SDK, Java Technology Edition.
      Les emplacements du magasin de clés et du magasin de clés de confiance sont définis dans le fichier server.xml. Voir les attributs keyStoreRef et trustStoreRef dans Attributs de configuration SSL. Par défaut, le magasin de clés du profil Liberty est ${server.config.dir}/resources/security/key.jks. Si la référence du magasin de clés de confiance est manquante ou n'est pas définie dans le fichier server.xml, le magasin de clés de confiance spécifié par keyStoreRef est utilisé. Le serveur utilise le magasin de clés par défaut et le fichier est créé à la première exécution du serveur. Dans ce cas, un certificat par défaut est créé avec une période de validité de 365 jours. En production, vous pouvez envisager d'utiliser votre propre certificat (y compris les certificats intermédiaires si nécessaire) ou de changer la date d'expiration du certificat généré.
      Remarque : pour confirmer l'emplacement du magasin de clés de confiance, ajoutez la déclaration suivante dans le fichier server.xml :
      <logging traceSpecification="SSL=all:SSLChannel=all"/>
      Enfin, démarrez le serveur et recherchez les lignes contenant com.ibm.ssl.trustStore dans le fichier ${wlp.install.dir}/usr/servers/nom_serveur/logs/trace.log.
      • Importez les certificats publics des autres serveurs du parc de serveurs dans le magasin de clés de confiance qui est référencé par le fichier de configuration server.xml du serveur. Le tutoriel Installation de MobileFirst Server en mode graphique explique comment échanger les certificats entre deux serveurs Liberty dans un parc de serveurs. Pour plus d'informations, voir l'étape 5 de la section Création d'un parc de deux serveurs Liberty exécutant MobileFirst Server.
      • Redémarrez chaque instance du profil Liberty de WebSphere Application Server pour appliquer la configuration des paramètres de sécurité. Les étapes ci-après sont requises pour que la connexion unique fonctionne.
      • Démarrez un membre du parc de serveurs. Dans la configuration LTPA par défaut, une fois que le serveur Liberty a démarré, un magasin de clés LTPA ${wlp.user.dir}/servers/nom_serveur/resources/security/ltpa.keys est généré.
      • Copiez le fichier ltpa.keys dans le répertoire ${wlp.user.dir}/servers/nom_serveur/resources/security de chaque membre du parc de serveurs afin de répliquer les magasins de clés LTPA sur les membres du parc de serveurs. Pour plus d'informations sur la configuration LTPA, voir Configuration de l'authentification LTPA dans le profil Liberty.
    • Profil complet de WebSphere Application Server
      Configurez le magasin de clés de confiance dans la console d'administration de WebSphere Application Server.
      • Connectez-vous à la console d'administration WebSphere Application Server.
      • Sélectionnez Sécurité → Certificat SSL et gestion des clés.
      • Dans Articles liés, sélectionnez Magasins de clés et certificats.
      • Dans la zone Utilisations des magasins de clés, assurez-vous que l'option Fichiers de clés SSL est sélectionnée. A présent, vous pouvez importer les certificats de tous les autres serveurs dans le parc de serveurs.
      • Cliquez sur NodeDefaultTrustStore.
      • Dans Propriétés supplémentaires, sélectionnez Certificats de signataire.
      • Cliquez sur Extraire d'un port. A présent, vous pouvez entrer les détails de communication et de sécurité des autres serveurs dans le parc de serveurs. Suivez les étapes ci-dessous pour chaque autre membre du parc de serveurs.
      • Dans la zone Hôte, entrez le nom d'hôte ou l'adresse IP du serveur.
      • Dans la zone Port, entrez le port de transport HTTPS (SSL).
      • Dans Configuration SSL pour une connexion de communication sortante, sélectionnez NodeDefaultSSLSettings.
      • Dans la zone Alias, entrez un alias pour ce certificat de signataire.
      • Cliquez sur Récupérer les informations du signataire.
      • Vérifiez les informations qui sont extraites depuis le serveur distant, puis cliquez sur OK.
      • Cliquez sur Sauvegarder.
      • Redémarrez le serveur.

Vérification de la configuration du parc de serveurs

Le but de cette tâche consiste à vérifier le statut des membres du parc de serveurs et à déterminer si le parc de serveurs est configuré correctement.

  1. Démarrez tous les serveurs du parc de serveurs.
  2. Accédez à MobileFirst Operations Console, par exemple en entrant http://nom_serveur:port/mfpconsole ou https://nom_hôte:port_sécurisé/mfpconsole pour HTTPS. La barre de navigation de la console contient un menu supplémentaire intitulé Noeuds de parc de serveurs.
  3. Cliquez sur Noeuds de parc de serveurs pour accéder à la liste des membres de parc de serveurs enregistrés et à leur statut. Dans l’exemple ci-dessous, le noeud MembreParc2 est considéré comme arrêté, ce qui indique que ce serveur est probablement défaillant et qu’il requiert une maintenance.

Statut des noeuds de parc de serveurs dans la MobileFirst Operations Console

Cycle de vie d’un noeud de parc de serveurs

Vous pouvez configurer la fréquence des signaux de présence et la valeur de délai permettant de détecter les problèmes de serveur possibles pour les membres du parc de serveurs en déclenchant la modification du statut d’un noeud affecté.

Enregistrement et surveillance des serveurs en tant que noeuds de parc de serveurs

Lorsqu’un serveur configuré en tant que noeud de parc de serveurs est démarré, son service d’administration l’enregistre automatiquement comme nouveau membre du parc de serveurs. Lorsqu’un membre de parc de serveurs est arrêté, son enregistrement dans le parc de serveurs est annulé automatiquement.

Un mécanisme de signaux de présence existe pour assurer le suivi des membres de parc de serveurs qui ne répondent plus, en raison d’une panne de courant ou d’une défaillance du serveur par exemple. Dans ce mécanisme de signaux de présence, les environnements d’exécution de MobileFirst envoient régulièrement un signal de présence aux services d’administration de MobileFirst à une fréquence spécifiée. Si le service d’administration de MobileFirst détermine que le temps écoulé depuis le dernier signal de présence envoyé par un membre du parc de serveurs est trop long, il considère que le membre du parc de serveurs est arrêté.

Les membres du parc de serveurs qui sont considérés comme arrêtés n’envoient plus de demandes aux applications mobiles.

Le fait qu’un ou plusieurs noeuds soient arrêtés n’empêche par les autres membres du parc de serveurs d’envoyer correctement des demandes aux applications mobiles ni d’accepter de nouvelles opérations de gestion qui sont déclenchées via MobileFirst Operations Console.

Configuration de la fréquence des signaux de présence et de la valeur de délai

Vous pouvez configurer la fréquence des signaux de présence et la valeur de délai en définissant les propriétés JNDI suivantes :

  • mfp.admin.farm.heartbeat
  • mfp.admin.farm.missed.heartbeats.timeout


Pour plus d’informations sur les propriétés JNDI, voir Liste des propriétés JNDI pour le MobileFirst Serverservice d’administration.

Last modified on October 04, 2017