Quick Launch

Example of a Quick Launch Definition for a Remote Application (PuTTY)

Pre-requisites

• Copy the application executable to the /drm/downloads directory on the Axeda Platform.

• The application has been configured (using Axeda® Builder) as a Remote Application in the project that the Axeda Agents are running on the assets of this model.

• If you want to take advantage of the ability of the Application Bridge feature that allows it to increment to the next available IP address/port (available as of the Summer '11, Upgrade 2, release), make sure that you have cleared the Java Plug-in cache. For details, refer to the topic, Clearing_the Java_Plug-in_Cache.

Minimum configuration parameters:

• Launch Command: putty.exe -ssh -P <$PORT> localhost

• Download Launcher From: <$ENTERPRISE_HOST>/drm/downloads/putty.exe

• Launch Automatically: Yes (select the check box)

For purposes of this discussion, the terms "client machine" and "your computer" refer to the computer from which the remote session was requested. After you click the Desktop link in the Remote Sessions module, Quick Launch operates as follows:

1.       Quick Launch checks the viewer application currently configured for the model of this asset (the Launch Command shown in the Model Remote Interfaces page in the Configuration application). If the Launch Command contains the information for a third-party viewer application, Quick Launch passes that command (with its path) to the Application Bridge applet. If the Launch Command includes a <$DOWNLOAD_TO> variable, the Platform retrieves the values for the Desktop "downloadto" properties. It substitutes these values for the variable in the Launch Command, passing both the Windows and UNIX paths to the Application Bridge applet, so that either path is available, depending on the operating system of the client machine.

2.       If the Launch Command field is empty or contains the <$AUTO> variable, Quick Launch determines which desktop server is running on the asset and passes both the Windows and UNIX commands for the viewer that is appropriate for the Platform to the Application Bridge applet. For example, if the desktop server running on the asset is Axeda Desktop Server, then Quick Launch passes the Windows and UNIX commands for Axeda Desktop Viewer to the Application Bridge.

3.       On startup, the Application Bridge applet receives the Launch Command. If the Launch Command is blank or contains the <$AUTO> or <$DOWNLOAD_TO> variables, the Application Bridge uses the Windows or UNIX version of the viewer, based on the operating system of the client machine.

4.       The Application Bridge expands the Launch Command to resolve any variables used. First, it separates the executable from any other arguments. Next, it checks the command for a quotation mark at the beginning, and if found, looks for the end quotation mark and uses the content between the quotation marks as the executable. If the command does not start with a quotation mark, it looks for the first space and uses the content from the beginning to the first space as the executable. If the command has no spaces, the entire string is treated as the executable. Anything remaining after the executable is extracted and treated as arguments.

5.       The Application Bridge parses the executable, resolving any environment variables by calling the platform specific method for retrieving environment variables.

6.       The Application Bridge tries to find the executable on the client machine. First, it checks whether the file exists as originally specified. If not, and if a fully-qualified path is not provided, it checks if the file exists in the system path. If not, and no download-from data exists (it has not been configured in the Model Remote Interfaces page), then the Application Bridge window displays an error message. If download-from data exists and the Launch Command specifies a fully-qualified path, the Application Bridge checks to see if the directory structure as specified exists. If not, the Application Bridge tries to create that structure. If the directory exists or it is successfully created, the Application Bridge downloads the specified file to the specified location. If the directory creation or download fail, the Application Bridge looks in the browser current directory (in Firefox on Windows, %programfiles%Mozilla Firefox and in Internet Explorer on Windows, the user's desktop). If the executable does not exist there, the Platform Downloads the file to that location. If the download fails, the Application Bridge window displays an error message.

7.       If the executable is found successfully in Step 6, the Application Bridge parses the arguments, in the following order:

a.       <$PORT> variables - replaces with the first available listening port (if a configured port is not available due to port conflicts, this variable is expanded to the actual port in use).

b.       <$HOST> variables - replaces with "localhost."

c.       Java classpath (-cp or -classpath) - parses the classpath and checks whether each file in the classpath exists as specified (following the sequence of checks in Step 6).

After parsing the classpath, the Application Bridge checks for quotation marks, using them to delimit arguments, and using spaces if no quotation marks are found.

Note:  If you use the <$HOST> variable and want to use a range of ports for a Remote Application type of session, make sure that you have cleared the Java Plug-in cache. Refer to the topic, Clearing the Java_Plug-in_Cache.

8.       The Application Bridge combines the executable and arguments to launch the remote session process. If the Application Bridge did not find the executable in Step 6, then the Launch Application button in the Application Bridge window remains unavailable.