Screenshots Details of Workflow Commander, visually

Walkthrough - Server

The following images show you how to start the server process on the server machine

Starting the server

(Slide 1/3) The server process is started by running the Java JAR file for the appropriate OS (in this case, Linux) and giving the -S command-line option

Starting the server

(Slide 2/3) Once the server process has completely started up, it will return a message that includes the port it is listening to. The current default is 8080.The user running the server process must have privileges to bind ports. If the connecting client user and server process user are different, it is assumed that the server process user has sudo privileges to run commands as the client user.

Starting the server

(Slide 3/3) The -p command-line option can be used to specify an alternate port for the server process to listen to.

Walkthrough - Client

The following images show you how to start the client process on your desktop

Starting the client

(Slide 1/15) The client is started by running the JAR with no arguments

Starting the client

(Slide 2/15) When the window appears, the window is dividied into 2 sections. The left section has an "Execution Properties" area for entering SSH information and a "Buttons" section for operating on the workflow. The right section shows a graph of the currently-opened workflow.

Configuring SSH information

(Slide 3/15) Messages may appear in the original terminal window indicating that the SSH information (username, server name, etc.) is incorrect somehow. Ensure that the SSH username and server name are correct, that the server process is running on the server, that the user can silently log into the server using public key authentication. Once fixed, the SSH warning message ceases.

Configuring SSH information

(Slide 4/15) Here, the server address has been updated appropriately.

Loading a workflow

(Slide 5/15) Use the "Load workflow" or the File > Open file menu to load a workflow from file.

Loading a workflow

(Slide 6/15) When the workflow loads, its graph is drawn to the right

Running a workflow

(Slide 7/15) Clicking the "Run WF instance" button runs a workflow on the server. After doing so, the workflow will receive the job id's assigned to each job by the server's grid engine. If the user does not specify std. out and std. err files for a job, the server process will create these files. The tooltip for each job (appears after hovering the mouse over the job's ellipse) shows a small subset of information for that job.

Monitoring a workflow's status

(Slide 8/15) The workflow will continue to run on the server independently of the client. The client will update itself in real-time with the status of the workflow's jobs. Colors will indicate success, running, waiting, and error run statuses per job.

Monitoring a workflow's status

(Slide 9/15) The workflow's jobs will be executed by the grid engine, but it will keep dependent jobs waiting until the previous jobs finish. Arrows indicate dependencies.

Job array support

(Slide 10/15) This workflow is equivalent to the previously-shown workflow. Job arrays are used here, as supported by the grid engine.

Job array support

(Slide 11/15) As the tasks of a job array are executed independently, the execution statuses are collected and displayed.

Job array support

(Slide 12/15) The jobs of the workflow can still be accessed in the grid engine the traditional way -- at the command-line, logged into the server. This command (qstat) shows the state of all waiting, running, and failed jobs. Another command (qacct) is required to show the status of done jobs (success, error) on a one-job-at-a-time basis, while killed jobs are not reported in either command.

Job array support

(Slide 13/15) The workflow editor shows the successful completion of one of the tasks of the job array, even though it was not shown in the qstat output in the previous screenshot.

Saving and resuming

(Slide 14/15) You can save a workflow, including any new information (job id, execution status, etc.), to file. Since the workflow runs on the server, the client can be closed and re-opened without any effects. If a workflow with job id's is re-opened at a later point, the latest information known about the workflow's jobs is applied to the workflow graph.

Saving and resuming

(Slide 15/15) The workflows are saved as text files in an XML format, so the files can be viewed and modified in any text editor.