API Management の変換ポリシー

この記事では、API 要求または応答の変換に使用される API Management ポリシーのリファレンスを提供します。

ポリシーの詳細:

変換ポリシー

JSON から XML への変換

json-to-xml ポリシーは、要求本文または応答本文を JSON から XML に変換します。

ヒント

API Management ポリシーを設定または編集する方法について説明します。

ポリシー ステートメント

<json-to-xml apply="always | content-type-json" consider-accept-header="true | false" parse-date="true | false"/>

<policies>
    <inbound>
        <base />
    </inbound>
    <outbound>
        <base />
        <json-to-xml apply="always" consider-accept-header="false" parse-date="false"/>
    </outbound>
</policies>

要素

名前 説明 必須
json-to-xml ルート要素。 はい

属性

名前 説明 必須 Default
apply この属性の値は次のいずれかに設定する必要があります。

- always - 常に変換を適用します。
- content-type-json - 応答の Content-Type ヘッダーに JSON の存在が示されている場合のみ変換を行います。
はい 該当なし
consider-accept-header この属性の値は次のいずれかに設定する必要があります。

- true - 要求の Accept ヘッダーで XML が要求されている場合に変換を適用します。
- false - 常に変換を適用します。
いいえ true
parse-date false に設定すると、変換中、日付値がコピーされます。 いいえ true

使用法

このポリシーは、次のポリシー セクションスコープで使用できます。

  • ポリシー セクション: inbound、outbound、on-error

  • ポリシー スコープ: すべてのスコープ

XML から JSON への変換

xml-to-json ポリシーは、要求本文または応答方文を XML から JSON に変換します。 このポリシーを使用すると、XML のみのバックエンド Web サービスに基づく API を最新化することができます。

ヒント

API Management ポリシーを設定または編集する方法について説明します。

ポリシー ステートメント

<xml-to-json kind="javascript-friendly | direct" apply="always | content-type-xml" consider-accept-header="true | false"/>

<policies>
    <inbound>
        <base />
    </inbound>
    <outbound>
        <base />
        <xml-to-json kind="direct" apply="always" consider-accept-header="false" />
    </outbound>
</policies>

要素

名前 説明 必須
xml-to-json ルート要素。 はい

属性

名前 説明 必須 Default
kind この属性の値は次のいずれかに設定する必要があります。

- javascript-friendly - 変換後の JSON が JavaScript 開発者にとってわかりやすい形になります。
- direct - 変換後の JSON に元の XML ドキュメントの構造が反映されます。
はい 該当なし
apply この属性の値は次のいずれかに設定する必要があります。

- always - 常に変換します。
- content-type-xml - 応答の Content-Type ヘッダーに XML の存在が示されている場合のみ変換を行います。
はい 該当なし
consider-accept-header この属性の値は次のいずれかに設定する必要があります。

- true - 要求の Accept ヘッダーで JSON が要求されている場合に変換を適用します。
- false - 常に変換を適用します。
いいえ true

使用法

このポリシーは、次のポリシー セクションスコープで使用できます。

  • ポリシー セクション: inbound、outbound、on-error

  • ポリシー スコープ: すべてのスコープ

本文内の文字列の検索および置換

find-and-replace ポリシーは、要求または応答内の文字部分列を検索し、別の部分文字列で置き換えます。

ヒント

API Management ポリシーを設定または編集する方法について説明します。

ポリシー ステートメント

<find-and-replace from="what to replace" to="replacement" />

<find-and-replace from="notebook" to="laptop" />

要素

名前 説明 必須
find-and-replace ルート要素。 はい

属性

名前 説明 必須 Default
from 検索する文字列。 はい 該当なし
to 置換する文字列。 長さゼロの置換文字列を指定すると、検索文字列を削除できます。 はい 該当なし

使用法

このポリシーは、次のポリシー セクションスコープで使用できます。

  • ポリシー セクション: inbound、outbound、backend、on-error

  • ポリシー スコープ: すべてのスコープ

コンテンツ内の URL のマスク

redirect-content-urls ポリシーは、応答本文内のリンクを、ゲートウェイを経由して同じリンクをポイントするように書き換えます (マスクします)。 応答本文のリンクをゲートウェイにポイントさせる場合は outbound セクションで使用します。 反対の効果を生じさせる場合は inbound セクションで使用します。

Note

