Skip to main content

 

拡張および連携

 

OutSystems

サポートされていないSOAPのユースケース

サポートされていないユースケースのタイプ

Service Studioは、OutSystemsで現在利用できないSOAPの機能だけではなく、制限されている部分(こうした情報が確認できる場合)も検出します。

サポートされていない機能/ユースケースは、以下のいずれかのシナリオに分類されます。

現在の環境のPlatform Serverのバージョンが古いためにサポートされていない機能/ユースケース
Service Studioが接続している環境のPlatform Serverのバージョンは、この機能/ユースケースをサポートしていません。この機能/ユースケースを使用するWebサービスメソッドは、インポートされません。ユーザーは、管理者に連絡してPlatform Serverのバージョンをアップグレードするように依頼してください、というメッセージを受信します。
環境のいずれかが古いためにインフラ全体で十分にサポートされていない機能/ユースケース
この機能/ユースケースを使用するWebサービスメソッドはインポートされます。ユーザーは、管理者に連絡して開発インフラをアップグレードするように依頼してください、というメッセージを受信します。または、古い環境にデプロイする際にエラーが発生する可能性があります。
注記: こうしたサポートされていないユースケースが識別されるのは、インフラでLifeTimeが使用されている場合のみです。
現在サポートされていない機能/ユースケース
この機能/ユースケースは(Service Studioの現在のバージョンで)現在サポートされていません。こうしたサポートされていない機能/ユースケースを使用するWebサービスメソッドはインポートされません
ヒント: Service Studioの最新リリースで、この機能がすでにサポートされているかどうかを必ず確認してください。

サポートされていないユースケース

Service StudioにSOAP Webサービスをインポートすると、開発環境で識別された現在サポートされていない機能/ユースケースに関するフィードバックをただちに受信します。

この場合、すぐにWebサービスをService Studioにインポートすることはできません。ただし、場合によっては、識別された制限が適用されないように、サービスを記述するWSDLを少し変更し、OutSystemsでWebサービスを効果的に利用できます。

現在サポートされていない機能/ユースケースのリストは以下のとおりです。

Service StudioとOutSystemsプラットフォームは、サポートするSOAP 1.2の機能とユースケースを増やし、WSDLの調整が必要となるサポート対象外のシナリオを減らすために、継続的に改善されています。
このページを定期的に閲覧して、現在の制限に関する最新のリストを必ず確認してください。

以下のシナリオでは、現在サポートされていない一部の機能/ユースケースに対処できるように、WSDLに対して必要な変更を行うための一般的な手順を説明します。

SOAP配列

SOAP配列は、SOAP-ENC:Array型またはその派生型を保持するものとして定義されます。配列は要素の値で表され、格納要素の名前に対する制約は特にありません。

以下の例は、整数の配列番号を含む配列定義のスキーマの一部です。

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

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

ユースケースの回避策

現在、こうしたサポートされていないユースケースに対処するために利用できる一般的な回避策はありません。

多次元配列

これは、SOAP配列の特殊なケースです。

例:

<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>

ユースケースの回避策

現在、こうしたサポートされていないユースケースに対処するために利用できる一般的な回避策はありません。

ポリモーフィズム

ポリモーフィズムがWSDLで発生するのは、extensionまたはrestrictionのいずれかによる型の継承がサービス定義にある場合です。このユースケースが識別されるのは、基本型が他のWSDL宣言で実際に使用されている場合です。

例:

<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>

この例では、InternationalAddress型がAddressから派生しています。ポリモーフィズムはRegisterAddressで識別されます。つまり、SomeAddress要素はAddress型を保持していると宣言しますが、この型はInternationalAddressのような派生型にすることもできます。

RegisterAddress内の要素がInternationalAddress型であり、それ自体は派生型を保持していない場合(つまり、継承という木の「葉」である場合)、ポリモーフィズムのユースケースはRegisterAddressストラクチャで識別されません。ご注意ください。

ユースケースの回避策

以下の一般的なガイドラインに従い、サポートされていないユースケースがプラットフォームで識別されないようにWSDLを適応させます。

  • ポリモーフィズムが発生するストラクチャがリクエストのみで使用される場合:
    • 問題のある要素(上記の例ではSomeAddress)の型を送信対象の特定のサブタイプ(例ではInternationalAddress)になるようにサービス定義で変更する。
    • 基本型のみを送信する場合は、その派生型をすべてWSDLから削除し、WSDLをインポートする。
    • 複数の特定の型を送信できるようにする場合は、サービス定義を変更し、それを目的の型ごとに1回利用する。
  • ポリモーフィズムがレスポンスで識別され、特定の型のみが使用されることを認識している場合、または基本型にある情報にのみアクセスする場合は、派生型ではなく基本型を使用するようにWSDLを変更する。

