Configuración de MobileFirst Server

Visión general

Considerar su política de restauración y copia de seguridad, optimizar su configuración de servidor de MobileFirst Server y aplicar restricciones de acceso y opciones de seguridad.

Ir a

• Puntos finales del servidor de producción de MobileFirst Server
• Configuración de MobileFirst Server para habilitar TLS V1.2
• Configuración de la autenticación de usuario para la administración de MobileFirst Server
• Lista de propiedades JNDI de las aplicaciones web de MobileFirst Server
• Configuración de orígenes de datos
• Configuración de los mecanismos de registro y supervisión
• Configuración de varios tiempos de ejecución
• Configuración de seguimiento de licencias
• Configuración SSL de WebSphere Application Server y adaptadores HTTP

Puntos finales del servidor de producción de MobileFirst Server

Puede crear listas blancas y negras para los puntos finales de IBM MobileFirst Server.

Nota: La información relativa a los URL expuestos por Mobile Foundation se proporcionan como una directriz. Las organizaciones deben asegurarse de que se prueban los URL en una infraestructura de empresa, en función de lo que se ha habilitado en las listas blancas y negras.

Configuración de MobileFirst Server para habilitar TLS V1.2

Para que MobileFirst Server se comunique con dispositivos que solo soporten Transport Layer Security v1.2 (TLS) V1.2, entre los protocolos SSL, debe completar las siguientes instrucciones.

Los pasos para configurar MobileFirst Server para habilitar Transport Layer Security (TLS) V1.2 dependen de como MobileFirst Server se conecta con los dispositivos.

• Si MobileFirst Server está tras un proxy inverso que desencripta paquetes codificados con SSL desde los dispositivos antes de pasar los paquetes al servidor de aplicaciones, debe habilitar el soporte de TLS V1.2 en su proxy inverso. Si utiliza IBM HTTP Server como su servidor proxy inverso, consulte Securing IBM HTTP Server para obtener las instrucciones.
• Si MobileFirst Server se comunica directamente con los dispositivos, los pasos para habilitar TLS V1.2 dependen de si su servidor de aplicaciones es Apache Tomcat, perfil de Liberty de WebSphere Application Server o perfil completo de WebSphere Application Server.

Apache Tomcat

1. Confirme que Java Runtime Environment (JRE) soporta TLS V1.2. Asegúrese de que tiene una de las siguientes versiones de JRE:
   • Oracle JRE 1.7.0_75 o posterior
   • Oracle JRE 1.8.0_31 o posterior
2. Edite el archivo conf/server.xml y modifique el elemento Connector que declara el puerto HTTPS para que el atributo sslEnabledProtocols tenga el siguiente valor: sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1,SSLv2Hello".

Perfil de Liberty de WebSphere Application Server

1. Confirme que Java Runtime Environment (JRE) soporta TLS V1.2.

   • Si utiliza un Java SDK de IBM, asegúrese de que su Java SDK de IBM está parcheado para la vulnerabilidad de POODLE. Puede encontrar las versiones mínimas de Java SDK de IBM que contienen el parche para su versión de WebSphere Application Server en Boletín de seguridad: La vulnerabilidad en SSLv3 afecta a IBM WebSphere Application Server (CVE-2014-3566).

     Nota: Puede utilizar las versiones listadas en el boletín de seguridad o versiones posteriores.

   • Si utiliza un Java SDK de Oracle, asegúrese de que tiene una de las siguientes versiones:

     • Oracle JRE 1.7.0_75 o posterior
     • Oracle JRE 1.8.0_31 o posterior
2. Si utiliza un Java SDK de IBM, edite el archivo server.xml.
   • Añada la siguiente línea: <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" sslProtocol="SSL_TLSv2"/>
   • Añada el atributo sslProtocol="SSL_TLSv2" a todos los elementos <ssl> existentes.

Perfil completo de WebSphere Application Server

1. Confirme que Java Runtime Environment (JRE) soporta TLS V1.2.

   Asegúrese de que su Java SDK de IBM está parcheado para la vulnerabilidad de POODLE. Puede encontrar las versiones mínimas de Java SDK de IBM que contienen el parche para su versión de WebSphere Application Server en Boletín de seguridad: La vulnerabilidad en SSLv3 afecta a IBM WebSphere Application Server (CVE-2014-3566).

   Nota: Puede utilizar las versiones listadas en el boletín de seguridad o versiones posteriores.

2. Inicie la sesión en la consola de WebSphere Application Server y pulse Seguridad → Certificado SSL y gestión de claves → Configuraciones SSL.
3. Para cada configuración SSL listada, modifique la configuración para habilitar TLS V1.2.
   • Seleccione una configuración SSL y, a continuación, en Propiedades adicionales, pulse los valores de Calidad de protecciones.
   • En la lista Protocolo, seleccione SSL_TLSv2.
   • Pulse Aplicar y, a continuación, guarde los cambios.

