Configuring MobileFirst Server

Overview

Consider your backup and recovery policy, optimize your MobileFirst Server Server configuration, and apply access restrictions and security options.

Jump to

• Endpoints of the MobileFirst Server production server
• Configuring MobileFirst Server to enable TLS V1.2
• Configuring user authentication for MobileFirst Server administration
• List of JNDI properties of the MobileFirst Server web applications
• Configuring data sources
• Configuring logging and monitoring mechanisms
• Configuring multiple runtimes
• Configuring license tracking
• WebSphere Application Server SSL configuration and HTTP adapters

Endpoints of the MobileFirst Server production server

You can create allowlists and blocklists for the endpoints of the IBM MobileFirst Server.

Note: Information regarding URLs that are exposed by Mobile Foundation is provided as a guideline. Organizations must ensure the URLs are tested in an enterprise infrastructure, based on what has been enabled for allow and block lists.

Configuring MobileFirst Server to enable TLS V1.2

For MobileFirst Server to communicate with devices that support only Transport Layer Security v1.2 (TLS) V1.2, among the SSL protocols, you must complete the following instructions.

The steps to configure MobileFirst Server to enable Transport Layer Security (TLS) V1.2 depend on how MobileFirst Server connects to devices.

• If MobileFirst Server is behind a reverse proxy that decrypts SSL-encoded packets from devices before it passes the packets to the application server, you must enable TLS V1.2 support on your reverse proxy. If you use IBM HTTP Server as your reverse proxy, see Securing IBM HTTP Server for instructions.
• If MobileFirst Server communicates directly with devices, the steps to enable TLS V1.2 depend on whether your application serveris Apache Tomcat, WebSphere Application Server Liberty profile, or WebSphere Application Server full profile.

Apache Tomcat

1. Confirm that the Java Runtime Environment (JRE) supports TLS V1.2. Ensure that you have one of the following JRE versions:
   • Oracle JRE 1.7.0_75 or later
   • Oracle JRE 1.8.0_31 or later
2. Edit the conf/server.xml file and modify the Connector element that declares the HTTPS port so that the sslEnabledProtocols attribute has the following value: sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1,SSLv2Hello".

WebSphere Application Server Liberty profile

1. Confirm that the Java Runtime Environment (JRE) supports TLS V1.2.

   • If you use an IBM Java SDK, ensure that your IBM Java SDK is patched for the POODLE vulnerability. You can find the minimum IBM Java SDK versions that contain the patch for your version of WebSphere Application Server in Security Bulletin: Vulnerability in SSLv3 affects IBM WebSphere Application Server (CVE-2014-3566).

     Note: You can use the versions that are listed in the security bulletin or later versions.

   • If you use an Oracle Java SDK, ensure that you have one of the following versions:

     • Oracle JRE 1.7.0_75 or later
     • Oracle JRE 1.8.0_31 or later
2. If you use an IBM Java SDK, edit the server.xml file.
   • Add the following line: <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" sslProtocol="SSL_TLSv2"/>
   • Add the sslProtocol="SSL_TLSv2" attribute to all existing <ssl> elements.

WebSphere Application Server full profile

1. Confirm that the Java Runtime Environment (JRE) supports TLS V1.2.

   Ensure that your IBM Java SDK is patched for the POODLE vulnerability. You can find the minimum IBM Java SDK versions that contain the patch for your version of WebSphere Application Server in Security Bulletin: Vulnerability in SSLv3 affects IBM WebSphere Application Server (CVE-2014-3566).

   Note: You can use the versions that are listed in the security bulletin or later versions.

2. Log in to WebSphere Application Server administrative console, and click Security → SSL certificate and key management → SSL configurations.
3. For each SSL configuration listed, modify the configuration to enable TLS V1.2.
   • Select an SSL configuration and then, under Additional Properties, click Quality of protections (QoP) settings.
   • From the Protocol list, select SSL_TLSv2.
   • Click Apply and then save the changes.

Configuring user authentication for MobileFirst Server administration

MobileFirst Server administration requires user authentication. You can configure user authentication and choose an authentication method. Then, the configuration procedure depends on the web application server that you use.

