Community

Unsupported SOAP Use Cases

Last updated
Save as PDF

Collaborate with us

Edit this page on GitHub

While importing a SOAP Web Service in Service Studio, you get immediate feedback on any currently unsupported feature/use case identified by the development environment.

In this case, you can't import the Web Service immediately using Service Studio. Sometimes you can perform small changes in the WSDL describing the service so that the identified limitations no longer apply, and you can consume the Web Service in OutSystems.

The current list of unsupported features/use cases is the following:

Multidimensional arrays
Abstract types without implementation
Recursion
List attribute in a single list attribute
Wildcards:
- Any inside Choices
- Any attribute
Any types:
- AnyType
- AnySimpleType and AnyAtomicType
Attribute Groups
SOAP Action names with special characters
Repeated SOAP structure attribute names
Attributes in the same SOAP structure named "<attrib>" and "<attrib>Field"
RPC-style Web Services with the same 'name' property in message 'part' elements

Service Studio and the OutSystems platform are being continuously improved to support more SOAP 1.2 features and use cases and to have less unsupported scenarios that require WSDL adjustments.
Be sure to visit this page regularly for an updated list of the current limitations.

In the following sections you can find general instructions to perform the necessary WSDL changes for working around some currently unsupported features/use cases.

Multidimensional arrays

Although SOAP arrays are generally supported, the particular case of multidimensional arrays isn't currently supported in OutSystems.

Examples:

<xsd:complexType name="SummaryResultArray">
    <xsd:complexContent>
        <xsd:restriction base="soapenc:Array">
            <xsd:attribute ref="soapenc:arrayType" wsdl:arrayType="typens:SummaryResult[][]"/>
        </xsd:restriction>
    </xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="SummaryResultArray2">
    <xsd:complexContent>
        <xsd:restriction base="soapenc:Array">
            <xsd:attribute ref="soapenc:arrayType" wsdl:arrayType="typens:SummaryResult[,]"/>
        </xsd:restriction>
    </xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="SummaryResultArray3">
    <xsd:complexContent>
        <xsd:restriction base="soapenc:Array">
            <xsd:attribute ref="soapenc:arrayType" wsdl:arrayType="typens:SummaryResult[10,2]"/>
        </xsd:restriction>
    </xsd:complexContent>
</xsd:complexType>

Use case workaround

Currently there is no generic workaround available to overcome this unsupported use case.

Abstract types without implementation

WSDL files or included schemas might include abstract types. This means that, to actually use them, you must use a derived (non-abstract) type. When there is no non-abstract type derived from it, you can't use it.

In the following example AbstractContract is declared as abstract. If it's used as the type of an element but no type extends from it, this causes an error.

<xsd:complexType name="AbstractContract" abstract="true">
    <xsd:sequence>
        <xsd:element minOccurs="1" name="ContractNr" type="xsd:string" />
        <xsd:element minOccurs="1" name="StartDate" nillable="true" type="xsd:dateTime" />
        <xsd:element minOccurs="0" name="EndDate" nillable="true" type="xsd:dateTime" />
        <xsd:element minOccurs="2" maxOccurs="unbounded" name="Parties" type="tns:Party" />
    </xsd:sequence>
</xsd:complexType>

Use case workaround

There are two possible workarounds, according to your specific scenario:

If you need to send or receive the element (or attribute) that has the abstract type, you can try to remove the abstract indication from the type declaration.
If you don't use the abstract type and every occurrence refers to it as optional (for example, with minOccurs="0"), you can remove the usage of that type and the type itself from the service definition.

Recursion

Recursive data types are structures that reference themselves. Inside them there is a reference to another element of its own type.

This reference can be direct or indirect. For example, type A has an attribute of type B which references C which in turn contains an element of type A.

Check the following recursion example:

<xsd:complexType name="Person">
    <xsd:sequence>
        <xsd:element name="Firstname" type="xsd:string"/>
        <xsd:element name="Lastname" type="xsd:string"/>
        <xsd:element name="PhoneNumber" type="xsd:int"/>
        <xsd:element name="Address" type="s0:Address"/>
        <xsd:element name="Contacts" minOccurs="0" maxOccurs="unbounded" type="s0:Person">
    </xsd:sequence>
</xsd:complexType>

Use case workaround

Follow these generic guidelines to adapt the WSDL so that the unsupported use case is no longer identified by the platform:

"Unroll" the recursive structures up to the level you need to send or receive.
Following the example above, if you needed to handle two levels of recursion you would:
1. Change type of Contacts in the Person type to be of type s0:Person2.
2. Create a copy of the Person definition, renaming it to Person2.
3. Remove the Contacts element from Person2 definition.

