You can customize the mobile client by modifying the parameter values defined in the OSE.INI configuration file.
The installation automatically sets the parameters in the OSE.INI file, but you can modify them to customize the product behavior. To modify these files, use an ASCII text editor. You must have write permissions on the directory where either file is located to be able to modify them.
Note:
On the WinCE and Blackberry platforms, these files are named with the extension of.TXT, so that you can double-click on it to open the file.The following sections detail the parameters within the OSE.INI and DEVMGR.INI configuration files:
The OSE.INI file stores properties used by the mobile clients. It contains parameters that define the location of the mobile client database and mobile client files, defines parameters for all databases on a system, and how to customize synchronization for the mobile client database. There is a single OSE.INI file for each mobile device for all users of that device. The latest modifications to parameters in the OSE.INI file take effect only during a manual synchronization or after restarting the Sync Agent for automatic synchronization. On WinCE and EPOC, the file name is OSE.TXT.
Note:
The installation automatically sets the parameters in yourOSE.INI file, but you can customize the mobile client by modifying the parameter values defined in your OSE.INI file, which is available in Windows under %WINDIR%\OSE.INI and in Linux under $ORACLE_HOME/bin. You must have write permissions on the directory where this file is located to be able to modify the OSE.INI file. To modify the OSE.INI file, use an ASCII text editor.Depending on the platform, it can be located in one of the following directories on the mobile device:
On Win32, WinCE and Linux platforms, the OSE.INI file is located in the <mobile_client_install_root>\bin directory.
On SQLite native clients, the OSE.INI file is located in <mobile_client_install_root>\sqlite. On WinCE, this file is named OSE.TXT.
On Blackberry, the OSE.TXT file is located in /store/user/home/oracle/sync.
On Android, the OSE.INI file is located in /data/data/<application_package>/app_oracle.sync. Applications import the mSync.jar library; thus, the <application_package> should be replaced with the user's application that invokes the OSESession APIs.
The following are the parameter sections for the OSE.INI file:
The RESUME parameter specifies whether the resume transport is enabled. Values are YES or NO.
[OSE] RESUME=YES|NO
The SQLITE section configures certain aspects of both the Berkeley DB and SQLite Mobile Clients. The following sections describe the mobile client parameters that you can modify:
By default, the location of Berkeley DB and SQLite is determined by the DATA_DIRECTORY parameter in the OSE.INI file. However, if this parameter is not set, the location of SQLite on Win32, WinCE, or Linux platforms is determined by the location of the ospSqlite library.
SQLite, Oracle Database Mobile Server repository files, and temporary synchronization data are stored in the DATA_DIRECTORY/sqlite_db/<user> directory, where <user> is the synchronization user id. The database repository files are named with the .db extension, such as TERRY\mysqlite.db. These files are used to manage the change control for transactions and synchronization for the user.
Internal settings and parameters for the SQLite Mobile Client is stored in the DATA_DIRECTORY/oseconf directory.
Example for setting the directory on a Win32 platform:
[SQLITE] DATA_DIRECTORY=C:\mobileclient\sqlite
Example for setting the directory on a Blackberry:
[SQLITE] DATA_DIRECTORY=file:///SDCard/databases/my_app
The QUEUES parameter specifies which type of snapshots the client will use in tracking the changes for Berkely DB and SQLite databases. The following list the two snapshot types:
Queue-based: Both client and server changes are stored in a single queue. Whenever the snapshot is not locked by an application, the synchronization retrieves data from the In Queue and applies it to the base snapshot. At this point, the synchronization propagates data from the Out Queue to the server.
Although both snapshot types rely on triggers, queue-based snapshots allow concurrent operations on Berkely DB and SQLite databases while any synchronization is in progress. The Sync Agent's compose operation places modified data into the Out Queue. Later, the Sync Session uploads multiple client transactions delineated by a unique transaction id to the server.
Set this type with QUEUES=YES.
State-based. State-based snapshots decipher the difference in the state of the data between subsequent synchronization events. This snapshot type is more resource efficient than queue-based snapshots. Pure Java clients only support state-based snapshots. To enable queue-based snapshots, set the QUEUES parameter in the OSE.INI file to NO.
[SQLITE] QUEUES=YES|NO
Set LIMIT_CONNECTIONS to YES when you want to limit the number of concurrent connections used by synchronization. Setting this parameter to YES keeps alive only the minimum required number of connections. If the QUEUES parameter is set to YES, the minimum number of connections necessary for synchronization is 2. If QUEUES is set to NO, only a single connection is required.
Setting the LIMIT_CONNECTIONS parameter is a trade-off between performance and memory limitations. This parameter is set to YES by default on all Blackberry devices for conserving memory.
[SQLITE] LIMIT_CONNECTIONS=YES|NO
The DEVMGR.INI file contains mobile client parameters for Device Management in the DMC section and the network parameters in the NETWORK section. For full details on device management parameters that can be modified before installing the client, see Section 7.2, "Configuring Mobile Clients Before Installation" in the Oracle Database Mobile Server Administration and Deployment Guide.
The following sections describe the parameters for the DMC and Network sections:
The Device Management parameters are as follows:
The DISABLE_PROMPT parameter accepts a TRUE or FALSE value, which causes the following action:
TRUE: The device checks for software updates available on the server. If updates are available, these are brought down to the client and installed.
FALSE: The device checks for software updates available on the server. If updates are available, the option to bring down the updates and install them is displayed to the user, who decides what action to take. If the client chooses to update, then these are brought down to the client and installed.
The port number on the mobile device that accepts device management commands from the mobile server. By default, the port number is 8521. Do not modify on the client. Even though it is described here, you should only modify the PUSH_PORT variable in the INF file BEFORE the mobile client is installed. For full details, see Section 7.2, "Configuring Mobile Clients Before Installation" in the Oracle Database Mobile Server Administration and Deployment Guide.
The day and time to check for software updates for the client. You can modify day and time here or within the DMAgent UI. For details on the DMAgent UI, see Section 7.7, "Using the Device Manager Agent (dmagent) on the Client" in the Oracle Database Mobile Server Administration and Deployment Guide. If you do want to modify them here, the values are as follows:
Day when the device checks for software updates. Used in combination with UPDATE_TIME. UPDATE_DAY takes 0 - 8 which translates to the following days:
Never = 0
Daily = 1
Sunday = 2
Monday = 3
Tuesday = 4
Wednesday = 5
Thursday = 6
Friday = 7
Saturday = 8
Time of day that the device checks for software updates from the mobile server. Used in combination with UPDATE_DAY. UPDATE_TIME can take values 0 - 23 which translates to the following time:
00:00 = 0
01:00 = 1
12:00 = 12
13:00 = 13
23:00 = 23
Integer value that configures the maximum number of retry attempts before abandoning a server command.
The frequency of how many seconds between the client polls. The DMAGENT connects to the mobile server checking for new commands at the defined FREQUENCY interval.
If you turn on the DEBUG parameter in the [DMC] section, then this turns on the debugging for the device manager. All device manager debug messages are written to the _dmdebug.txt file.
To enable, set the DEBUG parameter in the [DMC] section to 1. Set to 0 to turn off debug feature, which is the default.
Default value: 0
The following parameter configures how the client interacts over the network:
This parameter points to the mobile server. It communicates with the mobile server over HTTP or HTTPS. The expected syntax for the SERVER_URL parameter is as follows:
HTTP://<host>:<port>/mobile
For example:
[NETWORK] SERVER_URL=HTTPs://myhost:8888/mobile
You can use certificates that are not signed by a trusted authority, such as a self-signed certificate, on the mobile server. Set the following parameter in the NETWORK section on the client device:
[NETWORK] DISABLE_SSL_CHECK=YES
This parameter enables the client to use the self-signed certificate for SSL encryption, but not to perform SSL authentication.
If user has a proxy between the mobile client and the mobile server, then in order for the Device Manager (dmagent) to access the mobile server to poll for command, then configure this parameter to the proxy server URL, including port number.
Format is <hostname>:<port>, as follows:
[NETWORK] HTTP_PROXY=proxy.foo.com:8080
The following content is displayed from a sample OSE.INI file.
[SQLITE] DATA_DIRECTORY=C:\mobileclient\sqlite QUEUES=YES [OSE] RESUME=NO [BGSYNC] DISABLE=NO
The following content is displayed from a sample DEVMGR.INI file.
[NETWORK] DISABLE_SSL_CHECK=YES HTTP_PROXY=proxy.foo.com:8080