15.9 Customizing Just In Time Package Upgrade

Why would you want to customise the JIT Package Upgrade?

• To provide command line parameters to the MSI to alter its behaviour, like a silent install, or logging parameters.

• To have different users on different upgrade paths. Say, some users receive a Patch but others don't. (This option is not compatible with Feature Set Deployment)

• To provide your own SETUP.EXE to do whatever you want.

A SETUP.EXE is shipped with LANSA in the execute directory. This program runs a file called SETUP.BAT from the same directory as SETUP.EXE is executed from.

An example of the automatically generated SETUP.BAT for a patch is:

The first line is the MSI or MSP to be run - in this case:
"TESTMSI2_v2.3.4.2_en-us.msp" /passive.
The Application Server generates this line. The second line contains the parameters of the client that is running JIT. This line is added by the Client before calling SETUP.EXE. This launches the application after the installation of the Patch completes. SETUP.EXE uses the API ShellExecute to execute SETUP.BAT using the verb 'open'.

Patches use /passive because they don't have any questions to answer, so why require the user to enter anything? The /passive option displays a progress bar so the user gets feedback that something is happening.

 

When setup.txt has /passive specified, an MSI install will NOT start x_run after installing.
/passive prevents the Exit Dialog being used and thus x_run is not started. The end user will need to restart the application manually.

So that's the automatic operation.

If the file "SETUP.TXT" exists in the Application directory, the contents are appended to the MSI/MSP filename, for example:

 /L*V+ "C:\package.log"

The parameters specified are MSI Public Properties. Please refer to msiexec.exe Command-Line Options for details.

Any valid MSI/MSP parameters can be used here. This particular example logs everything, appending to the file c:\package.log. This is the first level of customisation - add parameters to the MSI command line. The previous SETUP.BAT would therefore become:

The JIT Application Server checks if there is an x_apps directory for the requested Application. If there is, then an MSI will be downloaded.

The application to download is retrieved from applications.txt, unless this file does not exist. If that's the case then the application is taken from the command line parameter APPL.

The server then checks if SETUP.EXE is in the Application directory. If it isn't then the copy in the LANSA execute directory is transferred to the Client. This is another level of customisation available. A developer can put whatever SETUP.EXE file they like in the Application Directory and it will be transferred to the client and executed. For example it could be a self-extracting executable as a way to get other files downloaded to the client.

Of course, your custom SETUP.EXE will need to run SETUP.BAT if it is also going to install the MSI/MSP and then launch the application. Support by LANSA of this configuration only extends to delivering the custom SETUP.EXE to the Client. What it does after that you will need to support yourselves.

So, the files transferred to the Client are:

• SETUP.EXE

• SETUP.BAT

• <The next MSI/MSP file that the client does not have installed>

The Application Server can have an Application Directory that does not match the original Application name. The Client needs to install the first MSI specifying the new name as an MSI property. This will set the APPL value to the new one and attach to JIT using the new APPL. The Server will generate a SETUP.BAT that specifies APPL on the MSI command line.

Modifying the APPL value is not supported when using Feature Set Deployment.

APPL is a runtime only value that can ONLY be set on the MSI command line. It is only necessary when you have a JIT server. The 1^st install of the application needs to set the value too. That is done by supplying the 3 files (SETUP.EXE, SETUP.TXT and the MSI) that the JIT provides to the Client and just getting the Client to run SETUP.EXE rather than the MSI. This is the recommended approach to ensure consistency of APPL value. An alternative is to provide instructions for the Client to run the MSI using msiexec.exe and the property value to pass. Or a batch file can be provided.

The server is set up by creating the new APPL directory name. Copy the MSI file from the original directory. JIT will now correctly not find any updates to install on the client. Copy MSP files in as required and JIT will install them the next time the application is executed. There must be at least one MSI or MSP in the directory otherwise a 750 error is output to X_ERR.LOG on the server (0750 - Application testmsi3 not found or no packages in applpkg.dat)

In summary, the customisation available is:

1.  Create SETUP.TXT yourself and specify the MSI parameters, including all the X_RUN parameters exposed as MSI Properties.

2.  The SETUP.EXE can be replaced and perform whatever install the developer desires 

3.  Use a different Application Name than the one it was built with - for multi-client support at different Package levels. For example, Application built as LANSAInventoryControl could be put in directories Customer1InventoryControl and Customer2InventoryControl. These can then be maintained at different levels even though they are running exactly the same software. They can also be given different Patches too. (This option is not compatible with Feature Set Deployment)

Example setup.txt files

1.  /qb
Displays a progress dialog only for both MSI and MSP installs and no confirmation dialog. Thus the installs happen automatically without any user interaction. MSI installs will use the settings from the previous install.

2.  /l*vx %TEMP%\InstallLog.txt
Diagnostic log file output to user's temporary directory.

3.  /qf
Displays a full user interface which overrides the default Patch behaviour of /passive and also overrides the Silent Install setting inside the MSI/MSP.