Important: If you use stand-alone WebSphere Application Server full profile, use an authentication method other than the simple WebSphere authentication method (SWAM) in global security. You can use lightweight third-party authentication (LTPA). If you use SWAM, you might experience unexpected authentication failures.

You must configure authentication after the installer deploys the MobileFirst Server administration web applications in the web application server.

The MobileFirst Server administration has the following Java Platform, Enterprise Edition (Java EE) security roles defined:

• mfpadmin
• mfpdeployer
• mfpoperator
• mfpmonitor

You must map the roles to the corresponding sets of users. The mfpmonitor role can view data but cannot change any data. The following tables list MobileFirst roles and functions for production servers.

Deployment

MobileFirst Server management

Application management

Basically, all roles can issue GET requests, the mfpadmin, mfpdeployer, and mfpmonitor roles can also issue POST and PUT requests, and the mfpadmin and mfpdeployer roles can also issue DELETE requests.

Requests related to push notifications

Disabling

If you choose to use an authentication method through a user repository such as LDAP, you can configure the MobileFirst Server administration so that you can use users and groups with the user repository to define the Access Control List (ACL) of the MobileFirst Server administration. This procedure depends on the type and version of the web application server that you use.

Configuring WebSphere Application Server full profile for MobileFirst Server administration

Configure security by mapping the MobileFirst Server administration Java EE roles to a set of users for both web applications.

You define the basics of user configuration in the WebSphere Application Server console. Access to the console is usually by this address: https://localhost:9043/ibm/console/

1. Select Security → Global Security.
2. Select Security Configuration Wizard to configure users. You can manage individual user accounts by selecting Users and Groups → Manage Users.
3. Map the roles mfpadmin, mfpdeployer, mfpmonitor, and mfpoperator to a set of users.
   • Select Servers → Server Types → WebSphere application servers.
   • Select the server.
   • In the Configuration tab, select Applications → Enterprise applications.
   • Select MobileFirst_Administration_Service.
   • In the Configuration tab, select Details → Security role to user/group mapping.
   • Perform the necessary customization.
   • Click OK.
   • Repeat the steps to map the roles for the console web application. This time select MobileFirst_Administration_Console.
   • Click Save to save the changes.

Configuring WebSphere Application Server Liberty profile for MobileFirst Server administration

In WebSphere Application Server Liberty profile, you configure the roles of mfpadmin, mfpdeployer, mfpmonitor, and mfpoperator in the server.xml configuration file of the server.

To configure the security roles, you must edit the server.xml file. In the <application-bnd> element of each <application> element, create <security-role> elements. Each <security-role> element is for each roles: mfpadmin, mfpdeployer, mfpmonitor, and mfpoperator. Map the roles to the appropriate user group name, in this example: mfpadmingroup, mfpdeployergroup, mfpmonitorgroup, or mfpoperatorgroup. These groups are defined through the <basicRegistry> element. You can customize this element or replace it entirely with an <ldapRegistry> element or a <safRegistry> element.

Then, to maintain good response times with a large number of installed applications, for example with 80 applications, you should configure a connection pool for the administration database.

1. Edit the server.xml file. For example:

   <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. Define the AppCenterPool size:

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

3. In the <dataSource> element, define a reference to the connection manager:

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

Configuring Apache Tomcat for MobileFirst Server administration

You must configure the Java EE security roles for the MobileFirst Server administration on the Apache Tomcat web application server.

1. If you installed the MobileFirst Server administration manually, declare the following roles in the conf/tomcat-users.xml file:

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

2. Add roles to the selected users, for example:

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

3. You can define the set of users as described in the Apache Tomcat documentation, Realm Configuration HOW-TO.

List of JNDI properties of the MobileFirst Server web applications

Configure the JNDI properties for the MobileFirst Server web applications that are deployed to the application server.

• Setting up JNDI properties for MobileFirst Server web applications
• List of JNDI properties for MobileFirst Server administration service
• List of JNDI properties for MobileFirst Server config service
• List of JNDI properties for MobileFirst Server live update service
• List of JNDI properties for MobileFirst runtime
• List of JNDI properties for MobileFirst Server push service
• List of JNDI properties for MobileFirst Server liveupdate service

