AEB-labs/node-soap-graphql

Support namespaced input/output args

Closed this issue · 1 comments

Example: https://www.uid-wse.admin.ch/V5.0/PublicServices.svc?WSDL

Excerpt of the operation search:

<xs:element name="Search">
    <xs:complexType>
        <xs:sequence>
            <xs:element xmlns:q7="http://www.uid.admin.ch/xmlns/uid-wse/5" minOccurs="0" maxOccurs="1" name="searchParameters" type="q7:uidEntityPublicSearchRequest"/>
            <xs:element xmlns:q8="http://www.uid.admin.ch/xmlns/uid-wse-shared/2" minOccurs="0" maxOccurs="1" name="config" type="q8:searchConfiguration"/>
        </xs:sequence>
    </xs:complexType>
</xs:element>

Both parameters come with a new namespace prefix definition, e. g. xmlns:q7="http://www.uid.admin.ch/xmlns/uid-wse/5" . This namespace is ignored by soap-graphql. Currenctly, soap-graphql uses soapClient#describe() to get infos about the provided services and operations with prefixed argument names. Unfortunately, the local prefix to namespace lookup infos are not included. Perhaps it would be besser to not use describe() but to get all needed stuff from soapClient.wsdl.definitions. Of course, that's a major breaking change. A quickfix could be something like

        let namespace: string = inputNamespace;
        if (typeof argContent == 'string') {
            const nsAlias = namespaceWithoutTypename(argContent)
            const lookupTypes = this.wsdl.services[operation.service().name()].ports[operation.port().name()].binding.methods[operation.name()].input.$lookupTypes;
            namespace = lookupTypes?.find(t => t.$type === argContent)?.$namespace || inputNamespace
        }

        const inputType: SoapType = this.resolveContentToSoapType(
            namespace,
            argContent,
            `arg '${argWsdlFieldName}' of operation '${operation.name()}'`,
        );

in NodeSoapResolver#createOperationArg(). Seems to work here, but is poorly tested.

Perhaps it would be besser to not use describe() but to get all needed stuff from soapClient.wsdl.definitions

Yes, very much agree! ATM it is not used because node-soaps wsdl was not properly implemented back then. Of course this is a major re-implementation.

Of course, that's a major breaking change.

Would it be breaking? The produced GraphQL schema should still be the same or do I forget something?

Seems to work here, but is poorly tested.

Do the other tests still work with the fix?