Configuración de la autenticación de usuario para la administración de MobileFirst Server

La administración de MobileFirst Server requiere autenticación de usuario. Puede configurar la autenticación de usuario y elija un método de autenticación. Por lo tanto, el procedimiento de configuración depende del servidor de aplicaciones web que utilice.

Importante: Si utiliza un perfil completo de WebSphere Application Server de servidor autónomo, utilice un método de autenticación diferente al método de autenticación de WebSphere simple (SWAM) en la seguridad global. Puede utilizar lightweight third-party authentication (LTPA). Si utiliza SWAM, puede experimentar errores de autenticación inesperados.

Debe configurar la autenticación después de que el instalador despliegue aplicaciones web de administración de MobileFirst Server en el servidor de aplicaciones web.

La administración de MobileFirst Server tiene definidos los siguientes roles de seguridad de Java Platform, Enterprise Edition (Java EE):

• mfpadmin
• mfpdeployer
• mfpoperator
• mfpmonitor

Debe correlacionar los roles en los correspondientes conjuntos de usuarios. El rol mfpmonitor puede ver datos pero no puede cambiarlos. Las tablas siguientes listan los roles y funciones de MobileFirst para servidores de producción.

Despliegue

Gestión de MobileFirst Server

Gestión de aplicaciones

Básicamente, todos los roles pueden emitir solicitudes GET, los roles mfpadmin, mfpdeployer y mfpmonitor también pueden emitir solicitudes POST y PUT y los roles mfpadmin y mfpdeployer también pueden emitir solicitudes DELETE.

Solicitudes relacionadas con notificaciones push

Inhabilitación

Si elige utilizar un método de autenticación a través de un repositorio de usuarios como LDAP, puede configurar la administración de MobileFirst Server de modo que pueda utilizar usuarios y grupos con el repositorio de usuarios para definir la lista de control de acceso (ACL) de la administración de MobileFirst Server. Este procedimiento depende del tipo y la versión del servidor de aplicaciones web que utilice.

Configuración del perfil completo de WebSphere Application Server para la administración de MobileFirst Server

Configure la seguridad correlacionando los roles de Java EE de MobileFirst Server en un conjunto de usuarios para las aplicaciones web.

Defina los aspectos básicos de la configuración de usuario en la consola de WebSphere Application Server. El acceso a la consola se realiza normalmente mediante esta dirección: https://localhost:9043/ibm/console/

1. Seleccione Seguridad → Seguridad global.
2. Seleccione Asistente de configuración de seguridad para configurar usuarios. Puede gestionar cuentas de usuarios individuales seleccionando Usuarios y grupos → Gestionar usuarios.
3. Correlacione los roles mfpadmin, mfpdeployer, mfpmonitor y mfpoperator en un conjunto de usuarios.
   • Seleccione Servidores → Tipos de servidores → Servidores de aplicaciones de WebSphere.
   • Seleccione el servidor.
   • En el separador Configuración, seleccione Aplicaciones → Aplicaciones empresariales.
   • Seleccione MobileFirst_Administration_Service.
   • En el separador Configuración, seleccione Detalles → Rol de seguridad para la correlación usuario/grupo.
   • Realice la personalización necesaria.
   • Pulse Aceptar.
   • Repita los pasos para correlacionar los roles para la aplicación web de consola. Esta vez seleccione MobileFirst_Administration_Console.
   • Pulse Guardar para guardar los cambios.

Configuración del perfil de Liberty de WebSphere Application Server para la administración de MobileFirst Server

En el perfil de Liberty de WebSphere Application Server, puede configurar los roles de mfpadmin, mfpdeployer, mfpmonitor y mfpoperator en el archivo de configuración server.xml del servidor.

Para configurar los roles de seguridad, debe editar el archivo server.xml. En el elemento <application-bnd> de cada elemento <application>, cree elementos <security-role>. Cada elemento <security-role> es corresponde a un rol: mfpadmin, mfpdeployer, mfpmonitor y mfpoperator. Correlacione los roles con el nombre de grupo de usuarios adecuado, en este ejemplo: mfpadmingroup, mfpdeployergroup, mfpmonitorgroup o mfpoperatorgroup. Estos grupos se definen mediante el elemento <basicRegistry>. Puede personalizar este elemento o sustituirlo por completo por un elemento <ldapRegistry> o por un elemento <safRegistry>.

A continuación, para mantener buenos tiempos de respuesta con un gran número de aplicaciones instaladas, por ejemplo con 80 aplicaciones, debe configurar una agrupación de conexiones para la base de datos de administration.

1. Edite el archivo server.xml. Por ejemplo:

   <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. Defina el tamaño de AppCenterPool:

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

3. En el elemento <dataSource>, defina una referencia para el gestor de conexiones:

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

Configuración de Apache Tomcat para la administración de MobileFirst Server

