airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raminder Singh <>
Subject Re: Updates to Airavata API version 0.8
Date Tue, 21 May 2013 14:02:39 GMT
Thank, these are very useful for API users. Only thing i found confusing for the user is API
managers.  ProvenanceManager is the one used to get experiment status. Users will get FINISHED
or FAILED status from the data object. On failure, i was trying to find a method to get the
error data but i was not able to find as those methods exist in ExecutionManager. According
to me, experiment status and in case of failures get error need to be part of one manager.
May be a ExperimentManager?  Getting output data can be left as part of provenance manages
as only few client may want to get the data in few cases. Getting error detail in case of
error is obvious step.  

Other thing can you please explain the difference between WorkflowExecutionError, ExperimentExecutionError,
NodeExecutionError, GFacExecutionError on a Wiki page for the users. Also add a method to
get JobID as that is required to get GFacExecutionError. 

I tested the WorkflowExecutionError method and its not returning any data. Can you please
test that as well?

ExperimentData data =  airavataAPI.getProvenanceManager().getExperimentData(experimentID);
List<WorkflowExecutionError> experimentExecutionErrors = airavataAPI.getExecutionManager().getWorkflowExecutionErrors(experimentID,


On May 20, 2013, at 5:05 PM, Saminda Wijeratne wrote:

> Following updates will be present Airavata API from 0.8 release.
>   1. *Error message from the immediate exception used as the error message
>   for the AiravataAPInvocationException*. Earlier it was just "Error
>   invoking API". *This change was made so that the users of the API can
>   show the error from the exception without having to dig in to the inner
>   exception to get a better error message.*
>   2. *Saving and retrieving experiment execution error details*. Earlier
>   we were not persisting any execution error details of the workflow. Error
>   details are only available only if the developers are monitoring experiment
>   at the time of error occurs. *This is not feasible if users would only
>   want to go through the error details later without doing monitoring from
>   the beginning. Therefore we are now persisting the error details (not as
>   part of provenance data) of executing workflows (i.e. experiments)* in
>   to the registry and also retrieving from registry through Airavata API
>   (which calls the Registry API).
> For now we have the functions for saving and retrieving errors in the
> ExecutionManager[1]. We need to decide if this is the correct place to put
> these functions. Your thoughts in this matter are most welcome...
> Thanks,
> Saminda
> 1.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message