How can we apply MI Application Patches?

Introduction

There is sometimes a need to update the changes(User Interface Changes and Business Logic Changes) in mobile application which is already installed in many client devices. This article describes how to modify the already installed application in client without creating the new version of application. The assignment of new version of application results into the deletion of old application and hence the deletion of data associated with the old application. If there is no change in the structures(metadata information in meRepMeta.xml file) which are used in BAPI Wrappers (These are used in Synchronization Business Object – SyncBo – creation , and these SyncBos are used in particular Mobile Application ), assigning new version of application to the client device is a time spending process in production environments. In this article , i am discussing a simple way to update the mobile application which is installed on the client device by applying the patch of that application. This is applicable to JSP Client Runtime and JSP MI applications.

Prerequisites

1. Atleast SAP MI Client Component 2.5 SP11 (JSP Runtime)is installed on the mobile device.
2. Old Application must be installed on the Client Device.
3. There will not be any changes in the structures which are used in BAPI Wrapper creation.

MI Versions:

I used JSP Runtime of MI 2.5 SP11 ,SP13 and SP15 as the subject installations.

Export the MI Project as MI Archive

After changing the MI application in NetWeaver Developer studio , export the MI Project as MI Archive into the local machine.In the MI Client there is no need to keep the source code of the project.MI client is using the compiled classes of JSP pages and Java code(Java Class) we have included in the MI Project. So during export there is no need to select the “Include source code of the project” check box in the “Create MI Archive” pop up window. As it is a JSP Runtime client application , the exported MI Archive file is in the WAR(Web Archive) format.

Here we have created one application named “MIAPPLICATION”. So the exported MI Archive file is MIAPPLICATION.WAR.

Extracting the contents of MI Archive

Basically this WAR file is zip compatible, so we can extract the contents of the WAR file using WinZip or WinRar. Here what I did is without using the WinZip or WinRar , just renamed the MIAPPLICATION.WAR file to MIAPPLICATION.ZIP. Then used the default support for ZIP files in WinXP Operating System and extract the contents of this ZIP.

Contents of the MI Archive

These are the default folders that we got by extracting the contents of the MI Archive .

Here ,

css folder – for storing the Cascade Style Sheets

mimes folder -- for storing mime repository objects like picture

WEB-INF folder -- for storing the compiled java classes of JSP pages and Java Code we have included in our MI application , and the web.xml deployment descriptor for defining the Application.

meRepMeta.xml -- Metadata information regarding the the MI Application.

Subfolders in WEB-INF

The lib directory is for storing the compiled classes of our MI Application. This compiled classes include the class files of individual JSP files and the compiled classes of java files we have included in our application .These compiled classes are in the form of a jar file. In our case the lib contains the MIAPPLICATION.jar file.The srclib contains the source code of the project. We have not included the source of the project ,so in our case there will not be a directory named srclib inside the WEB-INF folder. On further extracting the contents of MIAPPLICATION.jar file , we can see

Contents of MIAPPLICATION.jar

The jsp folder contain the compiled classes of jsp pages in our application. The package(here i created a package named package and put my Java Files within this package. That’s why a folder named package is inside this MIAPPLICATION.jar file. Otherwise there will not be.), contain the compiled classes of all Java Files in our application. So if the change is only to our JSP files and Java code , we only have to replace the MIAPPLICATION.jar file in the client device which is residing inside the WEB-INF folder of our application installation folder , provided we have not changed the number of JSP files in our application. If we are changing the number of JSP files(means adding new JSP files or deleting the existing JSP files ),then we have to replace the web.xml file also. In this article i am discussing a scenario where the changes are only to the contents of the JSP files and Java Files. So in this example our aim is only to replace the MIAPPLICATION.jar file from the application installation directory in the client device.

Creating the Application Patch

Here the steps are ,

1) Extract the MIAPPLICATION.jar file from the extracted contents.

2) Create manifest file for the patch.

3) Put appropriate entries in the install.xml file.

4) Make the zip file (patch) containing the jar file , manifest file and the install.xml file.

Extract the MIAPPLICATION.jar file from the extracted contents
I have already explained how to pick up the MIAPPLICATION.jar file from the extracted contents of modified MI Archive file. Please follow the steps i discussed earlier.

Create manifest file for the patch
The manifest is a special file that can contain information about the files packaged in a JAR(ZIP) file. Create manifest.mf with the contents as shown in the figure below.

Contents of manifest file

Put this manifest file in a directory named meta-inf.

By tailoring this "meta" information that the manifest contains, you enable the file to be used for a variety of purposes. Here the PatchArchive : X means it is a patch application.

Put appropriate entries in the install.xml file