Setting up JNDI properties for MobileFirst Server web applications

Set up JNDI properties to configure the MobileFirst Server web applications that are deployed to the application server.
Set the JNDI environment entries in one of the following ways:

• Configure the server environment entries. The steps to configure the server environment entries depends on which application server you use:

  • WebSphere Application Server:
    1. In the WebSphere Application Server administration console, go to Applications → Application Types → WebSphere enterprise applications → application_name → Environment entries for Web modules.
    2. In the Value fields, enter values that are appropriate to your server environment.

    

  • WebSphere Application Server Liberty:

    In liberty_install_dir/usr/servers/serverName, edit the server.xml file, and declare the JNDI properties as follows:

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

    The context root (in the previous example: app_context_root) connects between the JNDI entry and a specific MobileFirst application. If multiple MobileFirst applications exist on the same server, you can define specific JNDI entries for each application by using the context path prefix.

    Note: Some properties are defined globally on WebSphere Application Server Liberty, without prefixing the property name by the context root. For a list of these properties, see Global JNDI entries.

    For all other JNDI properties, the names must be prefixed with the context root of the application:

    • For the config service, the context root must be /[adminContextRoot]config. For example, if the context root of the administration service is /mfpadmin, then the context root of the config service must be /mfpadminconfig.
    • For the push service, you must define the context root as /imfpush. Otherwise, the client devices cannot connect to it as the context root is hardcoded in the SDK.
    • For the liveupdate service, you must define the context root as /mfpliveupdate. Otherwise, the client devices cannot connect to it as the context root is hardcoded in the SDK.
    • For the MobileFirst Administration Service application, the MobileFirst Operations Console and MobileFirst runtime, you can define the context root as you want. However, by default it is /mfpadmin for MobileFirst Administration Service, /mfpconsole for MobileFirst Operations Console, and /mfp for MobileFirst runtime.

    For example:

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

  • Apache Tomcat:

    In tomcat_install_dir/conf, edit the server.xml file, and declare the JNDI properties as follows:

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

    • The context path prefix is not needed because the JNDI entries are defined inside the <Context> element of an application.
    • override="false" is mandatory.
    • The type attribute is always java.lang.String, unless specified differently for the property.

    For example:

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

• If you install with Ant tasks, you can also set the values of the JNDI properties at installation time.

  In mfp_install_dir/MobileFirstServer/configuration-samples, edit the configuration XML file for the Ant tasks, and declare the values for the JNDI properties by using the property element inside the following tags:

  • <installmobilefirstadmin>, for MobileFirst Server administration, MobileFirst Operations Console, and config services. For more information, see Ant tasks for installation of MobileFirst Operations Console, MobileFirst Server artifacts, MobileFirst Server administration, and config services.
  • <installmobilefirstruntime>, for MobileFirst runtime configuration properties. For more information, see Ant tasks for installation of MobileFirst runtime environments.
  • <installmobilefirstpush>, for configuration of the push service. For more information, see Ant tasks for installation of MobileFirst Server push service.

  For example:

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

List of JNDI properties for MobileFirst Server administration service

When you configure MobileFirst Server administration service and MobileFirst Operations Console for your application server, you set optional or mandatory JNDI properties, in particular for Java Management Extensions (JMX).

The following properties can be set on the administration service web application mfp-admin-service.war.

JNDI properties for administration service: JMX

JNDI properties for administration service: timeout

JNDI properties for administration service: logging

JNDI properties for administration service: proxies

JNDI properties for administration service: topologies

JNDI properties for administration service: relational database

JNDI properties for administration service: licensing

JNDI properties for administration service: JNDI configurations

The administration service uses a config service as an auxiliary facility to store various configurations. Use these properties to configure how to reach the config service.

JNDI properties for administration service: config service

The administration service uses a push/liveupdate service as an auxiliary facility to store various push/liveupdate settings. Use these properties to configure how to reach the push/liveupdate service. Because the push/liveupdate service is protected by the OAuth security model, you must set various properties to enable confidential clients in OAuth.

