Topic
  • 8 replies
  • Latest Post - ‏2013-06-25T17:36:10Z by JoeMorganNTST
bruneves
bruneves
44 Posts

Pinned topic Duplication of processing rules when a second FSH is added to a WSP

‏2013-04-16T20:35:47Z |

Does anyone know why DataPower duplicates the processing rules of a WSP service when a second FSH is added? What is the benefit of it?

Thank you!

  • JoeMorganNTST
    JoeMorganNTST
    427 Posts

    Re: Duplication of processing rules when a second FSH is added to a WSP

    ‏2013-04-18T15:03:31Z  

    I'm having the same problem.  I have 2 WSDL endpoints, one for SOAP 1.1, another for SOAP 1.2.  I have the same FSH for both, but the WSP published 4 endpoints, even though there are only 2 clearly shown in the WSDL tab.

    Only 2 of the 4 actually work.  I went to the policy tab and "un-published" the 2 that did not work.  It wasn't clear, though, which 2 weren't working.  That took trial and error.

     

  • HermannSW
    HermannSW
    6126 Posts

    Re: Duplication of processing rules when a second FSH is added to a WSP

    ‏2013-04-19T09:21:09Z  

    Bruno, Joseph,

    which firmware versions are you using?
     

    Joseph,

    deleting generated rules is definitely risky -- there was a reason why DataPower generated them.
    I would assume that one of the possible usage scenarios is now not usable for you anymore.
     

    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>

  • bruneves
    bruneves
    44 Posts

    Re: Duplication of processing rules when a second FSH is added to a WSP

    ‏2013-04-19T22:35:03Z  
    • HermannSW
    • ‏2013-04-19T09:21:09Z

    Bruno, Joseph,

    which firmware versions are you using?
     

    Joseph,

    deleting generated rules is definitely risky -- there was a reason why DataPower generated them.
    I would assume that one of the possible usage scenarios is now not usable for you anymore.
     

    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>

    Hi Hermann,

    We are currently running FW 5.0.0.0, but I have seen the same behavior since forever I think... I am pretty sure there is a reason for that to happen, but as that does not help us at all, we would like to understand why that happens at least...

    Thanks!

  • JoeMorganNTST
    JoeMorganNTST
    427 Posts

    Re: Duplication of processing rules when a second FSH is added to a WSP

    ‏2013-04-23T14:12:17Z  
    • HermannSW
    • ‏2013-04-19T09:21:09Z

    Bruno, Joseph,

    which firmware versions are you using?
     

    Joseph,

    deleting generated rules is definitely risky -- there was a reason why DataPower generated them.
    I would assume that one of the possible usage scenarios is now not usable for you anymore.
     

    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>

    5.0.0.3 on XI52. 

    I successfully "unpublished" the non-working endpoints.  The other 2 (the only 2 it should have) are working.  Even if I had not unpublished them, they aren't working.

    deleting generated rules is definitely risky -- there was a reason why DataPower generated them.

    If DataPower is generating things that don't work, in this case, extra things that don't work, then there's little risk at all!  I fixed it for a bug that's clearly in DataPower.  We just want to know why it is doing this, and if there is a non-risky way to clean it up.

  • HermannSW
    HermannSW
    6126 Posts

    Re: Duplication of processing rules when a second FSH is added to a WSP

    ‏2013-04-23T14:29:01Z  

    5.0.0.3 on XI52. 

    I successfully "unpublished" the non-working endpoints.  The other 2 (the only 2 it should have) are working.  Even if I had not unpublished them, they aren't working.

    deleting generated rules is definitely risky -- there was a reason why DataPower generated them.

    If DataPower is generating things that don't work, in this case, extra things that don't work, then there's little risk at all!  I fixed it for a bug that's clearly in DataPower.  We just want to know why it is doing this, and if there is a non-risky way to clean it up.

    Can you attach a sample export here?

    If not, please create a PMR and provide it that way.

    It is difficult to comment on "not working" if not being able to see it exactly.


    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>

  • JoeMorganNTST
    JoeMorganNTST
    427 Posts

    Re: Duplication of processing rules when a second FSH is added to a WSP

    ‏2013-04-23T15:25:27Z  
    • HermannSW
    • ‏2013-04-23T14:29:01Z

    Can you attach a sample export here?

    If not, please create a PMR and provide it that way.

    It is difficult to comment on "not working" if not being able to see it exactly.


    Hermann<myXsltBlog/> <myXsltTweets/> <myCE/>

    The scenario in my case is pretty simple.  I was provided a WSDL to proxy.  That WSDL has Soap 1.1 and Soap 1.2 bindings.  So, in the Edit WSDL tab, we have the same FSH for BOTH bindings, and they, of course, have different URI's.  2 bindings, 1 FSH each.

    We also are not using "local" publishing, because the WSP is internal, and the client needs to access via our DMZ.  So, we republish the host, port and URI for the DMZ.  Still, that's only 2.

    When we request the WSDL, it is republished with 4 port bindings, the 2 you'd ordinarily expect (XXXHttpSoap11Endpoint, and XXXHttpSoap12Endpoint), and then another each with a(XXXHttpSoap11Endpoint.0, and XXXHttpSoap12Endpoint.2). 

    To clean it up, in the "Policy" tab, I expanded it down to the ports where it is showing the 4.  Then I open up the fault validation popup and turn off "Enable this component" and "Publish in WSDL".  This is what took the experimentation.  At first, I thought I could just pick any 2.  Then I learned 2 of them didn't work.  I had to go through each of them one at a time and test it until I found the 2 that did work.

    J

  • OswaldoGago
    OswaldoGago
    27 Posts

    Re: Duplication of processing rules when a second FSH is added to a WSP

    ‏2013-06-20T19:37:08Z  

    The scenario in my case is pretty simple.  I was provided a WSDL to proxy.  That WSDL has Soap 1.1 and Soap 1.2 bindings.  So, in the Edit WSDL tab, we have the same FSH for BOTH bindings, and they, of course, have different URI's.  2 bindings, 1 FSH each.

    We also are not using "local" publishing, because the WSP is internal, and the client needs to access via our DMZ.  So, we republish the host, port and URI for the DMZ.  Still, that's only 2.

    When we request the WSDL, it is republished with 4 port bindings, the 2 you'd ordinarily expect (XXXHttpSoap11Endpoint, and XXXHttpSoap12Endpoint), and then another each with a(XXXHttpSoap11Endpoint.0, and XXXHttpSoap12Endpoint.2). 

    To clean it up, in the "Policy" tab, I expanded it down to the ports where it is showing the 4.  Then I open up the fault validation popup and turn off "Enable this component" and "Publish in WSDL".  This is what took the experimentation.  At first, I thought I could just pick any 2.  Then I learned 2 of them didn't work.  I had to go through each of them one at a time and test it until I found the 2 that did work.

    J

    Joe and bruneves,

    What appears to you to be extra rules is simply an additional synthesized or clones QName of the service.  DataPower creates it in order to differentiate it from the original. 

  • JoeMorganNTST
    JoeMorganNTST
    427 Posts

    Re: Duplication of processing rules when a second FSH is added to a WSP

    ‏2013-06-25T17:36:10Z  

    Joe and bruneves,

    What appears to you to be extra rules is simply an additional synthesized or clones QName of the service.  DataPower creates it in order to differentiate it from the original. 

    So... how do you get it *not* to create (or how to expel) the ones that won't work?

    What good is it to create QName clones when what it is creating won't work anyway.  If you read my above, you can see I went through all 4 to find out which ones don't work, and verified they don't, in fact, work.  So, why is it creating them?