In the client device, all installed applications will come under the webapps directory of the MI Installation folder. (During the first time installation of an application in the client device , the war file is downloaded to the client device and it automatically extracts to form the folder structure). File install.xml, contain the installation instructions.

So in client device for the particular installed application , we will have the folder structure that I already explained in the section “Extracting the Contents of MI Archive”. So we have to create appropriate entries in the install.xml file , so that it replaces the MIAPPLICATION.jar file which is in the <MI_HOME> \webapps\MIAPPLICATION\WEB-INF\lib path.

Create a install.xml file with contents as given in the figure below.

Contents of install.xml file

Details of adjusting the installation instructions is in this link

Please go through this link also

Create the zip file (patch) containing the jar file , manifest file and the install.xml file

In this step we are going to create ZAPPLIPATCH.zip file , which contain the jar file , manifest file and the install.xml file. We have already created the meta-inf directory which contain the manifest.mf file and created the install.xml file which contain the installation instructions .

Just look at this instruction in the install.xml file.(You must have a look at the help links for understanding this properly).

<PACKAGE name="MIAPPATCH" description="Installation and Migration Package"> Here it is specified that, MIAPPATCH is the root folder for the MIAPPLICATION.jar file in our case.

The tasks which are to be performed are enclosed within the <TASK></TASK> tag in the install.xml file.

<TASK name="Add new files"> <COPY source="/appatch/" pattern="MIAPPLICATION.jar" target="%MI_HOME%/webapps/MIAPPLICATION/WEB-INF/lib/" mi_running="false"/> </TASK>

Here it is specified that the task to be performed is , copy the MIAPPLICATION.jar file from the appatch (here the source path specified is a relative path with respect to the root directory MIAPPATCH) to the lib directory which is in the MI Application installation directory.(Refer help for details of this tag).

So we have to put the MIAPPLICATION.jar file in the appatchfolder and then put this appatch folder in MIAPPATCH (Root folder).

Now we have the meta-inf (manifest file) folder,MIAPPATCH (contains the application jar file) , and the install.xml(Installation instruction) file.So we can packaged this to make ZAPPLIPATCH.zip (Exact application patch) file.

Contents of ZAPPLIPATCH.zip
Content of MIAPPATCH
Content of appatch

We have created the patch application for our MI Client application. Now we have to upload the archive to the SAP MI Web Console as an add-on and then assign the uploaded archive to roles or users.

Refer these links for help..

Uploading add-on files
Assignment of Mobile Components to Users
Adjusting Installation Instructions

Summary

In this article I had described how to modify the already installed application in client device without creating the new version of application.The assignment of new version of application results into the deletion of old application and hence the deletion of data associated with the old application. Here these are to be noted that there must not be any changes in the meRepMeta.xml(Meta Data) , and the application must be installed on the client device.

Author's Note

I have already mentioned in the prerequisite section that, the original application must be installed on the client device before applying the application patch. If the assignment of application to the client devices is by means of role assignment (we can use role synchronization) and if we are assigning the application patch also through role synchronization, then we have to have a look here. Because, if we don’t have one installation order for applications which are to be installed on the client device then it can create problems. Suppose our original application is the first to be installed on the client device and then the application patch, then before installing the add-on for the application patch on the client device, we have to explicitly restart the mobile client. Because only at this time, the WAR file of the installed application extracted into its folder structure. Otherwise what will happen is that, after the installation of our original application on the client device, that will persist into its WAR format itself (without having the folder structure). On the top of this, we are installing the patch of our installed application. Just look at the installation instructions I mentioned in the blog.

In the installation instruction , it is written to copy the changed jar file to the lib folder of our application installation directory (I have already mentioned in details about the folder structure of our application). Right now we don’t have the folder structure, so after the installation process, in the webapps folder one folder named, as our application name will be created and the jar file will be copied to lib directory within that application folder. So here what will happen is that, this patch installation will create one folder, which is exactly the application name itself and will hold only the jar file into the folder we have specified in the installation instruction file (install.xml file). So after the installation, when we restart it, then the original WAR file (corresponding to our original application) will get deleted from the webapps folder, which is located in our MI_HOME. As a work around here what we can do is, we have to include the entire contents of our application WAR file in the application patch after modifying the application in the Developer Studio (what i meant is not only the jar file for the compiled classes). We have to make appropriate changes in the install.xml (installation instruction file) also. In the first case, we only have to write instruction to copy the jar file to the lib directory of our installed application directory. But in this case, we have to change that instruction to copy files from the patch’s application folder to the webapps, which is located in the MI_HOME root directory itself.

The changed installation instruction will look like this.(This is applicable if only one application is installed on the client device).

SAP PI Tutorials | SAP PI Training | SAP PI 7.5 Tutorials|SAP PI Step by Step Senarioas