Extensibility and Integration

Unsupported SOAP Use Cases

Last updated
Save as PDF

Types of Unsupported Use Cases

Service Studio detects not only SOAP features that currently cannot be consumed in OutSystems, but also where the limitations are occurring, when this information can be determined.

Unsupported features/use cases fall into one of the following scenarios:

Feature/Use case unsupported due to outdated Platform Server version in the current environment: The Platform Server version of the environment that Service Studio is connected to does not support the feature/use case. Web service methods using the feature/use case will not be imported. The user will receive a message to contact the Administrator asking him to upgrade the Platform Server version.
Feature/Use case not fully supported in the whole infrastructure because at least one of its environments is outdated: Web service methods using the feature/use case will still be imported. The user will receive a message to contact the Administrator asking him to perform a factory upgrade, or else errors might occur when deploying to outdated environments.
Note: This unsupported use case is only identified when the infrastructure is using LifeTime.
Feature/Use case currently unsupported: The feature/use case is currently unsupported (in the current version of Service Studio). Web service methods using the unsupported feature/use case will not be imported.
Tip: Remember to check the latest Service Studio releases to see if the feature is already supported.

Unsupported Use Cases

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

In this case, you will not be able to import the Web Service straight away in Service Studio. However, in some cases you can perform small changes in the WSDL describing the service so that the identified limitations no longer apply, and you can effectively consume the Web Service in OutSystems.

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

SOAP arrays
Multidimensional arrays
Polymorphism
Abstract types
Recursion
List attribute in a single list attribute
Wildcards:
- Any
- Any attribute
Any types:
- AnyType
- AnySimpleType and AnyAtomicType

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 we provide general instructions to perform the necessary WSDL changes for working around some of the currently unsupported features/use cases.

SOAP Arrays

SOAP arrays are defined as having a type of SOAP-ENC:Array or a type derived from it. Arrays are represented as element values with no specific constraint on the name of the containing element.

The following example is a schema fragment with an array definition containing integer array members.

<element name="myFavoriteNumbers" type="SOAP-ENC:Array"/>

<myFavoriteNumbers SOAP-ENC:arrayType="xsd:int[2]">
    <number>3</number>
    <number>4</number>
</myFavoriteNumbers>

Use Case Workaround

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

Multidimensional Arrays

This is a particular case of SOAP Arrays.

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.

Polymorphism

Polymorphism occurs in a WSDL when you have type inheritance in the service definition, either by extension or restriction. This use case is identified when the base type is actually used in the remaining WSDL declarations.

Example:

<xsd:complexType name="Address">
    <xsd:sequence>
        <xsd:element minOccurs="0" maxOccurs="1" name="Street" type="xsd:string" />
        <xsd:element minOccurs="1" maxOccurs="1" name="Town" type="xsd:string" />
        <xsd:element minOccurs="1" maxOccurs="1" name="County" type="xsd:string" />
        <xsd:element minOccurs="1" maxOccurs="1" name="PostalCode" type="tns:PostalCode" />
    </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="InternationalAddress">
    <xsd:complexContent>
        <xsd:extension base="tns:Address">
            <xsd:sequence>
                <xsd:element minOccurs="1" maxOccurs="1" name="Country" type="xsd:string" />
            </xsd:sequence>
        </xsd:extension>
    </xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="RegisterAddress">
    <xsd:sequence>
        <xsd:element minOccurs="0" maxOccurs="1" name="SomeAddress" type="tns:Address" />
    </xsd:sequence>
</xsd:complexType>

In this example the InternationalAddress type is derived from Address. The polymorphism is identified in RegisterAddress: the element SomeAddress declares that it has type Address, but it could also be a derived type like InternationalAddress.

Note that if the element inside RegisterAddress were of type InternationalAddress, which has no derived types itself (i.e. it's a 'leaf' in the inheritance tree), no polymorphism use case would be identified in the RegisterAddress structure.

Use Case Workaround

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

If the structure where polymorphism occurs is used only in requests:
- Change the type of the problematic element (in the above example, SomeAddress) in the service definition to be of the specific subtype you want to send (for example InternationalAddress);
- If you want to send only the base type, remove all its derived types from the WSDL and import it;
- If you want to be able to send more than one specific type, alter the service definition and consume it once for each desired type.
If polymorphism is identified in the response and you know that only a specific type is used, or if you only need to access the information present in the base type, change the WSDL to use the base type instead of the derived types.

Abstract types

A definition present in a WSDL or included schema might be marked as abstract. This means that, to actually use it, you must use a derived (non-abstract) type. Thus, this use case is closely related with polymorphism.

In this example the AbstractContract type is declared as an abstract type:

<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

Check the workaround suggestions provided for the polymorphism use case. Additionally, you can try to remove the abstract indication 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. E.g. 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 will 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 is identified when there is 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 (i.e. with 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

The xsd:any construct can be used to specify that arbitrary elements, optionally from certain namespaces, can be present in a type.

Example:

<xsd:complexType name="ExtensibleDataPoint">
    <xsd:sequence>
        <xsd:element minOccurs="1" name="Name" type="xsd:string" />
        <xsd:element minOccurs="1" name="Active" type="xsd:boolean" />
        <xsd:element minOccurs="1" name="X" type="xsd:integer" />
        <xsd:element minOccurs="1" name="Y" type="xsd:integer" />
        <xsd:any maxOccurs="unbounded" namespace="##other"/>
    </xsd:sequence>
</xsd:complexType>

Use Case Workaround

If the type containing xsd:any is being sent in a request and you know what element(s) you need to send, replace it by the specific element(s).
Otherwise, there is no generic workaround available to overcome the unsupported use case.

Wildcards - Any Attribute

The xsd:anyAttribute construct can be used 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 will 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 (i.e. not composed) types. They can be used in a declaration as a placeholder; values of a specific type will be provided at runtime.

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 does not include types defined as unions (xsd:union) or lists (xsd:list) of other types.
— AnySimpleType and AnyAtomicType types are mapped as strings by WCF.

Use Case Workaround

Since all possible values of the above types can be represented as strings, a possible workaround is to change the element type to the built-in string type.