Debe configurar los roles de seguridad de Java EE para la administración de MobileFirst Server en el servidor de aplicaciones web de Apache Tomcat.

1. Si ha instalado la administración de MobileFirst Server manualmente, declare los siguientes roles en el archivo conf/tomcat-users.xml:

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

2. Añada roles a los usuarios seleccionados, por ejemplo:

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

3. Puede definir el conjunto de usuarios tal como se describe en la documentación de Apache Tomcat, Realm Configuration HOW-TO.

Lista de propiedades JNDI de las aplicaciones web de MobileFirst Server

Configure las propiedades JNDI para las aplicaciones web de MobileFirst Server desplegadas en el servidor de aplicaciones.

• Configurar propiedades JNDI para aplicaciones web de MobileFirst Server
• Lista de propiedades JNDI para el servicio de administración de MobileFirst Server
• Lista de propiedades JNDI para el servicio de Live Update de MobileFirst Server
• Lista de propiedades JNDI para el tiempo de ejecución de MobileFirst
• Lista de propiedades JNDI para el servicio de envío por push de MobileFirst Server

Configurar propiedades JNDI para aplicaciones web de MobileFirst Server

Configurar las propiedades JNDI para configurar las aplicaciones web de MobileFirst Server desplegadas en el servidor de aplicaciones.
Configure las entradas de entorno JNDI de una de las siguientes maneras:

• Configurar las entradas de entorno de servidor. Los pasos para configurar las entradas de entorno de servidor dependen del servidor de aplicaciones que utilice:

  • WebSphere Application Server:
    1. En la consola de administración de WebSphere Application Server, vaya a Aplicaciones → Tipos de aplicaciones → Aplicaciones empresariales de WebSphere → nombre_aplicación → Entradas de entorno para módulos Web.
    2. En los campos de valor, introduzca los valores adecuados para su entorno de servidor.

    

  • WebSphere Application Server Liberty:

    En liberty_install_dir/usr/servers/serverName, edite el archivo server.xml y declare las propiedades JNDI de la manera siguiente:

    <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 raíz de contexto (en el ejemplo anterior: app_context_root) se conecta entre la entrada JNDI y una aplicación MobileFirst específica. Si existen varias aplicaciones MobileFirst en el mismo servidor, puede definir entradas JNDI específicas para cada aplicación utilizando el prefijo de vía de acceso de contexto.

    Nota: Algunas propiedades se definen de forma global en WebSphere Application Server Liberty, sin prefijar el nombre de la propiedad con la raíz de contexto. Para obtener una lista de estas propiedades, consulte Entradas JNDI globales.

    En el resto de las propiedades JNDI, los nombres deben prefijarse con la raíz de contexto de la aplicación:

    • Para los servicios de Live Update, la raíz de contexto debe ser /[adminContextRoot]config. Por ejemplo, si la raíz de contexto del servicio de administración es /mfpadmin, la raíz de contexto del servicio de Live Update debe ser /mfpadminconfig.
    • Para el servicio push, debe definir la raíz de contexto como /imfpush. De lo contrario, los dispositivos cliente no se podrán conectar a la misma, ya que la raíz de contexto está codificada en el SDK.
    • Para la aplicación de servicio de administración de MobileFirst, los tiempos de ejecución MobileFirst Operations Console y MobileFirst, puede definir la raíz de contexto como desee. Sin embargo, de forma predeterminada es /mfpadmin para el servicio de administración de MobileFirst, /mfpconsole para MobileFirst Operations Console, y /mfp para el tiempo de ejecución de MobileFirst.

    Por ejemplo:

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

  • Apache Tomcat:

    En tomcat_install_dir/conf, edite el archivo server.xml y declare las propiedades JNDI de la manera siguiente:

    <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>
    

    • El prefijo de vía de acceso de contexto no es necesario ya que las entradas JNDI están definidas en el elemento <Context> de una aplicación.
    • override="false" es obligatorio.
    • El atributo type siempre es java.lang.String, a menos que la propiedad lo especifique de forma diferente.

    Por ejemplo:

    <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 instala con Ant tasks, también puede establecer los valores de las propiedades JNDI al instalar.

  En mfp_install_dir/MobileFirstServer/configuration-samples, edite el archivo XML de configuración para las tareas Ant y declare los valores para las propiedades JNDI utilizando el elemento de propiedad en las siguientes etiquetas:

  • <installmobilefirstadmin>, para la administración de MobileFirst Server, MobileFirst Operations Console y servicios Live Update. Para obtener más información, consulte las tareas Ant para la instalación de MobileFirst Operations Console, artefactos de MobileFirst Server, administración de MobileFirst Server y servicios Live Update.
  • <installmobilefirstruntime>, para las propiedades de configuración de tiempo de ejecución de MobileFirst. Para obtener más información, consulte Tareas Ant para la instalación de entornos de ejecución de MobileFirst.
  • <installmobilefirstpush>, para la configuración del servicio de envío por push. Para obtener más información, consulte Tareas Ant para la instalación del servicio de envío por push de MobileFirst Server.

  Por ejemplo:

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