このポリシーでは、Location ヘッダーなどのヘッダー値は変更されません。 ヘッダーの値を変更するには、set-header ポリシーを使用します。

ヒント

API Management ポリシーを設定または編集する方法について説明します。

ポリシー ステートメント

<redirect-content-urls />

<redirect-content-urls />

要素

名前 説明 必須
redirect-content-urls ルート要素。 はい

使用法

このポリシーは、次のポリシー セクションスコープで使用できます。

  • ポリシー セクション: inbound、outbound

  • ポリシー スコープ: すべてのスコープ

バックエンド サービスの設定

set-backend-service ポリシーを使用すると、該当する操作の API 設定で指定されているものとは異なるバックエンドに受信要求をリダイレクトできます。 このポリシーでは、受信要求のバックエンド サービスのベース URL をこのポリシーで指定した URL に変更します。

ヒント

API Management ポリシーを設定または編集する方法について説明します。

ポリシー ステートメント

<set-backend-service base-url="base URL of the backend service" />

or

<set-backend-service backend-id="identifier of the backend entity specifying base URL of the backend service" />

Note

バックエンド エンティティは、Azure portal、管理 API、および PowerShell を使用して管理できます。

<policies>
    <inbound>
        <choose>
            <when condition="@(context.Request.Url.Query.GetValueOrDefault("version") == "2013-05")">
                <set-backend-service base-url="http://contoso.com/api/8.2/" />
            </when>
            <when condition="@(context.Request.Url.Query.GetValueOrDefault("version") == "2014-03")">
                <set-backend-service base-url="http://contoso.com/api/9.1/" />
            </when>
        </choose>
        <base />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>

この例では、バックエンド サービスの設定ポリシーにより、クエリ文字列に渡されるバージョン値に基づいて、API で指定されているものとは異なるバックエンド サービスに要求をルーティングしています。

まず、API 設定からバックエンド サービスのベース URL が読み取られます。 これにより、要求 URL https://contoso.azure-api.net/api/partners/15?version=2013-05&subscription-key=abcdefhttp://contoso.com/api/10.4/partners/15?version=2013-05&subscription-key=abcdef になります。http://contoso.com/api/10.4/ は API 設定で指定されているバックエンド サービスの URL です。

choose> ポリシー ステートメントを適用した場合、バックエンド サービスのベース URL は、要求クエリの version パラメーターの値に応じて http://contoso.com/api/8.2 または http://contoso.com/api/9.1 のどちらかに変更されます。 たとえば、このパラメーターの値が "2013-15" の場合、最終的な要求 URL は http://contoso.com/api/8.2/partners/15?version=2013-05&subscription-key=abcdefになります。

さらに要求を変換する必要がある場合には、別の変換ポリシーを使用できます。 たとえば、要求をバージョンごとのバックエンドにルーティングしたので version クエリ パラメーターを削除するには、クエリ文字列パラメーターの設定ポリシーを使用して、余計になった version 属性を削除できます。

<policies>
    <inbound>
        <set-backend-service backend-id="my-sf-service" sf-partition-key="@(context.Request.Url.Query.GetValueOrDefault("userId","")" sf-replica-type="primary" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>

この例では、ポリシーは、パーティション キーとして userId クエリ文字列を使い、パーティションのプライマリ レプリカを使って、サービス ファブリック バックエンドに要求をルーティングします。

要素

名前 説明 必須
set-backend-service ルート要素。 はい

属性

名前 説明 必須 Default
base-url バックエンド サービスの新しいベース URL。 base-url または backend-id のいずれかが存在しなければなりません。 該当なし
backend-id ルーティング先のバックエンドの識別子。 (バックエンド エンティティは、Azure portalAPI、および PowerShell を使用して管理されます)。 base-url または backend-id のいずれかが存在しなければなりません。 該当なし
sf-partition-key バックエンドが Service Fabric サービスで、'backend-id' を使って指定されている場合にのみ適用されます。 名前解決サービスからの特定のパーティションを解決するために使います。 いいえ 該当なし
sf-replica-type バックエンドが Service Fabric サービスで、'backend-id' を使って指定されている場合にのみ適用されます。 要求をパーティションのプライマリ レプリカとセカンダリ レプリカのどちらに送信する必要があるかを制御します。 いいえ 該当なし
sf-resolve-condition バックエンドが Service Fabric サービスの場合にのみ適用されます。 Service Fabric バックエンドへの呼び出しを新しい解決で繰り返す必要があるかどうかを識別する条件です。 いいえ 該当なし
sf-service-instance-name バックエンドが Service Fabric サービスの場合にのみ適用されます。 実行時にサービス インスタンスを変更できます。 いいえ 該当なし
sf-listener-name バックエンドが Service Fabric サービスで、"backend-id" を使って指定されている場合にのみ適用されます。 Service Fabric Reliable Services では、サービス内に複数のリスナーを作成できます。 この属性は、バックエンドのリライアブル サービスに複数のリスナーがある場合に、特定のリスナーを選択するために使用されます。 この属性が指定されていない場合、API Management によって名前のないリスナーの使用が試行されます。 リスナーが 1 つのみのリライアブル サービスでは、通常、リスナーに名前がありません。 いいえ 該当なし

