Known limitations

If you are developing globalized apps, notice the following restrictions:

• Part of the product IBM MobileFirst Platform Foundation V7.1.0, including its documentation, is translated in the following languages: Simplified Chinese, Traditional Chinese, French, German, Italian, Japanese, Korean, Portuguese (Brazil), Russian, and Spanish. Mainly user-facing text is translated.
• The applications that are generated by IBM MobileFirst Platform Foundation are not fully bidirectional enabled. Mirroring of the graphic user interface (GUI) elements and the control of the text direction are not provided by default. However, there is no hard dependency from the generated applications on this limitation. It is possible for the developers to achieve full bidi compliance by manual adjustments in the generated code.
• Although translation into Hebrew is provided for IBM MobileFirst Platform Foundation core functionality, some GUI elements are not mirrored.
• Names of projects, apps, adapters, Dojo custom builds and Dojo library projects must be composed only of the following characters:
  • Uppercase and lowercase letters (A-Z and a-z)
  • Digits (0-9)
  • Underscore (_)
  Some examples of the problems that you might encounter if the names of your Dojo library projects are NL strings are the incorrect display of the UI pattern preview, the failure of the generation of the Dojo custom build, and the failure to display the NL string in the Dojo custom build console.
• There is no support for Unicode characters outside the Basic Multilingual Plane.

IBM MobileFirst Platform Application Center mobile client

The Application Center mobile client follows the cultural conventions of the running device, such as the date formatting. It does not always follow the stricter International Components for Unicode (ICU) rules.

The Application Center mobile client for BlackBerry has the following known limitations:

• It supports only a limited set of languages. In particular, it does not fully support right-to-left languages, such as Arabic and Hebrew.
• It does not support Unicode characters outside the Basic Multilingual Plane.
• It supports Unicode characters inside the Basic Multilingual Plane but how these characters are displayed depends on the fonts that are available on the device

IBM MobileFirst Platform Operational Analytics

The IBM MobileFirst Platform Operational Analytics has the following limitations:

• In Analytics Console, the format for numbers does not follow the International Components for Unicode (ICU) rules.
• In Analytics Console, the numbers do not use the user's preferred number script.
• In Analytics Console, the format for dates, times, and numbers are displayed according to the language setting of the operating system rather than the locale of Microsoft Internet Explorer.
• When you create a custom filter for a custom chart, the numerical data must be in base 10, Western, or European numerals, such as 0, 1, 2, 3, 4, 5, 6, 7, 8, 9.
• When you create a custom filter for a custom chart, the query of a custom filter does not use Unicode Normalization Forms C (NFC) for comparison. The query does not consider language sensitivity such as normal matching, accent-insensitive, case-insensitive, and 1-to-2 mapping for search function to run correctly in different languages. The message property uses NFC and considers language sensitivity though.
• If you are using the latest interim fix of IBM MobileFirst Platform Foundation, the numerical data must be in base 10, Western, or European numerals, such as 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, when you create an alert in the Alert Management page of the Analytics Console.
• The Analytics page of the MobileFirst Operations Console supports the following browsers:
  • Microsoft Internet Explorer version 10 or later
  • Mozilla Firefox ESR or later
  • Apple Safari on iOS version 7.0 or later
  • Google Chrome latest version

IBM MobileFirst Platform Operations Console

The MobileFirst Operations Console has the following limitations:

• Provides only partial support for bidirectional languages.
• The text direction cannot be changed when notification messages are sent to an Android device :
  • if the first letters typed are in a right-to-left language, such as Arabic and Hebrew, the whole text direction is automatically right-to-left.
  • if the first letters typed are in a letf-to-right language, the whole text direction is automatically left-to-right.
• Some error messages of the MobileFirst Operations Console are not translated because they are generated at the server side.

IBM MobileFirst Platform Studio

The MobileFirst Studio has the following limitations:

• Provides only partial support for bidirectional languages.
• The dates and numbers might not be formatted according to the locale.

Server Configuration Tool

The Server Configuration Tool has the following restrictions:

• The descriptive name of a server configuration can contain only characters that are in the system character set. On Windows, it is the ANSI character set.
• Passwords that contain single quotation mark or double quotation mark characters might not work correctly.
• The console of the Server Configuration Tool has the same globalization limitation as the Windows console to display strings that are out of the default code page.

