Configuration de MobileFirst Server

Présentation

Déterminez votre stratégie de sauvegarde et de récupération, optimisez la configuration de votre serveur MobileFirst Server et appliquez des restrictions d’accès et des options de sécurité.

Aller à

• Points de terminaison du serveur de production de MobileFirst Server
• Configuration de MobileFirst Server pour activer TLS V1.2
• Configuration de l’authentification d’utilisateur pour l’administration de MobileFirst Server
• Liste des propriétés JNDI des applications Web de MobileFirst Server
• Configuration des sources de données
• Configuration des mécanismes de journalisation et de surveillance
• Configuration de plusieurs environnements d’exécution
• Configuration du suivi des licences
• Configuration SSL WebSphere Application Server et adaptateurs HTTP

Points de terminaison du serveur de production de MobileFirst Server

Vous pouvez créer des listes blanches et des listes noires pour les points de terminaison du serveur IBM MobileFirst Server.

Remarque : Des informations sur les URL qui sont exposées par Mobile Foundation sont fournies comme instructions. Les organisations doivent s’assurer que les URL sont testées dans une infrastructure d’entreprise, en fonction de ce qui a été activé pour les listes blanches et les listes noires.

Configuration de MobileFirst Server pour activer TLS V1.2

Pour que MobileFirst Server communique avec des appareils prenant en charge uniquement TLS (Transport Layer Security) v1.2, parmi les protocoles SSL, vous devez exécuter les instructions décrites ci-après.

Les étapes de configuration de MobileFirst Server pour activer TLS V1.2 dépendent de la façon dont MobileFirst Server se connecte aux appareils.

• Si MobileFirst Server se trouve derrière un proxy inverse qui déchiffre des paquets codés en SSL à partir d’appareils avant de transmettre ces paquets au serveur d’applications, vous devez activer la prise en charge de TLS V1.2 sur votre proxy inverse. Si vous utilisez IBM HTTP Server comme proxy inverse, voir Securing IBM HTTP Server pour obtenir des instructions.
• Si MobileFirst Server communique directement avec des appareils, les étapes permettant d’activer TLS V1.2 varient selon que votre serveur d’applications est Apache Tomcat, le profil Liberty de WebSphere Application Server ou le profil complet de WebSphere Application Server.

Apache Tomcat

1. Vérifiez que l’environnement d’exécution Java (JRE) prend en charge TLS V1.2. Assurez-vous que vous disposez de l’une des versions JRE suivantes :
   • Oracle JRE version 1.7.0_75 ou ultérieure
   • Oracle JRE version 1.8.0_31 ou ultérieure
2. Editez le fichier conf/server.xml et modifiez l’élément Connector qui déclare le port HTTPS de sorte que l’attribut sslEnabledProtocols soit défini avec la valeur suivante : sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1,SSLv2Hello".

Profil Liberty de WebSphere Application Server

1. Vérifiez que l’environnement d’exécution Java (JRE) prend en charge TLS V1.2.

   • Si vous utilisez un logiciel SDK IBM Java, assurez-vous que celui-ci dispose d’un correctif pour la vulnérabilité POODLE. Les versions minimales du logiciel SDK IBM Java qui contiennent le correctif pour votre version de WebSphere Application Server sont disponibles sur la page Security Bulletin: Vulnerability in SSLv3 affects IBM WebSphere Application Server (CVE-2014-3566).

     Remarque : Vous pouvez utiliser les versions répertoriées dans le bulletin de sécurité ou des versions ultérieures.

   • Si vous utilisez un logiciel SDK Oracle Java, assurez-vous que vous disposez de l’une des versions suivantes :

     • Oracle JRE version 1.7.0_75 ou ultérieure
     • Oracle JRE version 1.8.0_31 ou ultérieure
2. Si vous utilisez un logiciel SDK IBM Java, éditez le fichier server.xml.
   • Ajoutez la ligne suivante : <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" sslProtocol="SSL_TLSv2"/>
   • Ajoutez l’attribut sslProtocol="SSL_TLSv2" à tous les éléments <ssl> existants.

Profil complet de WebSphere Application Server

1. Vérifiez que l’environnement d’exécution Java (JRE) prend en charge TLS V1.2.

   Assurez-vous que votre logiciel SDK IBM Java dispose d’un correctif pour la vulnérabilité POODLE. Les versions minimales du logiciel SDK IBM Java qui contiennent le correctif pour votre version de WebSphere Application Server sont disponibles sur la page Security Bulletin: Vulnerability in SSLv3 affects IBM WebSphere Application Server (CVE-2014-3566).

   Remarque : Vous pouvez utiliser les versions répertoriées dans le bulletin de sécurité ou des versions ultérieures.

2. Connectez-vous à la console d’administration de WebSphere Application Server, puis cliquez sur **Sécurité → Certificat SSL et gestion des clés → Configurations SSL **.
3. Pour chaque configuration SSL répertoriée, modifiez la configuration de manière à activer TLS V1.2.
   • Sélectionnez une configuration SSL, puis, sous Propriétés supplémentaires, cliquez sur les paramètres Qualité de protections (QoP).
   • Dans la liste Protocole, sélectionnez SSL_TLSv2.
   • Cliquez sur Appliquer et sauvegardez les modifications.

Configuration de l’authentification d’utilisateur pour l’administration de MobileFirst Server

L’administration de MobileFirst Server requiert l’authentification d’utilisateur. Vous pouvez configurer l’authentification d’utilisateur et sélectionner une méthode d’authentification. Ensuite, la procédure de configuration dépend du serveur d’applications Web que vous utilisez.

