Web Console  |  Deployment during development

 

Application Deployment

Introduction

MI offers a sophisticated application deployment concept to manage a fleet of devices centrally. The administrator simply needs to assign applications to a user or to a role. At next synchronization of their devices, the application will be installed on the device of this user (or all users assigned to this role respectively).

Prerequisites

Application deployment requires that

  1. MI Client Component is installed on the mobile device
  2. Synchronization between MI Client and MI Server is possible
  3. Mobile Component Descriptor (MCD) exists on MI Server (created throuhg transaction MI_MCD or being delivered in SAP standard via transport)
  4. Application archive has been assigned to the MCD by uploading it to the Web Console
  5. For role-based deployment of an application, a miniapp of the same name as the MCD needs to exist.
When a .war file (that contains the mobile application) has to be deployed on a device that has only a Java Runtime (JRE) installed, you have to create the .war file with compiled JSP. JSP compilation by the Tomcat servlet engine requires the Java Development Kit (JDK). See the Eclipse "Export project to a .war file" documentation for more details.

 

Deployment process

The deployment process is depicted in the following diagram:

  1. The administrator can assign one or many mobile applications to individual users in the MI Web Console. For further information on the deployment console, please consult its online documentation on help.sap.com.
  2. Alternatively, applications can also be assigned to roles using standard role maintenance (transaction PFCG) on the MI Server. It will then automatically be deployed to all users that are assigned to this role. This automatism also considers role assignments from remote systems.
    The mobile application is assigned to the role by adding a miniapp of the same name as the mobile application to the role. The version of the application that will be deployed was defined during upload of the mobile application in the Web Console. If an application is assigned to several roles, it will always be deployed in the same version.
    As the role management and the application deployment use different database tables, a role comparison needs to be run to copy the information from the role management. The role comparison can be started manually from within the Web Console or automatically via a scheduled job WAF_DEPLOYMENT_FROM_ROLES.
  3. The information from role maintenance and deployment console together form the deployment definition for a given user. The deployment definition represents the target state for a given user and device.
  4. All installed applications are registered in the MI Registry of the MI Client Component. The MI Registry organizes which of the installed applications is actually assigned to the current user and only allows the user to start the relevant applications. The MI Registry plays a central role in MI's multi-user feature.
    The MI registry has nothing to do with the well-known Windows registry. It is a set of files owned by MI that cannot be accessed by applications.
    During synchronization, the MI client passes its current registry to the WebAS for comparison.
  5. The WebAS compares the received registry with the deployment definition. If the user assignment on the WebAS is different from the MI registry, the corresponding delta is computed. This can happen because applications are missing, installed in wrong versions, are no longer required etc.
  6. The delta information is sent to the device during the synchronization response in a normal data container. For missing applications or applications of wrong version, the application name, version, short text and download link are handed back to the device together with the names of the users the application is intended for. For applications that are no longer required, a trigger for their deletion is handed back.
    The new installation status is now displayed in the deployment console. For applications that have been successfully installed or deleted, the information is updated in the console. For applications that should be installed or de installed, the response for successful installation or de installation will only be received on next synchronization. The deployment console displays the texts 'Installation is runnning' or 'De installation is running'.
  7. On receipt of the delta information, the device initiates a download from the specified location. The download uses a normal http-get to download the war-files (for JSP applications) or jar-files (for AWT applications).
  8. On successful download, the application archive is copied to <MI root>/webapps and registered. If a previous versions of the application was installed before, all its application files need to be deleted first. For this purpose, the MI Client keeps track of all installed application files. This same mechanism is used for de installation of applications.
    To finish the deployment process, MI needs to be restarted. This will restart MI's Tomcat and hence extract the application archive under <MI root>/webapps. For PocketPC devices, where MI is launched at start up of the operating system, the device needs to be soft-reset.
    The MI Home page is generated from the MI Registry, and therefore the application start link is automatically displayed - even before restart of MI and hence before the application can actually be started.