使用法

このポリシーは、次のポリシー セクションスコープで使用できます。

  • ポリシー セクション: inbound、backend

  • ポリシー スコープ: すべてのスコープ

本文の設定

着信要求と発信要求のメッセージ本文を設定するには、set-body ポリシーを使用します。 メッセージ本文へのアクセスには、ポリシーを inbound セクションと outbound セクションのどちらに記載するかに応じて context.Request.Body プロパティまたは context.Response.Body を使用します。

重要

既定では、context.Request.Body または context.Response.Body を使用してメッセージ本文にアクセスした場合元のメッセージ本文は失われるため、この本文を式で返して設定する必要があります。 本文の内容を保持するには、メッセージへのアクセス時に preserveContent パラメーターを true に設定します。 preserveContenttrue に設定している場合に式から別の本文が返されると、返された本文が使用されます。

set-body ポリシーを使用する際は次の考慮事項に注意してください。

  • set-body ポリシーを使用して新しい本文はまたは更新した本文を返す場合、新しい本文の内容を明示的に指定しているため、preserveContenttrue に設定する必要はありません。
    • 受信パイプラインには応答が存在しないため、このパイプラインで応答の内容を保持しても意味がありません。
    • 送信パイプラインで要求の内容を保持しても、要求はこの時点で既にバックエンドに送信されているため意味がありません。
    • 受信パイプラインの GET 内など、メッセージ本文がない場合にこのポリシーを使用すると、例外がスローされます。

詳細については、context.Request.Bodyに関する表の context.Request.Bodycontext.Response.BodyIMessage の各セクションを参照してください。

ヒント

API Management ポリシーを設定または編集する方法について説明します。

ポリシー ステートメント

<set-body>new body value as text</set-body>

リテラル テキストの例

<set-body>Hello world!</set-body>

文字列である本文にアクセスする例。 後からパイプラインでアクセスできるように、元の要求本文を保持していることに注意してください。

<set-body>
@{ 
    string inBody = context.Request.Body.As<string>(preserveContent: true); 
    if (inBody[0] =='c') { 
        inBody[0] = 'm'; 
    } 
    return inBody; 
}
</set-body>

JObject である本文にアクセスする例。 元の要求本文を予約していないため、後でパイプラインでそこにアクセスすると例外が発生することに注意してください。

<set-body> 
@{ 
    JObject inBody = context.Request.Body.As<JObject>(); 
    if (inBody.attribute == <tag>) { 
        inBody[0] = 'm'; 
    } 
    return inBody.ToString(); 
} 
</set-body>

製品に基づいて応答をフィルター処理する

この例は、Starter 製品を使用しているときに、バックエンド サービスから受信された応答からデータ要素を削除することによってコンテンツのフィルター処理を実行する方法を示しています。 このバックエンド応答の例には、OpenWeather One Call API に似たルート レベルのプロパティが含まれています。

<!-- Copy this snippet into the outbound section to remove a number of data elements from the response received from the backend service based on the name of the product -->
<choose>
  <when condition="@(context.Response.StatusCode == 200 && context.Product.Name.Equals("Starter"))">
    <set-body>@{
        var response = context.Response.Body.As<JObject>();
        foreach (var key in new [] {"current", "minutely", "hourly", "daily", "alerts"}) {
          response.Property (key).Remove ();
        }
        return response.ToString();
      }
    </set-body>
  </when>
</choose>

本文の設定がある Liquid テンプレートの使用

