Variables for the Launch Command

There are six variables that you can use with the Launch Command for remote desktop and/or remote application interfaces. Two of these variables are also available for use in the Download Launcher From field. The explanations below describe which configuration field you can use the variable in, which type of remote interface (desktop or application) you can use the variable with, what the Platform does when it encounters the variable, and what you need to know about using the variable, including syntax and examples.

Important! When you enter values for the Launch Command and Download Launcher From fields, you are responsible for ensuring that those values work, whether or not you use the variables. The Launch Command field must reference an executable that can be invoked by the Application Bridge applet (either with a fully-qualified path to the executable or by finding the executable on the system path). The Download Launcher From field must be a correct URL, and the specified application executable must be available at that URL.

If remote desktop is enabled on an asset (in the configuration of the Axeda Gateway or Axeda Connector Agent) and you do not enter anything for the Launch Command or Download Launcher From fields, the Platform operates as if you had entered <$AUTO> for these fields. If you do not enter anything on this page at all, remote desktop still works by obtaining the automatic launch and download parameters, but remote sessions will not launch or close automatically (because no one has selected those options). For remote application sessions to invoke Quick Launch, you must configure them in this page.

The following list shows each of the variables that you can use with the Launch Command and examples of using these variables. Click the name of a variable or of an example to display the details. Click again to hide the details:

How It Works

The Platform finds the host that the application or desktop viewer will need to connect to and substitutes that name for this variable. When the remote session is launched from the Asset dashboard of the Service application, the Application Bridge always resolves this variable to localhost because the Application Bridge connection to the remote asset takes place through the tunnel established by the applet running on the client machine.

Notes: As of the Summer '11, Upgrade 2, release, the Application Bridge supports a range of port numbers for Remote Application sessions that require a range of ports (for example, an application that uses dynamic ports). ALL of the ports in the range must be available for the application on the asset for the remote session to succeed. If any of the ports are in use by another application, the Application Bridge ends the session.

If you use the <$HOST> variable in the Model Remote Interface definition 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..

Usage

o Field: Launch Command only

o Interface Type: Application and Desktop.

How It Works

The Platform finds the first available listening port and substitutes that port number for the variable. The default port numbers for Axeda Desktop Viewer are 5920 for the Windows viewer and 5820 for the Java viewer. If a configured port has been remapped due to port conflicts on a computer, <$PORT> is expanded to the actual port in use.

Usage

o Field: Launch Command only

o Interface Type: Application and Desktop

To run the Axeda Deployment Utility as a Remote Application, configured for Port 3030 in the Agent project, you might type, "c:\Axeda\Deployment\Axeda_Deployment.exe <$HOST> <$PORT>" (leaving a space between the two variables for this application; whether or not you use a space or a colon depends on the application). Note that instead of entering the absolute path, you can use an environment variable.

To run Microsoft RDP, type the following: C:\WINDOWS\system32\mstsc.exe /v:<$HOST>:<$PORT>, making sure that you use the complete file name for the executable, including the extension ("exe" in this example). For this application, you need to use a colon between the <$HOST> and <$PORT> variables.

When the Remote Application session is launched, the Application Bridge expands <$HOST> to localhost (the destination) and, when the configured port is available, it expands <$PORT> to the configured port, 3030. You should use <$PORT> here because the configured port may be remapped due to port conflicts on a computer. In this situation, <$PORT> is expanded to the actual port in use.

If you also select to launch it automatically, the Application Bridge will launch the Deployment Utility for you.

How It Works

When you use this variable, the Platform performs full substitution, such that it uses the particulars of the Platform and the client and selects the appropriate viewer, host, and port. If Launch Automatically is checked, the Platform also launches the viewer. If the viewer is not present on the client computer or the version on the Platform is more recent, the system automatically downloads the viewer from the Platform and launches it. The Platform matches the version of the desktop server running on the asset to the version of the desktop viewer.

Usage

o Field: Launch Command and Download Launcher From

o Interface Type: Desktop only

This variable is the only one that can be used for remote desktop sessions only because only Desktop interfaces have the Platform infrastructure needed to translate this variable into something that can be launched.

How It Works

When you use this variable, the Platform checks the environment variables on the client operating system and substitutes the value found there for the specified variable. If a value is not found, an empty string is returned.

The resolution of <$ENV:env_var> does not affect any other text defined in the Launch Command. Thus, if an environment variable is not defined or otherwise is not found on the client system, the remainder of the Launch Command remains in effect.