Lista de propiedades JNDI para el servicio de administración de MobileFirst Server

Cuando configura el servicio de administración de MobileFirst Server y MobileFirst Operations Console en su servidor de aplicaciones, establece propiedades JNDI obligatorias y opcionales, en particular para Java Management Extensions (JMX).

Se pueden definir las siguientes propiedades en la aplicación web del servicio de administración mfp-admin-service.war.

Propiedades JNDI para el servicio de administración: JMX

Propiedades JNDI para el servicio de administración: tiempo de espera

Propiedades JNDI para el servicio de administración: registro

Propiedades JNDI para el servicio de administración: proxies

Propiedades JNDI para el servicio de administración: Topologías

Propiedades JNDI para el servicio de administración: Base de datos relacional

Propiedades JNDI para el servicio de administración: Licencias

Propiedades JNDI para el servicio de administración: Configuraciones JNDI

El servicio de administración utiliza el servicio Live Update como instalación auxiliar para almacenar varias configuraciones. Utilice estas propiedades para configurar cómo alcanzar el servicio Live Update.

Propiedades JNDI para el servicio de administración: Servicio Live Update

El servicio de administración utiliza un servicio de envío por push como instalación auxiliar para almacenar varios valores push. Utilice estas propiedades para configurar cómo alcanzar el servicio de envío por push. Puesto que el servicio de envío por push está protegido por el modelo de seguridad OAuth, debe establecer varias propiedades para habilitar clientes confidenciales en OAuth.

Propiedades JNDI para el servicio de administración: Servicio de envío por push

Propiedades JNDI para MobileFirst Operations Console

Se pueden definir las siguientes propiedades en la aplicación web (mfp-admin-ui.war) de MobileFirst Operations Console.

Lista de propiedades JNDI para el servicio de Live Update de MobileFirst Server

Al configurar el servicio de Live Update de MobileFirst Server para su servidor de aplicaciones, puede definir las siguientes propiedades JNDI. La tabla lista las propiedades JNDI para el servicio de Live Update de base de datos relacional de IBM.

Para saber cómo definir estas propiedades, consulte Configurar propiedades JNDI para aplicaciones web de MobileFirst Server.

Lista de propiedades JNDI para el tiempo de ejecución de MobileFirst

Al configurar el tiempo de ejecución de MobileFirst Server para su servidor de aplicaciones, debe definir las propiedades JNDI opcionales u obligatorias.
La siguiente tabla lista las propiedades de MobileFirst que están siempre disponibles como entradas JNDI:

Lista de propiedades JNDI para el servicio de envío por push de MobileFirst Server

Configuración de orígenes de datos

Descubrimiento de algunos detalles de configuración de origen de datos pertenecientes a las bases de datos soportadas.

• Gestión del tamaño del registro de transacciones de DB2
• Configuración de migración tras error ininterrumpida de DB2 HADR para orígenes de datos de MobileFirst Server y Application Center
• Manejo de conexiones en punto muerto
• Datos obsoletos tras crear o suprimir aplicaciones de MobileFirst Operations Console

Gestión del tamaño del registro de transacciones de DB2

Al desplegar una aplicación que tenga al menos 40 MB con la consola de IBM MobileFirst Operations Console, es posible que reciba un error transaction log full.

La salida del sistema siguiente es un ejemplo del código de error transaction log full.

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

El contenido de cada aplicación se almacena en la base de datos de administración de MobileFirst.

Los archivos de registro activos están definidos en número por los parámetros de configuración de base de datos LOGPRIMARY y LOGSECOND, y en tamaño por el parámetro de configuración de base de datos de LOGFILSIZ. Una sola transacción no puede utilizar más espacio de registro que LOGFILSZ * (LOGPRIMARY + LOGSECOND) * 4096 KB.

El mandato DB2 GET DATABASE CONFIGURATION incluye información sobre el tamaño de archivo de registro, y el número de archivos de registro primarios y secundarios.

Según el tamaño más grande de la aplicación MobileFirst que esté desplegada, es posible que tenga que aumentar el espacio de registro de DB2.

Utilizando el mandato DB2 update db cfg, aumente el parámetro LOGSECOND. El espacio no está asignado cuando la base de datos está activada. En su lugar, el espacio se asigna sólo cuando es necesario.

Configuración de migración tras error ininterrumpida de DB2 HADR para orígenes de datos de MobileFirst Server y Application Center

Debe habilitar la migración tras error ininterrumpida con el perfil de Liberty de WebSphere Application Server y WebSphere Application Server. Con esta característica, puede gestionar una excepción cuando falla una base de datos y el controlador JDBC de DB2 la reencamina.

