Environment
Aspects of the environment within which the external application will be run are configured under the Environment tab.
Environmental variables
Environment variables that should be present for the external application when it executes can be created here, and default values set. In the example shown in figure 15.15, an environment variable named "HELLO" with value "hello world" would be present in the execution environment of the external application.
Figure 15.15: Under the Environment tab, settings related to the environment an external application will be run on are configured.
Working directory
The Working directory setting specifies where temporary files should be created. This setting is only relevant to standard (non-containerized) external applications. For containerized external applications, the working directory is defined in the containerized execution environment, as described in Configuring the containerized execution environment.
- Default temp-dir
- Temporary files will be placed under the directory specified by the
java.io.tmpdirsetting for the system. - Shared temp-dir
- Temporary files will be placed under the directory you specify. The files will be accessible to all execution nodes and the master server without needing to be moved between machines.
To be available for use as a shared temp-dir, a directory must be:
- Already configured as an Import/export directory(see Import/export directories).
- A shared directory, accessible by all machines where the external application will be executed.
Grid environments: For an external application to be executable on grid nodes, the Shared temp-dir option must be chosen for the working directory.
Job node setups: For an external applications to run on job nodes, either Working directory option is fine. However, if the directory specified by java.io.tmpdir is not an area shared between machines, and it usually is not, choosing Default temp-dir means that files will need to be moved between the master and job nodes.
Execute as master process
When the Execute as master process option is enabled, the command line application will be executed on the master machine of a job node or grid setup. Export, import and post-processing steps are still run on the execution environment selected by the user when launching the external application. This setting has no effect for single server setups, where all execution happens on the same system.
With this option unselected, all stages of the external application are run on the execution environment selected when launching the external application. This is the default situation.
Execute as master process is not recommended for use with memory or cpu intensive tasks as the command line application will be launched on the master system without consideration of how busy that system is, or what processing capabilities it has.
For grid setups: Whether or not the Execute as master process option is enabled, export, import and post-processing steps will be run on a grid node if a grid execution environment is selected when launching an external application. This is why the Working directory option must be set to Shared temp-dir when running an external application on a grid setup.
Add parameter history to imported objects
When checked, information is added to the history of CLC data elements created as a result of an external application.
The history information added includes parameter values supplied for the native command by the external application author, as well as values supplied by a user when launching the external application. For relevant elements, it includes the final, substituted command line. The history entries for the simple "Copy sequences" example described earlier in this chapter are shown in figure 15.17. The 3 genera steps of an external application, export from the CLC Server, running the command line, and importing result into the CLC Server, each have their own history entry.
Figure 15.16: Settings related to the environment an external application will be run on are configured under the Environment tab.
Figure 15.17: An example of the history information provided for a CLC data element generated by an external application in the web client (top) and in a CLC Workbench (bottom). In both cases, the history entry relating to running the native command is open.