The GRIA Workflow Plugins comprise of a number of Processors for use in Taverna. Discovery is performed to determine the GRIA applications and workflows that are hosted by a particular GRIA server. After performing discovery, appropriate Processors are made available for use in workflows. After adding a processor to a workflow, some configuration may be appropriate, though often the default processor configuration will be suitable.
The sections below describe GRIA application and workflow discovery, the Processors provided by this software and their configuration. Finally, details are provided of log files that should be sent in support queries and bug reports, if you encounter problems with the software.
The GRIA applications and workflows hosted by a GRIA server are discovered as follows. In the Available services panel tree, right-click on the root node, named Available Processors. In the context menu that's displayed, select Add applications from a GRIA 5.* service provider. This can be seen in Figure 1.
You'll be asked to enter the Address (URL) of the GRIA service. Enter this appropriately. Usually this will involve simply replacing the HOST:PORT placeholder in the text field with the name of the server. You may also need to change the URL prefix from https to http if the services aren't secured by SSL. The URLs from GRIA service providers are stored in a configuration file, therefore users are not required to fill in the HOST:PORT information again; they can just select previously included service providers. The configuration file can also be edited manually. It can be found in
TAVERNA_HOME/conf/recent.gria.service.provider
After discovery is complete, Processors will be made available in the
Available services panel tree. After discovering GRIA applications, there will be processors
available for performing data transfer operations and a processor for each application hosted by
the server.
After adding a processor to a workflow, Processor configuration is achieved by right-clicking on the processor in the Advanced model explorer panel and selecting the appropriate configuration option in the context menu. Note that you have to right-click directly on the label for the processor in the Advanced model explorer panel, otherwise the context menu may not be presented.
After the context menu has been displayed you can configure a job processor, for example, by selecting Configure GRIA job, as below.
Figure 2 Configuration of a job processor
Note that if
the service required for an Upload or Job processor is currently unavailable (offline),
you will be informed that an error occurred during configuration.
The upload processor is used to transfer a file from the client machine to a GRIA server. The uploaded file is said to be staged at the GRIA server.
Configuration options for the Upload processor include specifying a data stager (to upload the data to) as well as supplying appropriate billing and lifecycle information.
An Upload processor always has an input port named either localFile or stringData. The Use string or file panel should be used to configure which of these is used. If the use file radio button is selected, the localFile input port will be exposed. This should be passed a relative or absolute file name corresponding to the file to upload. If using relative paths, note that paths are relative to the TAVERNA_HOME directory. In contrast, if the use string radio button is selected, the stringData input port will be exposed. This should be provided with the actual data that you wish to upload (instead of just the filename).
Figure 3 Upload processor configuration
There are two main options regarding the data stager to use for upload. An existing data stager can be used, or a new data stager can be created.
Select the Use existing radio button if you want to upload data to an existing data stager. When this is selected, there are two further options that concern how the data stager is determined. The ID radio button should be selected if you wish to specify the data stager statically, at the time that the workflow is authored. In this case, the associated '...' button should be used to discover and select an existing data stager, as seen below.
Alternatively, the data stager can be determined dynamically at runtime by exposing an input port. If this is selected, a new input port called existingDataStager will be exposed on the processor. This should be passed the ID of the data stager at runtime.
The second option for data stager use is
Create new. Select this radio button, if you want the uploaded file to be stored in a new
data stager, created at the GRIA server. When this option is selected, the options for
Billing,
Life cycle and
Authorisations become relevant. This is because in
GRIA, whenever a data stager (or job) is allocated and the service is not free, it is done so
within the context of a SLA.
For more information see the section for
Billing, Life cycle and Authorisations below.
Note that when you select to use an Input port for an existing data stager or an SLA, a new input port is exposed on the processor. After this, it isn't possible to rename the input port. If you wish to rename the port, simply remove the port temporarily by selecting an alternative option and clicking on the OK button. Next reconfigure the processor and add the port again, with the new name.
The number and names of input ports and output ports for job processors varies depending on the application that the processor represents. Different applications require different numbers and types of input files and produce different numbers of output files, and for a particular job processor this is reflected in the ports that are present. In addition, a command line port and SLA port can optionally be exposed. Details of optional port configuration are provided below.
Configuration involves specifying a command line for the application, and specifying how a SLA should be selected. The latter aspects are discussed below in the section for Billing, Life cycle and Authorisations.
The Static radio button should be selected if the command line for the application is known before workflow runtime. In this case, simply provide the command line string in the associated text box. Note that the command line string should not include the name of the executable application itself, just the options, switches and arguments that should be passed to the application.
If the command line for the application is to be determined during workflow execution, select the Input port radio button. This will expose on the job processor an input port on which to read the command line. The name for the new input port must be provided in the associated text box. After this, it isn't possible to rename the input port. If you wish to rename the port, simply remove the port temporarily by selecting an alternative option and clicking on the OK button. Next reconfigure the processor and add the port again, with the new name.
The processor has an input port dataStager which
should be passed the ID of the source data stager.
There are two options
for storing the contents of the downloaded data.
Firstly, an input port localFile can be used. This should be passed the relative or
absolute file name at which to store the downloaded data. If you are using relative paths, note
that they should be relative to the TAVERNA_HOME directory.
Alternatively, an output port stringData can be used. In this case the downloaded data will
not be stored on the file system. Instead, the data will be passed to the output port for use later
in the workflow.
A configuration dialog is used to specify these options, as shown below. Select the Use file
radio button to expose the localFile input port. Alternatively, select the Use string
radio button if you with the downloaded data to be made available on the stringData output port.
The billing section allows configuration of how to obtain and present billing information to
remote services. GRIA 5 services may be free, or alternatively may require that a valid SLA is presented
when creating new Jobs and Data Stagers. Note that the system determines if a service is free automatically
by querying the remote service. If it is free, the other options will be disabled in the configuration dialog.
If a service is not free, the user is responsible for providing the
corresponding SLA information. This can be done in several ways. One possibility is to discover the
endpoint reference (EPR) of a SLA. This can be done statically before runtime of the workflow. A
dynamic solution is to provide the EPR of the SLA during execution by passing this information to
an assigned input port.
Finally the user can decide to use a predefined project account. For that, a client management
service has to be connected in order to discover available private accounts. Normally the user has
just to define the HOST:PORT of the client management account service.
Figure 7 Discover client management service
After connecting to a client management account, existing private accounts are displayed for selection.
The URLs of different client management services used so far are
stored in
TAVERNA_HOME/conf/recent.gria.client.mgt.service
This functionality is not used or available in the current release.
The authorisations section of the different dialogs is used to configure access control for data stagers. This is important when the workflow will be deployed to a Freefluo service. To enable a remote client of the Freefluo service to be able to read the output data stagers of the Upload processor, select the checkbox labelled Allow client to read outputs. Typically, a workflow author should be careful to allow Freefluo service clients to access only the data stagers they require.
Log files for plugins can be found in the file:
TAVERNA_HOME/plugins/logs/plugins.log
