Installation de MobileFirst Server sur un serveur d'applications
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.
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 :
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 :
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 :
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 :
Pour une configuration simple, ajoutez les options suivantes dans CATALINA_OPTS :
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 :
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.
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.
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.
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.
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 :
liberty_install_dir/bin/productInfo featureInfo
Remarque : Vérifiez que la sortie de la commande contient 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 :
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.
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.
Le programme de lancement ServerConfigurationTool (SCT) sur Mac OS est chargé d’installer l’environnement d’exécution Java SE 6 existant. Vous pouvez voir le message ci-dessous lors du démarrage du programme de lancement SCT sur Mac OS.
Pour contourner cette instruction, vous pouvez suivre l’une des approches suivantes et exécuter SCT à l’aide de l’exécutable correspondant sans avoir à installer l’environnement d’exécution Java SE 6.
Approche 1
Cliquez avec le bouton droit de la souris sur le programme de lancement ServerConfigurationTool.
Sélectionnez Show Package Contents
Cliquez sur Contents > MacOS.
Cliquez sur l’exécutable ServerConfigurationTool pour lancer SCT.
Approche 2
Java SE 8 et Java SE6 peuvent tous deux être installés sur votre ordinateur.
Lorsque la fenêtre en incrustation s’affiche lorsque vous utilisez le programme de lancement SCT, cliquez sur More Info.
Vous serez redirigé vers le site de support d’Apple. Vous y trouverez des informations supplémentaires sur la manière d’obtenir l’environnement d’exécution Java SE 6.
Suivez les instructions d’installation de Java SE 6 et exécutez le programme de lancement SCT.
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 :
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.
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.
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.
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.
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.
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.
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.
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 :
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é.
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.
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.
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.
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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.
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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 :
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
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.
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 :
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.
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.
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 :
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 :
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.
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 :
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 :
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.
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 :
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.
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 :
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 :
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 :
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.
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 :
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 :
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 :
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.
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 :
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.
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
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 :
Connectez-vous à la console d’administration WebSphere Application Server.
Sélectionnez Sécurité → Sécurité globale. Assurez-vous que l’option Activer la sécurité administrative est sélectionnée.
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.
Cliquez sur OK.
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 :
Connectez-vous à la console d’administration WebSphere Application Server.
Sélectionnez Serveurs → Types de serveurs → Serveurs d’applications WebSphere et cliquez sur le serveur qui est utilisé pour Mobile Foundation.
Si la règle de chargeur de classe est Plusieurs, ne faites rien.
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.
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 :
Cliquez sur l’application MobileFirst Server. Par défaut, le nom de l’application est le nom du fichier WAR.
Dans la section Propriétés du détail, cliquez sur le lien Chargement de classes et détection de mise à jour.
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).
Cliquez sur OK.
Dans la section Modules, cliquez sur le lien Gestion des modules.
Cliquez sur le module.
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).
Cliquez sur OK deux fois pour confirmer la sélection et revenir au panneau Configuration de l’application.
Cliquez sur Sauvegarder pour sauvegarder les modifications.
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.
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 :
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 :
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.
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 :
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.
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.
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.
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 :
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.
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.
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.
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.
Echangez les certificats de signataire entre tous les serveurs dans leurs magasins de clés de confiance respectifs.
Remarque : Cette étape est obligatoire pour les parcs de serveurs qui utilisent le profil complet de WebSphere Application Server ou Liberty, car la sécurité doit y être activée. 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.
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.
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.
Echangez les certificats de signataire entre tous les serveurs dans leurs magasins de clés de confiance respectifs.
Remarque : Cette étape est obligatoire pour les parcs de serveurs qui utilisent le profil complet de WebSphere Application Server ou Liberty, car la sécurité doit y être activée. 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
.
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-samples où fichier-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.
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 serveur 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,
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.
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.
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.
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.
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.
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.
Arrêtez tous les serveurs devant devenir membres du parc de serveurs.
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.
Ces propriétés doivent être définies avec les 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.
La propriété mfp.admin.serverid doit être définie sur l'identificateur que vous avez spécifié pour le membre de ce 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.
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.
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 : Si vous voulez confirmer l'emplacement du magasin de clés de confiance, vous pouvez le faire en ajoutant la déclaration suivante au fichier server.xml :
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.
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.
Echangez les certificats de signataire entre tous les serveurs dans leurs magasins de clés de confiance respectifs.
Remarque : Cette étape est obligatoire pour les parcs de serveurs qui utilisent le profil complet de WebSphere Application Server ou Liberty, car la sécurité doit y être activée. 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 appliquer cette configuration, effectuez les étapes ci-dessous.
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.
Démarrez tous les serveurs du parc de serveurs.
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.
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.
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 :
L’environnement d’exécution de Mobile Foundation fait appel aux planificateurs Quartz pour réaliser certaines activités planifiées.
Le planificateur d’exécution de Mobile Foundation effectue les activités suivantes :
Suivi des licences
Création de journaux d’audit
L’exécution du planificateur est contrôlée par les deux propriétés JNDI suivantes :
mfp.licenseTracking.enabled
mfp.purgedata.enabled (disponible à partir du correctif temporaire 8.0.0.0-MFPF-IF201812191602-CDUpdate-04)
Ces propriétés JNDI sont activées par défaut pour tous les serveurs d’application pris en charge.
Remarque : Si vous exécutez Mobile Foundation sous WebSphere Application Server, la propriété JNDI mfp.licenseTracking.enabled a besoin d’être activée à l’aide de la valeur true dans les entrées d’environnement d’exécution de la console WAS.
Suivi des licences
Le suivi des licences assure le suivi des indicateurs relatifs aux règles de licence, tels que les appareils client actifs, les appareils adressables et les applications installées. Ces informations permettent de déterminer si l’utilisation actuelle de Mobile Foundation respecte les niveaux d’autorisation de licence, et peuvent empêcher de potentielles violations de licence. Le suivi des licences aide à mettre les appareils qui n’accèdent plus au serveur Mobile Foundation hors service et à archiver et supprimer les anciens enregistrements de MFP_PERSISTENT_DATA.
Le tableau ci-dessous répertorie les propriétés JNDI liées au suivi des licences.
Propriété JNDI
Description
mfp.device.decommissionProcessingInterval
Définit la fréquence (en secondes) à laquelle la tâche de déclassement est exécutée. Valeur par défaut : 86400 (un jour).
mfp.device.decommission.when
Nombre de jours d’inactivité au terme desquels un appareil client est déclassé par la tâche de déclassement d’appareil. Valeur par défaut : 90 jours.
mfp.device.archiveDecommissioned.when
Nombre de jours d’inactivité au terme desquels un appareil client déclassé est archivé. Cette tâche écrit les appareils client déclassés dans un fichier archive. Les appareils client archivés sont écrits dans un fichier du répertoire home\devices_archive du serveur Mobile Foundation. Le nom du fichier contient l’horodatage de création du fichier archive. Valeur par défaut : 90 jours.
mfp.licenseTracking.enabled
Valeur utilisée pour activer ou désactiver le suivi des licences dans IBM Mobile Foundation. Pour améliorer les performances, vous pouvez désactiver le suivi des licences lorsqu’IBM Mobile Foundation n’exécute que des applications Business-to-Consumer (B2C). Lorsque le suivi des appareils est désactivé, les rapports de licence sont également désactivés et aucune mesure de licence n’est générée. Les valeurs possibles sont true (valeur par défaut) et false.
Veuillez consulter les rubriques ci-dessous pour en savoir plus sur le suivi des licences.
Le planificateur s’exécute huit heures après le démarrage d’un serveur. Autrement dit, si les serveurs sont démarrés à 23 heures ce jour, le planificateur ne s’exécutera pas à 01h00 (heure d’exécution par défaut du planificateur) mais à 08h00, le lendemain. L’écart entre le démarrage d’un serveur et l’exécution du planificateur est de huit heures.
Démarrage du correctif temporaire 8.0.0.0-MFPF-IF201907091643 l’écart entre le démarrage d’un serveur et l’exécution du planificateur est de quatre heures et non de huit heures.
La nouvelle propriété mfp.scheduler.startHour est également introduite. Celle-ci permet au client de choisir l’heure d’exécution du planificateur au lieu de la valeur par défaut (01h00). La propriété peut avoir une valeur comprise entre un et 23. Elle permet ainsi au client de régler le démarrage du planificateur aux heures les moins chargées et garantit que le planificateur s’exécute malgré un démarrage de serveur quotidien. Si un client redémarre ses serveurs tous les jours à 01h00, il peut définir la propriété mfp.scheduler.startHour sur 5. L’écart de quatre heures est conservé et le planificateur s’exécutera à 05h00.
Nous vous conseillons de laisser le suivi des licences désactivé, car les activités associées entraînent une utilisation intensive de la base de données. Seuls les clients utilisant le modèle de licence pour les appareils adressables Mobile Foundation ont besoin d’activer le suivi des licences.
Les clients qui n’ont pas activé le suivi des licences peuvent utiliser la fonctionnalité de purge pour supprimer les anciens enregistrements et assurer la maintenance des tables MFP_PERSISTENT_DATA et MFP_TRANSIENT_DATA.
Création de journaux d’audit
Le suivi des licences enregistre les dernières données de licence et d’exécution dans la table d’exécution Mobile Foundation LICENSE_TERMS. Le journal d’audit génère un journal basé sur l’entrée la plus récente de la table. Les rapports sont disponibles au format de fichier .slmtag dans le dossier des journaux sous le répertoire d’installation du serveur.
Désactivation de la mise à jour Quartz
L’environnement d’exécution de Mobile Foundation regroupe les bibliothèques requises, dont quelques bibliothèques tierces. Mobile Foundation fait appel aux planificateurs de tâches Quartz et inclut quartz2.2.0.jar.
Quartz contient une fonctionnalité de recherche de mises à jour qui se connecte au serveur afin de vérifier si une nouvelle version de Quartz est disponible au téléchargement. La vérification s’exécute de manière asynchrone et n’a pas d’incidence sur le temps de démarrage/d’initialisation de Quartz. Elle échoue si la connexion ne peut pas être établie. Si la vérification s’exécute et qu’une mise à jour est détectée, celle-ci apparaît comme disponible dans les journaux de Quartz.
Vous pouvez désactiver la recherche de mises à jour en utilisant l’indicateur org.quartz.scheduler.skipUpdateCheck = true. Le déploiement Liberty de Mobile Foundation crée un fichier jvm.options et lors du déploiement à l’aide de l’outil de configuration de serveur, le fichier jvm.options créé indiquera cette propriété à partir du correctif temporaire 8.0.0.0-MFPF-IF201909190904. Pour les correctifs temporaires antérieurs, vous pouvez ajouter cette propriété dans le fichier jvm.options.
Dans le cadre des déploiements de WebSphere Application Server (WAS), la propriété JNDI ci-dessus doit être ajoutée à la propriété d’environnement de l’application Mobile Foundation via la console d’administration WAS.
Inclusive terminology note: The Mobile First Platform team is making changes to support
the IBM® initiative to replace racially biased and other discriminatory language in our code and content
with more inclusive language. While IBM values the use of inclusive language, terms that are outside of
IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other
industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the
documentation to reflect those changes.