JNDI properties for administration service: push service

JNDI properties for administration service: liveupdate service

JNDI properties for MobileFirst Operations Console

The following properties can be set on the web application (mfp-admin-ui.war) of MobileFirst Operations Console.

List of JNDI properties for MobileFirst Server live update service

When you configure the MobileFirst Server live update service for your application server, you can set the following JNDI properties. The table lists the JNDI properties for the IBM relational database live update service.

List of JNDI properties for MobileFirst Server config service

When you configure the MobileFirst Server config service for your application server, you can set the following JNDI properties. The table lists the JNDI properties for the IBM relational database config service.

To know how to set those properties, see Setting up JNDI properties for MobileFirst Server web applications.

List of JNDI properties for MobileFirst runtime

When you configure the MobileFirst Server runtime for your application server, you need to set the optional or mandatory JNDI properties.
The following table lists the MobileFirst properties that are always available as JNDI entries:

List of JNDI properties for MobileFirst Server push service

List of JNDI properties for MobileFirst Server liveupdate service

When you configure the MobileFirst Server config service for your application server, you can set the following JNDI properties. The table lists the JNDI properties for the IBM relational database liveupdate service.

Configuring data sources

Find out some data source configuration details pertaining to the supported databases.

• Managing the DB2 transaction log size
• Configuring DB2 HADR seamless failover for MobileFirst Server and Application Center data sources
• Handling stale connections
• Stale data after creating or deleting apps from MobileFirst Operations Console

Managing the DB2 transaction log size

When you deploy an application that is at least 40 MB with IBM MobileFirst Operations Console, you might receive a transaction log full error.

The following system output is an example of the transaction log full error code.

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

The content of each application is stored in the MobileFirst administration database.

The active log files are defined in number by the LOGPRIMARY and LOGSECOND database configuration parameters, and in size by the LOGFILSIZ database configuration parameter. A single transaction cannot use more log space than LOGFILSZ * (LOGPRIMARY + LOGSECOND) * 4096 KB.

The DB2 GET DATABASE CONFIGURATION command includes information about the log file size, and the number of primary and secondary log files.

Depending on the largest size of the MobileFirst application that is deployed, you might need to increase the DB2 log space.

Using the DB2 update db cfg command, increase the LOGSECOND parameter. Space is not allocated when the database is activated. Instead, the space is allocated only as needed.

Configuring DB2 HADR seamless failover for MobileFirst Server and Application Center data sources

You must enable the seamless failover feature with WebSphere Application Server Liberty profile and WebSphere Application Server. With this feature, you can manage an exception when a database fails over and gets rerouted by the DB2 JDBC driver.

Note: DB2 HADR failover is not supported for Apache Tomcat.

By default with DB2 HADR, when the DB2 JDBC driver performs a client reroute after detecting that a database failed over during the first attempt to reuse an existing connection, the driver triggers com.ibm.db2.jcc.am.ClientRerouteException, with ERRORCODE=-4498 and SQLSTATE=08506. WebSphere Application Server maps this exception to com.ibm.websphere.ce.cm.StaleConnectionException before it is received by the application.

In this case, the application would have to catch the exception and execute again the transaction. The MobileFirst and Application Center runtime environments do not manage the exception but rely on a feature that is called seamless failover. To enable this feature, you must set the enableSeamlessFailover JDBC property to “1”.

WebSphere Application Server Liberty profile configuration

You must edit the server.xml file, and add the enableSeamlessFailover property to the properties.db2.jcc element of the MobileFirst and Application Center data sources. For example:

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

WebSphere Application Server configuration

From the WebSphere Application Server administrative console for each MobileFirst and Application Center data source:

1. Go to Resources → JDBC → Data sources → DataSource name.
2. Select New and add the following custom property, or update the values if the properties already exist: enableSeamlessFailover : 1
3. Click Apply.
4. Save your configuration.

For more information about how to configure a connection to an HADR-enabled DB2 database, see Setting up a connection to an HADR-enabled DB2 database.

Handling stale connections

Configure your application server to avoid database timeout issues.

