Glossary
The following terminology is used in the Deployment Tool.
|
ActiveX External component |
ActiveX External Components are ActiveX controls provided by a 3rd-party. Visual LANSA supports all standard ActiveX Interfaces. To use an external ActiveX Control within the LANSA development environment, a corresponding LANSA ActiveX component is created. The external program information associated with the ActiveX control is identified within this ActiveX object. The ActiveX control can then be used within Visual LANSA much the same as any other Visual LANSA component. For more information, refer to ActiveX Controls in the Visual LANSA Developer's Guide. |
|
ActiveX wrapped component |
LANSA Components can be "wrapped" and made available to other vendors as an ActiveX Control. The processing of "wrapping" the LANSA component requires the registration of the LANSA component and creation of a supporting session.cfg file in the environment where the ActiveX will be used. For more information, refer to ActiveX Controls in the Visual LANSA Developer's Guide. |
|
Application |
"Application" has a dual meaning in the context of the Deployment Tool. In the first instance an Application draws a boundary around the product you have developed using LANSA, encompassing all the bits and pieces which comprise the Application. This is a LANSA-developed Application. In terms of the Deployment Tool an Application is a group of Packages. One or more Packages can be linked under the "umbrella" of an Application in the Deployment Tool. An Application is distributed for download, rather than a Package. You may have more than one Application defined in the Deployment Tool to deploy your LANSA-developed application. For example, if you need to deploy a client server application you will typically define a Deployment Tool Application to deploy the client side components and a separate Deployment Tool Application to deploy the server side components. |
|
Application Server |
For Just in Time deployment, the Application Server is the repository for all released deployment packages and has an active listener to receive requests from Client (or Target) PCs. When the Application is launched on a Client PC this initiates communication with the Application Server to determine if updates to be downloaded. Any updates will be automatically applied on the Client PC before the Application is started. |
|
Assembler |
The person selecting the deployment tool options & settings described in this guide. |
|
Base Language |
The language to be translated from when performing LANSA Object or Parameter File translations based on a translation package. The language must be defined in the partition where the package is installed. |
|
Client PC |
Client PC(s) are an integral part of a client-server installation. Typically the Client PC accesses a database on the server (rather than locally) and may rely on the server to perform some operations. |
|
Communication Files |
The communication files are Host Route Table (lroute.dat) and Listener Table (listener.dat). These files are maintained using the LANSA Communications Administrator interface. |
|
Corporate Application Install |
In a corporate environment it is assumed users do not have administrative rights to their PC therefore when installing an Application with a database an administrator of the machine is required to set up the shared database by executing an "All Users" install of the Application with Setup Database = TRUE (i.e. SUDB=1). The end user can then install any subsequent updates which do not modify the database using a "Per User" install. If an end user needs to be allowed to set up the database the Application deployment settings can be modified to ensure the database setup is allowed OR the installation can be executed from a command line using msiexec.exe and setting a parameter to change Setup Database to TRUE (i.e. SUDB= 1). Refer to Personal Application Install for comparison. |
|
Deployment Template |
In the context of the Deployment Tool a Template is implements a predetermined set of values for the Package's settings and options. Objects can also be included in a Deployment Template. By using Templates, you can reduce the number of options to be set each time you wish to create a package. You can create a purpose-built template or save a package as a template. A number of pre-recorded Templates are supplied with the Deployment Tool. |
|
Developer |
The person who developed the Visual LANSA application being deployed. This person may also be the Assembler of the package. |
|
DLL Upgrade |
DLL upgrades are no longer supported. The alternate approach is a Package Upgrade. |
|
End User |
The user of the Visual LANSA Application. |
|
Globally Unique Identifier (GUID) |
A Globally Unique Identifier, commonly called a GUID, is a unique reference number used to identify software. GUIDs are usually stored as 128-bit values, and are commonly displayed as 32 hexadecimal digits with groups separated by hyphens, for example 5667BA66-1CC2-442E-8B80-03288BB8FDC0. |
|
Installer |
The person who installs the package on the end user's PC. This person may also be the end user. |
|
Just in Time (JIT) Installation |
Just-in-time package installation ensures the latest changes to a Package-developed application are installed before a user accesses the application. The Application Packages are defined with appropriate dependencies, for example install package A before package B, and then they are installed on a network server. When a user starts the application a check is performed to see if any upgrades needs to be installed before the application is launched. Any packages not previously installed on the client system are autoamtically installed according to the pre-defined dependencies before the application is launched. Only installing changes when an application is used has the advantages of:
|
|
MSI file |
MSI file is an installer package file format used by Windows.MSI files are used for installation, storage, and removal of applications. |
|
msiexec.exe |
Msiexec.exe belongs to Windows Installer and is used to install, modify or configure applications from the command line which are installed from an MSI file. |
|
MSP file |
An application that has been installed using the Microsoft Windows Installer can be upgraded by reinstalling an updated installation package (a MSI file), or by applying a Windows Installer patch (an MSP file) to the application. An MSP file contains updates to an application and describes which versions of the application can receive the patch. Servicing applications by delivering a Windows Installer patch, rather than a complete installation package for the updated product can have advantages. A patch can contain an entire file or only the file bits necessary to update part of the file. This enables the user to download an upgrade patch that is much smaller than the installation package for the entire product. It is not recommended that you include database changes as they are complex to manage and can easily result in a corrupted database. |
|
Network Client Application |
A Network Client application allows you to create packages that do not include LANSA executable objects. Typically, a package for a Network Client application will contain shortcuts to the server and indicate the target platform. It is intended for applications where the executables and runtime environment are installed on a central sever for shared use. A separate application must be defined to install the server side components, that is, the LANSA runtime environment, communications and compiled DLLs from functions and components. |
|
Package |
A package defines what and how your LANSA-developed Application will be deployed to a user's PC. A Package is a generic term to refer to a Version or Patch. |
|
Package Upgrade |
There is only one type of Just-In-Time Upgrade, so this distinction - Package Upgrade - is superfluous. See Just-In-Time Installations. |
|
Patch |
A Patch is used to deliver a set of changes to a software product that has been installed using the Windows Installer. A software product can be upgraded by installing a new Version (MSI file) or by applying a Patch (MSP file). A Patch is typically used to apply modified compiled objects, shortcuts and executables. A patch should not be used to deploy database changes. A Patch is identified by its Patch Number. The Patch number has a direct relationship to the Version or Patch it was based on, for example Patch 1.0.0.1 would be the first patch against Version 1.0.0. |
|
Personal Application Install |
In the case of a Personal Application with a database the end user of the application is allowed to set up the database for an Application. To facilitate this the package must be built with the appropriate Database Setup options OR the installation can be executed from a command line using msiexec.exe and setting a parameter to change the Setup Database Setup to TRUE (i.e. SUDB= 1). Refer to Corporate Application Install for comparison. |
|
Primary Installation |
The main Application installation is generally referred to as the primary installation to distinguish it from the network client installation which is a small MSI file automatically created for most primary installations and delivered by the primary installation. |
|
Target PC |
The PC where the Visual LANSA application is to be deployed. |
|
Template |
See Deployment Template. |
|
Translation Language |
The language to be translated to when performing LANSA Object or Parameter File translations based on a translation package. The language must be defined in the partition where the package is installed. |
|
Translation Package |
A translation package includes either (or both) of the or options described in Settings . When installed a translation package will create a desktop folder with two options:
The Translate Application option will launch the Translate Object Details form supplied by LANSA. The XTRANSLT template provides a basis for a translation package. |
|
X_START |
The X_START.SAV file stores any override values to be used in conjunction with an X_RUN.EXE command. Typically, when a package is installed a desktop icon is created to launch the application. This icon has a LANSA X_RUN command associated with it. The X_START file is used in conjunction with the X_RUN to prompt for values before launching the application and to provide useful default values to be used on the prompt dialog. This can introduce flexibility into how and what is launched when the application is started. |
|
Version |
A Version is a full install of the software product. A Version belongs to an Application. A Version is identified by its Version Number. The Version Numbering is arbitrary but subsequent version numbers must be greater than previous ones. |