Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Bio::Tools::Run::AnalyUser3Contributed Perl DocumeBio::Tools::Run::Analysis(3)

       Bio::Tools::Run::Analysis - Module representing any (remote or local)
       analysis	tool

	 # run analysis	'seqret' using a default location and a	default
	 # access method (which	means using a Web Service at EBI)
	 use Bio::Tools::Run::Analysis;
	 print new Bio::Tools::Run::Analysis (-name => 'edit::seqret')
	      ->wait_for ({ sequence_direct_data => 'tatatacgtatacga',
			    osformat =>	'embl'
	      ->result ('outseq');

	 # run a longer	job without waiting for	its completion
	 use Bio::Tools::Run::Analysis;
	 my $job = Bio::Tools::Run::Analysis->new(-name	=> 'edit::seqret')
			->run ({ sequence_direct_data => 'tatatacgtatacga',
				 osformat => 'embl'
	 # ...and after	a while
	 $job->result ('outseq');

	 # get all results in the same invocation (as a	hash reference
	 # with	result names as	keys) -	let the	module decide which
	 # results are binary (images in this examples)	and save those
	 # in file (or files); it also shows how to tell that the module
	 # should read input data from a local file first
	 use Bio::Tools::Run::Analysis;
	 my $results =
	   Bio::Tools::Run::Analysis->new(-name	=> 'alignment_multiple::prettyplot')
	      ->wait_for ( { msf_direct_data =>	'@/home/testdata/my.seq' } )
	      ->results	('?');
	 use Data::Dumper;
	 print Dumper ($results);

	 # get names, types of all inputs and results,
	 # get short and detailed (in XML) service description
	 use Bio::Tools::Run::Analysis;
	 my $service = Bio::Tools::Run::Analysis->new(-name => 'edit::seqret');
	 my $hash1 = $service->input_spec;
	 my $hash2 = $service->result_spec;
	 my $hash3 = $service->analysis_spec;
	 my $xml = $service->describe;

	 # get current job status
	 use Bio::Tools::Run::Analysis;
	 print new Bio::Tools::Run::Analysis (-name => 'edit::seqret')
	   ->run ( { #...input data...
		   } )

	 # run a job and print its job ID, keep	the job	un-destroyed
	 use Bio::Tools::Run::Analysis;
	 my $job =
	   Bio::Tools::Run::Analysis->new(-name	=> 'edit::seqret',
					  -destroy_on_exit => 0)
	   ->run ( { sequence_direct_data => '@/home/testdata/mzef.seq'	} );
	 print $job->id	. "\n";
	 # prints	(for example):
	 #    edit::seqret/c8ef56:ef535489ac:-7ff4

	 # another time, on another planet, you may say
	 use Bio::Tools::Run::Analysis;
	 my $job =
	   Bio::Tools::Run::Analysis::Job->new(-name =>	'edit::seqret',
					       -id => 'edit::seqret/c8ef56:ef535489ac:-7ff4');
	 print join ("\n",
		   'Finished: '	. $job->ended (1),   # (1) means 'formatted'
		   'Elapsed time: ' . $job->elapsed,
		   $job->result	('outseq')

	 # ...or you may achieve the same keeping module
	 # Bio::Tools::Run::Analysis::Job invisible
	 use Bio::Tools::Run::Analysis;
	 my $job =
	   Bio::Tools::Run::Analysis->new(-name	=> 'edit::seqret')
	       ->create_job ('edit::seqret/c8ef56:ef535489ac:-7ff4');
	 print join ("\n",
		   # ...

	 # ...and later	you may	free this job resources

	 # --- See DESCRIPTION for using generator '':

       The module represents an	access to the local and/or remote analysis
       tools in	a unified way that allows adding new access methods
       (protocols) seamlessly.

       At the moment of	writing, there is available a SOAP access to almost
       all EMBOSS applications,	running	at the European	Bioinformatics

       The documentation of all	"public" methods are to	be found in
       "Bio::AnalysisI". A tutorial (and examples how to call almost all
       public methods) is in the script	"panalysis.PLS"	(go to the "scripts"
       directory and type "perldoc panalysis.PLS").

       The module "Bio::Tools::Run::Analysis" uses general approach allowing
       to set arbitrary	input data and to retrieve results by naming them.
       However,	sometimes is more convenient to	use a specific module,
       representing one	analysis tool, that already knows about	available
       input and result	names. Such analyses-specific Perl modules can be
       generated by "papplmaker.PLS" generator.	Its features and usage are
       documented in the generator (go to the "scripts"	directory and type
       "perldoc	papplmaker.PLS").

	 # this	will generate module
	 perl papplmaker.PLS -n	edit.seqret -m Seqret

	 # ...which can	be used	with data-specific methods
	 use Seqret;
	 my $outseq = new Seqret
	   ->sequence_direct_data ('@/home/testdata/my.seq')
	   ->osformat ('embl')
	 print $outseq;

   Mailing Lists
       User feedback is	an integral part of the	evolution of this and other
       Bioperl modules.	Send your comments and suggestions preferably to the
       Bioperl mailing list.  Your participation is much appreciated.			- General discussion	- About	the mailing lists

       Please direct usage questions or	support	issues to the mailing list:

       rather than to the module maintainer directly. Many experienced and
       reponsive experts will be able look at the problem and quickly address
       it. Please include a thorough description of the	problem	with code and
       data examples if	at all possible.

   Reporting Bugs
       Report bugs to the Bioperl bug tracking system to help us keep track of
       the bugs	and their resolution. Bug reports can be submitted via the

       Martin Senger (

       Copyright (c) 2003, Martin Senger and EMBL-EBI.	All Rights Reserved.

       This module is free software; you can redistribute it and/or modify it
       under the same terms as Perl itself.

       This software is	provided "as is" without warranty of any kind.


       Here is the rest	of the object methods.	Internal methods are preceded
       with an underscore _.

	Usage	: my $tool =
		    Bio::Tools::Run::Analysis->new(-access => 'soap',
						   -name => 'edit.seqret',
	Returns	: a new	Bio::Tools::Run::Analysis object representing the given	tool
	Args	: There	may be additional arguments which are specific
		  to the access	method (see methods 'new' or '_initialize'
		  of the access-specific implementations (such as module
		  Bio::Tools::Run::Analysis::soap for a	SOAP-based access).

		  The recognised and used arguments are:

       It builds, populates and	returns	a new "Bio::Tools::Run::Analysis"
       object. This is how it is seen from the outside.	But in fact, it
       builds, populates and returns a more specific lower-level object, for
       example "Bio::Tools::Run::Analysis::soap" object	- which	one it depends
       on the "-access"	parameter.

	   It indicates	what lower-level module	to load.  Default is 'soap'.
	   Other (but future) possibilities may	be:

	      -access => 'novella'
	      -access => 'local'

	   A location of the service. The contents is access-specific (see
	   details in the lower-level implementation modules).

	   Default is "" (	services
	   running at European Bioinformatics Institute	on top of most of
	   EMBOSS analyses, and	on few others).

	   A name of an	analysis tool, or a name of its	higher-level
	   abstraction,	possibly including a category where the	analysis
	   belong to. There is no default value	(which usually means that this
	   parameter is	mandatory unless your -location	parameter includes
	   also	the name (but it is then access-dependent).

       -destroy_on_exit	=> '0'
	   Default value is '1'	which means that all
	   Bio::Tools::Run::Analysis::Job objects - when being finalised -
	   will	send a request to the remote site to forget the	results	of
	   these jobs.

	   If you change it to '0' make	sure that you know the job
	   identification - otherwise you will not be able to re-established
	   connection with it (later, when you use your	program	again).	This
	   can be done by calling method "id" on the job object	(such object
	   is returned by any of these methods:	"create_job", "run",

	   In addition to the location parameter, you may need to specify also
	   a location/URL of an	HTTP proxy server (if your site	requires one).
	   The expected	format is "http://server:port".	 There is no default
	   value. It is	also an	access-specific	parameter which	may not	be
	   used	by all access methods.

	   For long(er)	running	jobs the HTTP connection may be	time-outed. In
	   order to avoid it (or, vice-versa, to call timeout sooner) you may
	   specify "timeout" with the number of	seconds	the connection will be
	   kept	alive. Zero means to keep it alive forever. The	default	value
	   is two minutes.

   VERSION and Revision
	Usage	: print	$Bio::Tools::Run::Analysis::VERSION;
		  print	$Bio::Tools::Run::Analysis::Revision;

Module Bio::Tools::Run::Analysis::Job
       It represents a job, a single execution of an analysis tool. Usually
       you do not instantiate these objects - they are returned	by methods
       "create_job", "run", and	"wait_for" of "Bio::Tools::Run::Analysis"

       However,	if you wish to re-create a job you need	to know	its ID (method
       "id" gives it to	you). The ID can be passed directly to the "new"
       method, or again	you may	use "create_job" of a
       "Bio::Tools::Run::Analysis" object with the ID as parameter. See
       SYNOPSIS	above for an example.

       Remember	that all public	methods	of this	module are described in
       details in interface module "Bio::AnalysisI" and	in the tutorial	in the
       "" script.

	Usage	: my $job = Bio::Tools::Run::Analysis::Job->new
			      (-access => 'soap',
			       -name =>	'edit.seqret',
			       -id => 'xxxyyy111222333'
	Returns	: a re-created object representing a job
	Args	: The same arguments as	for Bio::Tools::Run::Analysis object:
		    (and perhaps others)
		  Additionally and specifically	for this object:

       -id A job ID created some previous time and now used to re-create the
	   same	job (in	order to re-gain access	to this	job results, for

	   A "Bio::Tools::Run::Analysis" object	whose properties (such as
	   "-access" and "-location" are used to re-create this	job object.

Module Bio::Tools::Run::Analysis::Utils
       It contains several general utilities. These are	"functions", not
       methods.	Therefore call them like, for example:

	   &Bio::Tools::Run::Analysis::Utils::format_time (...);

	Usage	: Bio::Tools::Run::Analysis::Utils::format_time	($time);
	Returns	: Slightly formatted $time
	Args	: $time	is number of seconds from the beginning	of Epoch

       It returns what "localtime" returns which means that return value is
       different in the	array and scalar context (see localtime). If $time is
       ``-1'' it returns 'n/a' (in the scalar context) or an empty array (in
       the array context). If $time is too small to represent the distance
       from the	beginning of the Epoch,	it returns it unchanged	(the same in
       any contex) - this is reasonable	for $time representing an elapsed

       The function is used to format times coming back	from various job time

	Usage	: $class->_load_access_module ($access)
	Returns	: 1 on success,	undef on failure
	Args	: 'access' should contain the last part	of the
		  name of a module who does the	real implementation

       It does (in the run-time) a similar thing as

	  require Bio::Tools::Run::Analysis::$access

       It prints an error on STDERR if it fails	to find	and load the module
       (for example, because of	the compilation	errors in the module).

	Usage	: Bio::Tools::Run::Analysis::Utils::guess_access ($rh_params)
	Returns	: string with a	guessed	access protocol	(e.g. 'soap'),
		  or undef if the guessing failed
	Args	: 'rh_params' is a hash	reference containing parameters	given
		  to the 'new' method.

       It makes	an expert guess	what kind of access/transport protocol should
       be used to access the underlying	analysis. The guess is based on	the
       parameters in rh_params.	Remember that this method is called only if
       there was no -access parameter which could tell directly	what access
       method to use.

perl v5.32.0			  2019-12-07	  Bio::Tools::Run::Analysis(3)

NAME | SYNOPSIS | DESCRIPTION | FEEDBACK | AUTHOR | COPYRIGHT | DISCLAIMER | SEE ALSO | APPENDIX | Module Bio::Tools::Run::Analysis::Job | Module Bio::Tools::Run::Analysis::Utils

Want to link to this manual page? Use this URL:

home | help