Process Action

The process action is among the most heavily used actions in Flux. Its purpose is simple but necessary in most work flows - execute an external program. However, the configuration options make it a potent addition to the Flux library. This guide will delve into those options and discuss proper implementation of the process action.

The basic configuration

The only piece of information required for running a process action is the command the user wishes to invoke. In the designer, this is specified in the "command" field in the action properties for a process action. In code, you can specify the command using the "setCommand" method. The command must be able to be executed at the command line, so you may need to include the absolute path to the program you are attempting to run. If the command falls within the path variable specified by your system, you can provide the name of the program (such as "notepad" in Windows systems).

Additional configuration options

There are a plethora of additional options to configure a process action with to optimize its use. These include:

Asynchronous - This specifies whether or not Flux should wait for the process to complete before continuing on the flow. If it is set to true, Flux will launch the process and immediately continue without waiting for it to complete. The opposite is true if the asynchronous property set to false. It is important to note that you will not be able to manipulate the flow based on the exit code of the process if this is set to true.

Command Arguments - This option consists of a List of Strings that denote the proper arguments given at the command. For example, if you were running the "rm" command in UNIX/LINUX (?del? in Windows), you will want to specify the file or directory to delete, and possibly additional options such as "-r" to recursively delete through the directory.

Destroy on Interrupt - Occasionally you will want to interrupt a process if its outcome will be unfavorable or problematic. By default, a process started by a process action will continue to run even if a flowchart is interrupted. Setting the "destroy on interrupt" property to true will permit Flux to terminate these processes when interrupted.

Destroy on Signal - If you want to have Flux destroy a running process when a monitored signal is raised, set this to true. For more information on signals, see the Flux end-user's manual, software developer's manual, and the bundled examples in your Flux install.

Destroy on Timeout - This option concerns whether or not to terminate a process if it takes too long to being executed. By default it is set to false.

Stderr File - Specifies the file that stderr writes to. If you do not want the file to be created in the same directory as your engine is running in, you will want to specify the full path.

Stdout File - Specifies the file stdout writes to. Similar to the syntax "command > file"

Stdin file - Specifies the file stdin reads from. Similar to the syntax "command < file"

Work Directory - The working directory is the directory from where the command is attempted to be run from. This is not the folder from which process actions are invoked, but rather the working directory given when the process is running. By default, this is the base of your Flux install (c:/flux-x-y-z/ in Windows)

Agent Pool - It is possible to delegate the process in question to Flux agents that belong to the same agent pool. This is useful when you want to conserve system resources and/or run a resource heavy process on a quicker computer.

Command Properties - Command properties are a properties set of keys and values that can be referenced from the command line

Command Environment - The command environment sets properties that are propagated to the JVM when the process is run

All of these properties can receive input by using runtime data mapping. Refer to the end users manual for more information.

Proper usage

The process action is commonly overused. For example if you just need to copy files, there is no need to set up a process action for the cp/copy command. Flux has built in file actions that will get most jobs germane to file manipulation done efficiently and with more control than just using the command line. Process actions should be delegated to only tackle commands that are a) unique and unable to be replicated by any of Flux's built in actions or triggers and b) the task is not easy to implement as a Java action, dynamic Java action, or custom action.

A Practical Example

Consider the following scenario in which a process action is a major asset to a work flow.

A video hosting website accepts videos from its user base in a variety of different formats. Videos are uploaded from the website to an FTP server that serves as a temporary archive for all content. Before distribution, all videos are to be copied to a local machine, encoded and resampled to a web-friendlier format, and finally copied over to a permanent archive server that stores all user content for easy access. This work flow is required to be executed every 30 minutes.

Flux is well equipped to handle this progression easily. Breaking this work flow down into its components, it is easy to see where a process action will be used.

• A timer trigger is needed for the 30 minute scheduling component.
• Two file copy actions or file move actions are needed to receive the files and then move them to the next machine
• A file exists trigger and for each element action should be used to cycle through the copied files
• 1 to many process actions are needed for manipulating the files in question

To fit the scope of this article, only the process action(s) will be discussed. Assume there is fictional encoding software, fluxenc, which is located in "c:/Fluxenc" and has syntax close to the following at the command line:

fluxenc (input file) (video bitrate) (audio bitrate) (output file)

With this knowledge it is possible to completely set all of the necessary options for our process action. The command would be set to "fluxenc". The file is required to completely finish encoding before copying, so asynchronous would be set to false. Using either runtime data mapping or variable substitution, the command arguments would be similar to "{RESULT.filename} 800 124 {RESULT.filename}_converted.flv". The "fluxenc" executable is in the folder "c:/Fluxenc", so the working directory is set to this. Of course additional options could be set, but for this example, these options are the only essential ones.