List attribute in a single list attribute

This use case occurs when there's a complexType with a single element with maxOccurs > 1 and that type is used as an element inside another type with maxOccurs > 1.

Example:

<xsd:complexType name="Organization">
    <xsd:sequence>
        <xsd:element name="Integration_ID" type="tns:External_Integration_ID" minOccurs="0" maxOccurs="unbounded" />
        <xsd:element minOccurs="0" maxOccurs="1" name="Name" type="xsd:string" />
    </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="External_Integration_ID">
    <xsd:sequence>
        <xsd:element name="ID" type="tns:IDType" maxOccurs="unbounded" />
    </xsd:sequence>
</xsd:complexType>

In this example, the Integration_ID element in Organization is not supported, because it has External_Integration_ID type — composed of a single element with maxOccurs > 1 — and is itself a list.

Use case workaround

Add a dummy optional element (for example, using minOccurs="0") in the type containing the single list element.

Following the previous example, you would add the following element inside the <xsd:sequence> element belonging to External_Integration_ID:

<xsd:element name="dummy" type="xsd:string" minOccurs="0" />

Wildcards - any inside choices

You can use the xsd:any construct to specify that an arbitrary element (optionally from certain namespaces) can be present in a type.
Although this feature is generally supported in the platform, there is a specific situation that's not supported yet, when the xsd:any element is inside a Choice definition. In this case, Service Studio doesn't import the structure.

Example:

<xsd:element name="RelatedPerson">
    <xsd:complexType>
        <xsd:choice minOccurs="0" maxOccurs="unbounded">
            <xsd:element name="Employee" type="s0:Employee"/>
            <xsd:element name="Customer" type="s0:Customer"/>
            <xsd:any namespace="##other"/>
        </xsd:choice>
    </xsd:complexType>
</xsd:element>

Use case workaround

Currently there is no generic workaround available to overcome this unsupported use case.

Although it's possible to modify the WSDL by moving the xsd:any element outside the Choice definition and making it optional (for example, adding a minOccurs="0" attribute), the obtained result isn't strictly equal to the original definition.
Additionally, you should only perform this change for types included in requests.

Wildcards - any attribute

You can use the xsd:anyAttribute construct to specify that an arbitrary attribute, optionally from certain namespaces, can be present in a type.

Example:

<xsd:complexType name="LocationWithMetadata">
    <xsd:sequence>
        <xsd:element minOccurs="1" maxOccurs="1" name="name" type="xsd:string" />
        <xsd:element minOccurs="1" maxOccurs="1" name="coordinates" type="tns:CoordsGPS" />
    </xsd:sequence>
    <xsd:anyAttribute namespace="##targetNamespace"/>
</xsd:complexType>

Use case workaround

If the type that contains xsd:anyAttribute is being sent in a request and you know what attribute you need to send, you can replace anyAttribute with it.
Otherwise, there is no generic workaround available to overcome the unsupported use case.

Any types - AnyType

Every element present in a SOAP service definition has a type. In some special cases that type might be xsd:anyType. This is a special type: it's the most generic possible type and all other types derive from it. Having it in a element means that the element can have any possible type.

Example:

<xsd:complexType name="GenericInformation">
    <xsd:sequence>
        <xsd:element minOccurs="1" name="Name" type="xsd:string" />
        <xsd:element minOccurs="1" name="Type" type="tns:InformationKind" />
        <xsd:element minOccurs="1" name="IsActive" type="xsd:boolean" />
        <xsd:element name="SpecificInfo" type="xsd:anyType" />
    </xsd:sequence>
</xsd:complexType>

Use case workaround

Currently there is no generic workaround available to overcome this unsupported use case.

Any types - AnySimpleType and AnyAtomicType

The xsd:anySimpleType and xsd:anyAtomicType types represent all simple (not composed) types. You can use them in a declaration as a placeholder. At runtime the placeholder is replaced with a value of a specific type.

Example:

<xsd:complexType name="ThirdParty">
    <xsd:attribute name="partyId" type="xsd:string" use="required"/>
    <xsd:attribute name="name" type="xsd:string" use="required"/>
    <xsd:attribute name="description" type="xsd:string"/>
    <xsd:attribute name="tags" type="xsd:anySimpleType"/>
    <xsd:attribute name="classifier" type="xsd:anyAtomicType"/>
</xsd:complexType>

Notes:
— The xsd:anyAtomicType type doesn't include types defined as unions (xsd:union) or lists (xsd:list) of other types.
— The Windows Communication Foundation (WCF) framework maps the AnySimpleType and AnyAtomicType types as strings.