You might also experience restrictions or anomalies in various aspects of globalization because of limitations in other products, such as browsers, database management systems, or software development kits in use. For example:

• You must define the user name and password of the Application Center with ASCII characters only. This limitation exists because IBM® WebSphere® Application Server (full or Liberty profiles) does not support non-ASCII passwords and user names. See Characters that are valid for user IDs and passwords.
• On Windows:
  • To see any localized messages in the log file that the test server that is embedded in MobileFirst Studio creates, you must open this log file with the UTF8 encoding.
  • In the test server console in Eclipse, the localized messages are not properly displayed.
  These limitations exist because of the following causes:
  • The test server is installed on IBM WebSphere Application Server Liberty profile, which creates log file with the ANSI encoding except for its localized messages for which it uses the UTF8 encoding.
  • The test server console in Eclipse displays the content by using the ANSI encoding, not the UTF8 encoding.
• In Java™ 7.0 Service Refresh 4-FP2 and previous versions, you cannot paste Unicode characters that are not part of the Basic Multilingual Plane into the input field. To avoid this issue, create the path folder manually and choose that folder during the installation.
• Custom title and button names for the alert, confirm, and prompt methods must be kept short to avoid truncation at the edge of the screen.
• The applications that are developed with MobileFirst Application Framework running in Portuguese (Portugal) will see runtime messages in Portuguese (Brazil).
• JSONStore does not handle normalization. The Find functions for the JSONStore API do not take account of language sensitivity such as accent insensitive, case insensitive, and 1 to 2 mapping.
• The sorted results of JSONStore Find API are not language-specific and not compliant with Common Locale Data Repository (CLDR) rules.

The work-around for this limitation is to force set WLJQ. Add the following line to the head element of the web page if you are using the embedded Safari browser. Safari is the default embedded browser option on Mac.

<script>window.$ = window.jQuery = WLJQ;</script>

This change is not required if you are using the Firefox or Internet Explorer browsers on Windows.

You cannot install MobileFirst Data Proxy on the following application servers:

• Apache Tomcat
• Versions of WebSphere Application Server Liberty profile earlier than V8.5.5.0.

If you use Tomcat as an external server in Eclipse (for example to test and debug the applications directly in MobileFirst Studio), the following restrictions apply:

• The context path that you set to your project is ignored. When you deploy your app from MobileFirst Studio to Tomcat, the default context path, which is the project name, is used instead of the context path. The URL of the MobileFirst Operations Console for your app similarly uses the project name.
• When you deploy your app from MobileFirst Studio to Tomcat, the deployed WAR file is not visible in the Server view of Eclipse (in MobileFirst Studio), even if the application is correctly deployed.

The compressed (.zip) file does not always preserve UNIX file permissions correctly. Thus, complete the following steps to edit the imported compressed file.

1. Expand the compressed file to a directory and change all of the file permissions to allow read access.
2. Compress the file again.
3. Reimport the file by using MobileFirst Studio.

You can change the file permissions in either the Finder or on the command line if you run chmod 755 on all of the files.

The CLI can not detect a given runtime on a MobileFirst Server for one or more of the following reasons:

• The MobileFirst Server is not running.
• There is no network connectivity between the system running the CLI and the MobileFirst Server.
• You have not deployed the runtime to the MobileFirst Server.

Actions:

1. Confirm that the MobileFirst Server is running.
   • Local MobileFirst Server:
     1. Run mfp status. For more information, see status.
     2. If the MobileFirst Server is not running:
        1. Change directories into the top level directory of the associated project. Run cd <your mfp back-end project>.
        2. Run mfp start.
        3. Run mfp status to ensure that the MobileFirst Server started.
   • Remote MobileFirst Server:
     1. Run the mfp server info command and identify the target remote server. Note the corresponding URL and Name values.
     2. Ping the host specified in the target server's URL. Do not include the port or protocol. For example: ping remotehost.com. If the host is unreachable or the pings timeout, contact the server administrator to have the server started and verify that there are no network connectivity issues.
     3. Assuming the server is running, run the mfp server info <server> command, where <server> is the Name value from the previous mfp server info command.
     4. If the MobileFirst Server information is displayed, the MobileFirst Server is running. Otherwise contact your server administrator to start the MobileFirst Server. For more information, see server info.
