| Summary | Included libraries | Package variables | Synopsis | Description | General documentation | Methods |
use Bio::Tools::Run::Analysis; my $tool = new Bio::Tools::Run::Analysis (@args);
| BEGIN | Code | |
| analysis_name | Description | Code |
| analysis_spec | Description | Code |
| describe | Description | Code |
| input_spec | Description | Code |
| result_spec | Description | Code |
| create_job | Description | Code |
| run | Description | Code |
| wait_for | Description | Code |
| analysis_name | code | next | Top |
Usage : $tool->analysis_name; Returns : a name of this analysis Args : none |
| analysis_spec | code | prev | next | Top |
Usage : $tool->analysis_spec; Returns : a hash reference describing this analysis Args : noneThe returned hash reference uses the following keys (not all of them always present, perhaps others present as well): name, type, version, supplier, installation, description. Here is an example output: Analysis 'edit.seqret':
installation => EMBL-EBI
description => Reads and writes (returns) sequences
supplier => EMBOSS
version => 2.6.0
type => edit
name => seqret |
| describe | code | prev | next | Top |
Usage : $tool->analysis_spec; Returns : an XML detailed description of this analysis Args : noneThe returned XML string contains metadata describing this analysis service. It includes also metadata returned (and easier used) by method analysis_spec, input_spec and result_spec. The DTD used for returned metadata is based on the adopted standard (BSA specification for analysis engine): But the DTD may be extended by provider-specific metadata. For example, the EBI experimental SOAP-based service on top of EMBOSS uses DTD explained at http://www.ebi.ac.uk/~senger/applab. |
| input_spec | code | prev | next | Top |
Usage : $tool->input_spec; Returns : an array reference with hashes as elements Args : noneThe analysis input data are named, and can be also associated with a default value, with allowed values and with few other attributes. The names are important for feeding the service with the input data (the inputs are given to methods create_job, run, and/or wait_for as name/value pairs). Here is a (slightly shortened) example of an input specification: $input_spec = [
{
'mandatory' => 'false',
'type' => 'String',
'name' => 'sequence_usa'
},
{
'mandatory' => 'false',
'type' => 'String',
'name' => 'sequence_direct_data'
},
{
'mandatory' => 'false',
'allowed_values' => [
'gcg',
'gcg8',
...
'raw'
],
'type' => 'String',
'name' => 'sformat'
},
{
'mandatory' => 'false',
'type' => 'String',
'name' => 'sbegin'
},
{
'mandatory' => 'false',
'type' => 'String',
'name' => 'send'
},
{
'mandatory' => 'false',
'type' => 'String',
'name' => 'sprotein'
},
{
'mandatory' => 'false',
'type' => 'String',
'name' => 'snucleotide'
},
{
'mandatory' => 'false',
'type' => 'String',
'name' => 'sreverse'
},
{
'mandatory' => 'false',
'type' => 'String',
'name' => 'slower'
},
{
'mandatory' => 'false',
'type' => 'String',
'name' => 'supper'
},
{
'mandatory' => 'false',
'default' => 'false',
'type' => 'String',
'name' => 'firstonly'
},
{
'mandatory' => 'false',
'default' => 'fasta',
'allowed_values' => [
'gcg',
'gcg8',
'embl',
...
'raw'
],
'type' => 'String',
'name' => 'osformat'
}
]; |
| result_spec | code | prev | next | Top |
Usage : $tool->result_spec;
Returns : a hash reference with result names as keys
and result types as values
Args : none
The analysis results are named and can be retrieved using their namesby methods results and result. Here is an example of the result specification (again for the service edit.seqret): $result_spec = {
'outseq' => 'String',
'report' => 'String',
'detailed_status' => 'String'
}; |
| create_job | code | prev | next | Top |
Usage : $tool->create_job ( {'sequence'=>'tatat'} )
Returns : Bio::Tools::Run::Analysis::Job
Args : data and parameters for this execution
(in various formats)
Create an object representing a single execution of this analysistool. Call this method if you wish to "stage the scene" - to create a job with all input data but without actually running it. This method is called automatically from other methods (run and wait_for) so usually you do not need to call it directly. The input data and prameters for this execution can be specified in various ways: array reference The array has scalar elements of the formname = [[@]value]where name is the name of an input data or input parameter (see method input_spec for finding what names are recognized by this analysis) and value is a value for this data/parameter. If value is missing a 1 is assumed (which is convenient for the boolean options). If value starts with @ it is treated as a local filename, and its contents is used as the data/parameter value. hash reference The same as with the array reference but now there is no need to usean equal sign. The hash keys are input names and hash values their data. The values can again start with a @ sign indicating a local filename. scalar In this case, the parameter represents a job ID obtained in someprevious invocation - such job already exists on the server side, and we are just re-creating it here using the same job ID. TBD: here we should allow the same by using a reference to the Bio::Tools::Run::Analysis::Job object. undef Finally, if the parameter is undefined, ask server to create an emptyjob. The input data may be added later using set_data... method(s) - see scripts/papplmaker.PLS for details. |
| run | code | prev | next | Top |
Usage : $tool->run ( ['sequence=@my.seq', 'osformat=embl'] )
Returns : Bio::Tools::Run::Analysis::Job,
representing started job (an execution)
Args : the same as for create_job
Create a job and start it, but do not wait for its completion. |
| wait_for | code | prev | next | Top |
Usage : $tool->wait_for ( { 'sequence' => '@my,file' } )
Returns : Bio::Tools::Run::Analysis::Job,
representing finished job
Args : the same as for create_job
Create a job, start it and wait for its completion.Note that this is a blocking method. It returns only after the executed job finishes, either normally or by an error. Usually, after this call, you ask for results of the finished job: $analysis->wait_for (...)->results; |
| BEGIN | Top |
$Revision = q[AnalysisI.pm,v 1.7.2.1 2005/10/09 15:16:18 jason Exp];}
| analysis_name | description | prev | next | Top |
shift->throw_not_implemented();}
| analysis_spec | description | prev | next | Top |
shift->throw_not_implemented();}
| describe | description | prev | next | Top |
shift->throw_not_implemented();}
| input_spec | description | prev | next | Top |
shift->throw_not_implemented();}
| result_spec | description | prev | next | Top |
shift->throw_not_implemented();}
| create_job | description | prev | next | Top |
shift->throw_not_implemented();}
| run | description | prev | next | Top |
shift->throw_not_implemented();}
| wait_for | description | prev | next | Top |
shift->throw_not_implemented();}
| FEEDBACK | Top |
| Mailing Lists | Top |
bioperl-l@bioperl.org - General discussion http://bioperl.org/MailList.shtml - About the mailing lists
| Reporting Bugs | Top |
http://bugzilla.bioperl.org/
| AUTHOR | Top |
| COPYRIGHT | Top |
| DISCLAIMER | Top |
| SEE ALSO | Top |
| APPENDIX | Top |