Nota: La migración tras error de DB2 HADR no está soportada en Apache Tomcat.

De forma predeterminada con DB2 HADR, cuando el controlador JDBC de DB2 realiza una redirección de cliente tras detectar que una base de datos ha fallado durante el primer intento de reutilización de una conexión existente, el controlador activa com.ibm.db2.jcc.am.ClientRerouteException, con ERRORCODE=-4498 y SQLSTATE=08506. WebSphere Application Server correlaciona esta excepción con com.ibm.websphere.ce.cm.StaleConnectionException antes de que la reciba la aplicación.

En este caso, la aplicación tendrá que tomar la excepción y volver a ejecutar la transacción. Los entornos de ejecución de MobileFirst y Application Center no gestionan la excepción pero se basan en una característica llamada migración tras error ininterrumpida. Para habilitar esta característica, debe establecer la propiedad JDBC enableSeamlessFailover en “1”.

Configuración del perfil de Liberty de WebSphere Application Server

Debe editar el archivo server.xml y añadir la propiedad enableSeamlessFailover al elemento properties.db2.jcc de los orígenes de datos de MobileFirst y Application Center. Por ejemplo:

<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>

Configuración de WebSphere Application Server

Desde la consola de administración de WebSphere Application Server para cada origen de datos de MobileFirst y Application Center:

1. Vaya a Recursos → JDBC → Orígenes de datos → DataSource name.
2. Seleccione Nuevo y añada la siguiente propiedad personalizada o actualice los valores si la propiedad ya existe: enableSeamlessFailover : 1
3. Pulse Aplicar.
4. Guarde su configuración.

Para obtener más información sobre cómo configurar una conexión con una base de datos DB2 habilitada para HADR, consulte Configuración de una conexión a una base de datos DB2 habilitada para HADR.

Manejo de conexiones en punto muerto

Configure su servidor de aplicaciones para evitar problemas de tiempo de espera excedido de base de datos.

Una StaleConnectionException es una excepción generada por el código de conexión de base de datos de perfil de servidor de aplicaciones Java cuando un controlador JDBC devuelve un error irrecuperable desde una solicitud de conexión u operación. StaleConnectionException surge cuando el proveedor de base de datos emite una excepción para indicar que una conexión actual en la agrupación de conexiones ya no es válida. Esta excepción puede suceder por muchas razones. La causa más habitual de StaleConnectionException es debida a las conexiones recuperadas desde agrupación de conexión de base de datos y averiguar que la conexión ha expirado o se ha descartado por no utilizarla durante mucho tiempo.

Puede configurar su servidor de aplicaciones para evitar esta excepción.

Configuración de Apache Tomcat

MySQL
La base de datos MySQL cierra sus conexiones tras un periodo de no actividad en una conexión. Este tiempo de espera excedido viene definido por la variable de sistema llamada wait_timeout. El valor predeterminado es 28000 segundos (8 horas).

Cuando una aplicación intenta conectarse con la base de datos después de que MySQL cierre la conexión, se genera la siguiente excepción:

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

Edite los archivos server.xml y context.xml y, para cada elemento <Resource>, añada las siguientes propiedades:

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

Por ejemplo:

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

Configuración del perfil de Liberty de WebSphere Application Server

Edite el archivo server.xml y, para cada elemento <dataSource> (bases de datos de tiempo de ejecución y de Application Center), añada un elemento <connectionManager> con la propiedad agedTimeout:

<connectionManager agedTimeout="timeout_value"/>

El valor de tiempo de espera depende, principalmente, de la cantidad de conexiones abiertas en paralelo pero también del número máximo y mínimo de conexiones en la agrupación. Por lo tanto, debe ajustar los diferentes atributos connectionManager para identificar los valores más apropiados. Para obtener más información sobre el elemento connectionManager, consulte Liberty: Elementos de configuración en el archivo server.xml.

Nota: MySQL junto con el perfil de Liberty de WebSphere Application Server o el perfil completo de WebSphere Application Server no está clasificado como una configuración soportada. Para obtener más información, consulte WebSphere Application Server Support Statement. Utilice IBM DB2 u otra base de datos soportada por WebSphere Application Server para que se beneficie de una configuración que está totalmente soportada por IBM Support.

Datos obsoletos tras crear o suprimir aplicaciones de MobileFirst Operations Console

En un servidor de aplicaciones Tomcat 8, si utiliza una base de datos MySQL algunas llamadas de MobileFirst Operations Console a servicios devuelven un error 404.

En un servidor de aplicaciones Tomcat 8, si trabaja con una base de datos MySQL, cuando utilice MobileFirst Operations Console para suprimir una aplicación o añadir una nueva e intentar actualizar la consola un par de veces, es posible que vea datos obsoletos. Por ejemplo, es posible que los usuarios vean una aplicación ya suprimida en la lista.

Para evitar este problema, cambie el nivel de aislamiento a READ_COMMITTED en el origen de datos o en el sistema de gestión de bases de datos.