2. Determine the required runtime name.
   • The runtime name is the value of the <name> argument given at the time of creation via the mfp create <name> command. This is also the default top level project directory name of your project.
3. If you know that the MobileFirst Server is running, confirm that the required runtime is installed and running on that MobileFirst Server. For both a local and remote server:
   1. Run the mfp server info command and identify the target remote server Name value. The local MobileFirst Server name is typically local.
   2. Run the mfp server info <server> command, where <server> is the Name value from the previous step.
   3. Look at the command output and find the runtimes listed under the Runtime section.
   4. If the runtime name from Step 2 is not included, proceed to step 4.
4. Build, install and start a runtime on the MobileFirst Server.
   • Local MobileFirst Server:
     1. Change directories into the associated project's root directory. Run cd <your mfp back-end project>.
     2. Confirm that the local MobileFirst Server is started by running the mfp status command. If the server is not running, run mfp start.
     3. Run mfp push local. This builds the runtime WAR file, and automatically installs it on the local MobileFirst Server. For more information, see push.
     4. Refer to step 3 to ensure that the runtime is correctly installed and running on the local MobileFirst Server.
     5. If the runtime is not present, run mfp restart to restart the local MobileFirst Server. For more information, see restart.
   • Remote MobileFirst Server:
     1. Change directories into the associated project's root directory. Run cd <your mfp back-end project>.
     2. Run the mfp push --nosend command to build the runtime WAR file, but not install it. The WAR file can only be deployed on a local server. For more information, see push.
     3. Complete the instructions here: Deploying MobileFirst projects.
     4. Refer to step 3 to ensure that the runtime is correctly installed and running on the target remote MobileFirst Server.

The MobileFirst Development Server (an instance of the WebSphere Application Server Liberty profile server) cannot handle an Eclipse workspace path with white space. As a result, a simple app cannot be deployed or previewed. In MobileFirst Operations Console, an error message is displayed:

Server error. Contact the server administrator.

In the log file, the following error messages are logged:

[12/11/14 10:27:57:376 IST] 0000002f m.ibm.ws.container.service.app.deploy.ManifestClassPathUtils W SRVE9967W: The manifest class path jaxb-api.jar can not be found in jar file wsjar:file:/home/administrator/.ibm/mobilefirst/6.3.0/server/wlp/usr/servers/worklight/apps/worklightconsole.war!/WEB-INF/lib/jaxb-impl-2.1.12.osgi.jar or its parent.
[12/11/14 10:27:57:376 IST] 0000002f m.ibm.ws.container.service.app.deploy.ManifestClassPathUtils W SRVE9967W: The manifest class path activation.jar can not be found in jar file wsjar:file:/home/administrator/.ibm/mobilefirst/6.3.0/server/wlp/usr/servers/worklight/apps/worklightconsole.war!/WEB-INF/lib/jaxb-impl-2.1.12.osgi.jar or its parent.
[12/11/14 10:27:57:376 IST] 0000002f m.ibm.ws.container.service.app.deploy.ManifestClassPathUtils W SRVE9967W: The manifest class path jsr173_1.0_api.jar can not be found in jar file wsjar:file:/home/administrator/.ibm/mobilefirst/6.3.0/server/wlp/usr/servers/worklight/apps/worklightconsole.war!/WEB-INF/lib/jaxb-impl-2.1.12.osgi.jar or its parent.
[12/11/14 10:27:57:377 IST] 0000002f m.ibm.ws.container.service.app.deploy.ManifestClassPathUtils W SRVE9967W: The manifest class path jaxb1-impl.jar can not be found in jar file wsjar:file:/home/administrator/.ibm/mobilefirst/6.3.0/server/wlp/usr/servers/worklight/apps/worklightconsole.war!/WEB-INF/lib/jaxb-impl-2.1.12.osgi.jar or its parent.
[12/11/14 10:27:57:637 IST] 00000029 com.ibm.ws.webcontainer.osgi.webapp.WebGroup I SRVE0169I: Loading Web Module: IBMJMXConnectorREST.

