次の方法で共有

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

  • [アーティクル]

適用対象: すべての API Management レベル

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

バックエンド エンティティを参照すると、バックエンド サービスのベース URL やその他の設定を 1 か所で管理し、複数の API と操作でそれらを再利用できます。 また、バックエンド サービスのプール全体のトラフィックの負荷分散とサーキット ブレーカールールを実装して、バックエンドを多くの要求から保護します。

Note

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

Note

ポリシーの要素と子要素を、ポリシー ステートメントで指定された順序で設定します。 API Management ポリシーを設定または編集する方法について説明します。

ポリシー ステートメント

<set-backend-service base-url="base URL of the backend service"  backend-id="name of the backend entity specifying base URL of the backend service" sf-resolve-condition="condition" sf-service-instance-name="Service Fabric service name" sf-listener-name="Service Fabric listener name" />

属性

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

使用法

使用上の注意

現時点では、backend-id 属性を使用して基本 set-backend-service ポリシーを定義し、スコープ内で <base /> を使用して基本ポリシーを継承した場合は、base-url 属性ではなく、backend-id 属性を使用したポリシーにのみオーバーライドできます。

例

クエリ文字列の値に基づいて要求をルーティングする

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

<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 設定からバックエンド サービスのベース URL が読み取られます。 これにより、要求 URL https://contoso.azure-api.net/api/partners/15?version=2013-05&subscription-key=abcdef が http://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-15&subscription-key=abcdefになります。

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

サービス ファブリック バックエンドに要求をルーティングする

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

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

関連するコンテンツ

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