Important : Si vous utilisez un profil complet de WebSphere Application Server autonome, utilisez une méthode d’authentification autre que la méthode d’authentification WebSphere simple (SWAM) dans la sécurité globale. Vous pouvez utiliser l’authentification LTPA. Si vous utilisez la méthode d’authentification SWAM, il se peut que des échecs d’authentification inattendus se produisent.

Vous devez configurer l’authentification après que le programme d’installation a déployé les applications Web d’administration de MobileFirst Server dans le serveur d’applications Web.

Les rôles de sécurité Java Platform, Enterprise Edition (Java EE) suivants sont définis pour l’administration de MobileFirst Server :

• mfpadmin
• mfpdeployer
• mfpoperator
• mfpmonitor

Vous devez mapper les rôles aux ensembles d’utilisateurs correspondants. Le rôle mfpmonitor ne peut pas modifier des données, mais uniquement les visualiser. Les tableaux ci-après répertorient les rôles et les fonctions MobileFirst pour les serveurs de production.

Déploiement

Gestion de MobileFirst Server

Gestion des applications

D’une manière générale, tous les rôles peuvent émettre des demandes GET, les rôles mfpadmin, mfpdeployer et mfpmonitor peuvent également émettre des demandes POST et PUT, et les rôles mfpadmin et mfpdeployer peuvent également émettre des demandes DELETE.

Demandes liées aux notifications push

Désactivation

Si vous choisissez d’utiliser une méthode d’authentification via un référentiel d’utilisateurs, tel que LDAP, vous pouvez configurer l’administration de MobileFirst Server de manière à pouvoir utiliser des utilisateurs et des groupes avec le référentiel d’utilisateurs pour définir la liste de contrôle d’accès de l’administration de MobileFirst Server. Cette procédure dépend du type et de la version du serveur d’applications Web que vous utilisez.

Configuration du profil complet de WebSphere Application Server pour l’administration de MobileFirst Server

Configurez la sécurité en mappant les rôles Java EE d’administration de MobileFirst Server à un ensemble d’utilisateurs pour les deux applications Web.

Vous définissez les bases de la configuration utilisateur dans la console WebSphere Application Server. L’accès à la console se fait généralement à l’aide de l’adresse suivante : https://localhost:9043/ibm/console/

1. Sélectionnez Sécurité → Sécurité globale.
2. Sélectionnez Assistant de configuration de sécurité pour configurer des utilisateurs. Vous pouvez gérer des comptes utilisateur individuels en sélectionnant Utilisateurs et groupes → Gérer les utilisateurs.
3. Mappez les rôles mfpadmin, mfpdeployer, mfpmonitor et mfpoperator à un ensemble d’utilisateurs.
   • Sélectionnez Serveurs → Types de serveur → Serveurs d’applications WebSphere.
   • Sélectionnez le serveur.
   • Sur l’onglet Configuration, sélectionnez Applications → Applications d’entreprise.
   • Sélectionnez MobileFirst_Administration_Service.
   • Sur l’onglet Configuration, sélectionnez Détails → Mappage de rôle de sécurité à utilisateur/groupe.
   • Effectuez les tâches de personnalisation nécessaires.
   • Cliquez sur OK.
   • Répétez les étapes afin de mapper les rôles pour la console d’application Web. Cette fois-ci, sélectionnez MobileFirst_Administration_Console.
   • Cliquez sur Sauvegarder pour sauvegarder les modifications.

Configuration du profil Liberty de WebSphere Application Server pour l’administration de MobileFirst Server

Dans le profil Liberty de WebSphere Application Server, vous configurez les rôles mfpadmin, mfpdeployer, mfpmonitor et mfpoperator dans le fichier de configuration server.xml du serveur.

Pour configurer les rôles de sécurité, vous devez éditer le fichier server.xml. Dans l’élément <application-bnd> de chaque élément <application>, créez des éléments <security-role>. Chaque élément <security-role> s’applique à chacun des rôles : mfpadmin, mfpdeployer, mfpmonitor et mfpoperator. Mappez les rôles du nom de groupe d’utilisateurs approprié, dans cet exemple :mfpadmingroup, mfpdeployergroup, mfpmonitorgroup ou mfpoperatorgroup. Ces groupes sont définis via l’élément <basicRegistry>. Vous pouvez personnaliser cet élément ou le remplacer entièrement par un élément <ldapRegistry> ou un élément <safRegistry>.

Ensuite, pour garantir des temps de réponse convenables avec un nombre important d’applications installées, par exemple, avec 80 applications, vous devez configurer un pool de connexions pour la base de données d’administration.

1. Editez le fichier server.xml. Exemple :

   <security-role name="mfpadmin">
      <group name="mfpadmingroup"/>
   </security-role>
   <security-role name="mfpdeployer">
      <group name="mfpdeployergroup"/>
   </security-role>
   <security-role name="mfpmonitor">
      <group name="mfpmonitorgroup"/>
   </security-role>
   <security-role name="mfpoperator">
      <group name="mfpoperatorgroup"/>
   </security-role>
   
   <basicRegistry id="mfpadmin">
      <user name="admin" password="admin"/>
      <user name="guest" password="guest"/>
      <user name="demo" password="demo"/>
      <group name="mfpadmingroup">
        <member name="guest"/>
        <member name="demo"/>
      </group>
      <group name="mfpdeployergroup">
        <member name="admin" id="admin"/>
      </group>
      <group name="mfpmonitorgroup"/>
      <group name="mfpoperatorgroup"/>
   </basicRegistry>
   