A StaleConnectionException is an exception that is generated by the Java application server profile database connection code when a JDBC driver returns an unrecoverable error from a connection request or operation. The StaleConnectionException is raised when the database vendor issues an exception to indicate that a connection currently in the connection pool is no longer valid. This exception can happen for many reasons. The most common cause of StaleConnectionException is due to retrieving connections from the database connection pool and finding out that the connection has timed out or dropped when it was unused for a long time.

You can configure your application server to avoid this exception.

Apache Tomcat configuration

MySQL
The MySQL database closes its connections after a period of non-activity on a connection. This timeout is defined by the system variable called wait_timeout. The default is 28000 seconds (8 hours).

When an application tries to connect to the database after MySQL closes the connection, the following exception is generated:

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

Edit the server.xml and context.xml files, and for every <Resource> element add the following properties:

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

For example:

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

WebSphere Application Server Liberty profile configuration

Edit the server.xml file and for every <dataSource> element (runtime and Application Center databases) add a <connectionManager> element with the agedTimeout property:

<connectionManager agedTimeout="timeout_value"/>

The timeout value depends mainly on the number of opened connections in parallel but also on the minimum and maximum number of the connections in the pool. Hence, you must tune the different connectionManager attributes to identify the most adequate values. For more information about the connectionManager element, see Liberty: Configuration elements in the server.xml file.

Note: MySQL in combination with WebSphere Application Server Liberty profile or WebSphere Application Server full profile is not classified as a supported configuration. For more information, see WebSphere Application Server Support Statement. Use IBM DB2 or another database that is supported by WebSphere Application Server to benefit from a configuration that is fully supported by IBM Support.

Stale data after creating or deleting apps from MobileFirst Operations Console

On a Tomcat 8 application server, if you use a MySQL database, some calls from MobileFirst Operations Console to services return a 404 error.

On a Tomcat 8 application server, if you work with a MySQL database, when you use MobileFirst Operations Console to delete an app, or add a new one, and try to refresh the console a couple of times, you might see stale data. For example, users might see an already deleted app in the list.

To avoid this problem, change the isolation level to READ_COMMITTED, either in the data source, or in the database management system.

For the meaning of READ_COMMITTED, see the MySQL documentation at http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html.

• To change the isolation level to READ_COMMITTED in the data source, modify the server.xml Tomcat configuration file: In the <Resource name=”jdbc/mfpAdminDS” …/> section, add the defaultTransactionIsolation=”READ_COMMITTED” attribute.
• To change the isolation level to READ_COMMITTED globally in the database management system, refer to the SET TRANSACTION Syntax page of the MySQL documentation at http://dev.mysql.com/doc/refman/5.7/en/set-transaction.html.

WebSphere Application Server full profile configuration

DB2 or Oracle
To minimize the stale connection issues, check the connection pools configuration on each data source in WebSphere Application Server administration console.

1. Log in to the WebSphere Application Server administration console.
2. Select Resources → JDBC Providers → database_jdbc_provider → Data Sources → your_data_source → Connection pool properties.
3. Set the Minimum connections value to 0.
4. Set the Reap time value to be lesser than the Unused timeout value.
5. Make sure that the Purge policy property is set to EntirePool (default).

For more information, see Connection pool settings.

MySQL

1. Log in to the WebSphere Application Server administration console.
2. Select Resources → JDBC → Data sources.
3. For each MySQL data source:
   • Click the data source.
   • Select Connection pool properties under Additional Properties.
   • Modify the value of the Aged timeout property. The value must be lower than the MySQL wait_timeout system variable so that the connections are purged before MySQL closes these connections.
   • Click OK.

Note: MySQL in combination with WebSphere Application Server Liberty profile or WebSphere Application Server full profile is not classified as a supported configuration. For more information, see WebSphere Application Server Support Statement. Use IBM DB2 or another database that is supported by WebSphere Application Server to benefit from a configuration that is fully supported by IBM Support.

Configuring logging and monitoring mechanisms

Mobile Foundation reports errors, warnings, and informational messages into a log file. The underlying logging mechanism varies by application server.

MobileFirst Server

