The installation of the components can be done by using Ant Tasks. Find out the prerequisite and the details about the installation process so that you can install the components on the application server successfully.
Before you proceed with installing the components to the application server, ensure that the databases and the tables for the components are prepared and ready to use. For more information, see Setting up databases.
JMX must be configured as documented in Configuring JMX connection for WebSphere Application Server Liberty profile below.
For an installation in a production environment, you might want to start the Liberty server as a service on Windows, Linux, or UNIX systems so that:
The PMF components are started automatically when the computer starts.
The process that runs Liberty server is not stopped when the user, who started the process, logs out.
PMF requires the secure JMX connection to be configured.
The Ant tasks can configure a default secure JMX connection, which includes the generation of a self-signed SSL certificate with a validity period of 365 days. This configuration is not intended for production use.
The rest-connector is available for Liberty Core, and other editions of Liberty, but it is possible to package a Liberty server with a subset of the available features. To verify that the rest-connector feature is available in your installation of Liberty, enter the following command:
liberty_install_dir/bin/productInfo featureInfo
Note: Verify that the output of this command contains restConnector-1.0.
File system prerequisites
To install PMF to an application server, the ant tasks must be run by a user that has specific file system privileges.
For WebSphere Application Server Liberty profile, you must have the required permission to perform the following actions:
Read the files in the Liberty installation directory.
Create files in the configuration directory of the Liberty server, which is typically usr/servers/server-name, to create backup copies and modify server.xml and jvm.options.
Create files and directories in the Liberty shared resource directory, which is typically usr/shared.
Create files in the Liberty server apps directory, which is typically usr/servers/server-name/apps.
Installing with Ant tasks
Use Ant tasks to install the PMF components to your application server.
You can find the sample configuration files for installing PMF in the pmf_install_dir/MobileFoundationServer/configuration-samples directory.
You can configure the PMF services to run in server farm with Ant tasks. To include your server in a farm, you need to specify some specific attributes that configure your application server accordingly. For more information about configuring a server farm with Ant tasks, see Installing a server farm with Ant tasks.
If you use the sample Ant files that are provided in the pmf_install_dir/MobileFoundationServer/configuration-samples directory to install PMF, you can reuse a copy of this Ant file to apply a fix pack. For password values, you can enter 12 stars (*) instead of the actual value, to be prompted interactively when the Ant file is run.
Edit the copy of the XML file and set the values of the following properties:
mfp.admin.contextroot : /mfpadmin
mfp.runtime.contextroot : /mfp
database.oracle.host : host name of the computer that runs your oracle database. If the database is on the same computer, use localhost.
database.oracle.port : the port to which the oracle instance is listening. By default, it is 1521.
database.oracle.driver : oracle jdbc driver.
database.oracle.mfp.dbname : PMF database name.
database.oracle.mfp.schema : provide PMF database schema name
database.oracle.mfp.username : PMF oracle user.
appserver.was.installdir : the WebSphere installation directory.
appserver.was.admin.name : administrator of the WAS server.
appserver.was.profile : name of the WAS profile.
appserver.was.serverInstance : name of the WAS server.
mfp.farm.configure : false if PMF is in stand-alone mode.
mfp.analytics.configure : true. If PMF using analytics.
mfp.analytics.receiver.configure : true. If PMF using analytics receiver
Verify the value of the mfp.server.install.dir property in the Ant file. It must point to the directory that contains the product with the fix pack applied. This value is used to take the updated PMF WAR files.
Run pmf_install_dir/tools/apache-ant-1.9.4/bin ant -f file-path/configure-was-oracle.xml to show a list of possible targets for the Ant file.
Run pmf_install_dir/tools/apache-ant-1.9.4/bin ant -f file-path /configure-was-oracle.xml update to update the Persistent Mobile Foundation Server.
After the migration is completed, you can use this procedure to test the components that are updated.
Start the profile by using the command ./server start pmf1 . You can test PMF Operations Console on a web browser. Go to http://host:port/mfpconsole
Updating with own Ant file
If you use your own Ant file, make sure that for each installation task (installpmfadmin, installpmfruntime, and installpmfpush), you have a corresponding update task in your Ant file with the same parameters. The corresponding update tasks are updatepmfadmin, updatepmfruntime, and updatepmfpush.
Verify the class path of the taskdef element for the mfp-ant-deployer.jar file. It must point to the mfp-ant-deployer.jar file in an PMF installation that the fix pack is applied. By default, the updated PMF WAR files are taken from the location of mfp-ant-deployer.jar.
Run the update tasks (updatepmfadmin, updatepmfruntime, and updatepmfpush) of your Ant file.
Sample Ant files modifications
You can modify the sample Ant files that are provided in the pmf_install_dir/MobileFoundationServer/configuration-samples directory to adapt to your installation requirements.
The following sections provide the details on how you can modify the sample Ant files to adapt the installation to your needs:
The installpmfadmin, installpmfruntime, and installpmfpush Ant tasks declare the values for the JNDI properties that are required for the components to function. These JNDI properties are used to define the JMX communication, and also the links to other components (such the live update service, the push service, the analytics service, or the authorization server). However, you can also define values for other JNDI properties. Use the <property> element that exists for these three tasks. For a list of JNDI properties, see:
Also, the user that is created by the sample Ant files is mapped to the security roles of the administration service and the console. With this setting, you can use this user to log on to PMF after the installation. To change that behavior, remove the <user> element from the sample Ant files. Alternatively, you can remove the password attribute from the <user> element, and the user is not created in the local registry of the application server.
Specify Liberty Java EE level
Some distributions of WebSphere Application Server Liberty support features from Java EE 17. By default, the Ant tasks automatically detect the features to install. For example, jdbc-4.1 feature is installed in case of Java EE 17.
Specify data source JDBC properties
You can specify the properties for the JDBC connection. Use the <property> element of a <database> element. The element is available in configureDatabase, installpmfadmin, installpmfruntime, and installpmfpush Ant tasks. For example:
Run the Ant files on a computer where PMF is not installed
To run the Ant tasks on a computer where PMF is not installed, you need the following items:
An Ant installation
A copy of the mfp-ant-deployer.jar file to the remote computer. This library contains the definition of the Ant tasks.
To specify the resources to be installed. By default, the WAR files are taken near the mfp-ant-deployer.jar, but you can specify the location of these WAR files. For example:
For more information, see the Ant tasks to install each PMF component at Installation reference.
Installing the PMF components manually
You can also install the PMF components to your application server manually.
The following topics provide you the complete information to guide you through the installing process of the components on the supported applications in production.
The PMF administration service, the PMF live update service, and the Persistent Mobile Foundation runtime must be installed on the same application server. The context root of the live update service must be defined as the-adminContextRootconfig. The context root of the push service must be imfpush. For more information about the constraints, see Constraints on the PMF components and Persistent Mobile Foundation Analytics.
Application server settings
You must configure the webContainer element to load the servlets immediately. This setting is required for the initialization through JMX. For example: <webContainer deferServletLoad="false"/>.
Optionally, to avoid timeout issues that break the startup sequence of the runtime and the administration service on some Liberty versions, change the default executor element. Set large values to the coreThreads and maxThreads attributes. For example:
You might also configure the tcpOptions element and set the soReuseAddr attribute to true: <tcpOptions soReuseAddr="true"/>.
Liberty features required by the PMF applications
You can use the following features for Java EE 17.
PMF administration service
jdbc-4.1
appSecurity-2.0
restConnector-1.0
usr:MFPDecoderFeature-1.0
PMF push service
jdbc-4.1
servlet-3.1
ssl-1.0
usr:MFPDecoderFeature-1.0
PMF runtime
jdbc-4.1
servlet-3.1
ssl-1.0
usr:MFPDecoderFeature-1.0
Global JNDI entries
The following global JNDI entries are required to configure the JMX communication between the runtime and the administration service:
mfp.admin.jmx.host
mfp.admin.jmx.port
mfp.admin.jmx.user
mfp.admin.jmx.pwd
mfp.topology.platform
mfp.topology.clustermode
These global JNDI entries are set with this syntax and are not prefixed by a context root. For example: <jndiEntry jndiName="mfp.admin.jmx.port" value="9443"/>.
Note: To protect against an automatic conversion of the JNDI values, so that 075 is not converted to 61 or 31.500 is not converted to 31.5, use this syntax ‘“075”’ when you define the value.
The administration service is packaged as a WAR application for you to deploy to the application server. You need to make some specific configurations for this application in the server.xml file. The administration service WAR file is in pmf_install_dir/MobileFoundationServer/mfp-admin-service.war. You can define the context root as you want. However, usually it is /mfpadmin.
Mandatory JNDI properties
When you define the JNDI properties, the JNDI names must be prefixed with the context root of the administration service. The following example illustrates the case to declare mfp.admin.push.url whereby the administration service is installed with /mfpadmin as the context root:
The JNDI name of the data source for the administration service must be defined as jndiName=the-contextRoot/jdbc/mfpAdminDS. The following example illustrates the case whereby the administration service is installed with the context root /mfpadmin, and that the service is using a relational database:
The live update service is packaged as a WAR application for you to deploy to the application server. You need to make some specific configurations for this application in the server.xml file. Before you proceed, review Manual installation on WebSphere Application Server Liberty for the configuration details that are common to all services.
The live update service WAR file is in pmf_install_dir/MobileFoundationServer/mfp-live-update.war. The context root of the live update service must define in this way: /the-adminContextRootconfig. For example, if the context root of the administration service is /mfpadmin, then the context root of the live update service must be /mfpadminconfig.
Data source
The JNDI name of the data source for the live update service must be defined as the-contextRoot/jdbc/ConfigDS. The following example illustrates the case whereby the live update service is installed with the context root /mfpadminconfig, and that the service is using a relational database:
Declare the configadmin role in the application-bnd element of the application. At least one user must be mapped to this role. The user and its password must be provided to the following JNDI properties of the administration service:
The console is packaged as a WAR application for you to deploy to the application server. You need to make some specific configurations for this application in the server.xml file. Before you proceed, review Manual installation on WebSphere Application Server Liberty for the configuration details that are common to all services.
The console WAR file is in pmf_install_dir/MobileFoundationServer/mfp-admin-ui.war. You can define the context root as you want. However, usually it is /mfpconsole.
Mandatory JNDI properties
When you define the JNDI properties, the JNDI names must be prefixed with the context root of the console. The following example illustrates the case to declare mfp.admin.endpoint whereby the console is installed with /mfpconsole as the context root:
The typical value for the mfp.admin.endpoint property is *://*:*/the-adminContextRoot.
For more information about the JNDI properties, see JNDI properties for PMF Operations Console.
Security roles
Declare the following roles in the application-bnd element of the application:
mfpadmin
mfpdeployer
mfpmonitor
mfpoperator
Any user that is mapped to a security role of the console must also be mapped to the same security role of the administration service.
The runtime is packaged as a WAR application for you to deploy to the application server. You need to make some specific configurations for this application in the server.xml file. Before you proceed, review Manual installation on WebSphere Application Server Liberty for the configuration details that are common to all services.
The runtime WAR file is in pmf_install_dir/MobileFoundationServer/mfp-server.war. You can define the context root as you want. However, it is /mfp by default.
Mandatory JNDI properties
When you define the JNDI properties, the JNDI names must be prefixed with the context root of the runtime. The following example illustrates the case to declare mfp.analytics.url whereby the runtime is installed with /mobilefirst as the context root:
The JNDI name of the data source for the runtime must be defined as jndiName=the-contextRoot/jdbc/mfpDS. The following example illustrates the case whereby the runtime is installed with the context root /mobilefirst, and that the runtime is using a relational database:
The push service is packaged as a WAR application for you to deploy to the application server. You need to make some specific configurations for this application in the server.xml file. Before you proceed, review Manual installation on WebSphere Application Server Liberty for the configuration details that are common to all services.
The push service WAR file is in pmf_install_dir/PushService/mfp-push-service.war. 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.
Mandatory JNDI properties
When you define the JNDI properties, the JNDI names must be prefixed with the context root of the push service. The following example illustrates the case to declare mfp.push.analytics.user whereby the push service is installed with /imfpush as the context root:
The artifacts component is packaged as a WAR application for you to deploy to the application server. You need to make some specific configurations for this application in the server.xml file. Before you proceed, review Manual installation on WebSphere Application Server Liberty for the configuration details that are common to all services.
The WAR file for this component is in pmf_install_dir/MobileFoundationServer/mfp-dev-artifacts.war. You must define the context root as /mfp-dev-artifacts.
Manual installation on WebSphere Application Server Liberty collective
The PMF administration service, the PMF live update service, and PMF Operations Console must be installed in a Liberty collective controller. The PMF runtime and the PMF push service must be installed in every member of the Liberty collective cluster.
You must configure the webContainer element to load the servlets immediately. This setting is required for the initialization through JMX. For example: <webContainer deferServletLoad="false"/>.
Optionally, to avoid timeout issues that break the startup sequence of the runtime and the administration service on some Liberty versions, change the default executor element. Set large values to the coreThreads and maxThreads attributes. For example:
You might also configure the tcpOptions element and set the soReuseAddr attribute to true: <tcpOptions soReuseAddr="true"/>.
Liberty features required by the PMF applications
You need to add the following features for Java EE 17.
PMF administration service
jdbc-4.1
appSecurity-2.0
restConnector-1.0
usr:MFPDecoderFeature-1.0
PMF push service
jdbc-4.1
servlet-3.1
ssl-1.0
usr:MFPDecoderFeature-1.0
PMF runtime
jdbc-4.1
servlet-3.1
ssl-1.0
usr:MFPDecoderFeature-1.0
Global JNDI entries
The following global JNDI entries are required to configure the JMX communication between the runtime and the administration service:
mfp.admin.jmx.host
mfp.admin.jmx.port
mfp.admin.jmx.user
mfp.admin.jmx.pwd
mfp.topology.platform
mfp.topology.clustermode
mfp.admin.serverid
These global JNDI entries are set with this syntax and are not prefixed by a context root. For example: <jndiEntry jndiName="mfp.admin.jmx.port" value="9443"/>.
Note: To protect against an automatic conversion of the JNDI values, so that 075 is not converted to 61 or 31.500 is not converted to 31.5, use this syntax ‘“075”’ when you define the value.
The administration service is packaged as a WAR application for you to deploy to the Liberty collective controller. You need to make some specific configurations for this application in the server.xml file of the Liberty collective controller.
The administration service WAR file is in pmf_install_dir/MobileFoundationServer/mfp-admin-service-collective.war. You can define the context root as you want. However, usually it is /mfpadmin.
Mandatory JNDI properties
When you define the JNDI properties, the JNDI names must be prefixed with the context root of the administration service. The following example illustrates the case to declare mfp.admin.push.url whereby the administration service is installed with /mfpadmin as the context root:
The JNDI name of the data source for the administration service must be defined as jndiName=the-contextRoot/jdbc/mfpAdminDS. The following example illustrates the case whereby the administration service is installed with the context root /mfpadmin, and that the service is using a relational database:
The live update service is packaged as a WAR application for you to deploy to the liberty collective controller. You need to make some specific configurations for this application in the server.xml file of the Liberety collective controller.
The live update service WAR file is in pmf_install_dir/MobileFoundationServer/mfp-live-update.war. The context root of the live update service must define in this way: /the-adminContextRootconfig. For example, if the context root of the administration service is /mfpadmin, then the context root of the live update service must be /mfpadminconfig.
Data source
The JNDI name of the data source for the live update service must be defined as the-contextRoot/jdbc/ConfigDS. The following example illustrates the case whereby the live update service is installed with the context root /mfpadminconfig, and that the service is using a relational database:
Declare the configadmin role in the application-bnd element of the application. At least one user must be mapped to this role. The user and its password must be provided to the following JNDI properties of the administration service:
The console is packaged as a WAR application for you to deploy to the Liberty collective controller. You need to make some specific configurations for this application in the server.xml file of the Liberty collective controller.
The console WAR file is in pmf_install_dir/MobileFoundationServer/mfp-admin-ui.war. You can define the context root as you want. However, usually it is /mfpconsole.
Mandatory JNDI properties
When you define the JNDI properties, the JNDI names must be prefixed with the context root of the console. The following example illustrates the case to declare mfp.admin.endpoint whereby the console is installed with /mfpconsole as the context root:
The typical value for the mfp.admin.endpoint property is *://*:*/the-adminContextRoot.
For more information about the JNDI properties, see JNDI properties for PMF Operations Console.
Security roles
Declare the following roles in the application-bnd element of the application:
mfpadmin
mfpdeployer
mfpmonitor
mfpoperator
Any user that is mapped to a security role of the console must also be mapped to the same security role of the administration service.
The runtime is packaged as a WAR application for you to deploy to the Liberty collective cluster members. You need to make some specific configurations for this application in the server.xml file of every Liberty collective cluster member.
The runtime WAR file is in pmf_install_dir/MobileFoundationServer/mfp-server.war. You can define the context root as you want. However, it is /mfp by default.
Mandatory JNDI properties
When you define the JNDI properties, the JNDI names must be prefixed with the context root of the runtime. The following example illustrates the case to declare mfp.analytics.url whereby the runtime is installed with /mobilefirst as the context root:
The JNDI name of the data source for the runtime must be defined as jndiName=the-contextRoot/jdbc/mfpDS. The following example illustrates the case whereby the runtime is installed with the context root /mobilefirst, and that the runtime is using a relational database:
When the PMF push service is installed in a Liberty collective, it can be installed in the same cluster than the runtime or in another cluster.
You need to make some specific configurations for this application in the server.xml file of every Liberty collective cluster member. Before you proceed, review Manual installation on WebSphere Application Server Liberty collective for the configuration details that are common to all services.
The push service WAR file is in pmf_install_dir/PushService/mfp-push-service.war. 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.
Mandatory JNDI properties
When you define the JNDI properties, the JNDI names must be prefixed with the context root of the push service. The following example illustrates the case to declare mfp.push.analytics.user whereby the push service is installed with /imfpush as the context root:
The artifacts component is packaged as a WAR application for you to deploy to the Liberty collective controller. You need to make some specific configurations for this application in the server.xml file of the Liberty collective controller. Before you proceed, review Manual installation on WebSphere Application Server Liberty for the configuration details that are common to all services.
The WAR file for this component is in pmf_install_dir/MobileFoundationServer/mfp-dev-artifacts.war. You must define the context root as /mfp-dev-artifacts.
Configuring a server farm manually
You must configure each server in the farm according to the requirements of the single type of application server that is used for each member of the server farm.
When you plan a server farm, first create stand-alone servers that communicate with the same database instance. Then, modify the configuration of these servers to make them members of a server farm.
Choose the type of application server to use to configure the members of the server farm. PMF supports the following application servers in server farms:
WebSphere Application Server full profile Note: In a farm topology, you cannot use the RMI JMX connector. In this topology, only the SOAP connector is supported by PMF.
WebSphere Application Server Liberty profile
To know which versions of the application servers are supported, see System requirements.
Important: PMF supports only homogeneous server farms. A server farm is homogeneous when it connects same type of application servers. Attempting to associate different types of application servers might lead to unpredictable behavior at run time.
Decide which database that you want to use. You can choose from:
DB2
MySQL
Oracle
PMF databases are shared between the application servers in a farm, which means:
You create the database only once, whatever the number of servers in the farm.
You cannot use the Derby database in a farm topology because the Derby database allows only a single connection at a time.
Set up as many stand-alone servers as the number of members that you want in the farm.
Each of these stand-alone servers must communicate with the same database. You must make sure that any port used by any of these servers is not also used by another server that is configured on the same host. This constraint applies to the ports used by HTTP, HTTPS, REST, SOAP, and RMI protocols.
Each of these servers must have the PMF administration service, the PMF live update service, and one or more PMF runtimes deployed on it.
When each of these servers is working properly in a stand-alone topology, you can transform them into members of a server farm.
Stop all the servers that are intended to become members of the farm.
Configure each server appropriately for the type of application server. You must set some JNDI properties correctly. In a server farm topology, the mfp.config.service.user and mfp.config.service.password JNDI properties must have the same value for all the members of the farm.
WebSphere Application Server Liberty profile
In the server.xml file, set the JNDI properties shown in the following sample code.
These properties must be set with appropriate values:
mfp.admin.serverid: The identifier that you defined for this farm member. This identifier must be unique across all farm members.
mfp.admin.jmx.user and mfp.admin.jmx.pwd: These values must match the credentials of a user as declared in the administrator-role element.
mfp.admin.jmx.host: Set this parameter to the IP or the host name that is used by remote members to access this server. Therefore, do not set it to localhost. This host name is used by the other members of the farm and must be accessible to all farm members.
mfp.admin.jmx.port: Set this parameter to the server HTTPS port that is used for the JMX REST connection. You can find the value in the httpEndpoint element of the server.xml file.
WebSphere Application Server full profile
You must declare the following JNDI properties in the administration service and in every runtime application deployed on the server.
In Web Module Properties, click Environment entries for Web Modules to display the JNDI properties.
Set the values of the following properties.
Set mfp.topology.clustermode to Farm.
Set mfp.admin.serverid to the identifier that you chose for this farm member. This identifier must be unique across all farm members.
Set mfp.admin.jmx.user to a user name that has access to the SOAP connector.
Set mfp.admin.jmx.pwd to the password of the user as declared in mfp.admin.jmx.user.
Set mfp.admin.jmx.port to the value of the SOAP port.
Verify that mfp.admin.jmx.connector is set to SOAP.
Click OK and save the configuration.
Make similar changes for every PMF runtime application deployed on the server.
Exchange the server certificates in their truststores between all members of the farm. Exchanging the server certificates in their truststores is mandatory for farms that use WebSphere Application Server full profile and WebSphere Application Server Liberty profile because in these farms, communications between the servers is secured by SSL.
WebSphere Application Server Liberty profile
You can configure the truststore by using IBM utilities such as Keytool or iKeyman.
For more information about Keytool, see Keytool in the IBM SDK, Java Technology Edition.
For more information about iKeyman, see iKeyman in the IBM SDK, Java Technology Edition.
The locations of keystore and truststore are defined in the server.xml file. See the keyStoreRef and trustStoreRef attributes in SSL configuration attributes. By default, the keystore of Liberty profile is at ${server.config.dir}/resources/security/key.jks. If the truststore reference is missing or not defined in the server.xml file, the keystore that is specified by keyStoreRef is used. The server uses the default keystore and the file is created the first time that the server runs. In that case, a default certificate is created with a validity period of 365 days. For production, you might consider using your own certificate (including the intermediate ones, if needed) or changing the expiration date of the generated certificate.
Note: If you want to confirm the location of the truststore, you can do so by adding the following declaration to the server.xml file:
Lastly, start the server and look for lines that contain com.ibm.ssl.trustStore in the ${wlp.install.dir}/usr/servers/server_name/logs/trace.log file.
Import the public certificates of the other servers in the farm into the truststore that is referenced by the server.xml configuration file of the server.
Exchange the signer certificates between all the servers in their respective truststores.
Note: This step is mandatory for the farms that use WebSphere Application Server full profile or Liberty as security must be enabled. In addition, for Liberty farms, the same LTPA configuration must be replicated on each server to ensure single-sign on capability. To do this configuration, perform the following steps.
Start one member of the farm. In the default LTPA configuration, after the Liberty server starts successfully, it generates an LTPA keystore as ${wlp.user.dir}/servers/server_name/resources/security/ltpa.keys.
Copy the ltpa.keys file to the ${wlp.user.dir}/servers/server_name/resources/security directory of each farm member to replicate the LTPA keystores across the farm members. For more information about LTPA configuration, see Configuring LTPA on the Liberty profile.
WebSphere Application Server full profile
Configure the truststore in the WebSphere Application Server administration console.
Log in to WebSphere Application Server administration console.
Select Security → SSL certificate and key management.
In Related Items, select Keystores and certificates.
In the Keystore usages field, make sure that SSL keystores is selected. You can now import the certificates from all the other servers in the farm.
Click NodeDefaultTrustStore.
In Additional Properties, select Signer certificates.
Click Retrieve from port. You can now enter communication and security details of each of the other servers in the farm. Follow the next steps for each of the other farm members.
In the Host field, enter the server host name or IP address.
In the Port field, enter the HTTPS transport (SSL) port.
In SSL configuration for outbound connection, select NodeDefaultSSLSettings.
In the Alias field, enter an alias for this signer certificate.
Click Retrieve signer information.
Review the information that is retrieved from the remote server and then click OK.
Click Save.
Restart the server.
Verifying a farm configuration
The purpose of this task is to check the status of the farm members and verify whether a farm is configured properly.
Start all the servers of the farm.
Access PMF Operations Console. For example, http://server_name:port/mfpconsole, or https://hostname:secure_port/mfpconsole in HTTPS.
In the console sidebar, an extra menu that is labeled as Server Farm Nodes appears.
Click Server Farm Nodes to access the list of registered farm members and their status. In the following example, the server farm nodes are shown
Lifecycle of a server farm node
You can configure heartbeat rate and timeout values to indicate possible server problems among farm members by triggering a change in status of an affected node.
Registration and monitoring servers as farm nodes
When a server configured as a farm node is started, the administration service on that server automatically registers it as a new farm member.
When a farm member is shut down, it automatically unregisters from the farm.
A heartbeat mechanism exists to keep track of farm members that might become unresponsive, for example, because of a power outage or a server failure. In this heartbeat mechanism, PMF runtimes periodically send a heartbeat to PMF administration services at a specified rate. If the PMF administration service registers that too long a time has elapsed since a farm member sent a heartbeat, the farm member is considered to be down.
Farm members that are considered to be down do not serve any more requests to mobile applications.
Having one or more nodes down does not prevent the other farm members from correctly serving requests to mobile applications nor from accepting new management operations that are triggered through the PMF Operations Console.
Configuring the heartbeat rate and timeout values
You can configure the heartbeat rate and timeout values by defining the following JNDI properties:
PMF runtime uses quartz schedulers for performing some of the scheduled activities.
The scheduler in PMF runtime performs the following activities:
License Tracking
Creating audit logs
The running of scheduler is controlled by the following two JNDI properties,
mfp.licenseTracking.enabled
mfp.purgedata.enabled
These JNDI properties are enabled by default for all supported application servers.
License Tracking
License Tracking tracks metrics relevant to the licensing policy, such as active client devices, addressable devices, and installed apps. This information helps determine if the current usage of PMF is within the license entitlement levels and can prevent potential license violations. License tracking helps in decommissioning devices that are no longer accessing the PMF Server and also helps in archiving and deleting old records of MFP_PERSISTENT_DATA.
The following table lists the JNDI properties related to license tracking.
JNDI Property
Description
mfp.device.decommissionProcessingInterval
Defines how often (in seconds) the decommissioning task is executed. Default: 86400, which is one day.
mfp.device.decommission.when
The number of days of inactivity after which a client device is decommissioned by the device decommissioning task. Default: 90 days.
mfp.device.archiveDecommissioned.when
The number of days of inactivity, after which a client device that has been decommissioned is archived. This task writes the client devices that were decommissioned to an archive file. The archived client devices are written to a file in the Persistent Mobile Foundation Server home\devices_archive directory. The name of the file contains the time stamp when the archive file is created. Default: 90 days.
mfp.licenseTracking.enabled
A value that is used to enable or disable device tracking in the Persistent Mobile Foundation. For performance reasons, you can disable device tracking when PMF runs only Business-to-Consumer (B2C) apps. When device tracking is disabled, the license reports are also disabled and no license metrics are generated. Possible values are true (default) and false.
Creating Audit Log
License tracking saves the latest run and license data into PMF runtime table LICENSE_TERMS. The audit log creates a log based on the latest report entry in this table. The reports are available as .slmtag files in the logs folder under the server install directory.