2. Définissez la taille AppCenterPool :

   <connectionManager id="AppCenterPool" minPoolSize="10" maxPoolSize="40"/>
   

3. Dans l’élément <dataSource>, définissez une référence au gestionnaire de connexions :

   <dataSource id="MFPADMIN" jndiName="mfpadmin/jdbc/mfpAdminDS" connectionManagerRef="AppCenterPool">
   ...
   </dataSource>
   

Configuration d’Apache Tomcat pour l’administration de MobileFirst Server

Vous devez configurer les rôles de sécurité Java EE pour l’administration de MobileFirst Server sur le serveur d’applications Web Apache Tomcat.

1. Si vous avez installé l’administration de MobileFirst Server manuellement, déclarez les rôles suivants dans le fichier conf/tomcat-users.xml :

   <role rolename="mfpadmin"/>
   <role rolename="mfpmonitor"/>
   <role rolename="mfpdeployer"/>
   <role rolename="mfpoperator"/>
   

2. Ajoutez des rôles aux utilisateurs sélectionnés, par exemple :

   <user name="admin" password="admin" roles="mfpadmin"/>
   

3. Vous pouvez définir l’ensemble d’utilisateurs en procédant comme indiqué dans la documentation Apache Tomcat, Realm Configuration HOW-TO.

Liste des propriétés JNDI des applications Web MobileFirst Server

Configurez les propriétés JNDI des applications Web MobileFirst Server qui sont déployées sur le serveur d’applications.

• Configuration de propriétés JNDI pour les applications Web de MobileFirst Server
• Liste des propriétés JNDI pour le service d’administration de MobileFirst Server
• Liste des propriétés JNDI pour le service Live Update de MobileFirst Server
• Liste des propriétés JNDI pour l’environnement d’exécution de MobileFirst
• Liste des propriétés JNDI pour le service push de MobileFirst Server

Configuration de propriétés JNDI pour les applications Web de MobileFirst Server

Configurez les propriétés JNDI pour configurer les applications Web MobileFirst Server qui sont déployées sur le serveur d’applications.
Définissez les entrées d’environnement JNDI en procédant de l’une des façons suivantes :

• Configurer les entrées d’environnement de serveur. Les étapes permettant de configurer les entrées d’environnement de serveur dépendent du serveur d’applications que vous utilisez :

  • WebSphere Application Server :
    1. Dans la console d’administration de WebSphere Application Server, accédez à Applications → Types d’application → Applications d’entreprise WebSphere → application_name → Entrées d’environnement pour les modules Web.
    2. Dans les zones Valeur, entrez les valeurs appropriées pour votre environnement de serveur.

    

  • WebSphere Application Server Liberty :

    Dans liberty_install_dir/usr/servers/serverName, éditez le fichier server.xml et déclarez les propriétés JNDI comme suit :

    <application id="app_context_root" name="app_context_root" location="app_war_name.war" type="war">
          ...
    </application>
    <jndiEntry jndiName="app_context_root/JNDI_property_name" value="JNDI_property_value" />
    

    La racine de contexte (dans l’exemple précédent : app_context_root) se connecte entre l’entrée JNDI et une application MobileFirst spécifique. Si plusieurs applications MobileFirst existent sur le même serveur, vous pouvez définir des entrées JNDI spécifiques pour chaque application en utilisant le préfixe du chemin de contexte.

    Remarque : Certaines propriétés sont définies globalement sur WebSphere Application Server Liberty, sans préfixer le nom de propriété avec la racine de contexte. Pour obtenir la liste de ces propriétés, voir Entrées JNDI globales.

    Pour toutes les autres propriétés JNDI, les noms doivent être préfixés avec la racine de contexte de l’application :

    • Pour le service Live Update, la racine de contexte doit être /[adminContextRoot]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.
    • Pour le service push, vous devez définir la racine de contexte comme /imfpush. Sinon, les appareils client ne peuvent pas se connecter à ce service car la racine de contexte est codée en dur dans le logiciel SDK.
    • Pour l’application Service d’administration de MobileFirst, le composant MobileFirst Operations Console et l’environnement d’exécution de MobileFirst, vous pouvez définir la racine de contexte comme vous le souhaitez. Toutefois, par défaut, il s’agit de /mfpadmin pour le service d’administration de MobileFirst, /mfpconsole pour MobileFirst Operations Console et /mfp pour l’environnement d’exécution de MobileFirst.

    Exemple :

    <application id="mfpadmin" name="mfpadmin" location="mfp-admin-service.war" type="war">
          ...
    </application>
    <jndiEntry jndiName="mfpadmin/mfp.admin.actions.prepareTimeout" value = "2400000" />
    

  • Apache Tomcat :

    Dans tomcat_install_dir/conf, éditez le fichier server.xml et déclarez les propriétés JNDI comme suit :

    <Context docBase="app_context_root" path="/app_context_root">
          <Environment name="JNDI_property_name" override="false" type="java.lang.String" value="JNDI_property_value"/>
    </Context>
    

    • Le préfixe du chemin de contexte n’est pas nécessaire car les entrées JNDI sont définies au sein de l’élément <Context> d’une application.
    • override="false" est obligatoire.
    • L’attribut type est toujours java.lang.String, sauf spécification contraire pour la propriété.

    Exemple :

    <Context docBase="app_context_root" path="/app_context_root">
          <Environment name="mfp.admin.actions.prepareTimeout" override="false" type="java.lang.String" value="2400000"/>
    </Context>
    

