Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

wsdl generation output dataclass missing namespace #612

Closed
brunnels opened this issue Nov 10, 2021 · 13 comments · Fixed by #621
Closed

wsdl generation output dataclass missing namespace #612

brunnels opened this issue Nov 10, 2021 · 13 comments · Fixed by #621

Comments

@brunnels
Copy link

Here's the wsdl parts for loginResponse

    <wsdl:message name="loginResponse">
        <part name="Result" type="nas:Result"/>
    </wsdl:message>
    <wsdl:portType name="NetworkManagementApi">
        <wsdl:operation name="login">
            <wsdl:documentation></wsdl:documentation>
            <wsdl:input message="nas:loginRequest"/>
            <wsdl:output message="nas:loginResponse"/>
            <wsdl:fault name="error" message="nas:nasFaultMessage"/>
        </wsdl:operation>
    </wsdl:binding>

Results in

@dataclass
class LoginResponse:
    class Meta:
        name = "loginResponse"

    result: Optional[Result] = field(
        default=None,
        metadata={
            "name": "Result",
            "type": "Element",
            "namespace": "",
        }
    )

but should have "namespace": "http://microfocus.com/nas/2020/08" in order for parser to be able to parse response envelope.
tefra added a commit that referenced this issue Nov 14, 2021
@tefra
Maintain namespace for WSDL message part types
b2bd49f 
Notes:
I am not very sure about this but my rpc samples,
which are not many all pass.

Closes #612
@tefra tefra closed this as completed in a3331e4 Nov 14, 2021
@tefra
Copy link
Owner

tefra commented Nov 14, 2021

Are you sure about this one @brunnels? I trust soap ui and this is the sample response, it generates

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://microfocus.com/nas/2020/08">
 <soapenv:Header/>
 <soapenv:Body>
    <ns:loginResponse>
       <Result>
          <ns:Status>gero et</ns:Status>
       </Result>
    </ns:loginResponse>
 </soapenv:Body>
</soapenv:Envelope>

Which is spot on what xsdata generates

from issue.models import LoginResponse
from issue.models import Result
from issue.models import NetworkManagementApiLoginOutput
from xsdata.formats.dataclass.serializers import XmlSerializer

output = NetworkManagementApiLoginOutput()
output.body = NetworkManagementApiLoginOutput.Body()
output.body.login_response = LoginResponse()
output.body.login_response.result = Result()
output.body.login_response.result.status = "pame"
serializer = XmlSerializer()
serializer.config.pretty_print = True
print(serializer.render(output))

<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
  <soap-env:Body>
    <ns1:loginResponse xmlns:ns1="http://microfocus.com/nas/2020/08">
      <Result>
        <ns1:Status>pame</ns1:Status>
      </Result>
    </ns1:loginResponse>
  </soap-env:Body>
</soap-env:Envelope>

@tefra tefra reopened this Nov 14, 2021
@brunnels
Copy link
Author

Maybe I did not state the issue correctly?

On the main branch I generated the client in the mfna directory with xsdata -mll 120 --relative-imports -ss clusters -p mfna mfna-partial.wsdl

If I run these tests on the main branch, they fail.

If I run the same tests from the generate-fixes branch they pass.

Here are the changes I made to get them to pass.

With the namespace as an empty string in the LoginResponse dataclass metadata the test_success test fails with AssertionError: None is not an instance of <class 'mfna.result.Result'> because it is unable to parse the loginResponse.

@tefra
Copy link
Owner

tefra commented Nov 15, 2021

I hear you @brunnels and I understand what you are saying but soap ui is also generating the same models as xsdata

Screenshot from 2021-11-15 15-19-14

Either both xsdata and soapUI are doing it wrong or I am missing something, that's why I wanted a source with official request/responses

@brunnels
Copy link
Author

I wish MFNA had more docs but this is the actual response I'm receiving from our MFNA server.

<?xml version="1.0" encoding="utf-8" ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header/>
  <SOAP-ENV:Body>
    <nas:loginResponse xmlns:nas="http://microfocus.com/nas/2020/08">
      <nas:Result>
        <nas:Status>200 Logged in</nas:Status>
        <nas:Text>s229dc048-746e-471e-aaf8-66f7317d89d7</nas:Text>
      </nas:Result>
    </nas:loginResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

It looks like the thing that matters is that <Result></Result> will parse but the namespaced response from MFNA <nas:Result></nas:Result> will not.

I created 3 additional tests to verify the soapUI output parses, that the xsdata output parses, and that removing the namespace from Result of the MFNA response parses.

@brunnels
Copy link
Author

AFAIK, MFNA is using java AXIS or AXIS2 for their SOAP implementation so it's probable that other AXIS implementations will exhibit the same behavior.

@brunnels
Copy link
Author

I just double checked and the xsdata and soapUI generated responses fail the tests if the namespace is added to the dataclass.

I guess if MFNA incorrectly adds the namespace then I can subclass Client and modify the send method to convert the response bytes to string and remove the namespace from Result there before using parser.from_string.

@tefra
Copy link
Owner

tefra commented Nov 16, 2021

Is that wsdl an official copy?

    <wsdl:message name="activate_deviceResponse">
        <part name="Result" type="nas:Result"/> # the issue is here, it should be element and not type
    </wsdl:message>

it should have been

    <wsdl:message name="activate_deviceResponse">
        <part name="Result" element="nas:Result"/>
    </wsdl:message>

element means qualified, type means unqualified as far as I know, but in your case there an element and a complex type named Result. I am not really sure what the clients are supposed to do in this case... I 'll try to read once more the spec...

@brunnels
Copy link
Author

that's straight from the server after install so hasn't been modified. I will probably just use sed to fix the wsdl rather than modify the client.send method

@brunnels
Copy link
Author

I guess we can close this and point the blame at MFNA or axis.

@tefra
Copy link
Owner

tefra commented Nov 18, 2021

I want to try something @brunnels, I think I can add a validation during the processing to catch these cases and correct them

@tefra tefra reopened this Nov 18, 2021
@tefra tefra mentioned this issue Nov 21, 2021
Merged
@tefra
Copy link
Owner

tefra commented Nov 21, 2021

Hey @brunnels, I added the late validation for these cases that should take care of the issue, I found a source that said that even though message element exists the type can also point to an element or complex type.

Thanks for reporting and helping me troubleshoot this one!

@brunnels
Copy link
Author

brunnels commented Nov 21, 2021 via email

@brunnels
Copy link
Author

brunnels commented Nov 26, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

WSDL Message part type can also be a qualified element tefra/xsdata
2 participants
@brunnels @tefra