[Question] How to handle "complex" types extending primitives?

[pfumagalli]

We have a supplier's WSDL containing something like this:

  <xs:complexType name="StrasseType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="kurz" type="xs:string"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

Here, node-soap will either return a string (in case there's no kurz attribute) or something like:

{
  $value: "the string value",
  attributes: {
    kurz: "the value of the kurz attribute"
  }
}

Currently it seems to me that wsdl-tsclient emits this as a simple string, for example:

  <xs:complexType name="HausanschriftType">
    <xs:sequence>
      <xs:element form="qualified" minOccurs="0" name="Strasse" type="tns:StrasseType"/>
      <!-- ... more stuff ... -->
    </xs:sequence>
  </xs:complexType>

generates:

export interface Hausanschrift {
    /** xs:string */
    Strasse?: string;
    // ... more stuff ...
}

What am I doing wrong? Any idea?

[pfumagalli]

Flagging @esivkov to this one!

[dderevjanik]

Hi,

wsdl-tsclient only inherits parsed types from node-soap and then generates client.... Some complex types are too "complex" :/ . Right now, there's no easy solution for this. I think it should be handled first by node-soap and then I can implement it in wsdl-tsclient

[Hufschmidt]

You can pass a customDeserializer into node-soap's createClientAsync method, maybe wsdl-tsclient could use this?

We do this for example to generate Date-Objects from a WSDL object containing custom Date & DateTime types, but those types are currently detected as simple strings by wsdl-tsclient.

On the reverse-direction you can pass custom-types as arguments into WSDL methods generated by node-soap as long as they provide a string $value property. There is currently no way to handle this mapping with wsdl-tsclient as well.

---

Example File: OrgUnitService.wsdl.txt

With example customDeserializer:

const client = soap.createClientAsync('example.wsdl', {
  customDeserializer:  {
    date: (text: string, xmlContext: XMLContext): SoapDate | string | undefined => {
      if (xmlContext.nil) { return undefined; }
      if (text.length > 0) { return new SoapDate(text); }
      return text;
    },
  }
});

And example custom type:

import moment from 'moment';

class SoapDate {
  protected $value: string;
  protected data: moment.Moment;

  public constructor(input: string | moment.Moment) {
    if (moment.isMoment(input)) {
      this.data = moment.utc(input, 'YYYY-MM-DD');
    } else {
     this.data = input;
    }
    this.$value = this.data.format('YYYY-MM-DD');
  }

This custom-type can be used as any string-type argument of a Soap-Method due to its $value property and with the customDeserializer it is returned by any Soap-Method that returns an argument of type date.

In my customized type-definitions I can ensure that Date-Type input and output values are pinned to the corresponding SoapDate-type, reducing any ambiguity when reading results or piping in arguments.

[Hufschmidt]

Addendum: This not only affects complex-types but (understandably) any customDeserializer type.

An option to pass in a custom type mapping from WSDL TypeDefinition to TypeScript type would be nice or as an alternative an option to preserve the WSDL TypeDefinition name here instead of pinning it to string:

https://github.com/dderevjanik/wsdl-tsclient/blob/60d1eda3a1a5cacf5a42a7e4bb32259ccea0622f/src/parser.ts#L158

https://github.com/dderevjanik/wsdl-tsclient/blob/60d1eda3a1a5cacf5a42a7e4bb32259ccea0622f/src/parser.ts#L98

For example replace "string" with the type value. This would preserve this information and allow for text-level post-processing and would be an easy workaround.