Mobile Foundation (MobileFirst Server for short) uses the standard java.util.logging package. By default, all MobileFirst logging goes to the application server log files. You can control MobileFirst Server logging by using the standard tools that are available in each application server. For example, if you want to activate trace logging in WebSphere Application Server Liberty, add a trace element to the server.xml file. To activate trace logging in WebSphere Application Server, use the logging screen in the console and enable trace for MobileFirst logs.

MobileFirst logs all begin with com.ibm.mfp.
Application Center logs begin with com.ibm.puremeap.

For more information about the logging models of each application server, including the location of the log files, see the documentation for the relevant application server, as shown in the following table.

Log level mappings

MobileFirst Server uses the java.util.logging API. The logging levels map to the following levels:

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

Log monitoring tools

For Apache Tomcat, you can use IBM Operations Analytics - Log Analysis or other industry standard log file monitoring tools to monitor logs and highlight errors and warnings.

For WebSphere Application Server, use the log viewing facilities that are described in IBM Knowledge Center. The URLs are listed in the table in the MobileFirst Server section of this page.

Back-end connectivity

To enable trace to monitor back-end connectivity, see the documentation for your specific application server platform in the table of section MobileFirst Server of this page. Use the com.ibm.mfp.server.js.adapter package and set the log level to FINEST.

Audit log for administration operations

MobileFirst Operations Console stores an audit log for login, logout, and for all administration operations, such as deploying apps or adapters or locking apps. You can disable the audit log by setting the JNDI property mfp.admin.audit to false on the web application of the MobileFirst administration service (mfp-admin-service.war).

When the audit log is enabled, you can download it from MobileFirst Operations Console by clicking the Audit log link in the footer of the page.

Login and authentication issues

To diagnose login and authentication issues, enable the package com.ibm.mfp.server.security for trace and set the log level to FINEST.

Configuring multiple runtimes

You can configure MobileFirst Server with multiple runtimes, creating a visual differentiation between application “types” in the MobileFirst Operations Console.

Note: multiple runtimes are not supported in a Mobile Foundation server instance created by the Mobile Foundation IBM Cloud service. In the IBM Cloud service, you must create multiple service instances instead.

Jump to

• Configuring multiple runtimes in WebSphere Liberty profile
• Registering applications and deploying adapters to different runtimes
• Exporting and importing runtime configurations

Configuring multiple runtimes in WebSphere Liberty profile

1. Open the server.xml file of the application server. Typically located in the [application-server]/usr/servers/server-name/ folder. For example, with the MobileFirst Developer Kit, the file can be found it [installation-folder]/mfp-server/usrs/servers/mfp/server.xml.

2. Add a second application element:

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

3. Add a second set of JNDI entries:

   <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. Add a second dataSource element:

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

   Note:

   • Make sure the dataSource is pointing to a different database schema.
   • Make sure you have created another database instance for the new runtime.
   • In the development environment, add createDatabase="create" in the properties.derby.embedded child-element.

5. Restart the application server.

Registering applications and deploying adapters to different runtimes

When a MobileFirst Server is configured with multiple runtimes, the registration of applications and deployment of adapters is slightly different.

• Registering and deploying from the MobileFirst Operations Console
• Registering and deploying from the Command-line

Registering and deploying from the MobileFirst Operations Console

When performing these actions in the MobileFirst Operations Console, you now need to select the runtime to register or deploy to.

Registering and deploying from the Command-line

When performing these actions using the mfpdev command-line tool, you now need to add the runtime name to register or deploy to.

To register an application: mfpdev app register <server-name> <runtime-name>.

mfpdev app register local second-runtime

To deploy an adapter: mfpdev adapter deploy <server-name> <runtime-name>.

mfpdev adapter deploy local second-runtime

• local is the name of the default server definition in the MobileFirst CLI. Replace local with a the server definition name you need to register or deploy to.
• runtime-name is the name of the runtime to register or deploy to.

Learn more with the following CLI help commands:

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

Exporting and importing runtime configurations

You can export a runtime configuration and import it to another MobileFirst Server using the REST APIs of the MobileFirst Server administration service.

