[Pywps-devel] Error in ExcecuteProcess_r.add
Egil Støren
egil.storen at met.no
Fri Apr 13 16:30:46 CEST 2012
Finally it works!
Now I am leaving for a holliday, as I am one of those normal 8-16
working guys and takes no work with me at home :-)
Egil
On 04/13/2012 03:38 PM, Jorge de Jesus wrote:
>
> Hi Egil
>
> See reply below, I'm also in the #pywps channel if you need a faster help.
>
> On 13/04/12 13:32, Egil Støren wrote:
>> Hi Jorge,
>>
>> I have checked the /etc/pywps.cfg file, and it contains:
>>
>> serveraddress=http://dev-vm127/cgi-bin/pywps.cgi
>>
>> I have removed the wps symlink in the cgi-bin directory, which now
>> have the following content:
>>
>> -rwxr--r-- 1 www-data www-data 301 2012-03-30 09:48 grass.cgi
>> -rwxr-xr-x 1 www-data www-data 615061 2012-04-13 12:17 grass.wsdl
>> drwxr-xr-x 2 root root 4096 2012-03-06 10:41 processes
>> -rwxr--r-- 1 www-data www-data 165 2012-03-26 11:43 pywps.cgi
>>
>> The grass.cgi and grass.wsdl are not used, since I have also put the
>> grass.wsdl in the document root directory where I think taverna
>> fetches it. In the taverna GUI, this service is displayed as "WSDL @
>> http://dev-vm127/grass.wsdl".
>>
>
> I think it shouldn't be a problem for taverna to use WSDL @
> http://dev-vm127/grass.wsdl since the grass.wsdl should point to
> http://dev-vm127/cgi-bin/grass.cgi, but to be safe, could you please set
> Taverna to use the WSDL files from the cgi-bin directory
>
>> I think the initial "404 Not found" error I got before I introduced
>> the wps symlink, was due to me not regenerating the grass.wsdl file in
>> document root after I made a correction to the serveraddress in
>> pywps.cfg.
>>
>> When I now run the workflow, I no longer get the "404 not found" error.
>>
>> The run stops in the ExcecuteProcess_r.add box, and the error message
>> is the same as before (when I used the wps symlink):
>>
>> 'The requested process is not part of the instance. Check pywps conf
>> file and WSDL. WSDL has to point to the correct wrapper, please check
>> location attribute in address element of WSDL document'
>>
>> In the pywps.log I see the following messages:
>>
>> PyWPS [2012-04-13 12:42:42,673] INFO: Reading processes from
>> [/usr/lib/cgi-bin/processes]
>> PyWPS [2012-04-13 12:42:42,839] INFO: Following processes are
>> imported: ['returner', 'dummyprocess', 'ultimatequestionprocess',
>> 'complexVector', 'complexRaster', 'noOutput', 'firstInstance',
>> 'secondInstance', 'assyncprocess', 'bboxprocess', 'complexprocess',
>> 'literalprocess', 'noinputsprocess', 'GMLBuffer', 'reducer',
>> 'histogramprocess']
>> Traceback (most recent call last):
>> File
>> "/usr/local/lib/python2.6/dist-packages/pywps-soap_branch-py2.6.egg/EGG-INFO/scripts/wps.py",
>> line 95, in<module>
>> if wps.parseRequest(inputQuery):
>> File
>> "/usr/local/lib/python2.6/dist-packages/pywps-soap_branch-py2.6.egg/pywps/__init__.py",
>> line 212, in parseRequest
>> self.inputs = self.parser.parse(queryStringObject)
>> File
>> "/usr/local/lib/python2.6/dist-packages/pywps-soap_branch-py2.6.egg/pywps/Parser/Post.py",
>> line 108, in parse
>> firstChild = self.isSoapFirstChild(self.document)
>> File
>> "/usr/local/lib/python2.6/dist-packages/pywps-soap_branch-py2.6.egg/pywps/Parser/Post.py",
>> line 234, in isSoapFirstChild
>> firstChild=soapCls.getWPSContent()
>> File
>> "/usr/local/lib/python2.6/dist-packages/pywps-soap_branch-py2.6.egg/pywps/Soap.py",
>> line 315, in getWPSContent
>> XMLStr=SOAPtoWPS(reqWPS[0])
>> File
>> "/usr/local/lib/python2.6/dist-packages/pywps-soap_branch-py2.6.egg/pywps/Soap.py",
>> line 164, in SOAPtoWPS
>> raise pywps.NoApplicableCode("The requested process is not part of
>> the instance. Check pywps conf file and WSDL. WSDL has to point to the
>> correct wrapper, please check location attribute in address element of
>> WSDL document")
>> NoApplicableCode:<?xml version="1.0" encoding="utf-8"?>
>> <ExceptionReport version="1.0.0"
>> xmlns="http://www.opengis.net/ows/1.1"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://www.opengis.net/ows/1.1
>> http://schemas.opengis.net/ows/1.1.0/owsExceptionReport.xsd">
>> <Exception exceptionCode="NoApplicableCode">
>> <ExceptionText>
>> 'The requested process is not part of the
>> instance. Check pywps conf file and WSDL. WSDL has to point to the
>> correct wrapper, please check location attribute in address element of
>> WSDL document'
>> </ExceptionText>
>> </Exception>
>> </ExceptionReport>
>>
>> Since I am using the grass service, I suppose the relevant WSDL
>> document is the grass.wsdl in my document root. It contains this
>> 'port' element near the end:
> Egil, please notice the following:
>
> INFO: Following processes are imported: ['returner', 'dummyprocess',
> 'ultimatequestionprocess', 'complexVector', 'complexRaster', 'noOutput',
> 'firstInstance', 'secondInstance', 'assyncprocess', 'bboxprocess',
> 'complexprocess', 'literalprocess', 'noinputsprocess', 'GMLBuffer',
> 'reducer', 'histogramprocess'
>
> There is no reference to the r.add process, I would expect for it to be
> in grass.cgi/grass.wsdl, Taverna is calling pywps.cgi instead of grass.cgi
>
>>
>> <port name="PywpsServer_Port"
>> binding="tns:PywpsServer_Binding"><address
>> xmlns="http://schemas.xmlsoap.org/wsdl/soap/"
>> location="http://dev-vm127/cgi-bin/pywps.cgi"/></port>
>>
>> The document I get in my browser when I ask for
>> http://dev-vm127/cgi-bin/pywps.cgi?wsdl has a similar port element:
>>
>> <port name="PywpsServer_Port"
>> binding="tns:PywpsServer_Binding"><address
>> location="http://dev-vm127/cgi-bin/pywps.cgi"/></port>
>>
>
> The above assumption is correct: address
> location="http://dev-vm127/cgi-bin/pywps.cgi"
>
> If you run a describeProcess on pywps.cgi I dont think you will find
> r.add process
>
>
>> Well. I am empty of ideas. Am I using a wrong python version? I am
>> using 2.6, but on the python web page, I see both a 2.7 and a 3.2
>> version.
>>
>> In anticipation of your support,
>>
>
> I'm mainly working with python 2.6.4
>
>> best regards,
>>
>> Egil
>>
>
> I've looked at page 33/34 of the cookbook, and I think I know what is
> the problem, I should have left an advise in the documentation for the
> user to set different pywps configuration for each pywps instance,
> where each configuration file has a different serveradress setting,
> according to the instance
>
> I think your grass.cgi is using the generic pywps.conf that in turn has
> serveradress set to http://dev-vm127/cgi-bin/pywps.cgi, you should make
> a copy of your pywps.conf rename it and set the correct serveraddress so
> that you have:
>
> pywps.cgi ---> export PYWPS_CFG=/etc/pywps.cfg -->
> serveradress=http://dev-vm127/cgi-bin/pywps.cgi
>
> grass.cgi ---> export PYWPS_CFG=/etc/pywps_grass.cfg -->
> serveradress=http://dev-vm127/cgi-bin/grass.cgi
>
> Jorge
>
>>
>> On 04/12/2012 09:46 AM, Jorge de Jesus wrote:
>>>
>>> Once again something badly documented, but the WPS exception gives some
>>> nices clues :), basically the WSDL and the WPS's DescribeProcess are not
>>> the same, the WSDL is asking for a process that is not in the WPS
>>> instance, the following explanation is the most likely cause of your
>>> problem:
>>>
>>> If you look at the bottom of the WSDL document you have the address
>>> location:
>>>
>>> <port
>>> name="PlymouthMarineLaboratory-RemoteSensingGroup.WpsGenericInstance-SoapBranchRev1302_Port"
>>>
>>> binding="tns:PlymouthMarineLaboratory-RemoteSensingGroup.WpsGenericInstance-SoapBranchRev1302_Binding">
>>>
>>> <address location="*http://rsg.pml.ac.uk/wps/generic.cgi*"/></port>
>>>
>>> This is the URL that taverna will use to call the services, and it has
>>> to be *identical *to the WPS instance, the URL in the WSDL document is
>>> fetched from the pywps configure file on the serveradress
>>>
>>> serveraddress=*http://rsg.pml.ac.uk/wps/generic.cgi*
>>>
>>> Looking at what you did and how it couldn't find the
>>> /usr/lib/cgi-bin/wps.py , it is very likely that you are running the
>>> default pywps config option and/or you didnt configured the
>>> serveradress.
>>>
>>> I recommend that you remove the ln link, reconfigure your system and see
>>> what is at the end of the WSDL file.
>>>
>>> Let me know if it helped
>>>
>>> Jorge
>>>
>>>> Any advise?
>>>>
>>>> Egil
>>>>
>>>> On 04/11/2012 01:35 PM, Alan R Williams wrote:
>>>>> On 11/04/2012 11:43, Egil Støren wrote:
>>>>>> Hello,
>>>>>
>>>>> Hello
>>>>>
>>>>> [snip]
>>>>>> I got a message in the error panel, and a similar message in the
>>>>>> standard output:
>>>>>>
>>>>>> WARN 2012-04-11 11:58:13,339
>>>>>> (net.sf.taverna.t2.workflowmodel.processor.dispatch.layers.Invoke:234)
>>>>>>
>>>>>> -
>>>>>> Failed (INVOCATION) invoking
>>>>>> net.sf.taverna.t2.activities.wsdl.xmlsplitter.XMLInputSplitterActivity at 12cc1d1d
>>>>>>
>>>>>>
>>>>>> for job DispatchJobEvent
>>>>>> facade0:Workflow1:ExecuteProcess_r.add_DataInputs[]: Error in
>>>>>> XMLInputSplitterActivity
>>>>>> org.jdom.IllegalDataException: The data ".... Long string of binary
>>>>>> rubbish ..." is not legal for a JDOM character content: 0x0 is not a
>>>>>> legal XML character." is not legal for a JDOM character content:
>>>>>> 0x0 is
>>>>>> not a legal XML character.
>>>>>> at org.jdom.Text.setText(Text.java:188)
>>>>>> at org.jdom.Text.<init>(Text.java:99)
>>>>>> at org.jdom.Element.addContent(Element.java:801)
>>>>>> at
>>>>>> net.sf.taverna.t2.provenance.lineageservice.utils.ProvenanceUtils.resolveToElement(ProvenanceUtils.java:82)
>>>>>>
>>>>>>
>>>>>> (about 50 additional lines with java trace)
>>>>>
>>>>> What a wonderful error message "Long string of binary rubbish" :-)
>>>>>
>>>>> I guess that the workflow is expecting the URL of the data as the
>>>>> input
>>>>> and you are telling Taverna to read the input from the URL. So the
>>>>> workflow is using the actual tif image.
>>>>>
>>>>> You need to make sure that you click "Set value" and do not click
>>>>> "Set URL".
>>>>>
>>>>> That is just my guess. If it is wrong, then you will need to send
>>>>> us the
>>>>> workflow so we can look at it.
>>>>>
>>>>>> According to Jorge, the cookbook author, he has no problem running
>>>>>> this
>>>>>> example workflow.
>>>>>>
>>>>>> I would very much appreciate if somebody could give me advice on
>>>>>> how to
>>>>>> track down this error.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Egil Støren
>>>>>> The Norwegian Meteorological Institute
>>>>>
>>>>> Alan
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> Better than sec? Nothing is better than sec when it comes to
>>>>> monitoring Big Data applications. Try Boundary one-second
>>>>> resolution app monitoring today. Free.
>>>>> http://p.sf.net/sfu/Boundary-dev2dev
>>>>> _______________________________________________
>>>>> taverna-users mailing list
>>>>> taverna-users at lists.sourceforge.net
>>>>> taverna-users at lists.sourceforge.net
>>>>> Web site: http://www.taverna.org.uk
>>>>> Mailing lists: http://www.taverna.org.uk/about/contact-us/
>>>>>
>>>>
>>>> _______________________________________________
>>>> Pywps-devel mailing list
>>>> Pywps-devel at wald.intevation.org
>>>> http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/pywps-devel
>>>
>>>
>>> --
>>> PGP public key: 0x595FF9D3
>>>
>>
>
>
More information about the Pywps-devel
mailing list