sounds like a shim to me.. here's a beanshell that would do it.
Input: list (depth 1)
Script:
if (list.isEmpty()) {
throw new Exception("List is empty");
}
Replace list.isEmpty() with inputString.contains("ERROR") or
inputString.equals("") etc. for similar kind of error-detecting shims.
(with depth 0 for the input)
What are the error conditions depend on the service - perhaps a job
for BioCatalogue? (Of course proper services should return a proper
SOAP error, but often they don't..).
Also what is an error to the workflow designer might not be an error
to the service, for instance it is a perfectly valid response from an
XPath extractor to give an empty list if there was no match, just like
a database query with no matches could give an empty list. (They
should however fail if the syntax was wrong in the query!)
You could picture a dispatch layer (sorry) similar to the looping
mechanism (under Details->Advanced) that adds these kinds of error
checks - in that way hiding the error-detecting shim from the
workflow.
On Thu, Jan 21, 2010 at 10:32, Alan Williams <[email protected]> wrote:
> Marco Roos wrote:
>> Hello,
>
> Hello Marco,
>
>> I wonder, would it be possible to treat empty results as 'potential errors'
>> in
>> Taverna, triggering some kind of error or perhaps a warning message with some
>> tips? When I tried Carsten's xpath example without a namespace the result was
>> empty, not an error. This is correct I now know, but obviously not what I
>> expected at first. My guess is that an empty result is often not what people
>> expect.
>
> I'm probably not being inventive, but I think this would require you to
> specify this small piece of expected behaviour for the service. Taverna
> would then need to compare the actual behaviour with the expected one
> and change the output to an ErrorDocument if it didn't match.
>
> Would the expected behaviour be the same for each use of the workflow?
> I can see that if the workflow was nested then what you expect to happen
> in its services may vary. Also, just applying it to different data sets
> could alter what you expect to happen.
>
> So I'm not sure where this information would be kept. I don't think
> it's OK to do it as a configuration of the service as that is too
> static; maybe it needs to be in something that goes along with the
> workflow run.
>
>> Just a thought...
>
> It's a good idea. It could be very useful. I've no ideas at the moment
> how to "architect" it.
>
> What do other users think?
>
>> Cheers,
>> Marco.
>
> Alan
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> taverna-users mailing list
> [email protected]
> [email protected]
> Web site: http://www.taverna.org.uk
> Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/
>
--
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
taverna-users mailing list
[email protected]
[email protected]
Web site: http://www.taverna.org.uk
Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/