• Si vous effectuez une installation à l’aide de tâches Ant, vous pouvez également définir les valeurs des propriétés JNDI lors de l’installation.

  Dans mfp_install_dir/MobileFirstServer/configuration-samples, éditez le fichier XML de configuration pour les tâches Ant et déclarez les valeurs pour les propriétés JNDI en utilisant l’élément property au sein des étiquettes suivantes :

  • <installmobilefirstadmin> pour l’administration de MobileFirst Server, MobileFirst Operations Console et les services Live Update. Pour plus d’informations, voir Tâches Ant pour l’installation de MobileFirst Operations Console, des artefacts de MobileFirst Server, de l’administration de MobileFirst Server et des services Live Update.
  • <installmobilefirstruntime> pour les propriétés de configuration de l’environnement d’exécution de MobileFirst. Pour plus d’informations, voir Tâches Ant pour l’installation des environnements d’exécution de MobileFirst.
  • <installmobilefirstpush> pour la configuration du service push. Pour plus d’informations, voir Tâches Ant pour l’installation du service push de MobileFirst Server.

  Exemple :

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

Liste des propriétés JNDI pour le service d’administration de MobileFirst Server

Lorsque vous configurez le service d’administration de MobileFirst Server et MobileFirst Operations Console pour votre serveur d’applications, définissez les propriétés JNDI facultatives ou obligatoires, en particulier pour Java Management Extensions (JMX).

Les propriétés suivantes peuvent être définies sur l’application Web (mfp-admin-service.war) du service d’administration.

Propriétés JNDI pour le service d’administration : JMX

Propriétés JNDI pour le service d’administration : délai

Propriétés JNDI pour le service d’administration : journalisation

Propriétés JNDI pour le service d’administration : proxys

Propriétés JNDI pour le service d’administration : topologies

Propriétés JNDI pour le service d’administration : base de données relationnelle

Propriétés JNDI pour le service d’administration : octroi de licence

Propriétés JNDI pour le service d’administration : configurations JNDI

Le service d’administration utilise un service Live Update comme fonction auxiliaire pour stocker différentes configurations. Utilisez ces propriétés pour configurer la façon dont le service Live Update doit être atteint.

Propriétés JNDI pour le service d’administration : service Live Update

Le service d’administration utilise un service push comme fonction auxiliaire pour stocker différents paramètres de push. Utilisez ces propriétés pour configurer la façon dont le service push doit être atteint. Le service push étant protégé par le modèle de sécurité OAuth, vous devez définir différentes propriétés pour activer les clients confidentielles dans OAuth.

Propriétés JNDI pour le service d’administration : service push

Propriétés JNDI pour MobileFirst Operations Console

Les propriétés suivantes peuvent être définies sur l’application Web (mfp-admin-ui.war) de MobileFirst Operations Console.

Liste des propriétés JNDI pour le service Live Update de MobileFirst Server

Lorsque vous configurez le service Live Update de MobileFirst Server pour votre serveur d’applications, vous pouvez définir les propriétés JNDI ci-après. Le tableau répertorie les propriétés JNDI pour le service Live Update de base de données relationnelle IBM.

Pour savoir comment définir ces propriétés, voir Configuration de propriétés JNDI pour les applications Web de MobileFirst Server.

Liste des propriétés JNDI pour l’environnement d’exécution de MobileFirst

Lorsque vous configurer l’environnement d’exécution de MobileFirst Server pour votre serveur d’applications, vous devez définir les propriétés JNDI facultatives ou obligatoires.
Le tableau suivant répertorie les propriétés MobileFirst qui sont déjà disponibles en tant qu’entrées JNDI :

Liste des propriétés JNDI pour le service push de MobileFirst Server

Configuration des sources de données

Découvrez certains détails de configuration de source de données relatifs aux bases de données prise en charge.

• Gestion de la taille du journal de transactions DB2
• Configuration de la reprise en ligne en continu HADR de DB2 pour les sources de données de MobileFirst Server et d’Application Center
• Gestion des connexions périmées
• Données périmées après création ou suppression d’applications dans MobileFirst Operations Console

Gestion de la taille du journal de transactions DB2

Lorsque vous déployez une application d’au moins 40 Mo avec IBM MobileFirst Operations Console, vous êtes susceptible de recevoir un journal de transactions contenant des erreurs.

La sortie système suivante est un exemple du code d’erreur contenu dans le journal de transactions :

DB2 SQL Error: SQLCODE=-964, SQLSTATE=57011

Le contenu de chaque application est stocké dans la base de données d’administration de MobileFirst.

Le nombre de fichiers journaux actifs est défini par les paramètres de configuration de base de données LOGPRIMARY et LOGSECOND et leur taille est définie par le paramètre de configuration de base de données LOGFILSIZ. Une seule transaction ne peut pas utiliser un espace journal supérieur à la valeur définie par LOGFILSZ * (LOGPRIMARY + LOGSECOND) * 4096 ko.

La commande DB2 GET DATABASE CONFIGURATION inclut des informations sur la taille de fichier journal, ainsi que le nombre de fichiers journaux principal et secondaire.

En fonction de la plus grande taille de l’application MobileFirst déployée, vous devrez peut-être augmenter l’espace journal DB2.

A l’aide de la commande DB2 update db cfg, augmentez la valeur du paramètre LOGSECOND. Aucun espace n’est alloué lorsque la base de données est activée. En revanche, de l’espace est alloué uniquement lorsque cela s’avère nécessaire.

Configuration de la reprise en ligne en continu HADR de DB2 pour les sources de données de MobileFirst Server et d’Application Center

Vous devez activer la reprise en ligne en continu avec le profil Liberty de WebSphere Application Server et WebSphere Application Server. Cette fonction vous permet de gérer une exception lorsqu’une base de données fait l’objet d’une reprise en ligne et est réacheminée par le pilote JDBC DB2.