set-body ポリシーは、set-body テンプレート作成言語を使用して要求または応答の本文を変換するように構成できます。 これは、メッセージの形式を完全に再構築する必要がある場合にとても効果的な場合があります。

重要

set-body ポリシーで使用される Liquid の実装は、「C# mode」で構成されます。 これは、フィルター処理などを実行する際に特に重要です。 たとえば、日付フィルターを使用するには、次のような Pascal 形式と C# date 形式を使用する必要があります。

{{body.foo.startDateTime| Date:"yyyyMMddTHH:mm:ssZ"}}

重要

Liquid テンプレートを使用して XML 本文に正しくバインドするには、set-header ポリシーを使用して、Content-Type を application/xml、text/xml (または任意の種類の終了 +xml) に設定します。JSON 本文の場合は、application/json、text/json (または任意の種類の終了 +json) にする必要があります。

Liquid テンプレートを使用して JSON を SOAP に変換する

<set-body template="liquid">
    <soap:Envelope xmlns="http://tempuri.org/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <soap:Body>
            <GetOpenOrders>
                <cust>{{body.getOpenOrders.cust}}</cust>
            </GetOpenOrders>
        </soap:Body>
    </soap:Envelope>
</set-body>

Liquid テンプレートを使用した JSON の変換

{
"order": {
    "id": "{{body.customer.purchase.identifier}}",
    "summary": "{{body.customer.purchase.orderShortDesc}}"
    }
}

要素

名前 説明 必須
set-body ルート要素。 本文のテキストか、または本文を返す式を記載します。 はい

Properties

名前 説明 必須 Default
template 本文の設定ポリシーが実行されるテンプレート作成モードの変更に使用されます。 現在サポートされている値:

- liquid - 本文の設定ポリシーでは、liquid テンプレート作成エンジンが使用されます
いいえ

要求と応答に関する情報にアクセスするために、Liquid テンプレートは次のプロパティでコンテキスト オブジェクトにバインドできます。

context.
    Request.
        Url
        Method
        OriginalMethod
        OriginalUrl
        IpAddress
        MatchedParameters
        HasBody
        ClientCertificates
        Headers

    Response.
        StatusCode
        Method
        Headers
Url.
    Scheme
    Host
    Port
    Path
    Query
    QueryString
    ToUri
    ToString

OriginalUrl.
    Scheme
    Host
    Port
    Path
    Query
    QueryString
    ToUri
    ToString

使用法

このポリシーは、次のポリシー セクションスコープで使用できます。

  • ポリシー セクション: inbound、outbound、backend

  • ポリシー スコープ: すべてのスコープ

HTTP ヘッダーの設定

set-header ポリシーは、既存の応答ヘッダーまたは要求ヘッダーに値を割り当てるか、新しい応答ヘッダーまたは要求ヘッダーを追加します。

ポリシーを使用して、HTTP ヘッダーの一覧を HTTP メッセージに挿入します。 受信パイプラインに配置した場合、このポリシーは、ターゲット サービスに渡される要求の HTTP ヘッダーを設定します。 送信パイプラインに配置した場合、このポリシーは、ゲートウェイのクライアントに送信される応答の HTTP ヘッダーを設定します。

ヒント

このポリシーの構成に役立つ、ガイド付きのフォーム ベース エディターがポータルに用意されています。 API Management ポリシーを設定または編集する方法について説明します。

ポリシー ステートメント

<set-header name="header name" exists-action="override | skip | append | delete">
    <value>value</value> <!--for multiple headers with the same name add additional value elements-->
</set-header>

例 - ヘッダーの追加、既存のオーバーライド

<set-header name="some header name" exists-action="override">
    <value>20</value>
</set-header>

例 - ヘッダーの削除

 <set-header name="some header name" exists-action="delete" />

バックエンド サービスにコンテキスト情報を転送する

次の例では、API レベルでポリシーを適用して、バックエンド サービスにコンテキスト情報を提供する方法を示します。

<!-- Copy this snippet into the inbound element to forward some context information, user id and the region the gateway is hosted in, to the backend service for logging or evaluation -->
<set-header name="x-request-context-data" exists-action="override">
  <value>@(context.User.Id)</value>
  <value>@(context.Deployment.Region)</value>
</set-header>

詳細については、ポリシー式およびコンテキスト変数に関する各ページを参照してください。

Note

ヘッダーの複数の値が次のように CSV 文字列に連結されます。headerName: value1,value2,value3