Use case workaround

Since you can use strings to represent all possible values of the above types, a possible workaround is to change the element type to the built-in string type.

Attribute groups

attributeGroup elements group a set of attribute declarations that you can later incorporate as a group in complex type definitions.

Example:

 <xsd:complexType name="PersonInfo">
    <xsd:sequence>
        <xsd:element name="Forename" type="xsd:string"/>
        <xsd:element name="Surname" type="xsd:string"/>
        <xsd:element name="Dob" type="xsd:date"/>
   </xsd:sequence>
   <xsd:attributeGroup ref="ms:DateOfBirthGroup"/>
</xsd:complexType>

<xsd:attributeGroup name="DateOfBirthGroup">
    <xsd:attribute name="Day" type="xsd:string"/>
    <xsd:attribute name="Month" type="xsd:string"/>
    <xsd:attribute name="Year" type="xsd:integer"/>
</xsd:attributeGroup>

Use case workaround

Since an attribute group is just a container of attributes that you can reference in complex types, a possible solution is to put all the attributes from the attribute group directly in the complex types that use it.

SOAP Action names with special characters

It's not currently possible to create Actions from some operations defined in a WSDL that contain special characters like "-".

In the example below, the GetExtrasAndAdd-Ons operation is not supported and Service Studio doesn't import it.

<wsdl:portType name="AccountInformationSoap">
    <wsdl:operation name="GetExtrasAndAdd-Ons">
        <wsdl:input message="tns:MethodGetExtrasSoapIn"/>
        <wsdl:output message="tns:MethodGetExtrasSoapOut"/>
    </wsdl:operation>
</wsdl:portType>
<wsdl:binding name="AccountInformationSoap" type="tns:AccountInformationSoap">
    <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="GetExtrasAndAdd-Ons">
        <soap:operation soapAction="http://example.com/AccountInformation/GetExtrasAndAddOns" style="document"/>
        <wsdl:input>
            <soap:body use="literal"/>
        </wsdl:input>
        <wsdl:output>
            <soap:body use="literal"/>
        </wsdl:output>
    </wsdl:operation>
</wsdl:binding>

Use case workaround

None, for the operations whose name contains special characters.
To import other operations from a WSDL, save the WSDL locally and edit it to remove any operations that cause this issue.

Repeated SOAP structure attribute names

A SOAP structure can have more than one element with the same name in non-consecutive positions (lists), although this is a rare case.

Consider the following example, where the AccountInformationType type contains two attributes named BranchId.

<xsd:complexType name="AccountInformationType">
    <xsd:sequence>
        <xsd:element name="FirstName" type="xsd:string"/>
        <xsd:element name="LastName" type="xsd:string"/>
        <xsd:element name="BranchId" type="xsd:string"/>
        <xsd:element name="Email" type="xsd:string"/>
        <xsd:element name="Phone" type="xsd:string"/>
        <xsd:element name="BranchId" type="tns:BranchId"/>
    </xsd:sequence>
</xsd:complexType>

Use case workaround

If you only need to send or receive one of the elements with the repeated name, edit the type definition in a local copy of the WSDL and delete the other occurrences.

Attributes in the same SOAP structure named "<attrib>" and "<attrib>Field"

It's not currently possible to have two attributes in the same SOAP structure that have the same name except for a "Field" suffix (case sensitive).

Consider the following example, where the ExampleType type contains two attributes, one named order and another named orderField.

<xsd:complexType name="ExampleType">
    <xsd:sequence>
        <xsd:element name="order" type="xsd:string"/>
        <xsd:element name="orderField" type="xsd:string"/>
    </xsd:sequence>
</xsd:complexType>

Use case workaround

Edit the type definition in a local copy of the WSDL and change the name of the <attrib>Field attribute.

RPC-style Web Services with the same 'name' property in message 'part' elements

Web Services defined in Remote Procedure Call (RPC) style are services where the WSDL representation of messages exchanged for an operation contains parameters as if it were a remote procedure call.

Due to Windows Communication Foundation (WCF) limitations, OutSystems doesn't support RPC-style Web Services that use the following pattern in their message definitions: parts with the same name property, but with distinct types.

Example:

<message name="loginIn">
    <part name="request" type="tns:LoginReq"/>
</message>
<message name="logoutIn">
    <part name="request" type="tns:LogoutReq"/>
</message>

In the example above, the loginIn and logoutIn messages both define a part named request with distinct types: tns:LoginReq and tns:LogoutReq, respectively.

Use case workaround

Currently there is no generic workaround available to overcome this unsupported use case.

Training

Documentation