Remarque : La reprise en ligne HADR de DB2 n’est pas prise en charge pour Apache Tomcat.

Par défaut avec la fonction HADR de DB2, lorsque le pilote JDBC DB2 effectue une redirection de client après avoir détecté qu’une base de données a fait l’objet d’une reprise en ligne lors de la première tentative de réutilisation d’une connexion existante, le pilote déclenche une exception com.ibm.db2.jcc.am.ClientRerouteException avec ERRORCODE=-4498 et SQLSTATE=08506. WebSphere Application Server mappe cette exception à com.ibm.websphere.ce.cm.StaleConnectionException avant qu’elle ne soit reçue par l’application.

Dans ce cas, l’application doit intercepter l’exception et relancer l’exécution de la transaction. Les environnements d’exécution de MobileFirst et d’Application Center ne gèrent pas l’exception, mais font appel à une fonction appelée reprise en ligne en continu. Pour activer cette fonction, vous devez affecter à la propriété JDBC enableSeamlessFailover la valeur “1”.

Configuration du profil Liberty de WebSphere Application Server

Vous devez éditer le fichier server.xml et ajouter la propriété enableSeamlessFailover à l’élément properties.db2.jcc des sources de données de MobileFirst et d’Application Center. Exemple :

<dataSource jndiName="jdbc/WorklightAdminDS" transactional="false">
  <jdbcDriver libraryRef="DB2Lib"/>
  <properties.db2.jcc databaseName="WLADMIN"  currentSchema="WLADMSC"
                      serverName="db2server" portNumber="50000"
                      enableSeamlessFailover= "1"
                      user="worklight" password="worklight"/>
</dataSource>

Configuration de WebSphere Application Server

A partir de la console d’administration de WebSphere Application Server pour chaque source de données de MobileFirst et d’Application Center :

1. Accédez à Ressources → JDBC → Sources de données → Nom de source de données.
2. Sélectionnez Nouveau et ajoutez la propriété personnalisée suivante ou mettez à jour les valeurs si les propriétés existent déjà : enableSeamlessFailover : 1
3. Cliquez sur Appliquer.
4. Enregistrez votre configuration.

Pour plus d’informations sur la procédure de configuration d’une connexion à une base de données DB2 prenant en charge la fonction HADR, voir Configuration d’une connexion à une base de données DB2 prenant en charge la fonction HADR.

Gestion des connexions périmées

Configurez votre serveur d’applications de manière à éviter les problèmes de dépassement de délai de base de données.

StaleConnectionException est une exception générée par le code de connexion de base de données de profils de serveur d’applications Java lorsqu’un pilote JDBC renvoie une erreur irrémédiable suite à une demande ou à une opération de connexion. L’exception StaleConnectionException est générée lorsque le fournisseur de base de données émet une exception pour indiquer qu’une connexion présente dans le pool de connexions n’est plus valide. Cette exception peut se produite pour un certain nombre de raisons. L’exception StaleConnectionException se produit le plus souvent lorsque des connexions sont extraites du pool de connexions de base de données et qu’il s’avère que la connexion a expiré ou a été supprimée car elle n’était plus utilisée depuis longtemps.

Vous pouvez configurer votre serveur d’applications de manière à éviter cette exception.

Configuration d’Apache Tomcat

MySQL
La base de données MySQL ferme une connexion après une période d’inactivité sur celle-ci. Ce délai est défini par la variable système appelée wait_timeout. La valeur par défaut de cette variable est 28000 secondes (8 heures).

Lorsqu’une application tente de se connecter à la base de données après que MySQL a fermé la connexion, l’exception suivante est générée :

com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after statement closed.

Editez les fichiers server.xml et context.xml, puis, pour chaque élément <Resource>, ajoutez les propriétés suivantes :

• testOnBorrow=”true”
• validationQuery=”select 1”

Exemple :

<Resource name="jdbc/AppCenterDS"
  type="javax.sql.DataSource"
  driverClassName="com.mysql.jdbc.Driver"
  ...
  testOnBorrow="true"
  validationQuery="select 1"
/>

Configuration du profil Liberty de WebSphere Application Server

Editez le fichier server.xml et, pour chaque élément <dataSource> (bases de données d’Application Center et d’environnement d’exécution), ajoutez un élément <connectionManager> avec la propriété agedTimeout :

<connectionManager agedTimeout="timeout_value"/>

La valeur de délai dépend principalement du nombre de connexions ouvertes en parallèle, mais également du nombre minimal et du nombre maximal de connexions dans le pool. Par conséquent, vous devez régler les différents attributs connectionManager pour identifier les valeurs les plus appropriées. Pour plus d’informations sur l’élément connectionManager, voir Liberty : Eléments de configuration dans le fichier server.xml.

Remarque : L’utilisation de MySQL conjointement avec le profil Liberty de WebSphere Application Server ou le profil complet de WebSphere Application Server n’est pas considérée comme une configuration prise en charge. Pour plus d’informations, voir WebSphere Application Server Support Statement. Utilisez IBM DB2 ou une autre base de données prise en charge par WebSphere Application Server afin de bénéficier d’une configuration entièrement prise en charge par le support IBM.

Données périmées après création ou suppression d’applications dans MobileFirst Operations Console

Sur un serveur d’applications Tomcat 8, si vous utilisez une base de données MySQL, certains appels émis depuis MobileFirst Operations Console vers des services renvoient une erreur 404.

