This section describes GRIA application and workflow discovery, the Processors provided in this release and how they are configured. Finally, locations of log files of log files are provided. These should be sent in support queries and bug reports, if you problems are encountered with the software.
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. Each of these tasks are considered below.
Discovery
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 is displayed, select
Add applications from a GRIA 5.* service provider. This can be seen in the figure below.
Application discovery
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.
Processor configuration
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.
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.
Upload processor
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.
Use string or file
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).
Upload processor configuration
Data stager
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.
Selection of available data stagers
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, Lifecycle 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.
Job processor
Job processors are used to execute a specific application at a GRIA
server. Job processors can be linked together in a workflow by passing references to data stagers
(data stager IDs) between them.
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, Lifecycle and Authorisations.
Job processor configuration
Command line
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.
Job description
The
Description text area can be used to specify user
constraints on job execution. This is optional and the text area can be left empty if job
constraints are not required. GRIA 5 supports a number of user-provided job contraints that can be
used to help manage job execution. The constraints should be specified using an XML document
that complies with the GRIA job constraints XML document schema. Further details of job
constraints and an example job constraints XML file can be found in the Job Service section of the GRIA user guides.
Download processor
The download processor is the most simple of the
available processor types. It is used to download to the client machine a file that has been staged at a
GRIA server.
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 wish the downloaded data to be made available on the stringData output port.
Download processor configurationBilling, lifecyle and authorisations
Billing
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.
Discover client management service
After connecting to a client management account, existing private
accounts are displayed for selection.
Selecting an account
The URLs of different client management services used so far are
stored in
TAVERNA_HOME/conf/recent.gria.client.mgt.service
Lifecycle
The life cycle section applies to data stagers and jobs that are created
during workflow execution. It allows the user to
specify if these remote resources should outlive the execution of the workflow, or if instead they should be
finished i.e destroyed at the end of
workflow execution.
Authorisation
This functionality is not used or available in the current release.
Log files
Log files for plugins can be found in the file:
TAVERNA_HOME/plugins/logs/plugins.log