例外として、次のような値を持つ標準化されたヘッダーがあります。

  • コンマを含む可能性がある (User-AgentWWW-AuthenticateProxy-Authenticate)。
  • 日付を含む可能性がある (CookieSet-CookieWarning)。
  • 日付を含む (DateExpiresIf-Modified-SinceIf-Unmodified-SinceLast-ModifiedRetry-After)。

これらの例外の場合は、複数のヘッダー値が 1 つの文字列に連結されることはなく、次のように個別のヘッダーとして渡されます。User-Agent: value1User-Agent: value2User-Agent: value3

要素

名前 説明 必須
set-header ルート要素。 はい
value 設定するヘッダーの値を指定します。 同じ名前のヘッダーが複数ある場合は、value 要素をさらに追加します。 いいえ

Properties

名前 説明 必須 Default
exists-action 対象のヘッダーが既に指定されている場合の操作を指定します。 この属性の値は次のいずれかに設定する必要があります。

- override - 既存のヘッダーの値を置き換えます。
- skip - 既存のヘッダーの値を置き換えません。
- append - 既存のヘッダーの値に値を追加します。
- delete - 要求からヘッダーを削除します。

override に設定した場合、同じ名前の複数のエントリを記載すると、すべてのエントリに従ってヘッダーが設定されます (複数回記載されます)。結果に設定されるのは記載した値のみです。
いいえ override
name 設定するヘッダーの名前を指定します。 はい 該当なし

使用法

このポリシーは、次のポリシー セクションスコープで使用できます。

  • ポリシー セクション: inbound、outbound、backend、on-error

  • ポリシー スコープ: すべてのスコープ

クエリ文字列パラメーターの設定

set-query-parameter ポリシーは、要求クエリ文字列パラメーターの追加、値の置換、または削除を行います。 このポリシーを使用すると、オプションであるかまたは要求内に存在しない、バックエンド サービスで必要とされるクエリ パラメーターを渡すことができます。

ヒント

このポリシーの構成に役立つ、ガイド付きのフォーム ベース エディターがポータルに用意されています。 API Management ポリシーを設定または編集する方法について説明します。

ポリシー ステートメント

<set-query-parameter name="param name" exists-action="override | skip | append | delete">
    <value>value</value> <!--for multiple parameters with the same name add additional value elements-->
</set-query-parameter>


<set-query-parameter name="api-key" exists-action="skip">
  <value>12345678901</value>
</set-query-parameter>

バックエンド サービスにコンテキスト情報を転送する

次の例では、API レベルでポリシーを適用して、バックエンド サービスにコンテキスト情報を提供する方法を示します。

<!-- Copy this snippet into the inbound element to forward a piece of context, product name in this example, to the backend service for logging or evaluation -->
<set-query-parameter name="x-product-name" exists-action="override">
  <value>@(context.Product.Name)</value>
</set-query-parameter>

詳細については、ポリシー式およびコンテキスト変数に関する各ページを参照してください。

要素

名前 説明 必須
set-query-parameter ルート要素。 はい
value 設定するクエリ パラメーターの値を指定します。 同じ名前のクエリ パラメーターが複数ある場合は、value 要素をさらに追加します。 はい

Properties

名前 説明 必須 Default
exists-action 対象のクエリ パラメーターが既に指定されている場合の操作を指定します。 この属性の値は次のいずれかに設定する必要があります。

- override - 既存のパラメーターの値を置き換えます。
- skip - 既存のクエリ パラメーターの値を置き換えません。
- append - 既存のクエリ パラメーターの値に値を追加します。
- delete - 要求からクエリ パラメーターを削除します。

override に設定した場合、同じ名前の複数のエントリを記載すると、すべてのエントリに従ってクエリ パラメーターが設定されます (複数回記載されます)。結果に設定されるのは記載した値のみです。
いいえ override
name 設定するクエリ パラメーターの名前を指定します。 はい 該当なし

使用法

このポリシーは、次のポリシー セクションスコープで使用できます。

  • ポリシー セクション: inbound、backend

  • ポリシー スコープ: すべてのスコープ

URL の書き換え