Sur un serveur d’applications Tomcat 8, si vous utilisez une base de données MySQL, lorsque vous vous servez de MobileFirst Operations Console pour supprimer ou ajouter une application et que vous tentez d’actualiser la console deux fois, il se peut que des données périmées apparaissent. Par exemple, une application déjà supprimée peut apparaître dans la liste qui s’affiche pour les utilisateurs.

Pour éviter ce problème, remplacez le niveau d’isolement par READ_COMMITTED, soit dans la source de données, soit dans le système de gestion de base de données.

Pour connaître la signification de READ_COMMITTED, voir la documentation MySQL sur le sitehttp://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html.

• Pour remplacer le niveau d’isolement par READ_COMMITTED dans la source de données, modifiez le fichier de configuration Tomcat server.xml : dans la section <Resource name=”jdbc/mfpAdminDS” …/>, ajoutez l’attribut defaultTransactionIsolation=”READ_COMMITTED”.
• Pour effectuer un remplacement global du niveau d’isolement par READ_COMMITTED dans le système de gestion de base de données, voir la page relative à la syntaxe SET TRANSACTION dans la documentation MySQL sur le site http://dev.mysql.com/doc/refman/5.7/en/set-transaction.html.

Configuration du profil complet de WebSphere Application Server

DB2 ou Oracle
Pour réduire les problèmes de connexion périmée, vérifiez la configuration des pools de connexion sur chaque source de données dans la console d’administration de WebSphere Application Server.

1. Connectez-vous à la console d’administration de WebSphere Application Server.
2. Sélectionnez Ressources → Fournisseurs JDBC → database_jdbc_provider → Sources de données → votre_source_données → Propriétés de pool de connexions.
3. Affectez au paramètre Nombre minimal de connexions la valeur 0.
4. Définissez une valeur d’intervalle de régulation inférieure à la valeur de délai d’attente d’inactivité.
5. Vérifiez que la propriété Règle de purge a pour valeur EntirePool (valeur par défaut).

Pour plus d’informations, voir Paramètres de pool de connexions.

MySQL

1. Connectez-vous à la console d’administration de WebSphere Application Server.
2. Sélectionnez Ressources → JDBC → Sources de données.
3. Pour chaque source de données MySQL :
   • Cliquez sur la source de données.
   • Sélectionnez les propriétés Pool de connexions sous Propriétés supplémentaires.
   • Modifiez la valeur de la propriété Délai d’expiration inutilisé. La valeur doit être inférieure à celle de la variable système MySQL wait_timeout de sorte que les connexions soient purgées avant que MySQL ne les ferme.
   • Cliquez sur OK.

Remarque : L’utilisation de MySQL conjointement avec le profil Liberty de WebSphere Application Server ou le profil complet de WebSphere Application Server n’est pas considérée comme une configuration prise en charge. Pour plus d’informations, voir WebSphere Application Server Support Statement. Utilisez IBM DB2 ou une autre base de données prise en charge par WebSphere Application Server afin de bénéficier d’une configuration entièrement prise en charge par le support IBM.

Configuration des mécanismes de journalisation et de surveillance

Mobile Foundation consigne des erreurs, des avertissements et des messages d’information dans un fichier journal. Le mécanisme de journalisation sous-jacent varie en fonction des serveurs d’applications.

MobileFirst Server

Mobile Foundation (ou MobileFirst Server dans sa forme abrégée) utilise le package standard java.util.logging. Par défaut, toutes les informations journalisées par MobileFirst sont dirigées vers les fichiers journaux de serveur d’applications. Vous pouvez contrôler la journalisation de MobileFirst Server en utilisant les outils standard disponibles dans chaque serveur d’applications. Par exemple, si vous souhaitez activer la journalisation de trace dans WebSphere Application Server Liberty, ajoutez un élément de trace au fichier server.xml. Pour activer la journalisation de trace dans WebSphere Application Server, utilisez l’écran de journalisation dans la console et activez la trace pour les journaux MobileFirst.

Les journaux MobileFirst commencent tous par com.ibm.mfp.
Les journaux Application Center commencent par com.ibm.puremeap.

Pour plus d’informations sur les modèles de journalisation de chaque serveur d’applications, y compris l’emplacement des fichiers journaux, voir la documentation du serveur d’applications pertinent, comme indiqué dans le tableau ci-après.

Mappages de niveau de journalisation

MobileFirst Server utilise l’API java.util.logging. Les niveaux de journalisation sont mappés aux niveaux suivants :

• WL.Logger.debug : FINE
• WL.Logger.info : INFO
• WL.Logger.warn : WARNING
• WL.Logger.error : SEVERE

Outils de surveillance des journaux

Pour Apache Tomcat, vous pouvez utiliser IBM Operations Analytics - Log Analysis ou d’autres outils de surveillance de fichiers journaux standard afin de surveiller les journaux et mettre en évidence les erreurs et les avertissements.

Pour WebSphere Application Server, utilisez les fonctions d’affichage de journal décrites dans IBM Knowledge Center. Les URL sont répertoriées dans le tableau contenu dans la section MobileFirst Server de cette page.

Connectivité de back end

Pour activer la trace afin de surveiller la connectivité de back end, voir la documentation de votre plateforme de serveur d’applications spécifique dans le tableau contenu dans la section MobileFirst Server de cette page. Utilisez le package com.ibm.mfp.server.js.adapter et affectez la valeur FINEST au niveau de journalisation.

Journal d’audit pour les opérations d’administration

