Topic
  • 7 replies
  • Latest Post - ‏2012-11-26T22:20:15Z by Sri_XI50
Sri_XI50
Sri_XI50
23 Posts

Pinned topic WSP Validation failing

‏2012-11-15T07:45:42Z |
Hi,

I have configured WSP with a WSDL and I am trying to hit it to see if it is validating the request. I have not touched the rules yet. When I triggered the request is failing I couldn't identify the reason. Can someone help ? Below is the Error in log... and I am using 5.0.0.x version of XI50.

0) wsgw (GoogleSearch): Dynamic Execution Error
1) Validation Error
2) Execution of 'local:///GoogleSearch.wsdl' aborted: http://192.168.0.249:81/search/beta2: cvc-type 3.1.1: element key of type {http://www.w3.org/2001/XMLSchema}string had undefined attribute {http://www.w3.org/1999/XMLSchema-instance}type
3) No WS-Proxy service endpoints matched request.

Thanks in advance.
Updated on 2012-11-26T22:20:15Z at 2012-11-26T22:20:15Z by Sri_XI50
  • Sri_XI50
    Sri_XI50
    23 Posts

    Re: WSP Validation failing

    ‏2012-11-15T07:46:20Z  
    Attaching a request also....

    Thanks.
  • HermannSW
    HermannSW
    4740 Posts

    Re: WSP Validation failing

    ‏2012-11-15T09:49:13Z  
    • Sri_XI50
    • ‏2012-11-15T07:46:20Z
    Attaching a request also....

    Thanks.
    I think the error message is correct.
    Your WSDL specifies '<part name="key" type="xsd:string"/>', and so "<key>" is of type "xsd:string".
    An element of type "xsd:string" does not have attributes.
    But your '<key xsi:type="xsd:string">00000000000000000000000000000000</key>' has xsi:type attribute.

    I removed all "xsi:type" attributes from your input, and this modified file (attached) validates fine against the WSDL:
    
    <?xml version=
    '1.0' encoding=
    'UTF-8'?>   <SOAP-ENV:Envelope xmlns:SOAP-ENV=
    "http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi=
    "http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd=
    "http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:doGoogleSearch xmlns:ns1=
    "urn:GoogleSearch" SOAP-ENV:encodingStyle=
    "http://schemas.xmlsoap.org/soap/encoding/"> <key>00000000000000000000000000000000</key> <q>shrdlu winograd maclisp teletype</q> <start>0</start> <maxResults>10</maxResults> <filter>true</filter> <restrict></restrict> <safeSearch>false</safeSearch> <lr></lr> <ie>latin1</ie> <oe>latin1</oe> </ns1:doGoogleSearch> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
    


     
    Hermann<myXsltBlog/> <myXsltTweets/>

    Attachments

  • Sri_XI50
    Sri_XI50
    23 Posts

    Re: WSP Validation failing

    ‏2012-11-16T02:24:42Z  
    • HermannSW
    • ‏2012-11-15T09:49:13Z
    I think the error message is correct.
    Your WSDL specifies '<part name="key" type="xsd:string"/>', and so "<key>" is of type "xsd:string".
    An element of type "xsd:string" does not have attributes.
    But your '<key xsi:type="xsd:string">00000000000000000000000000000000</key>' has xsi:type attribute.

    I removed all "xsi:type" attributes from your input, and this modified file (attached) validates fine against the WSDL:
    <pre class="jive-pre"> <?xml version= '1.0' encoding= 'UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi= "http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd= "http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:doGoogleSearch xmlns:ns1= "urn:GoogleSearch" SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"> <key>00000000000000000000000000000000</key> <q>shrdlu winograd maclisp teletype</q> <start>0</start> <maxResults>10</maxResults> <filter>true</filter> <restrict></restrict> <safeSearch>false</safeSearch> <lr></lr> <ie>latin1</ie> <oe>latin1</oe> </ns1:doGoogleSearch> </SOAP-ENV:Body> </SOAP-ENV:Envelope> </pre>

     
    Hermann<myXsltBlog/> <myXsltTweets/>
    Thank you Herman for your response. I solved that issue but couldn't reach google service as I don't have key and heard that they are not issuing keys now. So I stubbed the response.

    I have one more question on the same post I did yesterday, I see very few messages in the system log in 5.0.0.x . I remember seeing lots of messages in 3.8.x.x version earlier which says, REQUEST DETECTED, FINDING A MATCH, MATCH FOUND, SERVICE XXXX INVOKED, SUCCESFULLY SCHEMA VALIDATED .... etc ( message may not be same but they deliver the contect ). Is there any setting I should change in default ? Or Datapower stopped showing all messages in 5.0.0.x ?

    Thanks.
  • kenhygh
    kenhygh
    1576 Posts

    Re: WSP Validation failing

    ‏2012-11-16T10:32:26Z  
    • Sri_XI50
    • ‏2012-11-16T02:24:42Z
    Thank you Herman for your response. I solved that issue but couldn't reach google service as I don't have key and heard that they are not issuing keys now. So I stubbed the response.

    I have one more question on the same post I did yesterday, I see very few messages in the system log in 5.0.0.x . I remember seeing lots of messages in 3.8.x.x version earlier which says, REQUEST DETECTED, FINDING A MATCH, MATCH FOUND, SERVICE XXXX INVOKED, SUCCESFULLY SCHEMA VALIDATED .... etc ( message may not be same but they deliver the contect ). Is there any setting I should change in default ? Or Datapower stopped showing all messages in 5.0.0.x ?

    Thanks.
    Make sure your logging options are still set to debug.
    Ken
  • Sri_XI50
    Sri_XI50
    23 Posts

    Re: WSP Validation failing

    ‏2012-11-18T08:48:33Z  
    • kenhygh
    • ‏2012-11-16T10:32:26Z
    Make sure your logging options are still set to debug.
    Ken
    Hi Ken,

    Thanks for the respopnse.

    Yes system log was set to Debug.

    Thanks.
  • HermannSW
    HermannSW
    4740 Posts

    Re: WSP Validation failing

    ‏2012-11-18T15:48:51Z  
    • Sri_XI50
    • ‏2012-11-18T08:48:33Z
    Hi Ken,

    Thanks for the respopnse.

    Yes system log was set to Debug.

    Thanks.
    Is your new service running in default domain or application domain?
    Did you check the "debug" setting in the service's domain?

    I just did run this against a 5.0.0.0 XI52:
    
    $ coproc2 double.xsl ab.xml http:
    //firestar:2223 ; echo <out><a>1<b>2</b>3</a><a>1<b>2</b>3</a></out> $
    


    As you can see the transaction log is pretty detailed (in 5.0.0.0):
    
    18:49:17 memory-report   debug           621857          9.164.186.219   0x80e00690      mpgw (coproc2): Response Finished: memory used 516280 18:49:17  mpgw    info            621857          9.164.186.219   0x80e0010f      mpgw (coproc2): Early completion detected - back side will not be executed 18:49:17     multistep       info            621857  request 9.164.186.219   0x80c00002      mpgw (coproc2): rule (coproc2_rule_1): #2 xform: 
    'Transforming INPUT with xsl results stored in OUTPUT' completed OK. 18:49:17        memory-report   debug           621857  request 9.164.186.219   0x80e0068d      mpgw (coproc2): Processing [Rule (coproc2_rule_1), Action (
    'coproc2_rule_1_xform_1', xform(xsl)), Input(INPUT), Output(OUTPUT)] finished: memory used 621728 18:49:17 xslt    info            621857          9.164.186.219   0x80a002a2      xmlmgr (
    
    default): xa35:
    //tmp/temp_00024 has identical SHA1 hash to xa35://tmp/temp_00008; using cached version. 18:49:17        xslt    debug           621857          9.164.186.219   0x80a002af      xmlmgr (
    
    default): xslt Compilation Request: Not in cache, compiling (xa35:
    //tmp/temp_00024) 18:49:17    xslt    debug           621857          9.164.186.219   0x80a002aa      xmlmgr (
    
    default): xslt Compilation Request: Checking cache 
    
    for URL xa35:
    //tmp/temp_00024 18:49:17      multistep       debug           621857  request 9.164.186.219   0x80c0004e      mpgw (coproc2): Stylesheet URL to compile is 
    'xsl' 18:49:17   multistep       info            621857  request 9.164.186.219   0x80c00002      mpgw (coproc2): rule (coproc2_rule_1): #1 xform: 
    'Transforming NULL with local:///coproc2.xsl results stored in NULL' completed OK. 18:49:17  memory-report   debug           621857  request 9.164.186.219   0x80e0068d      mpgw (coproc2): Processing [Rule (coproc2_rule_1), Action (
    'coproc2_rule_1_xform_0', xform(local:
    ///coproc2.xsl)), Input(NULL), Output(NULL)] finished: memory used 188096 18:49:17    mpgw    info            621857          9.164.186.219   0x80e00115      mpgw (coproc2): Will not process backside due to var:
    //service/mpgw/skip-backside 18:49:17       xslt    debug           621857          9.164.186.219   0x80a002ac      xmlmgr (
    
    default): xslt Compilation Request: Found in cache (local:
    ///coproc2.xsl) 18:49:17      xslt    debug           621857          9.164.186.219   0x80a002aa      xmlmgr (
    
    default): xslt Compilation Request: Checking cache 
    
    for URL local:
    ///coproc2.xsl 18:49:17       multistep       debug           621857  request 9.164.186.219   0x80c0004e      mpgw (coproc2): Stylesheet URL to compile is 
    'local:///coproc2.xsl' 18:49:17  xmlparse        debug           621857  request 9.164.186.219   0x80e003ab      mpgw (coproc2): Finished parsing: http:
    //9.152.8.190:2223/ 18:49:17      xmlparse        debug           621857  request 9.164.186.219   0x80e003a6      mpgw (coproc2): Parsing document: 
    'http://9.152.8.190:2223/' 18:49:17 memory-report   debug           621857          9.164.186.219   0x80e0068c      mpgw (coproc2): Request Started: memory used 58856 18:49:17     mpgw    info            621857  request 9.164.186.219   0x80e000b4      stylepolicy (coproc2): rule (coproc2_rule_1): selected via match 
    'all' from processing policy 
    'coproc2' 18:49:17    mpgw    debug           621857          9.164.186.219   0x81000171      Matching (all): Match: Received URL [/] matches rule 
    '*' 18:49:17     mpgw    debug           621857          9.164.186.219   0x80e00140      source-http (coproc2): Generating chunked response stream to front 18:49:17     mpgw    debug           621857          9.164.186.219   0x80e0013f      source-http (coproc2): Found content length 18 HTTP input 18:49:17      mpgw    debug           621857          9.164.186.219   0x80e0013b      source-http (coproc2): HTTP Transaction # 1 on 
    
    this TCP connection 18:49:17    mpgw    info            621857          9.164.186.219   0x80e0013a      source-http (coproc2): Received HTTP/1.1 POST 
    
    for / from 9.164.186.219
    


     
    Hermann<myXsltBlog/> <myXsltTweets/>
  • Sri_XI50
    Sri_XI50
    23 Posts

    Re: WSP Validation failing

    ‏2012-11-26T22:20:15Z  
    • HermannSW
    • ‏2012-11-18T15:48:51Z
    Is your new service running in default domain or application domain?
    Did you check the "debug" setting in the service's domain?

    I just did run this against a 5.0.0.0 XI52:
    <pre class="jive-pre"> $ coproc2 double.xsl ab.xml http: //firestar:2223 ; echo <out><a>1<b>2</b>3</a><a>1<b>2</b>3</a></out> $ </pre>

    As you can see the transaction log is pretty detailed (in 5.0.0.0):
    <pre class="jive-pre"> 18:49:17 memory-report debug 621857 9.164.186.219 0x80e00690 mpgw (coproc2): Response Finished: memory used 516280 18:49:17 mpgw info 621857 9.164.186.219 0x80e0010f mpgw (coproc2): Early completion detected - back side will not be executed 18:49:17 multistep info 621857 request 9.164.186.219 0x80c00002 mpgw (coproc2): rule (coproc2_rule_1): #2 xform: 'Transforming INPUT with xsl results stored in OUTPUT' completed OK. 18:49:17 memory-report debug 621857 request 9.164.186.219 0x80e0068d mpgw (coproc2): Processing [Rule (coproc2_rule_1), Action ( 'coproc2_rule_1_xform_1', xform(xsl)), Input(INPUT), Output(OUTPUT)] finished: memory used 621728 18:49:17 xslt info 621857 9.164.186.219 0x80a002a2 xmlmgr ( default): xa35: //tmp/temp_00024 has identical SHA1 hash to xa35://tmp/temp_00008; using cached version. 18:49:17 xslt debug 621857 9.164.186.219 0x80a002af xmlmgr ( default): xslt Compilation Request: Not in cache, compiling (xa35: //tmp/temp_00024) 18:49:17 xslt debug 621857 9.164.186.219 0x80a002aa xmlmgr ( default): xslt Compilation Request: Checking cache for URL xa35: //tmp/temp_00024 18:49:17 multistep debug 621857 request 9.164.186.219 0x80c0004e mpgw (coproc2): Stylesheet URL to compile is 'xsl' 18:49:17 multistep info 621857 request 9.164.186.219 0x80c00002 mpgw (coproc2): rule (coproc2_rule_1): #1 xform: 'Transforming NULL with local:///coproc2.xsl results stored in NULL' completed OK. 18:49:17 memory-report debug 621857 request 9.164.186.219 0x80e0068d mpgw (coproc2): Processing [Rule (coproc2_rule_1), Action ( 'coproc2_rule_1_xform_0', xform(local: ///coproc2.xsl)), Input(NULL), Output(NULL)] finished: memory used 188096 18:49:17 mpgw info 621857 9.164.186.219 0x80e00115 mpgw (coproc2): Will not process backside due to var: //service/mpgw/skip-backside 18:49:17 xslt debug 621857 9.164.186.219 0x80a002ac xmlmgr ( default): xslt Compilation Request: Found in cache (local: ///coproc2.xsl) 18:49:17 xslt debug 621857 9.164.186.219 0x80a002aa xmlmgr ( default): xslt Compilation Request: Checking cache for URL local: ///coproc2.xsl 18:49:17 multistep debug 621857 request 9.164.186.219 0x80c0004e mpgw (coproc2): Stylesheet URL to compile is 'local:///coproc2.xsl' 18:49:17 xmlparse debug 621857 request 9.164.186.219 0x80e003ab mpgw (coproc2): Finished parsing: http: //9.152.8.190:2223/ 18:49:17 xmlparse debug 621857 request 9.164.186.219 0x80e003a6 mpgw (coproc2): Parsing document: 'http://9.152.8.190:2223/' 18:49:17 memory-report debug 621857 9.164.186.219 0x80e0068c mpgw (coproc2): Request Started: memory used 58856 18:49:17 mpgw info 621857 request 9.164.186.219 0x80e000b4 stylepolicy (coproc2): rule (coproc2_rule_1): selected via match 'all' from processing policy 'coproc2' 18:49:17 mpgw debug 621857 9.164.186.219 0x81000171 Matching (all): Match: Received URL [/] matches rule '*' 18:49:17 mpgw debug 621857 9.164.186.219 0x80e00140 source-http (coproc2): Generating chunked response stream to front 18:49:17 mpgw debug 621857 9.164.186.219 0x80e0013f source-http (coproc2): Found content length 18 HTTP input 18:49:17 mpgw debug 621857 9.164.186.219 0x80e0013b source-http (coproc2): HTTP Transaction # 1 on this TCP connection 18:49:17 mpgw info 621857 9.164.186.219 0x80e0013a source-http (coproc2): Received HTTP/1.1 POST for / from 9.164.186.219 </pre>

     
    Hermann<myXsltBlog/> <myXsltTweets/>
    Hi,

    Thank you all for your responses.

    Herman... Yes with your suggestion I did take a look at the setting. I have added extra log targets and subscribed to the default-log log type. I started seeing what I want.

    Thanks.