Skip to Content
h3. Introduction    In MI implementation, every member has to carry out tests so many times and sometimes require reinstallation of the framework several times. This reinstallation process takes some time i.e. if you’re using the MI client installer; you need to run the uninstaller prior to a clean MI installation. And after the reinstallation you need to enter some settings information like gateway host server, port number and so on, which were the same information you did enter in your last installation.  This article describes a simple technique on how to reinitialize an existing MI installation as if it is a fresh installation while at the same time preserving the settings information. This technique could be useful also if you need a fresh installation but you don’t have the MI client installer file.  h4. Target MI Version    This article applies to SAP Mobile Infrastructure client 2.1 and 2.5 Tomcat runtime. For AWT MI version, there are slight differences. I will be posting a different blog for this one in the future as well.  >     NOTE: Due to the Japanese OS and default font that I’m using, the backslash may appear as ¥ (yen mark) .   h3. The MI File Structure    The MI installation directory structure is shown in Figure 1 – (a) is the newly installed MI structure and, (b) is an MI structure that has already been executed, registered or currently in-use state. Some new folders like +data +, +log +, and +work + folders are created during the first execution of the framework, and some other files inside the +sync + and +settings + directory are also created. The MI Installation Structure The +settings +folder is installed containing the following files as shown in Figure 2 . The +convids.sys + file has a 0KB size as there’s no existing conversation ID in the client yet. The +MobileEngine.registry + does not exist as well; it will be created upon the first execution of the framework; and all information like the deployed application’s MCD are being saved into this registry file. Fresh settings directory The +bin +, +conf +, +logs + and +webapps + directory are default file structure of the Tomcat framework. On a fresh installation, the +me + web application is already contained in the +webapps + folder. All MI applications (in WAR format) deployed into the client are also extracted into this location.  The +sync + folder is the directory where temporary file like raw outbound and inbound containers are saved prior to their transmission and processing, respectively. A separate folder inside this directory is created for every users and a common shared folder for the SHARED user account. The framework also stores some serialized objects like sync listeners registered by the application to the framework into this location. On a fresh installation, this directory is generally empty.  The +work + directory is the default working directory of the Tomcat framework. (It could be modified to other location by changing the +workDir + attribute value in the +conf\server.xml + file.  The +pios + contains the configuration information specific to the +Peripheral Input/Output Support (PIOS) + interface and log outputs specific to this interface. On a fresh installation, this directory is empty just like the sync folder.  The +log +directory contains the MI trace and application logs taken during the runtime.   h3. Re-initialization Procedures   The re-initialization of an MI installation is pretty straight-forward. It is just removing of files and directories created during the framework’s runtime and reverting some values of the framework’s configuration file. The procedures here are described step-by-step, and at the same time giving corresponding snippets based on Windows DOS batch command. For sure, it would be much easier doing this in Perl or in Visual Basic scripts; or even writing a tool in native programs or Java as well. The choice of which tool to use depends on the reader, and the author would just like to demonstrate the steps using the DOS commands equipped inside Windows.  h4. Prerequisite    Prior to the procedure’s execution, the framework should not be running and that no files within the installation are used or blocked for modification by external applications.  h4. Removal of Runtime Directories   On the MI root installation directory, folders created during the framework’s runtime should be removed. These folder are +data +, +log +, and +work + folders. You may remove the +sync + folder as well ? this folder is empty during the fresh installation. On your MI installation directory, run the following DOS commands.  >     rem Removing deployed applications   rmdir /s/q log   rmdir /s/q data   rmdir /s/q sync   rmdir /s/q work    Take note also that you might need to remove other directories from the installation root folder that were created by the deployed applications during the runtime.   h4. Removal of Deployed Applications   For MI client using the Tomcat runtime, all deployed applications reside in the +webapps + directory located in the root installation folder. These applications should be removed as well, but the framework’s application (the +me + folder) that is included in the installer should be retained.  The snippet below makes a backup copy of the +me + folder inside the +webapps + directory into a temporary directory called +MEBACKUP +. After the backup is done, the whole +webapps + directory is removed. The rest of the lines will copy back the +me + files into the +webapps + directory and delete the temporary folder. (You may use the move command here as well)  >     rem Removing deployed applications   xcopy webapps\me MEBACKUP /e/i/q   rmdir webapps /s/q   xcopy MEBACKUP webapps\me /e/i/q   rmdir MEBACKUP /s/q    h4. Working with Settings Folder   The +settings +folder contains the configuration and settings files as shown in Figure 3 . Let’s look at which files or sub-directory should we be touching. image h5. The Registry File++   MI stores all the framework and application/add-on specific information into this registry file. This is created upon the very first execution of the MI framework. To delete this file, run the following command from within the +settings + directory location. You may just as well rename the file into something like +MobileEngine.registry_old + but this would leave unnecessary files into your +settings + folder.  >     rem Removing MobileEngine.registry   del /s/f/q MobileEngine.registry     h5. The ConversationID Information   The conversation IDs of the framework and of the deployed applications are also stored in the +convids.sys + file and within the +covIds + sub-directory. This information should be reverted as well into its fresh state.     The contents of the +convids.sys + file should be cleaned up. You may use any text editor to delete its contents and overwrite the file. The following commands will delete the +convids.sys + file and then create an empty +convids.sys + file. This would save you some mouse clicks if you are to do it using an editor.  >     rem Refreshing convids.sys   del /s/f/q convids.sys   type nul>convids.sys    Next, the sub-directory +covIds + contains some +.cid +files as shown in Figure 4 . image This folder is created during the framework’s first execution and is the storage location for all the +cid + files which corresponds to every separate and user-shared conversation ids. The following command executed at the +settings + location will remove this sub-folder.  >     rmdir /s/q covIds    h5. The Sync Counter   The +.syncCount + file contains the synchronization counter. This file is created during runtime and is updated on client synchronization. The following command will delete this file.  >     del /s/f/q .syncCount    h5. The Configuration File   MI client stores its configuration information into the +MobileEngine.config +. Some entries having their default values are already contained in this file upon installation. The entries are in their +key + = +value + format. The fresh installation will contain the following configuration entries shown in Figure 5 . MobileEngine.config default entries
To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

Leave a Reply