4.
Reference
Up one level
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.
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.
Billing, 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.
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
