Documentation Issues and Updates for SAP Mobile Platform Runtime

Read about updates, corrections, and clarifications to the documentation released with SAP Mobile Platform Runtime.

Issue #	Description
SMPONP-12207	The unit of measurement for SupMaximumMessageLength is in bytes Applies to Configuring Context Variables for Hybrid App Packages in SAP Control Center for SAP Mobile Platform.
SMPONP-8099	Reset JCO repository caches using SAP Control Center or API You can reset JCo repository caches for a server to reduce the amount of heap memory used by the repository caches. Use the SAP Control Center user interface, or the runtime server API. SAP Control Center for SAP Unwired Platform: Resetting JCo Repository Caches for a Server Developer Guide: SAP Mobile Server Runtime: Reset of JCo Cache Repositories
SMPONP-7758	SAP JCo Function cache fresh option This release supports clearing of SAP JCo Function Metadata repository caches in the Workspace tooling and Server runtime. The tooling now always clears the Function cache prior to each Function module execute ensuring the latest freshly cached version of the function is used. By default, the Server runtime only loads the SAP JCo Function Metadata repository cache on the first use of a function. To enable the SAP JCo Function Metadata repository refresh, a property has to be added to the server properties and set to true. When the server starts, it reads this property and then the server clears the Function cache prior to each Function module execute, ensuring the latest freshly cached version of the function is used. There is a performance impact when this option is enabled because the Function metadata is reloaded. This option is provided to facilitate development of systems where mutating Functions are being developed without restarting the server runtime on each cycle of change. It is not recommended for production servers. To enable in this option in a server, add the `sup.jco.cache.clear=true` property to the end of the $SERVER\MobilePlatform\Servers\UnwiredServer\Repository\Instance\com\sybase\sup\server\SUPServer\sup.properties file. In the folder $INSTALL\MobilePlatform\Servers\UnwiredServer\bin\private, create an empty file sup.cff and then restart the server. To disable in this option in a Server, remove the `sup.jco.cache.clear=true` property or set its value to false in the $SERVER\MobilePlatform\Servers\UnwiredServer\Repository\Instance\com\sybase\sup\server\SUPServer\sup.properties file. In the folder $INSTALL\MobilePlatform\Servers\UnwiredServer\bin\private, create an empty file sup.cff and then restart the server.
SMPONP-7368	Correction to Sybase Control Center for Sybase Unwired Platform topic Proxy Properties, and Developer Guide: REST API Applications topic Creating a Proxy Connection (Whitelisting) The topic does not mention a requirement to configure anonymous access when creating multiple proxy connections. Whenever you create multiple proxy connections in the connection pool with the same proxy endpoint, set Allow Anonymous Access to True in all of those proxy connections. This configuration ensures that the endpoint is whitelisted only once in the connection pool.
N/A	In the Installing Introscope Enterprise Manager topic in Landscape Design and Integration, the last step (11) reads:. Start Introscope Enterprise Manager and verify that agents for DotNet Process and SMP Java Server are enabled. The last word, "disabled," should be "enabled."
RTC-419	In the Provisioning Properties Reference topic, the values for autoreghint are not updated. The autoreghint property sets the preferred method for initial connection registration. The application defaults to the configured method as determined by the value you set. 0 – No preference. The application implementation decides what is the default method to use 1 – Default to automatic registration using password authentication 2 – Default to manual registration 3 – Default to automatic registration using a provisioned certificate from Afaria (Afaria Certificate) 4 – Default to automatic registration using certificate from a local source preferred (Local Certificate) When an application does not support the requested registration method, an alternative method can be used as determined by the application.
N/A	Requirements for a computer name, used as default server or cluster name when installing SAP Mobile Server, are not listed. The Installation Guide for Runtime, Selecting Installation Options sections of the tasks that install a new instance of SAP Mobile Server, list the requirements for a server or cluster name that you enter. However, if you do not specifically select the option to Set SAP Mobile Server name (Set SAP Mobile Server name and cluster name on first SAP Mobile Server in a cluster), the documentation does not state: The installer uses the computer name by default for the server name (and cluster name on the first SAP Mobile Server in a cluster). The computer name must meet the same requirements for server and cluster names as names that you enter. The requirements for server and cluster names are documented in the Installation Guide for Runtime, in the Selecting Installation Options sections of the tasks that install a new instance of SAP Mobile Server. See the step that begins, "(Optional) If you selected Set SAP Mobile Server name ..." If the computer name does not meet those requirements, you have two options for installing SAP Mobile Server on that system: Workaround 1: Keep the computer name as is. In the Selecting Installation Options section of the installation task, select the option to Set SAP Mobile Server name ..., and then specify a name that meets the requirements listed in the step that follows immediately after making that selection. Workaround 2: Before running the installer, change the computer name so that it meets all the requirements for user-entered server and cluster names. Then, in the Selecting Installation Options section of the installation task, do not select the option to Set SAP Mobile Server name ...
N/A	CHAPTER 10 Scripting Silent Installation, Upgrade, or Uninstallation of the Installation Guide for Runtime (PDF format only) on the Getting Started CD provides instructions for performing these tasks for SAP MobileSDK, instead of SAP Mobile Platform Runtime. Refer to the corrected chapter of Installation Guide for Runtime on the Product Documentation Web site at http://sybooks.sybase.com/sybooks/sybooks.xhtml?id=1289&c=firsttab&a=0&p=categories
N/A	SAP Control Center Windows Service Deleted The \utility folder no longer exists, so the command shown in SAP Control Center Windows Service Deleted is incorrect. The correct command is: SMP_HOME\bin\amd64 (or x86)\sccservice.exe -install This topic appears in both SAP Control Center for SAP Mobile Platform and Troubleshooting.
N/A	SAP Control Center Windows Service Fails to Start A second explanation should be added to SAP Control Center Windows Service Fails to Start: Explanation 2: The process sccservice.exe was not stopped during previous stops of SAP Control Center (even though the Windows Service "SAP Control Center x.x.x" does not show that it is running). Solution: Use Windows Task Manager to kill the process tree of sccservice.exe, then restart SAP Control Center. This topic appears in both SAP Control Center for SAP Mobile Platform and Troubleshooting.
N/A	User Activation Results in Error 404 When attempting to activate a user (sometimes referred to as on-boarding), Error 404 appears instead. Error 404 may indicate that the security configuration that is specified by the X-SUP-SC and/or X-SUP-DOMAIN settings in the header, does not exist, or is incorrect. The header values must be set to a valid security configuration. See Troubleshooting, in the Application and Application User Management Issues section.
N/A	References to replication log and replication dispatcher in documentation are incorrect The replication domain log and the replication thread count property for the client dispatcher have been removed from SAP Control Center, but are still referred to in the documentation.
N/A	Sometimes domain log files do not generate correctly based on the filter selections made. This might happen if filters are not selected correctly. Domain log filters are divided into three groups: package-related, security-related, and application connections. Some filter selections do not work in combination. To resolve this, re-create your log filters using these guidelines: The "OR" logical operator is used for the filters in same group. The domain log is generated only if there is at least one filter group allowing the subsystem, and no filter group disallowing it. A filter is applied only if the subsystem includes the corresponding column, and the column has a value when logging. For example, the operation filter in the package-related group can be applied for Application and Operation Replay; Application and DS Interface; and all Connection subsystems. If the operation has no value in the logging context when logging (which is possible for Application and DS Interface, and all Connection subsystems), the operation filter does not take effect. If one filter is not applied, the permission is neither allowed nor disallowed, and other filters (groups) determine whether to generate domain logs. If no filter group is allowed, the domain log is not generated.