Updated August 2011
See History, below, for latest developments on this subject.
A server-based auto-updating system is available for keeping ATE clients updated. As a background, one problem with intelligent clients such as ATE is that they are typically installed independently on multiple clients, thus creating a logistical challenge to keep them updated. Many commercial programs are moving to an Internet-based model for doing this, whereby the client queries the developer's website each time it executes to see if there are any updates, and if so, offers to download and install it. Although we considered this model, there are two problems which seem to make it less than ideal for our circumstances:
| • | Not all clients have Internet access, or if they do, it may be blocked by their VPN software. |
| • | It may or may not be appropriate for the end-user to update to the latest ATE level. That decision should be made by the dealer, and it should be made relative to the software level running on the application server. In general you want the client version to match the server version, although in some cases it might be desirable to update the client or the server to a higher level than the counterpart. |
Since much depends on the level of the software on the application server (both A-Shell and the application itself), and since updating the server is much more difficult to automate (due to the need to coordinate with many users at once), we decided that the best way to manage the client update process is for the dealer or site administrator to place the desired version of ATE in a special place on the server, from which the clients can be updated on an as-needed or as-wanted basis. This eliminates the connectivity issue (since the client must necessarily have connectivity to the application server) and it allows for site-based control of the update process.
Step One: Create a directory /atesetup underneath the directory where the miame.ini resides (e.g. /vm/miame/atesetup).
Step Two: If you want to make an ATE update available to the clients connected to this server, put the ATE setup executable file in that directory. It should be named as follows:
ate-a.b.c{.d{-optional stuff}}.exe
where a, b, c and d are the major, minor, edit and patch levels. Examples:
ate-4.9.949.exe
ate-4.9.949.1.exe
ate-4.9.949.1-madics-1.2.3.4.exe
In the last example above, everything after the second dash (-madics...) is ignored.
You can have multiple files in the directory, as it will locate the one with the highest version number.
Step Three: Optionally, you can also put a message file in the directory, which will be displayed in a message box that presents the user with a YES/NO option of whether to update. The file must be named ate.txt and can contain up to 1024 characters, on one or more lines. For example:
A new version of your client connection software is available, and your dealer, ACME TECHNO, recommends that you update. The process will only take a minute, during which your client window will close and you will be prompted thru the installation program. At the end, you will be able to just launch the connection again. If you have a problem during the update, call us at 800-555-1212. Do you want to proceed?
If you do not supply your own ate.txt file, a generic message will be displayed asking the user if they want to update.
Step Four: When a new ATE session is launched, the server queries the ATE client to get its version, and then checks the atesetup directory to see if there is an update later than that version. If not, is just proceeds normally. If so, it prompts the user to update, and if the user agrees, it proceeds to FTP the setup file from the server to the client (ATECACHEDIR), close down the client, and launch the setup program.
There are probably a number of refinements that will be needed or desired in this process, so dealers are encouraged to start experimenting with it. A simple way to experiment is to first install the 4.9.949 ATE update, then copy that setup module (or any later one) to the atesetup directory. Even though the version of the server may be the same as on the client, you can fool it by just naming the file accordingly (i.e. call it ate-4.9.949.1.exe even though it is really 4.9.949.0).
Troubleshooting
The three most likely things that can go wrong are:
| • | a problem with the FTP transfer (bad login, firewall, etc.) |
| • | the ATECACHEDIR is invalid (see the Misc tab on the connection properties) |
| • | there are other instances of ATE or ASHW32 running on the client, preventing the installation from completing. |
We want to implement hooks or standard dialogs or other strategies for helping the users deal with these issues. But in any case, a failed update should be no worse than no update, and thus the user is unlikely to be left worse off than before.
History
2011 August, A-Shell 5.1.1227: When an ATE workstation connects to a server, the server scans the %MIAME%/atesetup directory looking for ATE install packages newer than the ATE version running on the client. Now, in addition to looking for monolithic install packages named "ate-#.#.#.#*.exe," it also looks for:
ate-#.#.#.#*-web.exe
ate-#.#.#.#*-web.txt
The -web.exe files are assumed to be small, web-based, granular update packages, which compare your current version to the one associated with the update package, pulling down from the Internet just the modules that need updating. This style of update package is dramatically faster to transfer from the host to the client and start executing, due to a size different of about 200KB versus 18MB, and often faster to complete since often only a few modules require updating. However, they do require that the client have Internet access.
The -web.txt files are tiny text files containing just the URL of the -web.exe module on the Internet. This version eliminates any need for a file transfer from the application server to the client prior to starting the update, as it merely commands the client to download the granular web installation package directly from the web. This approach is particularly attractive in conjunction with a Windows application server and 5.0 clients, where large file transfers from the Windows server to the client didn't always work very well.
In heterogeneous environments, you may want to use more than one type of update package. The original, monolithic (single-file) update modules are best with UNIX servers and LANs, particularly if the connection from the application server to the workstation has better throughput than the connection from the workstation to the Internet. But in WAN environments, and also with Windows servers, where the server-to-client file transfer may be slow or problematic, the -web.txt or -web.exe version may be best. An advantage of the -web.exe version is that the update procedure can be launched directly from the server after it transfers the file; with the -web.txt version, the installer gets downloaded from the Internet via the user's browser, which may require that the user click a button to save the file and then manually launch it when the download completes.
If there is more than one kind of update available, A-Shell will select the newest -web.exe or -web.txt version, unless it is able to determine that the client does not have internet access. Prior to ATE 5.1.1139, the server could not tell, so it assumes that the client does have Internet access. The -web.exe and -web.txt updates are given equal weighting; whichever one has the latest version will be used.