rewrite-uri ポリシーは、次の例に示すように、要求 URL をパブリックな形式から Web サービスで想定されている形式に変換します。

  • パブリック URL - http://api.example.com/storenumber/ordernumber

  • 要求 URL - http://api.example.com/v2/US/hardware/storenumber&ordernumber?City&State

    このポリシーは、人間やブラウザーにとって使いやすい URL を Web サービスで求められる URL 形式に変換する必要がある場合に使用します。 このポリシーを適用する必要があるのは、クリーン URL、RESTful URL、ユーザーフレンドリ URL、SEO フレンドリ URL など、(スキーマと機関の後に) クエリ文字列を含まずリソースのパスのみを含む純粋に構造的な URL のような代替 URL 形式を公開する場合のみです。 これは、一般的に、美学上、使いやすさ、または検索エンジン最適化 (SEO) の目的で行われます。

Note

ポリシーを使用して追加できるのはクエリ文字列パラメーターのみです。 書き換え URL にさらにテンプレート パス パラメーターを追加することはできません。

ヒント

API Management ポリシーを設定または編集する方法について説明します。

ポリシー ステートメント

<rewrite-uri template="uri template" copy-unmatched-params="true | false" />

<policies>
    <inbound>
        <base />
        <rewrite-uri template="/v2/US/hardware/{storenumber}&{ordernumber}?City=city&State=state" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>
<!-- Assuming incoming request is /get?a=b&c=d and operation template is set to /get?a={b} -->
<policies>
    <inbound>
        <base />
        <rewrite-uri template="/put" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>
<!-- Resulting URL will be /put?c=d -->
<!-- Assuming incoming request is /get?a=b&c=d and operation template is set to /get?a={b} -->
<policies>
    <inbound>
        <base />
        <rewrite-uri template="/put" copy-unmatched-params="false" />
    </inbound>
    <outbound>
        <base />
    </outbound>
</policies>
<!-- Resulting URL will be /put -->

要素

名前 説明 必須
rewrite-uri ルート要素。 はい

属性

属性 説明 必須 Default
template クエリ文字列パラメーターを設定した実際の Web サービス URL。 式を使用する場合は、値の全体が式である必要があります。 はい 該当なし
copy-unmatched-params 元の URL テンプレートに存在しない着信要求のクエリ パラメーターを、書き換えテンプレートで定義されている URL に追加するかどうかを指定します。 いいえ true

使用法

このポリシーは、次のポリシー セクションスコープで使用できます。

  • ポリシー セクション: inbound

  • ポリシー スコープ: すべてのスコープ

XSLT を使用した XML の変換

Transform XML using an XSLT ポリシーは、要求本文または応答本文に含まれる XML に XSL 変換を適用します。

ヒント

API Management ポリシーを設定または編集する方法について説明します。

ポリシー ステートメント

<xsl-transform>
    <parameter name="User-Agent">@(context.Request.Headers.GetValueOrDefault("User-Agent","non-specified"))</parameter>
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
        <xsl:output method="xml" indent="yes" />
        <xsl:param name="User-Agent" />
        <xsl:template match="* | @* | node()">
            <xsl:copy>
                <xsl:if test="self::* and not(parent::*)">
                    <xsl:attribute name="User-Agent">
                        <xsl:value-of select="$User-Agent" />
                    </xsl:attribute>
                </xsl:if>
                <xsl:apply-templates select="* | @* | node()" />
            </xsl:copy>
        </xsl:template>
    </xsl:stylesheet>
  </xsl-transform>

<policies>
  <inbound>
      <base />
  </inbound>
  <outbound>
      <base />
      <xsl-transform>
          <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
            <xsl:output omit-xml-declaration="yes" method="xml" indent="yes" />
            <!-- Copy all nodes directly-->
            <xsl:template match="node()| @*|*">
                <xsl:copy>
                    <xsl:apply-templates select="@* | node()|*" />
                </xsl:copy>
            </xsl:template>
          </xsl:stylesheet>
    </xsl-transform>
  </outbound>
</policies>

要素

名前 説明 必須
xsl-transform ルート要素。 はい
パラメーター (parameter) 変換で使用する変数の定義に使用します。 いいえ
xsl:stylesheet ルート スタイルシート要素。 この中で定義する要素と属性はすべて、標準的な XSLT の仕様に従う必要があります。 はい

使用法

このポリシーは、次のポリシー セクションスコープで使用できます。

  • ポリシー セクション: inbound、outbound

  • ポリシー スコープ: すべてのスコープ

次のステップ

ポリシーに対する処理の詳細については、次のトピックを参照してください。