The following known limitations apply when you use the FIPS 140-2 feature in IBM MobileFirst Platform Foundation:

• This FIPS 140-2 validated mode applies only to the protection (encryption) of local data that is stored by the JSONStore feature and protection of HTTPS communications between the MobileFirst client and the MobileFirst Server.
  • For HTTPS communications, only the communications between the MobileFirst client and the MobileFirst Server use the FIPS 140-2 libraries on the client. Direct connections to other servers or services do not use the FIPS 140-2 libraries.
• This feature is only supported on the iOS and Android platforms.
  • On Android, this feature is only supported on devices or simulators that use the x86 or armv7 architectures. It is not supported on Android using armv5 or armv6 architectures. The reason is because the OpenSSL library used did not obtain FIPS 140-2 validation for armv5 or armv6 on Android. FIPS 140-2 is not supported on 64-bit architecture even though the MobileFirst library does support 64-bit architecture. FIPS 140-2 can be run on 64-bit devices if there are only 32-bit native NDK libraries in the project.
  • On iOS, it is supported on i386, armv7, and armv7s architectures.
• This feature works with hybrid applications only (not native).
• The use of the user enrollment feature on the client is not supported by the FIPS 140-2 feature.
• The Application Center client does not support the FIPS 140-2 feature.

For more information about this feature, see FIPS 140-2 support.

The compatibility framework has the following limitations:

• IMFClient:unregisterAuthenticationDelegateForRealm has no effect as WLClient does not support unregistering challenge handlers. The work-around is to create an empty challenge handler that does nothing and register it for the same realm name.
• IMFResurceRequest:setHTTPMethod has no effect as the HTTP method is immutable in WLResourceRequest class.
• In [IMFClient initializeWithBackendRoute:backendGUID], the backendGUID parameter is ignored.

The following limitations apply if you install MobileFirst Server on a cluster of IBM WebSphere Application Servers, Liberty profile, that you administer with a collective controller:

• The Application Center installation with the MobileFirst Server installer does not use the collective controller. You must install MobileFirst Server on each server separately.
• The MobileFirst Operations Console installation with the <configureApplicationServer> Ant task does not use the collective controller. You must run the <configureApplicationServer> Ant task for each server separately.

An LTPA token is associated with the current user session. If the session expires before an LTPA token expires, a new session is created automatically. However, when an LTPA token expires before a user session expires, the following exception occurs:

com.ibm.websphere.servlet.session.UnauthorizedSessionRequestException: SESN0008E: A user authenticated as anonymous has attempted to access a session owned by {user name}

To resolve this limitation, you must force the user session to expire when the LTPA token expires.

• On WebSphere Application Server Liberty, set the httpSession attribute invalidateOnUnauthorizedSessionRequestException to true in the server.xml file.
• On WebSphere Application Server, add the session management custom property InvalidateOnUnauthorizedSessionRequestException with the value true to fix the issue.

To render the HTML page, use the following settings in your build-settings.xml file.

<windowsPhone8>
  <minification level="simple" excludes="cordova.js">
  <concatenation includes="*">
</windowsPhone8>

For more information about the build-settings.xml file, see MobileFirst application build settings.

In general, however, the initialization code is not strictly necessary to get a reasonable visual rendering of your page. To avoid this limitation, temporarily remove the "display: none" style from the body element in your page. Your page then renders even if the initialization functions do not execute completely.

The following known limitations apply when you use the User Certificate Authentication feature in IBM MobileFirst Platform Foundation:

• This feature is available only on the hybrid iOS and Android environments for this current release.
• This feature is not supported by the FIPS 140-2 feature.
• This feature is supported on WebSphere Application Server and WebSphere Application Server Liberty profile.
• This feature does not support an environment where the MobileFirst Server is protected by container security that requires a CLIENT-CERT authentication method. Instead, the server must be configured to accept the client certificate optionally, and not require one.
• Self-signed certificates are not supported by the User Certificate Authentication feature.
• This feature cannot be used when you use the IBM HTTP Server between the client device and the MobileFirst Server. The IBM HTTP Server is unable to provide user identity to the MobileFirst Server after authenticating with the client certificate.