MobileFirst Operations Console stocke un journal d’audit pour la connexion, la déconnexion et toutes les opérations d’administration, telles que le déploiement d’applications ou d’adaptateurs ou le verrouillage d’applications. Vous pouvez désactiver le journal d’audit en affectant à la propriété JNDI mfp.admin.audit la valeur false sur l’application Web du service d’administration de MobileFirst (mfp-admin-service.war).

Lorsque le journal d’audit est activé, vous pouvez le télécharger à partir de MobileFirst Operations Console en cliquant sur le lien Journal d’audit dans le pied de page de la page.

Problèmes de connexion et d’authentification

Pour diagnostiquer les problèmes de connexion et d’authentification, activez le package com.ibm.mfp.server.security pour la trace et affectez la valeur FINEST au niveau de journalisation.

Configuration de plusieurs environnements d’exécution

Vous pouvez configurer MobileFirst Server avec plusieurs environnements d’exécution en créant une différenciation visuelle entre les types d’application dans MobileFirst Operations Console.

Remarque : Plusieurs environnements d’exécution ne sont pas pris en charge dans une instance de serveur Mobile Foundation créée par le service IBM Cloud Mobile Foundation. Dans le service IBM Cloud, vous devez créer plusieurs instances de service à la place.

Aller à

• Configuration de plusieurs environnements d’exécution dans le profil Liberty de WebSphere
• Enregistrement d’applications et déploiement d’adaptateurs sur différents environnements d’exécution
• Exportation et importation de configurations d’environnement d’exécution

Configuration de plusieurs environnements d’exécution dans le profil Liberty de WebSphere

1. Ouvrez le fichier server.xml du serveur d’applications. Il se trouve généralement dans le dossier [serveur-applications]/usr/servers/server-name/. Par exemple, avec MobileFirst Developer Kit, le fichier se trouve dans [dossier-installation]/mfp-server/usrs/servers/mfp/server.xml.

2. Ajoutez un second élément application :

   <application id="second-runtime" name="second-runtime" location="mfp-server.war" type="war">
        <classloader delegation="parentLast">
            </classloader>
   </application>
   

3. Ajoutez un second ensemble d’entrées JNDI :

   <jndiEntry jndiName="second-runtime/mfp.analytics.url" value='"http://localhost:9080/analytics-service/rest"'/>
   <jndiEntry jndiName="second-runtime/mfp.analytics.console.url" value='"http://localhost:9080/analytics/console"'/>
   <jndiEntry jndiName="second-runtime/mfp.analytics.username" value='"admin"'/>
   <jndiEntry jndiName="second-runtime/mfp.analytics.password" value='"admin"'/>
   <jndiEntry jndiName="second-runtime/mfp.authorization.server" value='"embedded"'/>
   

4. Ajoutez un second élément dataSource :

   <dataSource jndiName="second-runtime/jdbc/mfpDS" transactional="false">
        <jdbcDriver libraryRef="DerbyLib"/>
        <properties.derby.embedded databaseName="${wlp.install.dir}/databases/second-runtime" user='"MFPDATA"'/>
   </dataSource>
   

   Remarque :

   • Assurez-vous que dataSource désigne un autre schéma de base de données.
   • Prenez soin de créer une autre instance de base de données pour le nouvel environnement d’exécution.
   • Dans l’environnement de développement, ajoutez createDatabase="create" dans l’élément enfant properties.derby.embedded.

5. Redémarrez le serveur d’applications.

Enregistrement d’applications et déploiement d’adaptateurs sur différents environnements d’exécution

Lorsqu’un serveur MobileFirst Server est configuré avec plusieurs environnements d’exécution, l’enregistrement d’applications et le déploiement d’adaptateurs sont légèrement différents.

• Enregistrement et déploiement à partir de MobileFirst Operations Console
• Enregistrement et déploiement à partir de la ligne de commande

Enregistrement et déploiement à partir de MobileFirst Operations Console

Lorsque vous exécutez ces actions dans MobileFirst Operations Console, vous devez désormais sélectionner l’environnement d’exécution sur lequel effectuer l’enregistrement ou le déploiement.

Enregistrement et déploiement à partir de la ligne de commande

Lorsque vous exécutez ces actions à l’aide de l’outil de ligne de commande mfpdev, vous devez désormais ajouter le nom de l’environnement d’exécution sur lequel effectuer l’enregistrement ou le déploiement.

Pour enregistrer une application : mfpdev app register <server-name> <runtime-name>.

mfpdev app register local second-runtime

Pour déployer un adaptateur : mfpdev adapter deploy <server-name> <runtime-name>.

mfpdev adapter deploy local second-runtime

• local est le nom de la définition de serveur par défaut dans l’MobileFirst CLI. Remplacez local par le nom de la définition de serveur sur lequel effectuer l’enregistrement ou le déploiement.
• runtime-name est le nom de l’environnement d’exécution sur lequel effectuer l’enregistrement ou le déploiement.

Obtenir plus d’informations à l’aide des commandes d’aide de l’interface de ligne de commande :

• mfpdev help server add
• mfpdev help app register
• mfpdev help adapter deploy

Exportation et importation de configurations d’environnement d’exécution

Vous pouvez exporter une configuration d’environnement d’exécution et l’importer sur un autre serveur MobileFirst Server à l’aide des API REST du service d’administration de MobileFirst Server.

Par exemple, vous pouvez définir une configuration d’environnement d’exécution dans un environnement de développement, l’exporter, puis l’importer dans un environnement de test pour une configuration rapide, puis la configurer davantage en fonction des besoins spécifiques de l’environnement de test.

Pour découvrir toutes les API REST disponibles, voir la documentation API Reference.

Configuration du suivi des licences