Para conocer el significado de READ_COMMITTED, consulte la documentación MySQL en http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html.

• Para cambiar el nivel de aislamiento a READ_COMMITTED en el origen de datos, modifique el archivo de configuración de Tomcat server.xml: En la sección <Resource name=”jdbc/mfpAdminDS” …/> añada el atributo defaultTransactionIsolation=”READ_COMMITTED”.
• Para cambiar el nivel de aislamiento a READ_COMMITTED de forma global en el sistema de gestión de bases de datos, consulte la Página SET TRANSACTION Syntax de la documentación de MySQL en http://dev.mysql.com/doc/refman/5.7/en/set-transaction.html.

Configuración del perfil completo de WebSphere Application Server

DB2 u Oracle
Para minimizar los problemas de conexión en punto muerto, compruebe la configuración de las agrupaciones de conexiones en cada origen de datos en la consola de administración de WebSphere Application Server.

1. Inicie sesión en la consola de administración de WebSphere Application Server.
2. Seleccione Recursos → Proveedores JDBC → proveedor_jdbc_base_de_datos → Orígenes de datos → su_origen_datos → Propiedades de agrupación de conexiones.
3. Establezca el valor de Conexiones mínimas en 0.
4. Establezca el valor de Tiempo de recopilación para que sea menor que el valor de Tiempo de espera no utilizado.
5. Asegúrese de que la propiedad Política de depuración se establece en EntirePool (predeterminado).

Para obtener más información, consulte Valores de agrupación de conexiones.

MySQL

1. Inicie sesión en la consola de administración de WebSphere Application Server.
2. Seleccione Recursos → JDBC → Orígenes de datos.
3. Para cada origen de datos de MySQL:
   • Pulse el origen de datos.
   • Seleccione las propiedades de Agrupación de conexiones en Propiedades adicionales.
   • Modifique el valor de la propiedad Tiempo de espera superado. El valor debe ser inferior a la variable de sistema wait_timeout de MySQL para que las conexiones se depuren antes de que MySQL las cierre.
   • Pulse Aceptar.

Nota: MySQL junto con el perfil de Liberty de WebSphere Application Server o el perfil completo de WebSphere Application Server no está clasificado como una configuración soportada. Para obtener más información, consulte WebSphere Application Server Support Statement. Utilice IBM DB2 u otra base de datos soportada por WebSphere Application Server para que se beneficie de una configuración que está totalmente soportada por IBM Support.

Configuración de los mecanismos de registro y supervisión

Mobile Foundation informa de errores, avisos y mensajes informativos en un archivo de registro. El mecanismo de registro subyacente varía en función del servidor de aplicaciones.

MobileFirst Server

Mobile Foundation (MobileFirst Server para abreviar) utiliza el paquete estándar de java.util.logging. De forma predeterminada, todos los registros de MobileFirst van a los archivos de registro del servidor de aplicaciones. Puede controlar el registro de MobileFirst Server utilizando las herramientas estándar disponibles en cada servidor de aplicaciones. Por ejemplo, si desea activar el registro de rastreo en WebSphere Application Server Liberty, añada un elemento de rastreo al archivo server.xml. Para activar el registro de rastreo en WebSphere Application Server, utilice la pantalla de registro en la consola para habilitar el rastreo de registros de MobileFirst.

Todos los registros de MobileFirst empiezan con com.ibm.mfp.
Los registros de Application Center empiezan con com.ibm.puremeap.

Para obtener más información sobre los modelos de registro de cada servidor de aplicaciones, incluyendo la ubicación de los archivos de registro, consulte la documentación del servidor de aplicaciones correspondiente, como se muestra en la siguiente tabla.

Correlaciones a nivel de registro

MobileFirst Server utiliza la API de java.util.logging. Los niveles de registro se correlacionan con los siguientes niveles:

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

Herramientas de supervisión de registro

Para Apache Tomcat, puede utilizar IBM Operations Analytics - Log Analysis u otras herramientas de supervisión de archivos de registro estándar del sector para supervisar los registros y resaltar errores y avisos.

Para WebSphere Application Server, utilice los recursos de visualización de registros descritos en IBM Knowledge Center. Los URL están listados en la tabla de la sección MobileFirst Server de esta página.

Conectividad de fondo

Para habilitar el rastreo para supervisar la conectividad de fondo, consulte la documentación de su plataforma de servidor de aplicaciones específica en la tabla de la sección MobileFirst Server de esta página. Utilice el paquete com.ibm.mfp.server.js.adapter y establezca el nivel de registro en FINEST.

Registro de auditoría para operaciones de administración

MobileFirst Operations Console almacena un registro de auditoría para iniciar y cerrar sesión y para todas las operaciones de administración, como el despliegue de aplicaciones o adaptadores o el bloqueo de aplicaciones. Puede inhabilitar el registro de auditoría estableciendo la propiedad JNDI mfp.admin.audit en false en la aplicación web del servicio de administración de MobileFirst (mfp-admin-service.war).