For example, suppose the administrator sets up the Launch command as "<$ENV:proframfiles>\\Axeda\\Desktop\\Viewers\\aviewer.exe" (with "programfiles" misspelled as "proframfiles"). The environment variable as typed will not be found (typically) and would return an empty string. After substitution, the Launch Command is \\Axeda\\Desktop\\Viewers\\aviewer.exe. Assuming that the home drive on the client machine is c:\, after Java processes the double backslashes, the Launch Command resolves to c:\Axeda\Desktop\Viewers\aviewer.exe. Quick Launch would then check if the executable file exists in the directory. If not, Quick Launch would try to create the directory and download the appropriate viewer for the asset to that client directory.

Usage

o Field: Launch Command only

o Interface Type: Application and Desktop

"<$ENV:programfiles>" would return "C:\Program Files" on most Windows systems. The Launch command with this environment variable might look like this:

"<$ENV:programfiles>"\\Axeda\\Desktop\\Viewers <$HOST>:<$PORT>

Syntax Notes: You must use quotation marks to delimit launch command arguments that contain spaces (for example, a path referencing "C:\Program Files"). When using the variables, if a command argument might contain spaces after expansion (for example, after substituting "C:\Program Files" for "<$ENV:programfiles>"), use quotation marks to delimit the argument.

When typing the file name of the executable, be sure to use the complete file name, INCLUDING THE EXTENSION.

The use of the colon between the <$HOST> and <$PORT> variables depends on the application. Structure the arguments for the Launch Command as you would when entering it from the command line.

How It Works

Path substitution (Optional). When you use this variable, the Platform path on the client system to which it will download the executable file. The value for this variable is configured by your Platform administrator. These properties and their default values follow:

§ Windows client --

com.axeda.drm.desktop.downloadto.windows = <$ENV:programfiles>\\Axeda\\Desktop\\Viewers

§ UNIX/Linux client --

com.axeda.drm.desktop.downloadto.nix=
/opt/Axeda/Desktop/Viewers

If the path is empty or missing or if the path specified in the property value does not exist on the client system, then the viewer executable is saved to the home directory of the browser used to access the Axeda Applications. For example, if you are working on a Windows XP computer and using Firefox 2.0, the executable is saved to c:\Program Files\Mozilla Firefox\plugins. For Internet Explorer, the executable would be saved to c:\Program Files\Internet Explorer.

Usage

o Field: Launch Command only

o Interface Type: Application and Desktop

Syntax Notes: You must use quotation marks to delimit launch command arguments that contain spaces.

For a Linux machine, you could use the HOME and PATH environment variables, as follows:

"<$ENV:JAVA_HOME>/bin/java" -cp "<$DOWNLOAD_TO>/AxedaDesktopViewer_v5226.jar" AxedaDesktopViewer HOST <$HOST> PORT <$PORT>

Note the use of quotation marks to delimit arguments that may contain spaces when variables are expanded.

How It Works

This variable returns the scheme, host, and port of the Platform (not the Axeda Global Access Server, if the connection is through GAS). For example: it returns http://ServiceLink_Server.axeda.com:7001.

Usage

o Field: Launch Command and Download Launcher From

o Interface Type: Application and Desktop

It is not sufficient to define the Download Launcher field as <$ENTERPRISE_HOST> alone, because the path to the file to be downloaded is not complete. Instead, use the <$ENTERPRISE_HOST> variable in conjunction with the rest of the path to the file. For example, here is a Download Launcher From entry for a third-party viewer:

<$ENTERPRISE_HOST>/drm/downloads/viewers/My_Viewer.exe

Note that the file name includes the extension ("exe").

Here is an example for a remote application (instead of a viewer application):

<$ENTERPRISE_HOST>/drm/downloads/putty.exe

Note that the file name includes the extension ("exe").

Here is an example using the Axeda Desktop Viewer, version 5.2, build 26:

<$ENTERPRISE_HOST>/drm/downloads/viewers/AxedaDesktopViewer_v5226.exe

This second example assumes that all assets of the same model are running Axeda Desktop Server, version 5.2, build 26. If your assets are running different versions of Desktop Server or even if some assets are running Axeda Access Remote and others are running Axeda Desktop Server, it may be better to use <$AUTO> so that the Platform can determine which viewer application is appropriate for the asset. The <$AUTO> variable can only be used for the Desktop type of remote interface in this field; you cannot use it for a remote Application interface. When you use <$AUTO>, the Platform downloads the viewer to the directories configured by your Platform administrator.

Click the following title to display a complete example of a Quick Launch definition; click again to hide it:

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.

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)

Variables for Quick Launch Configuration

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

Pre-requisites

Minimum configuration parameters: