Device repository update CLI

As an alternative to the Mobile Portal Toolkit interface to the device update service, administrators can use the mcsUpdateClient command line utility to download the latest version of the device information, and the mcsRepositoryManager utility to merge the information and report on the merge.

As an alternative to the Mobile Portal Toolkit interface to the device update service, administrators can use the mcsUpdateClient command line utility to download the latest version of the device information, and the mcsRepositoryManager utility to merge the information and report on the merge.

If MCS is installed with Mobile Portal Accelerator, you'll find the mcsUpdateClient script in the [wp_root]/repository/updatedevcfli/bin directory and the mcsRepositoryManamger script in the [wp_root]/repository/bin directory.

Before using the mcsUpdateClient and mcsRepositoryManager scripts:

  1. Set up the Mobile Portal Accelerator environment by running the following command:

    . [was-root]/bin/setupCmdLine.sh
    Note:

    There is a period and then a space before [was-root].

  2. If you plan to run the mcsUpdateClient script, add the JDBC driver file(s) to the CLASSPATH environment variable. For DB2, you must add db2java.zip and db2jcc.jar to the CLASSPATH. For Oracle, add ojdbc14.jar to the CLASSPATH.

  3. cd to the directory containing the script you plan to run.

Downloading the update

To load the new device information administrators can use the mcsUpdateClient command line, specifying a user name and password, the repository file to update, and the file location for the download. Administrators can also optionally define parameters for a proxy server.

An .mdpr file cannot be overridden, and therefore a new filename must be specified in the updateFile parameter. To overwrite or merge the update with a repository file, administrators can use the Update wizard.

Note:

It is not possible to specify a version of a repository information other than the latest version. However, earlier versions can be accessed using the Mobile Portal Toolkit interface.

CLI parameters

Parameter Description
-user Required. User name for the update service
-password Required. Password for the update service
-proxyHost Address of the proxy server
-proxyPort Port of the proxy server
-proxyUser Username for the proxy server
-proxyPassword Password for the proxy server
-deviceRepository Required. The full path to the current .mdpr file containing device information. Must exist.
-updateFile Required. The full path and name of the file to save. Must not exist. 

    
mcsUpdateClient[-user <username>
                -password <password>]
               [-proxyHost <proxyHost>
                -proxyPort <proxyHost>
                -proxyUser <proxyUser>
                -proxyPassword <proxyPassword>]   
               [latest
                -deviceRepository <deviceRepository>
                -updateFile <updateFile>]

Merging the update

To merge the update with a repository file, administrators use the mcsRepositoryManager merge command. It can merge the updates from the new device repository file into the customer's current file preserving any of the customer's changes. If the customer has no changes, then it is not necessary to use this tool instead the new .mdpr file can simply be imported to the device repository storage.

Parameter Description
-deviceRepository Required. The full path to the current .mdpr file. Must exist.
-updateFile Required. The full path and name of the update repository file. Must exist. 

mcsRepositoryManager
  merge[-deviceRepository <deviceRepository>
        -updateFile <updateFile>]

Merge report

MCS creates an XML merge report listing the changes to the device information in the same directory as the existing repository file. The report is named using the repository version numbers in the form [repositoryfilename]-2005040501-updates-to-2005033001.xml. Administrators can transform the report to another format using an XSL transform.

The report is divided into main sections by the categories, policies and devices elements. Individual category, policy and device elements have a name attribute, and a status attribute that can take the values 'created', 'updated, or 'deleted'. These elements, and others, can contain nested old or new elements, with details of labels types and values, and device elements can contain nested policy, device hierarchy and identification sections.

<policy-definitions>
  <categories>
    <category status="created" name="downloads">
      <new label="downloads" />
    </category>
  </categories>
  <policies>
    <policy status="created" name="audio.synth.polyphony.level">
      <new label="Polyphony Level">
        <type>
          <text />
        </type>
      </new>
    </policy>
    <policy status="created" name="downloadable.audio.3GPP">
      <new label="3GPP audio downloads">
        <type>
          <boolean />
        </type>
      </new>
    </policy>
  </policies>
  <devices>
    <device name="au-C410T" status="updated">
      <hierarchy>
        <device name="Master" />
        <device name="Mobile" />
        <device name="Handset" />
        <device name="HDML-Handset" />
        <device name="KDDI-HDML" />
      </hierarchy>
      <policies>
        <policy status="deleted" name="fallback">
          <old label="fallback">
            <value>KDDI-HDML</value>
          </old>
        </policy>
      </policies>
    </device>
  </devices>
</policy-definitions>

Related topics