Cuando el registro de auditoría está habilitado, puede descargarlo de MobileFirst Operations Console pulsando el enlace de Registro de auditoría en el pie de página.

Problemas de inicio de sesión y autenticación

Para diagnosticar problemas de inicio de sesión y autenticación, habilite el paquete com.ibm.mfp.server.security para rastrear y establezca el nivel de registro en FINEST.

Configuración de varios tiempos de ejecución

Puede configurar MobileFirst Server con varios tiempos de ejecución, creando una diferenciación visual entre “tipos” de aplicación en MobileFirst Operations Console.

Nota: los tiempos de ejecución múltiple no son compatibles en una instancia del servidor de Mobile Foundation creada por el servicio Mobile Foundation IBM Cloud. En el servicio de IBM, debe crear varias instancias de servicio en su lugar.

Ir a

• Configuración de varios tiempos de ejecución en el perfil de Liberty de WebSphere
• Registro de aplicaciones y despliegue de adaptadores en tiempos de ejecución diferentes
• Exportación e importación de configuraciones de tiempos de ejecución

Configuración de varios tiempos de ejecución en el perfil de Liberty de WebSphere

1. Abra el archivo server.xml del servidor de aplicaciones. Normalmente ubicado en la carpeta [servidor-aplicaciones]/usr/servers/server-name/. Por ejemplo, con MobileFirst Developer Kit, el archivo se puede encontrar en [carpeta-instalación]/mfp-server/usrs/servers/mfp/server.xml.

2. Añada un segundo elemento application:

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

3. Añada un segundo conjunto de entradas 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. Añada un segundo elemento 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>
   

   Nota:

   • Asegúrese de que dataSource apunta a un esquema de base de datos diferente.
   • Asegúrese de que ha creado otra instancia de base de datos para el nuevo tiempo de ejecución.
   • En el entorno de desarrollo, añada createDatabase="create" en el elemento hijo properties.derby.embedded.

5. Reinicie el servidor de aplicaciones.

Registro de aplicaciones y despliegue de adaptadores en tiempos de ejecución diferentes

Cuando MobileFirst Server se configura con varios tiempos de ejecución, el registro de aplicaciones y el despliegue de adaptadores es ligeramente diferente.

• Registro y despliegue desde MobileFirst Operations Console
• Registro y despliegue desde la línea de mandatos

Registro y despliegue desde MobileFirst Operations Console

Al realizar estas acciones en MobileFirst Operations Console, ahora debe seleccionar el tiempo de ejecución en el que registrar o desplegar.

Registro y despliegue desde la línea de mandatos

Al realizar estas acciones utilizando la herramienta de línea de mandatos mfpdev, ahora debe añadir el nombre del tiempo de ejecución en el que registrar o desplegar.

Para registrar una aplicación: mfpdev app register <server-name><runtime-name>.

mfpdev app register local second-runtime

Para desplegar un adaptador: mfpdev adapter deploy <server-name><runtime-name>.

mfpdev adapter deploy local second-runtime

• local es el nombre de la definición de servidor predeterminada en MobileFirst CLI. Sustituya local con el nombre de definición de servidor en el que debe registrar o desplegar.
• runtime-name es el nombre del tiempo de ejecución en el que registrar o desplegar.

Para saber más utilice los mandatos help de CLI:

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

Exportación e importación de configuraciones de tiempos de ejecución

Puede exportar una configuración de tiempo de ejecución e importarla en otro MobileFirst Server utilizando la API REST del servicio de administración de MobileFirst Server.

Por ejemplo, puede configurar una configuración de tiempo de ejecución en un entorno de desarrollo, exportar su configuración e importarla a un entorno de pruebas para una configuración rápida y, a continuación, acabar de configurarla para las necesidades específicas del entorno de pruebas.

Descubra todas las API REST en la referencia de API.

Configuración de seguimiento de licencias

El seguimiento de licencias está habilitado de forma predeterminada. Lea los siguientes temas para saber cómo puede configurar el seguimiento de licencias. Para obtener más información sobre el seguimiento de licencias, consulte Seguimiento de licencia.

• Configuración del seguimiento de licencias para dispositivos de cliente y dispositivos dirigibles
• Configuración de archivos de registro de IBM License Metric Tool

Configuración del seguimiento de licencias para dispositivos de cliente y dispositivos dirigibles

El seguimiento de licencia para dispositivos cliente y dispositivos dirigibles está habilitada de forma predeterminada. Los informes de licencia están disponibles en MobileFirst Operations Console. Puede especificar las siguientes propiedades JNDI para cambiar los valores predeterminados para el seguimiento de licencia.

Nota: Si tiene un contrato que defina la utilización de licencias de señales, consulte también Instalación y configuración para la gestión de licencias de señal.