For example, you can setup a runtime configuration in a development environment, export its configuration and then import it to a testing environment for a quick set-up, and then further configure it for the specific needs of the testing environment.

Find out all available REST APIs in the API Reference.

Configuring license tracking

License tracking is enabled by default. Read the following topics to learn how you can configure license tracking. For more information about license tracking, see License tracking.

• Configuring license tracking for client device and addressable device
• Configuring IBM License Metric Tool log files

Configuring license tracking for client device and addressable device

License tracking for client devices and addressable device is enabled by default. License reports are available in the MobileFirst Operations Console. You can specify the following JNDI properties to change the default settings for license tracking.

Note: If you have a contract that defines the use of token licensing, see also Installing and configuring for token licensing.

You can specify the following JNDI properties to change the default settings for license tracking.

mfp.device.decommission.when
The number of days of inactivity after which a device is decommissioned by the device decommissioning task. License reports do not count decommissioned devices as active devices. The default value for the property is 90 days. Do not set a value lower than 30 days if your software is licensed by Client Device or by Addressable Device, or license reports might not be sufficient to prove compliance.

mfp.device.archiveDecommissioned.when
A value, in days, that defines when decommissioned devices are placed in an archive file when the decommissioning task is run. The archived devices are written to a file in the IBM MobileFirst Server home\devices_archive directory. The name of the file contains the time stamp when the archive file is created. The default value is 90 days.

mfp.device.decommissionProcessingInterval
Defines how often (in seconds) the decommissioning task is run. Default: 86400, which is one day. The decommissioning task performs the following actions:

• Decommissions inactive devices, based on the mfp.device.decommission.when setting.
• Optionally, archives older decommissioned devices, based on the mfp.device.archiveDecommissioned.when setting.
• Generates the license tracking report.

mfp.licenseTracking.enabled
A value that is used to enable or disable license tracking in Mobile Foundation. By default, license tracking is enabled. For performance reasons, you can disable this flag when Mobile Foundation is not licensed by Client Device or by Addressable Device. When device tracking is disabled, the license reports are also disabled and no license metrics are generated. In that case, only IBM License Metric Tool records for Application count are generated.

For more information about specifying JNDI properties, see List of JNDI properties for MobileFirst runtime.

Configuring IBM License Metric Tool log files

Mobile Foundation generates IBM Software License Metric Tag (SLMT) files. Versions of IBM License Metric Tool that support IBM Software License Metric Tag can generate License Consumption Reports. Read this to understand how to configure the location and the maximum size of the generated files.

By default, the IBM Software License Metric Tag files are in the following directories:

• On Windows: %ProgramFiles%\ibm\common\slm
• On UNIX and UNIX-like operating systems: /var/ibm/common/slm

If the directories are not writable, the files are created in the log directory of the application server that runs the MobileFirst runtime environment.

You can configure the location and management of those files with the following properties:

• license.metric.logger.output.dir: Location of the IBM Software License Metric Tag files
• license.metric.logger.file.size: Maximum size of an SLMT file before a rotation is performed. The default size is 1 MB.
• license.metric.logger.file.number: Maximum number of SLMT archive files to keep in rotations. The default number is 10.

To change the default values, you must create a Java property file, with the format key=value, and provide the path to the properties file through the license_metric_logger_configuration JVM property.

For more information about IBM License Metric Tool reports, see Integration with IBM License Metric Tool.

WebSphere Application Server SSL configuration and HTTP adapters

By setting a property, you can let HTTP adapters benefit from WebSphere SSL configuration.

By default, HTTP adapters do not use WebSphere SSL by concatenating the Java Runtime Environment (JRE) truststore with the MobileFirst Server keystore, which is described in Configuring the MobileFirst Server keystore. Also see Configuring SSL between adapters and back-end servers by using self-signed certificates.

To have HTTP adapters use the WebSphere SSL configuration, set the ssl.websphere.config JNDI property to true. The setting has the following effects in order of precedence:

1. Adapters running on WebSphere use the WebSphere keystore and not the MobileFirst Server keystore.
2. If the ssl.websphere.alias property is set, the adapter uses the SSL configuration that is associated with the alias as set in this property.