抽象型

WSDLまたはインクルードされたスキーマにある定義は、abstractとしてマークされる場合があります。つまり、この定義を実際に使用するには、派生(非抽象)型を使用する必要があります。したがって、このユースケースはポリモーフィズムと密接な関係にあります。

この例では、AbstractContract型が抽象型として宣言されています。

<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>

ユースケースの回避策

ポリモーフィズムのユースケースに関する回避策のサジェスチョンを確認してください。また、サービス定義からabstractの記述を削除することもできます。

再帰

再帰データ型は自らを参照するストラクチャです。再帰データ型の内部には、自身の型の別の要素への参照があります。

この参照は、直接的な参照または間接的な参照のいずれかです。たとえば、A型にはCを参照するB型のアトリビュートがあり、そしてCにはA型の要素が含まれています。

以下に示す再帰の例を確認してください。

<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>

ユースケースの回避策

以下の一般的なガイドラインに従い、サポートされていないユースケースがプラットフォームで識別されないようにWSDLを適応させます。

  • 送信または受信する必要があるレベルまで再帰ストラクチャを「アンロール」する。
    上記の例に従って、2つのレベルの再帰を処理する場合には以下の処理を実行します。

    1. Person型に含まれるContacts型をs0:Person2型になるように変更します。
    2. Personの定義のコピーを作成し、それをPerson2に名前を変更します。
    3. Person2の定義からContacts要素を削除します。

単一のリストアトリビュートに含まれるリストアトリビュート

このユースケースが識別されるのは、maxOccursが1より大きい単一の要素を含むcomplexTypeがあり、その型が、maxOccursが1より大きい別の型の要素として使用される場合です。

例:

<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>

この例では、OrganizationIntegration_ID要素はサポートされていません。この要素にはExternal_Integration_ID型(maxOccursが1より大きい単一の要素で構成される)が含まれ、この要素自体がリストであるためです。

ユースケースの回避策

単一のリスト要素を含む型に任意のダミー要素(minOccurs="0")を追加します。

先ほどの例に従って、External_Integration_IDに属する<xsd:sequence>要素内に以下の要素を追加します。

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

ワイルドカード - 任意

xsd:any構文を使用して、任意の要素を、オプションで特定の名前空間から、型に含めることができます。

例:

<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>

ユースケースの回避策

xsd:anyを含む型がリクエストで送信されており、送信する必要がある要素を認識している場合、それを特定の要素に置き換えます。
その他の場合、こうしたサポートされていないユースケースに対処するために利用できる一般的な回避策はありません。

ワイルドカード - 任意のアトリビュート

xsd:anyAttribute構文を使用して、任意のアトリビュートを、オプションで特定の名前空間から、型に含めることができます。

例:

<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>

ユースケースの回避策

xsd:anyAttributeを含む型がリクエストで送信されており、送信する必要があるアトリビュートを認識している場合、それでanyAttributeを置き換えることができます。
その他の場合、こうしたサポートされていないユースケースに対処するために利用できる一般的な回避策はありません。

任意の型 - AnyType

SOAPのサービス定義に含まれるすべての要素には型があります。一部の特殊なケースでは、その型がxsd:anyTypeである場合があります。これは特殊な型です。つまり、最も汎用的と考えられる型であり、この型から他のすべての型が派生します。これが要素に含まれる場合、その要素には考えられるあらゆる型が含まれる可能性があります。

例:

<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>

ユースケースの回避策

現在、こうしたサポートされていないユースケースに対処するために利用できる一般的な回避策はありません。

任意の型 - AnySimpleTypeおよびAnyAtomicType

xsd:anySimpleType型およびxsd:anyAtomicType型は、すべての単純型(複合型ではない)を表します。これらは、宣言でプレースホルダとして使用できます。特定の型の値は実行時に指定されます。

例:

 <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>

注記:
xsd:anyAtomicType型には、他の型の結合(xsd:union)またはリスト(xsd:list)として定義される型は含まれません。
AnySimpleType型またはAnyAtomicType型は、WCFによって文字列としてマッピングされます。

ユースケースの回避策

上記の型の考えられるすべての値は、文字列として表すことができるため、要素の型をビルトインの文字列型に変更するという回避策が考えられます。

  • Was this article helpful?