Skip to end of metadata
Go to start of metadata

External tool service

The external tool service (also called the UseCase service) was developed by Hajo Krabbenhöft and Steffen Möller as part of the KnowArc project

The service is described in the paper:

H. Krabbenhöft, S. Möller, D. Bayer (2008) Integrating ARC Grid Middleware with Taverna Workflows.  Bioinformatics,

What is an external tool service?

An external tool can be called on the local machine, on any machine to which Taverna can obtain an ssh connection via the credential manager or on a grid node. The external tool service allows workflows to include calls to such tools as part of their workflow.

It is envisaged that the tools within operating systems and packages, such as those of Debian Linux, can be described within external tool description repositories. Workflows can then be created that will call external tools running (either locally or remotely) within those environments. The Linux distributions, and Debian in particular, are open for contributions to help achieve this aim.

Workflow developers can specify their own external tool descriptions.

The external tools are currently described in a format such as:

This states that the external tool service in Taverna will have an input port called shell_script and that the value sent to that port will be written to the file input when the command /bin/sh input is run.

The service automatically has output ports corresponding to stdout and stderr

Specifying where the external tool will run

You can define runtime constraints which specify the tool will run correctly. For example:

specifies that the command can be run in an environment where the version of boxshade is greater than 3.3.1-4 and the version of tcoffee is exactly 2.5.

The runtime constraints are only enforced on nodes in an ARC grid.

Suggestions for a generic specification of runtime constraints and of runtime environments are very welcome.

Input ports

Some common uses for an external tool service input port are:

Replace part of the command

For example:

This states that the service will have an input port called input_value and that the value passed into the service will be used in the command. For example, if "fred" is passed in, then "somecommand fred" will be called.

To populate a file used by the command

For example:

This states that the service will have an input port called input_value and that the value passed into the service will be written to the file used_file. When somecommand is run, it probably reads that file.

To populate a file used as a parameter by the command

For example:

This states that the service will have an input port called input_value. The value passed into the service will be written to a temporary file and then the path to that temporary file will replace %%some_file%% when somecommand is run.

Taking lists as inputs

Lists of values can also be used as inputs. For example,

This concatenates the list of values sent to the port input_list and saves them to the temporary file.

Output ports

Values from a file

You can specify that an output port of an external tool service will get the values from a file.  For example:

This indicates that when the service is run, the command writes to a file called some_file. Taverna then takes the content of that file and returns it on the output port output_value.

Static values

You can also specify static values that will be used for all calls of a command.

Static value from a URL

The normal purpose of these is to download data from a url. For example:

This downloads the contents of the URL and puts them into a file called some_file. The downloaded file can be used as part of the command, for example:

Alternatively, a static can be used to replace part of the command.

This downloads the contents of the URL and uses it for some_param in the command.

Explicit static value

A static value can also be stated explicitly as part of the description. For example:

The file some_file is populated with "some static content ...".

Telling Taverna about the services

The service descriptions need to be saved within a containing service descriptions file.  This looks like:

This file should be saved somewhere from which it can be accessed by Taverna i.e. on a website or in local filestore.

Within Taverna, install the UseCase plugin and then click on Import new services and select Usecase service... Enter the URL of the descriptions file and, if the file is accessible and OK, then you should see the UseCase services appear in the service panel.

By default, the UseCase plugin includes the services described at

Sharing external tool descriptions

It has not yet been decided how to publish, access and share user-defined external tool descriptions to description repositories such as that at . Suggestions for mechanisms are very welcome. If you have ideas then please send them to the Taverna hackers e-mail list.

  • None