Le suivi des licences est activé par défaut. Pour savoir comment configurer le suivi des licences, voir les rubriques ci-après. Pour plus d’informations sur le suivi des licences, voir Suivi des licences.

• Configuration du suivi des licences pour un appareil client et un appareil adressable
• Configuration de fichiers journaux IBM License Metric Tool

Configuration du suivi des licences pour un appareil client et un appareil adressable

Le suivi des licences pour les appareils client et les appareils adressables est activé par défaut. Les rapports de licence sont disponibles dans MobileFirst Operations Console. Vous pouvez spécifier les propriétés JNDI suivantes pour modifier les paramètres par défaut du suivi des licences.

Remarque : Si vous disposez d’un contrat qui définit l’utilisation de l’octroi de licence de jeton, voir aussi Installation et configuration pour l’octroi de licence de jeton.

Vous pouvez spécifier les propriétés JNDI suivantes pour modifier les paramètres par défaut du suivi des licences.

mfp.device.decommission.when
Nombre de jours d’inactivité au terme desquels un appareil est déclassé par la tâche de déclassement d’appareil. Les rapports de licence ne comptabilisent pas les appareils déclassés comme appareils actifs. La valeur par défaut de la propriété est 90 jours. Ne définissez pas une valeur inférieure à 30 jours si l’option de licence pour votre logiciel est Appareil client ou Appareil adressable, sinon, les rapports de licence ne seront peut-être pas suffisants pour prouver la conformité.

mfp.device.archiveDecommissioned.when
Valeur, exprimée en nombre de jours, qui indique à quel moment les appareils déclassés sont placés dans un fichier archive lors de l’exécution de la tâche de déclassement. Les appareils archivés sont écrits dans un fichier dans le répertoire home\devices_archive d’IBM MobileFirst Server. Le nom du fichier contient l’horodatage de création du fichier archive. La valeur par défaut est 90 jours.

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). La tâche de déclassement effectue les actions suivantes :

• Elle déclasse les appareils actifs, en fonction du paramètre mfp.device.decommission.when.
• Le cas échéant, elle archive les anciens appareils déclassés, en fonction du paramètre mfp.device.archiveDecommissioned.when.
• Elle génère le rapport de suivi des licences.

mfp.licenseTracking.enabled
Valeur qui est utilisée pour activer ou désactiver le suivi des licences dans Mobile Foundation. Par défaut, le suivi des licences est activé. Pour améliorer les performances, vous pouvez désactiver cet indicateur lorsque l’option Appareil client ou Appareil adressable n’est pas utilisée pour la mise sous licence de Mobile Foundation. 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. Dans ce cas, seuls les enregistrements IBM License Metric Tool pour le nombre d’applications sont générés.

Pour plus d’informations sur la spécification de propriétés JNDI, voir Liste des propriétés JNDI pour l’environnement d’exécution de MobileFirst.

Configuration de fichiers journaux IBM License Metric Tool

Mobile Foundation génère des fichiers SLMT (IBM Software License Metric Tag). Les versions d’IBM License Metric Tool qui prennent en charge IBM Software License Metric Tag peuvent générer des rapports de consommation de licences. Lisez cette section pour comprendre comment configurer l’emplacement et la taille maximale des fichiers générés.

Par défaut, les fichiers IBM Software License Metric Tag figurent dans les répertoires suivants :

• Sous Windows : %ProgramFiles%\ibm\common\slm
• Sous les systèmes d’exploitation UNIX et de type UNIX : /var/ibm/common/slm

Si les répertoires ne sont pas accessibles en écriture, les fichiers sont créés dans le répertoire de journaux du serveur d’applications qui exécute l’environnement d’exécution de MobileFirst.

Vous pouvez configurer l’emplacement et la gestion de ces fichiers à l’aide des propriétés suivantes :

• license.metric.logger.output.dir : Emplacement des fichiers IBM Software License Metric Tag.
• license.metric.logger.file.size : Taille maximale d’un fichier SLMT avant l’exécution d’une rotation. La taille par défaut est 1 Mo.
• license.metric.logger.file.number : Nombre maximal de fichiers archive SLMT à conserver dans les rotations. Le nombre par défaut est 10.

Pour modifier les valeurs par défaut, vous devez créer un fichier de propriétés Java, au format key=value, et indiquer le chemin d’accès à ce fichier de propriétés à l’aide de la propriété JVM license_metric_logger_configuration.

Pour plus d’informations sur les rapports IBM License Metric Tool, voir Intégration à IBM License Metric Tool.

Configuration SSL WebSphere Application Server et adaptateurs HTTP

En définissant une propriété, vous pouvez permettre aux adaptateurs HTTP de profiter de la configuration SSL WebSphere.

Par défaut, les adaptateurs HTTP n’utilisent pas SSL WebSphere en concaténant le magasin de clés JRE (Java Runtime Environment) et le magasin de clés MobileFirst Server, lequel est décrit dans Configuration du magasin de clés MobileFirst Server. Voir aussi Configuration de SSL entre des adaptateurs et des serveurs de back end à l’aide de certificats auto-signés.

Pour que des adaptateurs HTTP utilisent la configuration SSL WebSphere, affectez la valeur true à la propriété JNDI ssl.websphere.config. Cette propriété a les effets suivants sur l’ordre de priorité :

1. Les adaptateurs qui s’exécutent sur WebSphere utilisent le magasin de clés WebSphere et non le magasin de clés MobileFirst Server.
2. Si la propriété ssl.websphere.alias est définie, l’adaptateur utilise la configuration SSL qui est associée à l’alias, comme indiqué dans cette propriété.