Puede especificar las siguientes propiedades JNDI para cambiar los valores predeterminados para el seguimiento de licencia.

mfp.device.decommission.when
El número de días de inactividad después del cual un dispositivo se decomisa por la tarea de decomisar dispositivo. Los informes de licencia no hacen recuento de los dispositivos decomisados como dispositivos activos. El valor predeterminado para la propiedad es 90 días. No establezca un valor inferior a 30 días si su software está licenciado por dispositivo de cliente o por dispositivo dirigible o los informes de licencia no serán suficientes para probar la conformidad.

mfp.device.archiveDecommissioned.when
Un valor, en días, que define cuando se colocan los dispositivos decomisados en un archivo de archivado cuando se ejecuta la tarea de decomisar. Los dispositivos archivados se graban en un archivo en el directorio home\devices_archive de IBM MobileFirst Server. El nombre del archivo que contiene la indicación de fecha y hora de cuando se creó el archivo de archivado. El valor predeterminado es 90 días.

mfp.device.decommissionProcessingInterval
Define la frecuencia (en segundos) con la que se ejecuta la tarea de decomisar. Valor predeterminado: 86400, que es un día. La tarea de decomisar realiza las siguientes acciones:

• Decomisa los dispositivos inactivos, con base en el valor mfp.device.decommission.when.
• Opcionalmente, archiva dispositivos decomisados antiguos, con base en el valor de mfp.device.archiveDecommissioned.when.
• Genera el informe de seguimiento de licencia.

mfp.licenseTracking.enabled
Un valor utilizado para habilitar o inhabilitar el seguimiento de licencia en Mobile Foundation. De forma predeterminada, el seguimiento de licencia está habilitado. Por motivos de rendimiento, puede inhabilitar este distintivo cuando Mobile Foundation no está licenciado por el dispositivo de cliente o el dispositivo dirigible. Cuando el seguimiento de dispositivo está inhabilitado, los informes de licencia también están inhabilitados y no se generan métricas de licencia. En ese caso, solo se generan informes para recuento de aplicaciones de IBM License Metric Tool.

Para obtener más información sobre cómo especificar propiedades JNDI, consulte Lista de propiedades JNDI para el tiempo de ejecución de MobileFirst.

Configuración de archivos de registro de IBM License Metric Tool

Mobile Foundation genera archivos de IBM Software License Metric Tag (SLMT). Las versiones de IBM License Metric Tool que soportan IBM Software License Metric Tag pueden generar informes de consumo de licencia. Lea esto para comprender cómo configurar la ubicación y el tamaño máximo de los archivos generados.

De forma predeterminada, los archivos de IBM Software License Metric Tag se encuentran en los siguientes directorios:

• En Windows: %ProgramFiles%\ibm\common\slm
• En sistemas operativos UNIX y similares a UNIX: /var/ibm/common/slm

Si no se puede escribir en los directorios, los archivos se crean en el directorio de registro del servidor de aplicaciones que se ejecuta en el entorno de ejecución de MobileFirst.

Puede configurar la ubicación y la gestión de los archivos con las siguientes propiedades:

• license.metric.logger.output.dir: Ubicación de los archivos IBM Software License Metric Tag
• license.metric.logger.file.size: Tamaño máximo de un archivo SLMT antes de llevar a cabo una rotación. El tamaño predeterminado es 1 MB.
• license.metric.logger.file.number: Número máximo de archivos de archivado SLMT a mantener en rotación. El número predeterminado es 10.

Para cambiar los valores predeterminados, debe crear un archivo de propiedades Java con el formato key=value, y proporcionar la vía de acceso al archivo de propiedades a través de la propiedad JVM license_metric_logger_configuration.

Para obtener más información sobre los informes de IBM License Metric Tool, consulte Integración con IBM License Metric Tool.

Configuración SSL de WebSphere Application Server y adaptadores HTTP

Al establecer una propiedad, puede permitir que los adaptadores HTTP se beneficien de la configuración SSL de WebSphere.

De forma predeterminada, los adaptadores HTTP no utilizan SSL de WebSphere concatenando el almacén de confianza de Java Runtime Environment (JRE) con el almacén de claves de MobileFirst Server, descrito en Configuración del almacén de claves de MobileFirst Server. Consulte también Configuración SSL entre adaptadores y servidores de fondo utilizando certificados autofirmados.

Para tener adaptadores HTTP utilice la configuración SSL de WebSphere, establezca la propiedad JNDI ssl.websphere.config en true. El valor tiene los siguientes efectos por orden de precedencia:

1. Los adaptadores que se ejecutan en WebSphere utilizan el almacén de claves de WebSphere y no el de MobileFirst Server.
2. Si la propiedad ssl.websphere.alias está definida, el adaptador utiliza la configuración SSL asociada con el alias como se establece en esta propiedad.