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

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
    ACCEPTED ANSWER

    Re: WSP Validation failing

    ‏2012-11-15T07:46:20Z  in response to Sri_XI50
    Attaching a request also....

    Thanks.
    • HermannSW
      HermannSW
      4379 Posts
      ACCEPTED ANSWER

      Re: WSP Validation failing

      ‏2012-11-15T09:49:13Z  in response to Sri_XI50
      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
        ACCEPTED ANSWER

        Re: WSP Validation failing

        ‏2012-11-16T02:24:42Z  in response to HermannSW
        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
          1433 Posts
          ACCEPTED ANSWER

          Re: WSP Validation failing

          ‏2012-11-16T10:32:26Z  in response to Sri_XI50
          Make sure your logging options are still set to debug.
          Ken
          • Sri_XI50
            Sri_XI50
            23 Posts
            ACCEPTED ANSWER

            Re: WSP Validation failing

            ‏2012-11-18T08:48:33Z  in response to kenhygh
            Hi Ken,

            Thanks for the respopnse.

            Yes system log was set to Debug.

            Thanks.
            • HermannSW
              HermannSW
              4379 Posts
              ACCEPTED ANSWER

              Re: WSP Validation failing

              ‏2012-11-18T15:48:51Z  in response to Sri_XI50
              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
                ACCEPTED ANSWER

                Re: WSP Validation failing

                ‏2012-11-26T22:20:15Z  in response to HermannSW
                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.