# mulesoft Api Manager - Full Documentation # Anypoint API Manager Anypoint API Manager (API Manager) は、API を管理、制御、保護できる Anypoint Platform のコンポーネントです。Anypoint Flex Gateway、Anypoint Mule Gateway、および Anypoint Service Mesh のランタイム機能を設定するためのインターフェースを備えています。API Manager では、次の作業を行うことができます。 - ポリシーの適用 - 分析データの収集と追跡 - プロキシとアプリケーションの管理 - 暗号化と認証の提供 API Manager は、次のツールと緊密に統合されています。 - [Design Center](https://docs.mulesoft.com/design-center/)​: API の構造を指定する - [Exchange](https://docs.mulesoft.com/jp/exchange/)​: API アセットを保存およびパブリッシュする - [Studio](https://docs.mulesoft.com/studio/)​: API を実装する - [Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/)​: API インスタンスをデプロイ、管理、監視する - [API Governance](https://docs.mulesoft.com/api-governance/)​: API インスタンスを管理する API Manager を使用する前に、ユーザーインターフェースやそこで実行できるタスクに慣れておいてください。 次の動画で、API Manager の概要をすばやく確認できます。 ![](https://play.vidyard.com/DVBh7B1suty8yk1igmD2FC.jpg) ## [](#api-manager-の外観)API Manager の外観 API Manager にアクセスするには、Anypoint Platform にログインし、​**\[API Manager\]**​ を選択します。 ![コールアウト付きの「API Manager」ページのナビゲーション。](/mulesoft/current/ja-jp/api-manager/latest/_images/api-manager-ui-overview.png)
1 環境セレクター。Anypoint Platform を使用すれば、API およびアプリケーションの個別のデプロイ環境を作成して管理できます。API Manager には、設計環境以外のすべての環境が表示されます。詳細は、環境の切り替えを参照してください。
2 サイドバー:
  • API グループ

    API グループ​は、組織で API インスタンスのグループを単一ユニットとしてパブリッシュできるようにする API アセットです。詳細は、API グループを参照してください。

  • 自動ポリシー​

    ポリシーの自動化を使用すると、セキュリティアーキテクトやセキュリティ管理者は、環境内で実行されるすべての API を保護および制御できます。詳細は、自動ポリシーを参照してください。

  • クライアントアプリケーション

    アプリケーション​は、API をコンシュームする外部サービスです。アプリケーションとその関連コントラクトについての詳細は、API インスタンスコントラクトの表示を参照してください。

  • カスタムポリシー

    カスタムポリシー​は、既存の機能を拡張または新機能を定義するために誰もが開発して API に適用できるポリシーです。詳細は、カスタムポリシーを参照してください。

  • DataGraph Administration (DataGraph 管理)

    Anypoint DataGraph では、アプリケーションネットワーク内のすべてのデータを統合スキーマに統合できます。詳細は、Anypoint DataGraph の概要を参照してください。 [DataGraph Administration (DataGraph 管理)]​ は、DataGraph 統合スキーマを設定した後にのみ表示されます。

  • Mule API Analytics

    Mule API Analytics では、Mule API の使用状況とパフォーマンスに関するインサイトを得ることができます。詳細は、Mule API Analytics の使用方法の確認を参照してください。

3 [Add API (API を追加)]​ ボタン。新しい API インスタンスを追加したり、任意の環境から現在の環境に API を昇格させたり、API Manager からエクスポートされた設定 ZIP ファイルをインポートしたりできます。詳細は、API 管理の入門を参照してください。
4 [Environment information (環境情報)]​ ボタンは、管理者ユーザーのみが使用できます。管理者は、現在の環境に関する情報 (環境のログイン情報など) が含まれるダイアログを表示できます。環境のログイン情報を使用して、Anypoint Service Mesh アダプターをプロビジョニングしたり、環境と同期するように Studio を設定したりします。
5 Search (検索)。API 検索項目を使用して管理 API を検索できます。検索では大文字と小文字が区別されません。​[Active (アクティブ)]​ を選択して、検索結果を絞り込みます。
6 各 API の追跡登録状況 (​[Active (アクティブ)]​、​[Inactive (非アクティブ)]​、​[Unregistered (未登録)]​)。

[Unregistered (未登録)]​ の状況は、Anypoint Platform がこの API バージョンのエンドポイントを一度も追跡していないことを意味します。まだプラットフォームと通信していない API またはプロキシの URL を入力したか、API ゲートウェイ以外の場所でホストされているエンドポイントを宣言していて、プラットフォームで追跡できるようにそのエンドポイントをプロキシする必要があります。

ガバナンスポリシーや SLA 層が機能するには、エンドポイントの追跡登録状況が ​[Active (アクティブ)]​ になっている必要があります。

7 各 API の名前。API 名をクリックすると、以下を管理する API ​設定​ビューに移動します。
8 エラーが発生した API 要求の割合 (過去 24 時間)。

「No Data (データなし)」が表示されている場合、API の自動監視は有効になっていません。詳細は、はじめにを参照してください。

9 API 要求の合計数 (過去 24 時間)。

「No Data (データなし)」が表示されている場合、API の自動監視は有効になっていません。詳細は、はじめにを参照してください。

10 各 API のコントラクトされているクライアントアプリケーションの数。詳細は、クライアントアプリケーション、コントラクト、ログイン情報を参照してください。
## [](#api-manager-のコンポーネント概念機能)API Manager のコンポーネント、概念、機能 ### [](#api-インスタンス)API インスタンス API インスタンスは、Flex Gateway、Mule ゲートウェイ、Anypoint Service Mesh のいずれかのランタイムにデプロイされる API の設定を記述します。add、promote、または import オプションを使用して作成された API インスタンスは、API Manager によって管理されます。API は、削除されるまで API Manager の管理下に置かれます。API インスタンスの API 概要を表示するには、API インスタンス名をクリックします。 詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page)を参照してください。 ### [](#api-summary-api-の概要)API Summary (API の概要) \[API Summary (API の概要)\] にはデプロイした API インスタンスに関する主要な情報が表示されます。 ![「API Summary (API の概要)」 ページ](/mulesoft/current/ja-jp/api-manager/latest/_images/api-instance-summary.png) ### [](#重要なメトリクス)重要なメトリクス \[API Summary (API の概要)\] ページには、\[Key Metrics (重要なメトリクス)\] セクションが含まれています。 #### [](#key-metrics)重要なメトリクスの意味 \[API Summary (API の概要)\] の ​**\[Key Metrics (重要なメトリクス)\]**​ セクションには、以下のチャートがあります。 Total Requests (要求総数) 選択された時間範囲での特定の API に対する要求数の合計。 データは 1 分ごとの増分量となります。 Total Policy Violations (ポリシー違反総数) ポリシー違反を返した要求の合計数。 データは 1 分ごとの増分量となります。 Total Errors (総エラー数) 選択された期間で発生した HTTP 応答コードの合計数。このメトリクスで数えられる応答コードは、400、401、402、403、404、405、408、409、410、411、412、413、415、416、417、420、422、429、500、502、503、504、504、510、511 です。 データは 1 分ごとの増分量となります。チャートでは、HTTP 応答コードは 4xx や 5xx のように省略して表示されます。 Average Response Time (平均応答時間) 選択された期間での特定の API に対する要求への応答時間の平均。 データは 1 分ごとの増分量となります。 #### [](#重要なメトリクスの期間の設定)重要なメトリクスの期間の設定 直前の一定期間 (過去 5 分間や過去 30 分間など) または特定の日時範囲に収集されたデータポイントを表示できます。カレンダーアイコンのドロップダウンを使用して、グラフに表示する期間を選択します。 ### [](#api-アラート)API アラート _API アラート_​ (Runtime Manager アラートとは異なる) は、次のいずれかを示すアラームです。 - API 要求がポリシーに違反している。 - API で受信した要求が指定された期間内の指定された数を超えている。 - API が指定された HTTP エラーコードを返す。 - API 応答時間が指定されたタイムアウト値を超えている。 API Manager は、状態が \[desirable (望ましい)\] から \[undesirable (望ましくない)\] (またはその逆) に変わったときにアラートをトリガーします。アラートがトリガーされると、API Manager はあなたまたは設定で指定した他のユーザーにメール通知を送信します。 詳細は、[アラートの概念の確認](https://docs.mulesoft.com/jp/api-manager/latest/using-api-alerts)を参照してください。 ### [](#コントラクト)コントラクト コントラクトは、クライアントアプリケーションが API をコンシュームする方法を定義します。クライアントアプリケーションは、Exchange のアクセス権を要求します。要求の承認は API インスタンスのオーナーが API Manager で行うか、自動的に行われます。これは、設定によって決まります。 コントラクトは、以下のいずれかで適用されます。 - SLA 適用ポリシー - クライアント適用ポリシー 適用ポリシーについての詳細は、[クライアントアプリケーション、コントラクト、ログイン情報](https://docs.mulesoft.com/jp/api-manager/latest/api-contracts-landing-page)を参照してください。 ### [](#ポリシー)ポリシー ポリシーを使用すると、セキュリティの管理、トラフィックの制御、API の適応性の向上に役立つ規制を適用できます。たとえば、ポリシーは認証、アクセス、割り当てられたコンシューム量、サービスレベルアクセス (SLA) を制御できます。 API Manager では、次のポリシーの種類がサポートされます。 - デフォルトポリシー - カスタムポリシー 詳細は、[Securing Omni Gateway Instances with Policies](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis)を参照してください。 ### [](#sla-層)SLA 層 _サービスレベルアクセス (SLA) 層_​は、API で定義するユーザーアクセスのカテゴリです。層定義と SLA ベースのポリシーの組み合わせにより、特定のレベルの API へのアクセスで承認が必要かどうかが決まります。層定義では、アプリケーションで API に対して実行できる要求数を制限することもできます。SLA 層を適用するには、SLA ベースのレート制限または調整ポリシーを適用する必要があります。 詳細は、[SLA 層の概念の確認](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers)を参照してください。 ### [](#設定)設定 API インスタンスを追加するときに、API インスタンス設定を定義して、ランタイム、アップストリームおよびダウンストリーム URI などのパラメーターを設定します。 API インスタンスを追加するには、[API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/add-api-instances)を参照してください。 API インスタンスを作成したら、\[Settings (設定)\] から設定を編集できます。 API インスタンスを編集するには、[API インスタンスの編集](https://docs.mulesoft.com/jp/api-manager/latest/edit-api-endpoint-task)を参照してください。 ### [](#ガバナンスレポート)ガバナンスレポート API Governance は API Manager と統合されており、API インスタンスの準拠状況を特定します。 API Governance は、ルールセットに対して API インスタンスをテストし、ポリシーの欠落や TLS コンテキストの欠落などの準拠の問題を判断します。 ガバナンス検証レポートの詳細を表示して、準拠の問題を修正するために必要な情報を取得できます。検証レポートは、API Manager の \[Governance Report (ガバナンスレポート)\] ページと API Governance の両方にあります。 API インスタンスの管理についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 ### [](#クライアントプロバイダー-id-プロバイダー)クライアントプロバイダー (ID プロバイダー) クライアントプロバイダーを使用してビジネス組織のセキュリティや規制を適用します。クライアントプロバイダーは、クライアントアプリケーションを認証します。 クライアントプロバイダーの使用についての詳細は、[クライアント管理用の複数のクライアントプロバイダーの設定](https://docs.mulesoft.com/jp/api-manager/latest/configure-multiple-credential-providers)を参照してください。 ### [](#api-アセット)API アセット Exchange でパブリッシュされた API アセットは、アプリケーションを構成するコンポーネントです。コンポーネントには、以下のいずれかが含まれます。 - API (OAS、RAML、RAML フラグメント、HTTP、WSDL、カスタム) - API グループ - ポリシー - 例 - テンプレート - モジュール - コネクタ 非公開 Exchange や Exchange 公開ポータルを介したアセットの共有についての詳細は、[アセットのパブリッシュ](https://docs.mulesoft.com/jp/exchange/about-sharing-assets)を参照してください。 ### [](#api-console-api-コンソール)API Console (API コンソール) API Manager で API を作成または編集するときに、[REST API の構築、実装、テスト](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-implement-rest-api) を使用して API 仕様を公開およびテストします。プロキシを使用したエンドポイントとして API を管理する場合、RAML および OAS API をテストできます。Mule アプリケーション用の標準のプロキシをダウンロードしたときに、コンソールフローが API 仕様にすでに含まれ、(デフォルトで) 有効になっています。 Mule 4 以降、API Console へのアクセスを有効にして、API Manager から API Console パスを変更できます。API Manager からの API Console アクセスはデフォルトで無効になっています。API Manager からの API Console アクセスを有効にする方法については、[manage-exchange-api-task.adoc](#manage-exchange-api-task.adoc)を参照してください。 ### [](#api-グループ)API グループ _API グループ_​は、単一ユニットとして機能する API インスタンスのコレクションです。これにより、アプリケーションは 1 つのクライアント ID を使用して API インスタンスにアクセスできます。API グループは、API Manager で作成して、Exchange にパブリッシュします。 詳細は、[API グループ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-landing-page)を参照してください。 ### [](#自動検出スキーム)自動検出スキーム API Manager は、自動検出スキームを使用し、API をそのライフサイクル (変更、バージョン管理、デプロイメント、ガバナンス、デプロイ、パブリッシュ) を通して追跡できます。 ### [](#ビジネスグループ)ビジネスグループ システム管理者は組織内の個人をビジネスグループにグループ化します。各グループには独自の Exchange API アセットと環境があります。 詳細は、[ビジネスグループ](https://docs.mulesoft.com/jp/access-management/business-groups)を参照してください。 ### [](#環境)環境 Anypoint Platform を使用すれば、API およびアプリケーションの個別のデプロイ環境を作成して管理できます。これらの環境は互いに独立しており、本番環境と同じ条件でアプリケーションをテストできます。 Anypoint Platform の戦略コンポーネントの環境がサポートされるようになり、バージョン名を作成して環境を反映させる必要がなくなりました。環境のアクセス制限と管理も簡略化されます。API のアクセス権限は環境に基づきます。 詳細は、[環境](https://docs.mulesoft.com/jp/access-management/environments)を参照してください。 ## [](#APIM-hyperforce)Hyperforce の API Manager Anypoint API Manager のすべての機能は Hyperforce でサポートされますが、次の例外があります。 - API アラート。代わりに、​[Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ を使用して詳細なログを取得し、API パフォーマンスを監視します。 - 重要なメトリクス。代わりに、​[Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ を使用してメトリクスにアクセスし、API パフォーマンスを監視します。 - Mule ハイブリッドおよび CloudHub デプロイメント。​[CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/)​ に移行して API をデプロイします。 - API Service Mesh はサービス終了になる予定のため、Hyperforce では使用できません。サービスメッシュ機能については、​[API ゲートウェイ](https://docs.mulesoft.com/gateway/latest/)​へのアップグレードを検討してください。 - API Manager 1.x。引き続き使用して最新機能にアクセスするには、API Manager 2.x に移行します。 ## [](#関連情報)関連情報 - [チュートリアル: API ビルドの最初から最後まで](https://docs.mulesoft.com/jp/general/api-led-overview) - [API 管理の入門](https://docs.mulesoft.com/jp/api-manager/latest/getting-started-proxy) - [Anypoint Platform 用語集](https://docs.mulesoft.com/jp/general/glossary) # Anypoint DataGraph コントラクトのあるクライアントアプリケーションの表示 Anypoint DataGraph へのクライアントアプリケーションのアクセスを失効させるか、アプリケーションを削除するか、アプリケーションオーナーを削除することができます。 Anypoint DataGraph コントラクトのあるクライアントアプリケーションを表示または管理するには、​**API Manager**​ のサイドバーから ​**\[Client Applications (クライアントアプリケーション)\]**​ をクリックします。 ![「Client Applications (クライアントアプリケーション)」 ページが表示されている図](/mulesoft/current/ja-jp/api-manager/latest/_images/datagraph-view-contracts.png)
1 コントラクト種別に基づいてアプリケーションを絞り込みます。​[Clients with DataGraph Contracts (DataGraph コントラクトのあるクライアントアプリケーション)]​ ページを使用して、DataGraph コントラクトがあるアプリケーションのみを表示します。
2 クライアントアプリケーションを選択すると、そのコントラクトの詳細が表示されます。
3 選択したクライアントアプリケーションのコントラクトオプションを確認します。

このビューから、クライアントシークレットをリセットしたり、クライアントコントラクトを失効させたり、アプリケーションを削除したり、アプリケーションオーナーを削除したりできます。

## [](#関連情報)関連情報 - [Anypoint DataGraph の概要](https://docs.mulesoft.com/jp/datagraph/) - [Anypoint DataGraph でサポートされる認証方法](https://docs.mulesoft.com/jp/datagraph/security) # Anypoint DataGraph の SLA 層の追加 Anypoint DataGraph インスタンスに複数の SLA 層を追加してユーザーアクセスを制御し、要求を制限します。 SLA 層を追加する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[DataGraph Administration (DataGraph 管理)\]**​ > ​**\[SLA Tiers (SLA 層)\]**​ をクリックします。 3. \[DataGraph SLA Tiers (DataGraph SLA 層)\] ページから、​**\[Add SLA tier (SLA 層を追加)\]**​ をクリックします。 ![「Add SLA tier (SLA 層を追加)」 ウィンドウが表示されている図](/mulesoft/current/ja-jp/api-manager/latest/_images/datagraph-add-sla-tier.png) 4. **\[# of Reqs (要求数)\]**​ 項目で、クライアントが実行できる要求数 (例: `100`​) を追加します。 5. **\[Time Period (期間)\]**​ 項目で、クライアント要求の失敗を待機するタイムアウト (例: `60`​) を指定します。 6. **\[Time Unit (時間単位)\]**​ 項目で、ドロップダウンリストから時間単位 (例: `Seconds`​) を選択します。 7. コントラクトのある SLA 層を表示する場合は、​**\[Visible (参照可能)\]**​ を選択します。 8. 追加の SLA 層を作成する場合は、​**\[Add Limit (制限を追加)\]**​ をクリックします。 9. **\[Add (追加)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [Anypoint DataGraph の概要](https://docs.mulesoft.com/jp/datagraph/) - [API Manager における SLA 層の概念の確認](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) # Anypoint DataGraph のコントラクトの管理 Anypoint DataGraph 管理者は、指定されたユーザーログイン情報と SLA 層に基づいてアクセス権を付与するこで、認証されたクライアントアプリケーションのみが統合スキーマを使用できるようにします。 クライアントアプリケーションは、Anypoint DataGraph を介して統合スキーマへのアクセスを要求します。アクセスを承認すると、クライアントアプリケーションとその環境の統合スキーマ間にコントラクトが作成され、クライアントアプリケーションが登録されます。詳細は、​[「クライアントアプリケーションとコントラクト」](https://docs.mulesoft.com/jp/api-manager/latest/api-contracts-landing-page)​を参照してください。 ## [](#anypoint-datagraph-コントラクト管理)Anypoint DataGraph コントラクト管理 API Manager で、DataGraph の ​**\[Contracts (コントラクト)\]**​ ページには、アクセスを要求したクライアントアプリケーション、承認したクライアントアプリケーション、およびコントラクトを失効させたクライアントアプリケーションがリストされます。 ![DataGraph の \[Contracts (コントラクト)\] ページ](_images/datagraph-contracts.png)
1 クライアントアプリケーションに関する追加情報を取得するには、アプリケーション名の横にある ​[>]​ アイコンをクリックします。
2 アプリケーションのアクセスを失効させるには、​[Revoke (失効)]​ をクリックします。

アクセスを復元するには、​[Restore (復元)]​ をクリックします。

## [](#関連情報)関連情報 - [Anypoint DataGraph の概要](https://docs.mulesoft.com/jp/datagraph/) - [Anypoint DataGraph の権限](https://docs.mulesoft.com/jp/datagraph/permissions) # Anypoint DataGraph 管理 API Manager で Anypoint DataGraph を管理します。特定の環境の \[DataGraph Administration (DataGraph 管理)\] ページは、その環境の統合スキーマに少なくとも 1 つの API スキーマを追加した後にのみ表示されます。 Anypoint DataGraph 管理者とコントリビューターの両方が以下を行うことができます。 - [Anypoint DataGraph 管理設定](https://docs.mulesoft.com/jp/api-manager/latest/datagraph-settings)​を使用して、環境の選択、統合スキーマの GraphQL エンドポイントの表示と編集、ポリシーの設定、クライアントプロバイダーの設定を行う。 - [コントラクト](https://docs.mulesoft.com/jp/api-manager/latest/datagraph-managing-contracts)​を管理して、認証されたクライアントアプリケーションのみが統合スキーマをコンシュームできるようにする。 - 各 Anypoint DataGraph インスタンスの ​[SLA 層](https://docs.mulesoft.com/jp/api-manager/latest/datagraph-adding-sla-tiers)​を管理する。 - [API Manager の \[クライアントアプリケーション](https://docs.mulesoft.com/jp/api-manager/latest/datagraph-viewing-application-contracts)\]​ ページを使用して、クライアントアプリケーションコントラクトを表示および管理する。 ## [](#関連情報)関連情報 - [Anypoint DataGraph の概要](https://docs.mulesoft.com/jp/datagraph/) # Anypoint DataGraph 管理設定 DataGraph の \[Administration (管理)\] 設定ページでは、環境の選択、エンドポイントの表示と編集、ポリシーの設定、クライアントプロバイダーの設定を行うことができます。 ![Anypoint DataGraph の \[Administration (管理)\] ページが表示されている図](_images/datagraph-settings.png)
1 [Switch Environment (環境の切り替え)]​ コントロール。このコントロールをクリックすると、組織に追加した環境のリストが表示されます。切り替える環境を選択します。
2 [Consumer endpoint (コンシューマーエンドポイント)]​ 編集オプション。現在のエンドポイントを編集するには、​[Edit consumer endpoint (コンシューマーエンドポイントを編集)]​ アイコンをクリックします。システムで生成されたエンドポイントに戻すには、​[Revert (戻す)]​ アイコンをクリックします。
3 [DataGraph Policies (DataGraph ポリシー)]​ 設定オプション。統合スキーマへの要求を登録済みのクライアントアプリケーションからのみに制限するか、要求に SLA ベースのレート制限を設定するか、統合スキーマのエンドポイントにアクセスできるすべてのユーザーからの要求を許可するかを選択できます。
4 [DataGraph external client providers (DataGraph 外部クライアントプロバイダー)]​ コントロール。組織のシステム管理者によって以前に設定された外部クライアントプロバイダーのリストを表示するには、このコントロールをクリックします。リストからプロバイダーを選択します。Anypoint DataGraph でクエリを実行するには、外部クライアントプロバイダーから適切なログイン情報を取得します。

システム管理者が外部クライアントプロバイダーを設定していない場合、この項目は使用できません。

## [](#関連情報)関連情報 - [Anypoint DataGraph の権限](https://docs.mulesoft.com/jp/datagraph/permissions) - [Anypoint DataGraph でサポートされる認証方法](https://docs.mulesoft.com/jp/datagraph/security) # API Manager 2.x 2017 年 11 月以前に Anypoint Platform アカウントを作成した場合は、サイドバーのバージョンメニューにある API Manager 1.x ドキュメントを使用してください。 2017 年 11 月より後に Anypoint Platform アカウントを作成した場合: - API の管理には API Manager 2.x を使用します。 - RAML 仕様の作成と管理には Design Center を使用します。 Design Center を使用して API を開発すると、アプリケーションは自動的に CloudHub にデプロイされます。 - 他のサーバーに API プロ式をデプロイするには API Manager を使用します。 - API Manager 2.x では Mule Runtime Engine 4.x の API のみを管理できます。 # API Manager Release Notes API Manager automatically updates to the latest version available; you don’t need to perform any tasks to move to the new version. The following release notes are provided for API Manager: - [API Manager 2.x Release Notes](https://docs.mulesoft.com/jp/release-notes/api-manager/api-manager-release-notes) - [API Manager Policies Release Notes](https://docs.mulesoft.com/jp/release-notes/policies/policies-release-notes) - [API Manager Proxy Release Notes](https://docs.mulesoft.com/jp/release-notes/proxies/proxies-release-notes) - [API Gateway Extensions Release Notes](https://docs.mulesoft.com/jp/release-notes/api-gateway-extensions/api-gateway-extensions-release-notes) To take advantage of all new features, improvements, and bug fixes, ensure that you are using the latest version of your runtime. The following release notes are provided for your runtime: - [Omni Gateway Release Notes](https://docs.mulesoft.com/jp/release-notes/gateway/gateway-rn-landing-page) - [Mule Runtime Release Notes](https://docs.mulesoft.com/jp/release-notes/mule-runtime/mule-esb) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # API Manager でのゲートウェイポリシー API Manager から、Flex Gateway の接続モード、Mule ゲートウェイ、または Service Mesh で API にポリシーを適用できます。 ポリシーを使用すると、セキュリティの管理、トラフィックの制御、API の適応性の向上に役立つ規制を適用できます。たとえば、ポリシーは認証、アクセス、割り当てられたコンシューム量、サービスレベルアクセス (SLA) を制御できます。コードの実装を変更することなく、これらの規制を実装できます。 ゲートウェイで使用可能なポリシーについては、[ゲートウェイ別の可用性](https://docs.mulesoft.com/jp/policies/policies-availability-by-gateway) を参照してください。 特定のポリシーとその適用方法についての詳細は、以下を参照してください。 - [Flex Gateway ポリシー](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) - [Mule ゲートウェイおよび Service Mesh ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-policy-overview) # API Manager における API インスタンス ID の確認 API Manager は、API Manager で管理される新しい API インスタンスの ​`apiId`​ を生成して、API インスタンスダッシュボードの ID を表示します。API インスタンス ID は変更できません。 API インスタンス ID を検索する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、目的の ID の API インスタンスの名前をクリックします。 API インスタンス ID は、​**\[API Instance ID (API インスタンス ID)\]**​ の下に表示されます。 # API Manager における API インスタンスのエクスポート API インスタンスを作成したらエクスポートできます。この場合、API インスタンスのエンドポイント設定と Exchange のアセットリレーションがエクスポートされます。その後、同じビジネスグループの別の環境にインポートして、新しい API インスタンスを作成できます。 次のようなエクスポートファイルが作成されます。 - ファイル形式: ZIP - ファイル名形式: `{API name}-{version}-{API instance ID}` - ファイルサイズ: 100 MB 以下

次の情報は、API インスタンスと一緒にエクスポートされません。

  • クライアントプロバイダー設定 (API インスタンスをインポートするときに対象環境から抽出されます)。

  • アセットに保存されている情報 (契約、ポリシー、API 仕様など)。この情報を共有するために、API グループで API インスタンスを昇格できます。

API インスタンスをエクスポートする 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、エクスポートする API の名前をクリックします。 3. **\[Actions (アクション)\]**​ をクリックして ​**\[Export API (API をエクスポート)\]**​ を選択します。 これで、API インスタンスが正常にエクスポートされました。 ## [](#関連情報)関連情報 - [API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page) - [API グループの API インスタンスの昇格](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-promote-api-instance) # API Manager における API インスタンスの廃止 API のコンシューマーを更新されたインスタンスに移行する間、開発者が古い API インスタンスにアクセスするためのサインアップを行わないようにすることができます。API 管理者は、API を非推奨としてマークし、開発者がポータルページからアクセスを要求するための招待を削除します。既存のアプリケーションのコントラクトはアクティブなままですが、その API インスタンスの新しいコントラクトは作成できません。非推奨の API には、すべての場所で非推奨であることを示すインジケーターが表示されます。検索結果のバッジは、インスタンスが非推奨であることを示します。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、非推奨にする API インスタンスの名前をクリックします。 3. **\[Actions (アクション)\]**​ > ​**\[Deprecate API (API の非推奨化)\]**​ を選択します。 4. **\[Ok\]**​ をクリックします。 これで、この API は非推奨になりました。 ## [](#関連情報)関連情報 - [API などのアセットの共有について](https://docs.mulesoft.com/jp/exchange/to-create-an-asset) - [API へのアクセスを要求する方法](https://docs.mulesoft.com/jp/exchange/to-request-access) # API Manager の Mule API Analytics チャートの使用方法の確認 Mule API Analytics では、要求、上位のアプリケーション、およびレイテンシー (1 時間、3 時間、1 日、7 日、1 か月) の概要がチャート形式で提供されます。このデータは 30 日間使用できます。Mule API Analytics チャートを表示するには、API Manager で、デプロイされた API のインスタンス名をクリックします。 **注意:**​ Mule API Analytics チャートを表示するには、ユーザーに​`「API 設定の表示」`​権限が必要です。​[権限の設定方法](https://docs.mulesoft.com/jp/api-manager/latest/environment-permission-task)​を参照してください。 ## [](#要求の概要チャートの確認)要求の概要チャートの確認 要求の概要チャートには、選択した期間における API インスタンスへの要求数の合計が表示されます。このチャートには、W3C で規定された HTTP 状況コードが表示されます。次に例を示します。 ![2017 年 6 月 1 日の合計要求数を 1 時間ごとに表示した概要チャート。](/mulesoft/current/ja-jp/api-manager/latest/_images/request-analytics.png) 次のグラフ線が提供されています。 - 緑 - 1xx ~ 3xx の状況コードを返した成功要求。 - 濃い灰色 - 4xx の状況コードを返した、クライアントの失敗要求。 - 青 - 5xx の状況コードを返した、サーバーの失敗要求。 ## [](#上位のアプリケーションの概要チャートの確認)上位のアプリケーションの概要チャートの確認 上位のアプリケーションの概要チャートには、API インスタンスへの要求数が、その API インスタンスをコールした上位 5 個のアプリケーション別に表示されます。各色は、API にアクセスした上位 5 個の各アプリケーションを表します。Y 軸は API インスタンスのコール数です。 このグラフには、選択した期間における要求数が表示されます。次に例を示します。 ![2017 年 6 月 1 日の上位 5 件のアプリケーションの要求数を 1 時間ごとに表示した概要チャート。](/mulesoft/current/ja-jp/api-manager/latest/_images/top-apps-analytics.png) ## [](#レイテンシーの概要チャートの確認)レイテンシーの概要チャートの確認 レイテンシーの概要チャートには、選択した期間における API レイテンシーの平均が表示されます。このレイテンシーが長いほど、パフォーマンスが低下します。チャートの Y 軸には、平均レイテンシーがミリ秒 (ms) 単位で示されます。 次の例は、1 時間の最低の平均パフォーマンスが午前 8 時 30 分に発生したことを示しています。 ![チャートでもっとも高いポイントの平均レイテンシー (午前 8 時 30 分) を示すレイテンシー概要チャート。](/mulesoft/current/ja-jp/api-manager/latest/_images/performance-analytics.png) ## [](#チャートにポリシー違反を含める)チャートにポリシー違反を含める **注意:**​ ポリシーを参照したり、ポリシー違反アラートを編集したりするには、ユーザーに​`「ポリシーの参照」`​権限セットが必要です。 ポリシー違反の追跡を有効または無効にするには、Mule API Analytics チャート画面で \[Include Policy Violations (ポリシー違反を含む)\] チェックボックスを選択します。このチャートには、ポリシーにより拒否されたまたは拒否されなかったトラフィックが表示されます。 ![「Include Policy Violations (ポリシー違反を含む)」チェックボックスがコールアウトで示された分析チャート画面。](/mulesoft/current/ja-jp/api-manager/latest/_images/policy-violations-dashboard.png) ## [](#関連情報)関連情報 - [権限の設定](https://docs.mulesoft.com/jp/api-manager/latest/environment-permission-task) # API Manager の制限 ## [](#api-グループの制限)API グループの制限 API Manager では、各ビジネスグループで許可される機能の数が制限されています。
制限 値 注意事項

ビジネスグループあたりの API グループ数

1200

ビジネスグループあたりの API グループバージョン数

1200

ビジネスグループあたりの API グループインスタンス数

2000

## [](#アップストリームサービスの制限)アップストリームサービスの制限 API Manager では、1 つのコンシューマーエンドポイントを介して公開できるアップストリームサービスの数が制限されています。
制限 値 注意事項

API ごとのアップストリーム

50

API あたりのルート数

50

ルートあたりのアップストリーム数

10

## [](#api-アラートの制限)API アラートの制限
機能 Gold Platinum Titanium Integration Starter Intergration Advanced

ログ

Runtime Manager​ のドキュメントに記載

Runtime Manager​ のドキュメントに記載

購入したストレージサイズの 10% に当たる追加のストレージを検索可能なログのインデックスに利用できます。サブスクリプションごとに領域を占めます。

Runtime Manager​ のドキュメントに記載

ログは、価格設定パッケージで利用できる全領域を占めることができます。

検索可能なログ

利用不可

利用不可

購入したストレージサイズの 10% に当たる追加のストレージを検索可能なログのインデックスに利用できます。

利用不可

購入したストレージサイズの 10% に当たる追加のストレージを検索可能なログのインデックスに利用できます。

アプリケーションメトリクスの保持

30 日

30 日

365 日

30 日

365 日

拡張 API メトリクスの保持

30 日。​[Client Applications (クライアントアプリケーション)]​ タブのデータの制限は 1 時間です。

30 日。​[Client Applications (クライアントアプリケーション)]​ タブのデータの制限は 1 時間です。

30 日。​[Client Applications (クライアントアプリケーション)]​ タブのデータは 1 時間に制限されます。 カスタムダッシュボードの高度なモードの ​api_path_metric​ テーブルと ​api_client_ip_metric​ テーブルのデータは 1 時間に制限されます。

30 日。​[Client Applications (クライアントアプリケーション)]​ タブのデータの制限は 1 時間です。

30 日。​[Client Applications (クライアントアプリケーション)]​ タブのデータは 1 時間に制限されます。 カスタムダッシュボードの高度なモードの ​api_path_metric​ テーブルと ​api_client_ip_metric​ テーブルのデータは 1 時間に制限されます。

カスタムメトリクスの保持

利用不可

利用不可

本番環境では 365 日

利用不可

本番環境では 365 日

サーバーおよび Mule アプリケーションの基本アラート

50 アラート

50 アラート

組織の本番 vCore の数 x 50 + 100 個。

サーバーまたはアプリケーションあたり 6 アラート

サーバーまたはアプリケーションあたり 10 アラート

API の基本アラート

API インスタンスあたり 6 アラート

API インスタンスあたり 6 アラート

API インスタンスあたり 10 アラート

API インスタンスあたり 6 アラート

API インスタンスあたり 10 アラート

詳細アラート

利用不可

利用不可

親組織あたり 20 アラート

利用不可

アプリケーションまたは API インスタンスあたり 10 アラート

テレメトリーエクスポーター接続

利用不可

利用不可

組織あたり 10 接続

利用不可

組織あたり 10 接続

ログの切り捨て

1 行あたり最大 8 KB

1 行あたり最大 8 KB

1 行あたり最大 8 KB

1 行あたり最大 8 KB

1 行あたり最大 8 KB

最小画面解像度 1024x768 ピクセルを使用します。
# API Manager へのインポートによる API インスタンスの作成 このページのコンテンツは、​[「API インスタンスの追加」](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page)​に移動されました # API アラートのテスト この手順では、要求数アラートをテストする方法について説明します。この手順では、次の準備が必要です。 1. API をデザインします。 2. API を Exchange にパブリッシュします。 3. API Manager で、Exchange から API を管理します。 4. API インスタンスのプロキシを CloudHub にデプロイします。 5. 連続する 1 分以上の要求数が 1 より大きくなるように、レート制限ポリシーを API に適用します。 6. アラートの追加方法についてのトピックで説明したようにアラートを追加します。 7. API をコールします。 8. API を 2 回再コールします (ページを再読み込み)。API をコールして 1 分以内に再コールすると ​`API calls exceeded`​ が表示されることを確認します。1 分以内にさらにページの再読み込み操作を行っても効果はありません。 9. アラートを追加したときにメール通知で選択したユーザーが、実際にメール通知を受信することを確認します。 10. アラートが解決されたことを確認します。 ## [](#関連情報)関連情報 - [API アラートの追加](https://docs.mulesoft.com/jp/api-manager/latest/add-api-alert-task) - [Create and Publish an API Specification or API Fragment (API 仕様または API フラグメントの作成とパブリッシュ)](https://docs.mulesoft.com/design-center/design-create-publish-api-specs) # API アラートの編集、有効化、無効化 アラートの作成時に、アラートが有効または無効になるかを選択できます。既存のアラートを編集して、アラートを有効または無効にすることもできます。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、アラートを編集する API インスタンスの名前をクリックします。 3. **\[Alert (アラート)\]**​ をクリックします。 4. 編集するアラートで ​**\[Edit (編集)\]**​ ボタンをクリックします。 ![アラートの例が表示された API インスタンスアラートリスト。](/mulesoft/current/ja-jp/api-manager/latest/_images/edit-enable-disable-alerts-task-7e2ac.png) ## [](#関連情報)関連情報 - [アラートの概念の確認](https://docs.mulesoft.com/jp/api-manager/latest/using-api-alerts) - [API アラートのテスト](https://docs.mulesoft.com/jp/api-manager/latest/test-alert-task) # API アラートの表示と削除 ルート組織の​**組織のシステム管理者**​ロールが割り当てられている場合、API Manager で API に対して生成されたアラートのリストを表示できます。 アラートを表示および削除する前に、次を確認してください。 - API アラートを表示および削除するための​**「Manage Alerts (アラートの管理)」**​権限。 - アラートの表示のみを行うための​**「View Alerts (アラートの表示)」**​権限。 これらの権限の設定方法についての詳細は、​[権限の設定方法](https://docs.mulesoft.com/jp/api-manager/latest/environment-permission-task)​を参照してください。 アラートを表示および削除する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、アラートを表示または削除する API インスタンスの名前をクリックします。 3. **\[Alert (アラート)\]**​ をクリックします。 4. 削除するアラートを展開します。 アラートのオプションに関する詳細が表示されます。 5. **\[Delete (削除)\]**​ をクリックします。 # API インスタンスコントラクトの表示 API Manager で、API インスタンスへのアクセス権を付与するときに、その API インスタンスに対して作成されているコントラクトを表示できます。 API インスタンスコントラクトを表示する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、設定する API インスタンスの名前をクリックします。 3. **\[Contracts (コントラクト)\]**​ をクリックします。 タブに API インスタンスのコントラクト情報が表示されます。 ## [](#関連情報)関連情報 - [Exchange からの API インスタンスへのアクセス権の要求](https://docs.mulesoft.com/jp/exchange/to-request-access) - [API インスタンスコントラクトの削除](https://docs.mulesoft.com/jp/api-manager/latest/remove-client-app-latest-task) - [クライアントアプリケーションのクライアント ID とクライアントシークレットログイン情報の取得](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task) # API インスタンスの削除 API インスタンスを API Manager から管理する必要がなくなった場合、API インスタンスとそのバージョンを削除できます。API Manager からインスタンスを削除しても、Anypoint Exchange (Exchange) やファイルシステムなど、他のロケーションからその参照先アセットは削除されません。 API Manager で管理されている 1 つ以上の API インスタンスまたは API バージョンで現在使用されている API 仕様は削除できません。 API Manager から API インスタンスを削除する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、削除する API インスタンスの名前をクリックします。 3. **\[Actions (アクション)\]**​ > ​**\[Delete API (API を削除)\]**​ を選択します。 4. **\[Delete (削除)\]**​ をクリックして確認します。 API インスタンスが正常に削除されました。 # API インスタンスの管理 API インスタンスは、API 定義のインスタンス化です。ゲートウェイとコントロールプレーン間でデータを共有するために使用されるオブジェクトです。API インスタンスは、アップストリーム用の API のプロキシ、または Mule アプリケーションエンドポイントのいずれかです。 API Manager を使用して、API インスタンスを作成、インポート、非推奨化できます。API のインスタンスは複数の環境で使用できます。同じ環境で API の複数のインスタンスを使用することもできます。 プロキシとして機能する API バージョンのインスタンスと、エンドポイントとして直接管理する API インスタンスを作成できます。API がどのように (プロキシまたはエンドポイントのどちらとして) 設定されているかに基づいて API にポリシーを適用することができます。たとえば、キャッシュポリシーをプロキシに適用でき、スロットルポリシーやセキュリティポリシーをエンドポイントに適用できます。また、API を別の環境に昇格することもできます。 API Manager で API インスタンスを管理する手順は、次のとおりです。 1. 関連ゲートウェイの API インスタンスを追加します。 - [Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex) - [Mule ゲートウェイ API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-mule) - [Service Mesh API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-service-mesh) 2. API インスタンスの \[API Summary (API の概要)\] を表示し、インスタンスに関する情報を得たり、インスタンスをエクスポートしたりします。 - [Obtain API Instance ID (API インスタンス ID を取得)](https://docs.mulesoft.com/jp/api-manager/latest/find-api-id-task)​ - API Manager は、Mule 4 で使用する新しい API の apiId を生成して管理します。 - [Export an API Instance (API インスタンスをエクスポート)](https://docs.mulesoft.com/jp/api-manager/latest/export-api-latest-task)​ - API インスタンスを作成したらエクスポートできます。この場合、API インスタンスのエンドポイント設定と Exchange のアセットリレーションがエクスポートされます。その後、同じビジネスグループの別の環境にインポートして、新しい API インスタンスを作成できます。 - [Access the Developer Portal (開発者ポータルへのアクセス)](https://docs.mulesoft.com/jp/api-manager/latest/access-developer-portal-task)​ - システム管理者は API のリソースとメソッドを表示し、Anypoint Exchange (Exchange) からの他の詳細 (パブリッシュ日、モッキングサービスなど) にアクセスできます。API はアセットポータル (非公開) または公開ポータルで表示できます。 3. インスタンスが不要になった場合、または更新する必要がある場合は、API インスタンスを変更します。 - [Edit an API Instance (API インスタンスを編集)](https://docs.mulesoft.com/jp/api-manager/latest/edit-api-endpoint-task)​ - API インスタンスの設定を編集して、ベースパス、ポート、TLS コンテキストなどを更新します。 - [Deprecate an API Instance (API インスタンスの非推奨化)](https://docs.mulesoft.com/jp/api-manager/latest/deprecate-api-latest-task)​ - API のコンシューマーを更新されたインスタンスに移行する間、開発者が古い API インスタンスにアクセスするためのサインアップを行わないようにすることができます。 - [Delete an API Instance (API インスタンスを削除)](https://docs.mulesoft.com/jp/api-manager/latest/delete-api-task)​ - API インスタンスを API Manager から管理する必要がなくなった場合、API インスタンスとそのバージョンを削除できます。 - [Manage API Versions (API バージョンの管理)](https://docs.mulesoft.com/jp/api-manager/latest/manage-versions-instances-concept)​ - Anypoint Platform で API を作成した後に、API のバージョンの詳細を設定し、それを Anypoint Exchange (Exchange) にパブリッシュします。API バージョンは API Manager ではなく Exchange で管理されます。ただし、この API バージョンの管理は API Manager で行います。 4. API インスタンスの高度なユースケースを調べます。 - [Configure Multiple Client Providers (複数のクライアントプロバイダーを設定)](https://docs.mulesoft.com/jp/api-manager/latest/configure-multiple-credential-providers)​ - OpenAM や PingFederate など、複数のクライアントプロバイダーを使用して、ビジネス組織のセキュリティや規制を適用しやすくすることができます。これらのクライアントプロバイダーを使用することで、クライアントのログイン情報やアクセストークンなどの運営データを保護できます。 - [Govern API Instances (API インスタンスを管理)](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)​ - Anypoint API Governance を使用して API インスタンスを管理できます。管理対象インスタンスのガバナンス検証レポートを表示して、準拠の問題を特定し、修正するためのアクションを実行します。 # API インスタンスの管理 API Manager は ​[Anypoint API Governance](https://docs.mulesoft.com/api-governance/)​ と緊密に統合されており、ガバナンスルールセットを使用して API インスタンスのアスペクトを管理します。ガバナンスルールセットを API に適用すると、その API のすべてのインスタンスは、適用されるポリシーや TLS コンテキストが必要かどうかなどの標準に準拠するようになります。 API インスタンスを管理する手順は、次のとおりです。 1. [ガバナンスルールセットを適用する](#apply-a-ruleset) 2. [API Manager でインスタンスの準拠の問題を表示して修正する](#view-api-manager) ## [](#apply-a-ruleset)ガバナンスルールセットを適用する API インスタンスを管理するには、目的の API にガバナンスルールセットを適用する必要があります。ガバナンスルールセットを適用するには、[Applying Rulesets to Identified APIs](https://docs.mulesoft.com/api-governance/create-profiles)を参照してください。 独自の API 管理標準を適用するカスタムルールセットを作成するには、[Creating Custom Governance Rulesets](https://docs.mulesoft.com/api-governance/create-custom-rulesets)を参照してください。 ## [](#view-api-manager)API Manager でインスタンスの準拠の問題を表示して修正する API インスタンスの準拠状況を表示する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. 準拠状況を表示する API インスタンスの名前をクリックします。 **\[Instance Conformance (インスタンス準拠)\]**​ が ​**\[API Summary (API の概要)\]**​ ペインに表示されます。 3. インスタンスが準拠していない場合は、​**\[Governance Report (ガバナンスレポート)\]**​ ページを選択して、各ルールセットの準拠の詳細を表示します。 4. 各ルールセットで ​**\[View details (詳細を表示)\]**​ をクリックすると、準拠の問題についての詳細が表示されます。 ## [](#関連情報)関連情報 - [Instance Conformance](https://docs.mulesoft.com/api-governance/fix-instance-conformance-issues) # API インスタンスの編集 API Manager で API インスタンスを作成したら、インスタンスの設定を編集できます。 API エンドポイント設定についての詳細は、以下を参照してください。 - [Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex) - [Mule ゲートウェイ API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-mule) - [Service Mesh API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-service-mesh) API インスタンスのエンドポイントを編集する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、エンドポイントを編集する API インスタンスの名前をクリックします。 3. **\[Settings (設定)\]**​ をクリックします。 4. 目的の設定項目を編集します。 5. **\[Save (保存)\]**​ をクリックします。 # API インスタンスの追加 - [Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex) 分散およびマイクロサービス環境で動作し、CI/CD 環境に適合する柔軟で高性能の API ゲートウェイを必要とする API の場合、Flex Gateway を使用します。 - [Mule ゲートウェイ API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-mule) Mule Runtime に API があり、API を管理、監視、保護するために API ゲートウェイが必要な場合、Mule ゲートウェイを選択します。 - [Service Mesh API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-service-mesh) Mule アダプターのデプロイメントを通して Anypoint Platform の API 管理機能を Istio サービスメッシュに拡張するには、Anypoint Service Mesh を選択します。 # API インスタンスバージョンの管理 API 定義の新しいバージョンの詳細を Exchange にパブリッシュした後で、変更を反映させるには、API Manager でデプロイされた API インスタンスの​**アセットバージョン**​を更新する必要があります。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 API インスタンスのアセットバージョンを変更する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、バージョンを変更する API インスタンスの名前をクリックします。 3. **\[Actions (アクション)\]**​ > ​**\[Change API specification (API 仕様を変更)\]**​ を選択します。 4. **\[Asset version (アセットバージョン)\]**​ で、目的のバージョンを選択します。 5. **\[Change (変更)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [API インスタンス](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page) - [環境にアクセスするための権限の付与](https://docs.mulesoft.com/jp/api-manager/latest/environment-permission-task) - [Anypoint Exchange ドキュメント](https://docs.mulesoft.com/jp/exchange/) - [Exchange でのアセットの作成](https://docs.mulesoft.com/jp/exchange/to-create-an-asset) - [Exchange でのアセットの削除](https://docs.mulesoft.com/jp/exchange/to-delete-asset)​ (アセットの非推奨化についても説明) - [About Exchange Portals (Exchange ポータルについて)](https://docs.mulesoft.com/jp/exchange/about-portals) # API グループ API グループを使用すると、API とリソースをバンドルして、特定のユーザーのニーズを解決できます。リストから個別のリソースと API を使用する代わりに、ユーザーは特定の問題を解決するパッケージでそれらへのアクセスを要求して使用できます。 API グループを作成するときに、インスタンスが解決する必要がある問題に基づいて、異なる SLA とレート制限の条件でそのグループのインスタンスをカスタマイズできます。その後、API グループを Anypoint Exchange にパブリッシュして、ユーザーがパッケージを登録できるようにします。 各 API グループインスタンスに複数の API インスタンスを含めることが可能で、各インスタンスに複数の API グループインスタンスソリューションを含めることができるため、パッケージのカスタマイズオプションは無限です。 ## [](#api-グループのしくみ)API グループのしくみ API グループ管理者が、特定の組織および環境用の API グループを作成します。API グループは、更新を簡単に組み込めるように、その中に含まれる API と同様にバージョン管理されます。 各 API グループに複数のインスタンスを含めることができ、各 API グループインスタンスに複数の API インスタンスを含めることができます。これらの API グループインスタンスは、本番と Sandbox などの異なる環境に存在できます。 次の図は、異なる環境で API グループを実装する方法を示しています。 ![API グループ階層](/mulesoft/current/ja-jp/api-manager/latest/_images/api-groups-architecture.png) この例では、​`ORG A`​ と ​`ORG B`​ の 2 つのビジネスグループがあります。 各ビジネスグループには、​`Sandbox`​ と ​`Production`​ の 2 つの環境があります。​`ORG A`​ には ​`Twitter`​ と ​`Facebook`​ の 2 つの API があり、2 つの環境にその各 API の 1 つのインスタンスがあります。 `ORG B`​ には ​`Instagram`​ と ​`Snapchat`​ の 2 つの API があり、2 つの環境にその各 API の 1 つのインスタンスがあります。 `ORG A`​ には ​`Social Media`​ という 1 つの API グループがあり、1 つのバージョン ​`V1`​ があります。​`Social Media V1`​ には次の 2 つの API グループインスタンスがあります。 - `Sandbox`​ 環境の API グループインスタンス ​`QA`​。 このインスタンスには、​`ORG A`​ の ​`Facebook v1`​ (QA) と ​`Twitter v1`​ (QA)、および ​`ORG B`​ の ​`Instagram v1`​ (QA) と ​`Snapchat v1`​ (QA) の 4 つの API インスタンスがあります。 - `Production`​ 環境の API グループインスタンス ​`PROD`​。 このインスタンスには、​`ORG A`​ の ​`Facebook v1`​ (PROD) と ​`Twitter v1`​ (PROD)、および ​`ORG B`​ の ​`Instagram v1`​ (PROD) と ​`Snapchat v1`​ (PROD) の 4 つの API インスタンスがあります。 API グループインスタンス ​`QA`​ がパブリッシュされ、​`API Group Social Media V1`​ というアセットが作成されます。API グループインスタンス ​`PROD`​ がパブリッシュされた場合、アセットは作成されません。この場合、API グループ ​`Social Media`​ とバージョン ​`v1`​ は同じであるため、​`PROD`​ は既存のアセットにのみリンクされます。 ## [](#api-グループを使用して解決する問題の例)API グループを使用して解決する問題の例 API グループがどのように API コンシューマーエンゲージメントを促進するかの理解を深めるために、気象学を使用して特定の場所と時間の大気の状況を予測する、Good Weather という架空の会社のニーズを考えてみます。 Good Weather の顧客は、次の API を使用して要求した結果にアクセスできます。 - Locations API (場所 API) - Forecast API (予測 API) - Current Conditions API (現在の状況 API) - Indices API (インデックス API) - Weather Alarms API (天気警報 API) - Alerts API (アラート API) - Imagery API (イメージ API) - Tropical API (熱帯 API) - Translations API (翻訳 API) 現在、顧客が API にアクセスして使用するために従う必要があるプロセスは効率的ではなく、以下の作業が必要です。 - Good Weather の企業ポータルを検索して、ビジネスフローを実現するために適切な API を見つける 顧客が必要とする正確な API を判断するには、ポータルで長い API のリストを検索する必要があります。開発者が既存の API を変更したり、追加の API を導入したりすると、この問題はさらに悪化します。 - サービス全体の変更を採用するために、複数の API サービスプランを個別に変更する これにより、サービスのアップグレードまたはダウングレードのタスクが複雑になります。 - API アクセスが承認されたときに API の各要素にアクセスするための作業 API のパッケージ化では、個々のコールとデータ要素へのアクセスが制限されません。これにより、セキュリティの問題と不要なオーバーヘッドが発生します。 ## [](#api-グループソリューション)API グループソリューション Good Weather は API グループを使用して、コンシューマーの要件とシナリオに基づいて異なる API をパッケージ化でき、特定の SLA は他のコンシューマーの要件と競合しません。Good Weather は API の変更をすばやく適応して吸収できます。API グループを使用して、以下を行うことができます。 - Good Weather は異なる API セットをパッケージ化して、異なるコンシューマーの要件を対象とすることができる。 - API コンシューマーは、個々の API ではなく関連する API のコレクションにアクセスできるため、Good Weather ポータルでアセットを簡単に見つけることができる。 - API グループは、1 回のクリックで変更可能な SLA プランを使用してガバナンスを適用できる。 次の表は、Good Weather がビジネスの要件を満たすために作成した API グループパッケージを示しています。
Trial (トライアル) Base (ベース) Enterprise (大企業)

Locations API (場所 API)

Locations API (場所 API)

Locations API (場所 API)

Forecast API (予測 API)

Forecast API (予測 API)

Forecast API (予測 API)

Current Conditions API (現在の状況 API)

Current Conditions API (現在の状況 API)

Weather Alarms API (天気警報 API)

Weather Alarms API (天気警報 API)

Alerts API (アラート API)

Imagery API (イメージ API)

Translations API (翻訳 API)

## [](#api-グループの権限)API グループの権限 API グループに関するすべてのタスクを実行するには、「API Group Administrator (API グループ管理者)」権限が必要です。この権限はビジネスグループレベルで設定され、ユーザーに以下のアクセス権を付与します。 - ビジネスグループ内での API グループの作成、更新、および削除 - API グループに API インスタンスを追加できるようにするための、ビジネスグループ内のすべての API インスタンスの参照 - SLA 層の設定、および API グループとのコントラクトの管理 ## [](#関連情報)関連情報 - [API グループ](#) - [グループの作成](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-creating-groups) - [グループの変更](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-modifying-groups) - [Exchange への API グループのパブリッシュ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-publishing-to-exchange) - [グループの非推奨化](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-deprecating-groups) - [API グループの削除](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-deleting-groups) # API グループインスタンスコントラクトの管理 Exchange の API グループインスタンスへのアクセス権を付与すると、アプリケーションと API インスタンスの間にコントラクトが自動的に作成されます。その後、API Manager からそのコントラクトを管理できます。 ## [](#適用済みコントラクト)適用済みコントラクト API グループでは、アプリケーションは次のシナリオで同じ API との複数のコントラクトを持つことができます: - アプリケーションが API へのアクセスを要求し、その要求が承認される。 この場合、アプリケーションと API の間に直接的コントラクトが作成されます。これは ​_API インスタンスコントラクト_​と呼ばれます。 - アプリケーションは、すでにそのアプリケーションとの直接的コントラクトがある API インスタンスで構成される、API グループインスタンスへのアクセスを要求します。 これは ​_API グループインスタンスコントラクト_​と呼ばれます。 アプリケーションに同じ API インスタンスとのコントラクトが複数ある場合、常に 1 つのコントラクトのみがアクティブになります。これは​_適用済みコントラクト_​と呼ばれます。 このスクリーンショットは、API インスタンスコントラクトのコントラクトレベルとコントラクト状況を示しています。 ![API グループインスタンスコントラクト](/mulesoft/current/ja-jp/api-manager/latest/_images/api-groups-instance-contracts.png)
1インスタンスレベルの API インスタンスのコントラクト
2コントラクトが表示される API グループ
3現在 API インスタンスとのコントラクトがあるアプリケーション
4現在アクティブなコントラクト
5API グループレベルの API インスタンスのコントラクト
アプリケーションは、API グループ内の異なる API との複数のコントラクトを持つことができます。API グループレベルで API インスタンスコントラクトを表示できます。コントラクトは、API グループとのコントラクトがあるアプリケーションで並び替えられます。API グループ内で現在アクティブなコントラクトは、​`Applied`​ として表示されます。 アプリケーションに同じ API とのコントラクトが複数ある場合、同じ API の他のコントラクト層と比べて制限が最も少ない層が ​`Applied`​ に設定されます。承認済みのコントラクトのみが ​`Applied`​ に設定されます。取り消されたコントラクトはアクティブではなくなるため、​`Applied`​ に設定されることはありません。 ## [](#適用済みコントラクトの例)適用済みコントラクトの例 API とアプリケーションの間に複数のコントラクトがある場合、コントラクトが ​`Applied`​ に設定される方法についての理解を深めるために、次の例を考えてみます。 Good Weather は、​`Contacts`​ というアプリケーションの ​`Facebook`​ API へのアクセスを要求しています。​`Contacts`​ と ​`Facebook`​ の間にコントラクトが作成されます。コンシューマーは同じアプリケーション ​`Contacts`​ を使用して、数ある中から ​`Facebook`​ API で構成される ​`Social Chatter`​ という API グループインスタンスへのアクセスを要求します。​`Contacts`​ と ​`Social Chatter`​ の間にもコントラクトが作成されます。 この場合、アプリケーション ​`Contacts`​ には 2 つのコントラクトがあります。 - API ​`Facebook`​ との直接的コントラクト - API グループインスタンス ​`Social Chatter`​ とのコントラクトによる、API ​`Facebook`​ との間接的コントラクト `Contacts`​ には 2 つのコントラクトがあるため、どちらのコントラクトが ​`Applied`​ に設定されるでしょうか。次の条件があるとします。 - API コントラクト層では 1 分あたり 100 要求が許可されている - API グループコントラクトでは 1 分あたり 10 要求が許可されている この場合、​`Contacts`​ と ​`Facebook`​ の間のコントラクトが最も制限の少ない層であるため、​`Applied`​ に設定されます。ユーザーは、API グループコントラクトを使用する場合よりも 1 分あたり 90 個多い要求を取得します。 コントラクトは API に適用されますが、API グループインスタンスには適用されません。たとえば、コンシューマーが API グループインスタンス ​`Social Chatter`​ と別のアプリケーション ​`Interests`​ の間のコントラクトを作成するとします。 - `Contacts`​ と API ​`Facebook`​ の場合、適用済みコントラクトは API コントラクト。 - `Interests`​ と API ​`Facebook`​ の場合、API グループインスタンスコントラクトがアプリケーションと API の間の唯一のコントラクトであるため、適用済みコントラクトは API グループインスタンスコントラクト。 `Interests`​ には ​`Facebook`​ API との直接的コントラクトはありません。 API グループインスタンスコントラクトを表示する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Groups (API グループ)\]**​ をクリックします。 3. API グループインスタンスの詳細ページから、API グループインスタンスの ​`version:instance`​ リンクをクリックします。 4. **\[Contracts (コントラクト)\]**​ をクリックして、コントラクト情報を表示するインスタンスを展開します。 ![API グループインスタンスのコントラクトの表示](/mulesoft/current/ja-jp/api-manager/latest/_images/api-group-instance-contracts.png) API グループインスタンスのコントラクトが表示されます。 API グループインスタンスコントラクトを管理する手順は、次のとおりです。 1. **\[API Manager\]**​ で、​**\[API Groups (API グループ)\]**​ をクリックします。 2. API グループインスタンスの詳細ページから、API グループインスタンスの ​`version:instance`​ リンクをクリックします。 API グループインスタンスの詳細ページが表示されます。 3. **\[Contracts (コントラクト)\]**​ をクリックして、コントラクト情報を表示するインスタンスを展開します。 ![API グループインスタンスのコントラクトの管理](/mulesoft/current/ja-jp/api-manager/latest/_images/api-group-instance-manage-contracts.png) API グループインスタンスのコントラクトが表示されます。 4. コントラクトを管理する API グループインスタンスで、​**\[…​\]**​ > ​**\[Revoke (取り消し)\]**​ をクリックします。 # API グループインスタンスの削除 ビジネスニーズに基づいて不要になった API グループインスタンスは、削除することをお勧めします。API グループ自体を削除する場合は、まず、関連付けられたすべての API グループインスタンスを 1 つずつ削除する必要があります。 ## [](#タスクの前提条件)タスクの前提条件 開始する前に、API グループインスタンスを削除できる「API Group Administrator (API グループ管理者)」権限があることを確認してください。 API グループを削除する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Groups (API グループ)\]**​ をクリックします。 3. 削除する API グループのバージョンを選択します。 4. **\[…​\]**​ > ​**\[Delete (削除)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [API グループ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-landing-page) - [API グループの作成](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-creating-groups) - [API グループの変更](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-modifying-groups) - [Exchange への API グループのパブリッシュ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-publishing-to-exchange) - [API グループの非推奨化](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-deprecating-groups) # API グループインスタンスの非推奨化 より新しいバージョンのグループインスタンスが存在する場合は、API グループインスタンスを非推奨にすることをお勧めします。API Manager から API グループインスタンスを非推奨にしても、Exchange の API グループアセットは非推奨になりません。 API グループインスタンスが非推奨になると、新しいコントラクトは受け入れられません。Exchange でアセットを非推奨にするには、​[「アセットの非推奨化」](https://docs.mulesoft.com/jp/exchange/manage-versions)​を参照してください。 ## [](#タスクの前提条件)タスクの前提条件 開始する前に、API グループインスタンスを非推奨にできる「API Group Administrator (API グループ管理者)」権限があることを確認してください。 API グループを非推奨にする手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Groups (API グループ)\]**​ をクリックします。 3. 非推奨にする API グループのバージョンを選択します。 4. **\[…​\]**​ > ​**\[Deprecate (非推奨)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [API グループ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-landing-page) - [グループの作成](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-creating-groups) - [グループの変更](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-modifying-groups) - [Exchange への API グループのパブリッシュ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-publishing-to-exchange) - [API グループの削除](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-deleting-groups) # API グループからの SLA 層の削除 SLA 層が不要になった場合は、API グループインスタンスから削除できます。 SLA 層を削除する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Groups (API グループ)\]**​ をクリックします。 3. \[API Groups (API グループ)\] リストを展開し、SLA 層を追加する API グループインスタンスをクリックします。 4. **\[SLA Tiers (SLA 層)\]**​ をクリックします。 5. API グループインスタンスの詳細ページで、SLA 層リストの省略記号ボタンをクリックして、​**\[Delete (削除)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [API グループ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-landing-page) - [API グループへの SLA 層の追加](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-add-sla-tiers) # API グループの API インスタンスの昇格 API グループインスタンスをある環境から別の環境 (Sandbox から本番環境など) に昇格できます。API グループインスタンスを昇格しても、インスタンスの昇格元の環境は変更されません。ただし、昇格される API グループインスタンスを作成することで昇格先の環境が変更されます。 昇格された API グループインスタンスの API インスタンスは、元のグループインスタンスとは異なる可能性がありますが、定義 (関連アセット) は同じままです。 ## [](#タスクの前提条件)タスクの前提条件 開始する前に、以下が完了していることを確認します。 - API グループインスタンスを昇格できる「API Group Administrator (API グループ管理者)」権限を取得する - 昇格する API グループインスタンスの API が昇格先の環境にすでに存在することを確認する たとえば、昇格する API グループインスタンスに Facebook API が含まれている場合、昇格先の環境にその環境種別の Facebook API がすでに存在する必要があります。 API グループインスタンスを昇格する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Groups (API グループ)\]**​ > ​**\[Promote from environment (環境から昇格)\]**​ をクリックします。 3. **\[Source Environment (昇格元環境)\]**​ リストから、昇格する API の環境を選択します。 4. **\[API Group (API グループ)\]**​ リストから、API インスタンスが属する API グループを選択します。 5. **\[API Group version (API グループバージョン)\]**​ リストから、インスタンスが属する API グループのバージョンを選択します。 6. **\[API Group instance (API グループインスタンス)\]**​ リストから、昇格する API グループインスタンスを選択します。 7. 必要に応じて、昇格元環境から宛先環境に昇格するときに SLA 層を含める場合は、​**\[Import default limits from existent SLA Tiers (既存の SLA 層からデフォルト制限をインポート)\]**​ チェックボックスをオンにします。 すべての層のデフォルト制限のみが昇格される点に注意してください。 8. **\[Promote (昇格)\]**​ をクリックします。 # API グループの SLA 層 グループ管理者は、API グループインスタンスのサービスレベル契約 (SLA) 層を指定して、アプリケーション (ユーザー) が API グループの API に対して行うことができる要求の数を制限できます。SLA を使用すると、API グループインスタンスを保護し、API へのネットワークトラフィックを管理できます。 SLA 層の定義では、API グループインスタンスへのアクセスに承認が必要かどうかも決定します。要求に対して手動承認または自動承認を設定できます。 ## [](#sla-種別)SLA 種別 SLA 層には 2 つの種別があります。 - [デフォルトの SLA](#default_SLAs)​ - [個別の SLA](#individual_SLAs) ## [](#default_SLAs)デフォルトの SLA デフォルトの制限は、すべての API インスタンスに適用されます。つまり、同じ SLA 制限がその API グループのすべての API インスタンスに適用されます。 新しい API インスタンスを API グループインスタンスに追加すると、グループ管理者によって個別の API SLA 層も設定されている場合以外は、グループインスタンスレベルで設定されたデフォルトの制限 SLA が適用されます。 ## [](#individual_SLAs)個別の SLA グループ管理者は、API グループインスタンス内の API インスタンスに対して個別の制限を定義できます。API グループインスタンスレベルでデフォルトの SLA 制限を設定し、API インスタンスレベルで個別の SLA 制限を設定した場合、個別の SLA がデフォルトの制限より優先されます。 個別の SLA が設定されていない場合、デフォルトの SLA 制限がその API インスタンスに適用されます。 レート制限ポリシーが API インスタンスに適用されている場合、グループ管理者は、基盤となる API インスタンスで新しい SLA を履行できるかどうかを判断する必要があります。 ## [](#手動承認と自動承認)手動承認と自動承認 SLA 層の自動承認を設定すると、その層が適用される API インスタンスに対して行われた要求は自動的に承認されます。この場合、コンシューマーは API グループインスタンスをすぐに使用できます。 手動承認は、手動承認フロー経由で転送されます。API グループのオーナーは、コンシューマーの要求を手動で承認する必要があります。 ## [](#階層化された-sla)階層化された SLA API グループでは、複数の SLA 制限がサポートされています。1 つの SLA 層に複数のスループット制限を設定できます。​`Premium`​ という名前の 1 つの SLA 層では、要求を 100 件/秒および 10,000/日に制限できます。 この戦略を使用すると、​`Premium`​ 層に登録されているアプリケーションの要求が 100 件/秒の制限を超えなくなります。これにより、アプリケーションによって API が殺到されなくなり、登録済みアプリケーションの想定要求数が 10,000 件/日になります。 ## [](#関連情報)関連情報 - [API グループ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-landing-page) - [API グループへの SLA 層の追加](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-add-sla-tiers) - [API グループからの SLA 層の削除](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-remove-sla-tier) - [グループインスタンスコントラクトの管理](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-manage-api-group-instance-contracts) # API グループの作成と API インスタンスの追加 一連の API をパッケージ化するには、最初に API グループを作成してから、関連する API インスタンスをグループに追加します。API グループをコンシューマーが検出できるようにするには、それを Exchange にパブリッシュする必要があります。 次の情報を使用して、API グループを作成します。API グループの作成、そのグループの最初のバージョンの作成、最初のグループインスタンスの作成を行います。さらに、API インスタンスを API グループインスタンスに追加します。 API グループインスタンスを作成した環境 (本番環境、Sandbox など) に基づいて、API グループインスタンスに API インスタンスを追加できます。たとえば、本番環境で API グループインスタンスを作成した場合、本番環境からのみ API インスタンスを API グループインスタンスに追加できます。 次の手順を使用して API グループを作成します。 1. [API グループの作成](#create-api-groups) コンシューマーによって使用可能な API グループを作成する最初のステップは、API グループを作成することです。 2. [新しい API グループへの API インスタンスの追加](#adding-api-instances-to-groups) API グループを作成したら、最初にこのグループに API インスタンスを追加します。 ## [](#タスクの前提条件)タスクの前提条件 開始する前に、以下が必要です。 - 組織またはビジネスグループ内に少なくとも 1 つの API インスタンス それがない場合、リスト内で必要な組織またはビジネスグループを見つけることができません。 - API グループを作成するための「API Group Administrator (API グループ管理者)」権限 ## [](#create-api-groups)API グループの作成 組織レベルで API グループを作成します。 API グループを作成する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Groups (API グループ)\]**​ > ​**\[Create API Group (API グループを作成)\]**​ をクリックします。 3. **\[API Group name (API グループ名)\]**​ 項目で、作成する API グループの名前 (例: `Social Chatter`​) を指定します。 4. **\[API Group version (API グループバージョン)\]**​ 項目で、API グループのバージョン (例: `v1`​) を指定します。 5. 必要に応じて、​**\[API Group instance label (API グループインスタンス表示ラベル)\]**​ 項目で、API グループの表示ラベル (内部的に使用する場合の例: `Internal`​) を指定します。 6. **\[Continue (続行)\]**​ をクリックします。 **\[Creating a new group (新規グループの作成)\]**​ ページが表示されます。これで、API グループに ​[API インスタンスを追加](#adding-api-instances-to-groups)​する準備が整いました。 ## [](#adding-api-instances-to-groups)API グループへの API インスタンスの追加 バンドルするグループに API インスタンスを追加するまで、API グループは機能しません。API インスタンスを API グループに追加する場合、以下を追加できます。 - 同じビジネスグループまたは組織に属する API インスタンスのみ - API グループインスタンスと同じ環境種別に属する API インスタンスのみ - 同じ ID プロバイダー (IdP) に属する API インスタンスのみ API グループインスタンスに IdP を混在させることはできません。 新しい API グループに新しい API インスタンスを追加する手順は、次のとおりです。 1. **\[Creating a new group (新規グループの作成)\]**​ ページで、​**\[Select environment (環境を選択)\]**​ ドロップダウンリストから環境を選択します。 2. **\[Select an API (API を選択)\]**​ リストから、追加する API インスタンスを選択します。 3. **\[Select a version / instance (バージョン/インスタンスを選択)\]**​ リストから、グループに追加する API インスタンスのバージョンを選択します。 4. API グループに追加の API インスタンスを含める場合、​**\[Add (追加)\]**​ をクリックして詳細を指定します。 5. API インスタンスと API グループが異なるビジネスグループに属している場合: 1. **\[Add Organization (組織を追加)\]**​ をクリックします。 2. API インスタンスを使用できる組織またはビジネスグループを選択し、​**\[Add (追加)\]**​ をクリックします。 3. 追加する環境、API インスタンス、およびバージョンを選択します。 6. **\[Save (保存)\]**​ をクリックします。 これで、API インスタンスが API グループに追加されます。 ## [](#関連情報)関連情報 - [API グループ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-landing-page) - [API グループの変更](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-modifying-groups) - [Exchange への API グループのパブリッシュ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-publishing-to-exchange) - [API グループの非推奨化](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-deprecating-groups) - [API グループの削除](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-deleting-groups) # API グループの変更 ビジネス要件が変更された場合、新しい API インスタンスを追加して API グループを変更することをお勧めします。新しいシナリオに対応するため、新しい API インスタンスを追加すると役立ちます。 既存のインスタンスをバージョン管理して、カスタマイズを追加することもできます。サービスが不要になった場合は、そのサービスをサポートするそれぞれの API インスタンスを削除できます。ただし、API グループと API グループインスタンスの変更には特定の​[制限](#restrictions)​があります。 Exchange で API グループをパブリッシュすると、API グループの​[状況](#exchange_status)​は特定のシナリオに基づいて変更されます。 ## [](#restrictions)API グループとインスタンスの変更に関する制限 API グループを変更する前に、制限を慎重に確認してください。 - API グループインスタンスにコントラクトがない場合にのみ、グループにすでに存在する API の新しいインスタンスを追加する。 - 同じ ID プロバイダー (IdP) に属する API インスタンスのみを追加する。 API グループインスタンスに IdP を混在させることはできません。 - 以下に該当する場合、API ではなく API インスタンスを追加する。 - API グループインスタンスがパブリッシュされている。 - API グループバージョンがパブリッシュされている。 - API グループバージョンに複数の API グループインスタンスがある。 ## [](#exchange_status)API グループトランザクションに基づく Exchange 状況 API グループの Exchange 状況は、次の条件によって異なります。 - API グループが Exchange でパブリッシュされている場合、Exchange アセットに新しい API インスタンスが表示される。 - 追加した API インスタンスが Exchange API グループアセットにすでにリンク済みのアセットに関連している場合、API インスタンスにこれらの詳細が表示される。 - 追加した API インスタンスが Exchange API グループアセットにまだリンクされていない新しいアセットに属する場合、顧客が API グループアセットの新しいバージョンを作成する必要がある。 ## [](#タスクの前提条件)タスクの前提条件 開始する前に、以下が必要です。 - 組織またはビジネスグループ内に少なくとも 1 つの API インスタンス それがない場合、リスト内で必要な組織またはビジネスグループを見つけることができません。 - API インスタンスを API グループに追加するための「API Group Administrator (API グループ管理者権限)」 ## [](#adding-api-instances-to-groups)既存の API グループへの API インスタンスの追加 API インスタンスを既存の API グループに追加し、それによって解決されるビジネス上の問題の幅を広げることができます。 既存の API グループに API インスタンスを追加する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Groups (API グループ)\]**​ をクリックします。 3. API グループの詳細ページで API グループを展開して、使用可能なバージョンを表示します。 4. API インスタンスを追加する API グループのバージョンに対して ​**\[Add Instance (インスタンスを追加)\]**​ をクリックします。 **\[Creating a new group instance (新規グループインスタンスの作成)\]**​ ページが表示されます。 5. **\[+ Add (+ 追加)\]**​ をクリックします。 6. API インスタンスと API グループが同じビジネスグループまたは組織に属している場合、API グループに追加する API、API バージョン、環境、API バージョン/インスタンスを選択します。 7. API インスタンスと API グループが異なるビジネスグループに属している場合: 1. **\[Add Organization (組織を追加)\]**​ をクリックします。 2. API インスタンスを使用できる組織またはビジネスグループを選択し、​**\[Add (追加)\]**​ をクリックします。 3. 追加する環境、API インスタンス、およびバージョンを選択します。 8. **\[Save (保存)\]**​ をクリックします。 これで、API インスタンスが API グループに追加されます。API グループを Exchange にパブリッシュするには、​[「Exchange への API グループのパブリッシュ」](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-publishing-to-exchange)​を参照してください。 ## [](#removing-api-instances-from-groups)API グループからの API インスタンスの削除 ビジネス要件が変更された場合、既存の API インスタンスを削除して API グループを変更することをお勧めします。 API グループから API インスタンスを削除する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Groups (API グループ)\]**​ をクリックします。 3. API グループのページで API グループを展開して、使用可能なバージョンを表示します。 4. API グループバージョンを展開して、使用可能なインスタンスを表示します。 5. API グループインスタンスを展開して、インスタンスの詳細を表示します。 6. ​**\[Edit (編集)\]**​ の隣にある、その他のオプションを表示するメニューアイコン ( ![overflow menu icon](/mulesoft/current/ja-jp/api-manager/latest/_images/overflow-menu-icon.png "その他のオプションを表示するメニューアイコンのスクリーンショット") ) をクリックしてから、​**\[Delete (削除)\]**​ をクリックします。
削除した API インスタンスがアセットにリンクされた最後の API である場合、API グループの新しいバージョンを作成する必要がある点に注意してください。
7. **このアクションは元に戻すことができないと**​理解したことに同意するためのチェックボックスをオンにしてから ​**\[Delete Group instance (グループインスタンスを削除)\]**​ をクリックします。 ## [](#creating-new-versions-of-groups)API グループバージョンの作成 API グループを変更して新しい API を追加したり、ビジネス要件の変更に基づいて既存の API を削除したりする場合は、API グループを適切にバージョン管理することをお勧めします。 API グループの追加バージョンを作成する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Groups (API グループ)\]**​ をクリックします。 3. API グループに対して ​**\[Add group version (グループバージョンを追加)\]**​ をクリックします。 4. **\[API Group Version (API グループバージョン)\]**​ 項目で、作成するバージョン番号 (例: `v1.1`​ または ​`v2.0`​) を指定します。 5. **\[API Group instance label (API グループインスタンス表示ラベル)\]**​ 項目に、このグループインスタンスを一意に識別する表示ラベルを入力します。 6. **\[Continue (続行)\]**​ をクリックします。 . 7. API グループに API インスタンスを追加します。 API グループには、以前のバージョンの既存のインスタンスが事前に取り込まれています。API グループに API インスタンスを追加する方法についての詳細は、​[「既存のグループへの API インスタンスの追加」](#adding-api-instances-to-groups)​を参照してください。 8. **\[Save (保存)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [API グループ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-landing-page) - [グループの作成](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-creating-groups) - [Exchange への API グループのパブリッシュ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-publishing-to-exchange) - [グループの非推奨化](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-deprecating-groups) # API グループへの SLA 層の追加 1 つの API グループインスタンスに複数の SLA 層を追加できます。 SLA 層を追加する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Groups (API グループ)\]**​ をクリックします。 3. **\[API Groups (API グループ)\]**​ リストを展開し、SLA 層を追加する API グループインスタンスをクリックします。 4. **\[SLA Tiers (SLA 層)\]**​ をクリックし、詳細ページで ​**\[Add SLA tier (SLA 層を追加)\]**​ をクリックします。 5. SLA 層の名前 (例: `Premium`​) を入力します。 6. 説明を入力します (省略可能)。 7. **\[Approval (承認)\]**​ メソッドとして ​**\[Manual (手動)\]**​ または ​**\[Automatic (自動)\]**​ を選択します。 8. **\[Continue (続行)\]**​ をクリックします。 9. SLA 層を API グループインスタンス内のすべての API インスタンスに適用する場合は、SLA 層の詳細ページの上部にある ​**\[Default (デフォルト)\]**​ タブをクリックします。 それ以外の場合、​**\[Individual (個々)\]**​ をクリックし、API グループインスタンス内の特定の API インスタンスに適用します。
API グループインスタンス内のその API インスタンス固有の制限を作成する場合、API インスタンスの SLA 層をコピーできます。必要に応じて、コピーした制限を変更できます。
10. **\[# of Reqs (要求数)\]**​ 項目で、許可されている要求数 (例: `100`​) を追加します。 11. **\[Time Period (期間)\]**​ 項目で、期間 (例: `60`​) を指定します。 12. **\[Time Unit (時間単位)\]**​ 項目で、ドロップダウンリストから時間単位 (例: `Second`​) を選択します。 13. コントラクトと共に SLA 層を表示する場合は、​**\[Visible (参照可能)\]**​ チェックボックスをオンにします。 14. 追加の SLA 層を作成する場合は、​**\[Add new limit (新規制限を追加)\]**​ をクリックします。 15. **\[Save (保存)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [API グループからの SLA 層の削除](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-remove-sla-tier) - [グループインスタンスコントラクトの管理](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-manage-api-group-instance-contracts) # API コントラクトの取り消しと削除 ルート組織のシステム管理者は、アプリケーションによる API へのアクセスを可能にしているコントラクトを取り消したり削除したりできます。コントラクトを取り消した場合は、いつでも復元できます。 コントラクトを削除すると、承認済みのコントラクトが Anypoint Exchange から削除されます。コントラクトを取り消すと、クライアントアプリケーションは API にアクセスできなくなります。コントラクトを取り消した場合は、いつでも復元したり削除したりできます。コントラクトを削除するには、先に取り消す必要があります。 アプリケーションのコントラクトを削除するには、次の手順を実行します。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、アクセスを取り消す API インスタンスの名前をクリックします。 3. `:`​ のリンクをクリックします (例: `v1:16046365`​)。 4. **\[Contracts (コントラクト)\]**​ をクリックします。 5. アクセスを取り消すアプリケーションの ​**\[Revoke (取り消し)\]**​ をクリックします。 **\[Restore (復元)\]**​ オプションと ​**\[Delete (削除)\]**​ オプションが表示されます。 6. コントラクトを削除するには、​**\[削除\]**​ をクリックします。 ## [](#関連情報)関連情報 - [Exchange からの API インスタンスへのアクセス権の要求](https://docs.mulesoft.com/jp/exchange/to-request-access) - [API インスタンスコントラクトの削除](#) - [クライアントアプリケーションのクライアント ID とクライアントシークレットログイン情報の取得](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task) # API のプロキシの設定 外部アプリケーションとバックエンドサーバー間の中継として機能する API プロキシを使用して、API または Web サービスを攻撃から保護します。API プロキシは、バックエンドの場所やプログラミング言語に依存しません。さらに、バックエンドを Mule 以外のアプリケーションにすることもできます。 API の前に API プロキシをデプロイすると、プロキシは API ゲートウェイ機能を採用し、さまざまな種類の​[ポリシー](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis)​を使用して API を保護します。Anypoint Platform を使用すると、プロキシアプリケーションを CloudHub または Anypoint Runtime Fabric に直接デプロイできます。これにより、プロキシアプリケーションは API Manager によって自動的に追跡されます。 プロキシを使用するエンドポイントとして API を設定すると、API Manager はプロキシアプリケーションを自動的に生成し、アプリケーションに自動検出機能を含めます。Mule はすべてのポリシーが適用されるまで API をロックします。クライアントアプリケーション (コンシューマー) がプロキシをコールし、プロキシから API にコールが転送されます。アプリケーションをデプロイした後、Mule インスタンスはクライアント ID とシークレットを使用して API Manager をコールし、API のポリシーを取得します。 ## [](#api-プロキシを使用する状況)API プロキシを使用する状況 API プロキシは次の場合に使用できます。 - API が稼働中で、その API が Mule Runtime Engine (Mule) サーバーでまだホストされていない場合 - クローズドコードである Mule アプリケーションがすでにあり、その​[自動検出](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule4)​を含めるためのアクセス権がない場合 - RAML、OAS、または SOAP API のすべての受信要求に対してスキーマ検証を実行する場合 API の作成に使用した仕様の種類に応じて、次の API プロキシのいずれかを適用できます。 - HTTP または ​[HTTPS](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy) - [WSDL](https://docs.mulesoft.com/jp/api-manager/latest/building-soap-proxy) - [RAML または OAS](https://docs.mulesoft.com/jp/api-manager/latest/proxy-deploy-raml-oas-proxy) ## [](#api-プロキシの仕組み)API プロキシの仕組み オンプレミス Mule インスタンスを実行している場合は、事前設定済み Mule アプリケーションをダウンロードし、​[正しい Anypoint Platform ログイン情報を使用して Mule インスタンスを設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule4)​することで、他の Mule アプリケーションと同じ方法でデプロイできます。 次の図は、要求がプロキシエンドポイントと通信し、バックエンドサーバーから応答を返す方法を示しています。 ![API プロキシフローの概要](/mulesoft/current/ja-jp/api-manager/latest/_images/api-proxy-flow-diagram.png) 図に示されているように、外部コンシューマーアプリケーションが要求を送信すると、最初にプロキシエンドポイントへの ping を実行します。この時点で、API に適用されてプロキシアプリケーションで参照されるすべてのポリシーが有効になります。 ポリシーがいずれかの検証に失敗した場合、エラー応答が返され (失敗したポリシーに該当)、要求はバックエンドに到達しません。逆に、ポリシーによって実行されたすべての検証とアクションが成功した場合、要求はバックエンド API に送られ、プロキシはこの応答をコンシューマーアプリケーションに返します。 ポリシーが無効な要求を検出した場合、その要求はバックエンド API に到達しません。逆に、すべての検証が成功した場合、要求は処理のためにバックエンド API に送られ、プロキシは応答がコンシューマーアプリケーションに返されることを許可します。 ## [](#api-プロキシの利点)API プロキシの利点 API プロキシは、チームのパフォーマンスとバックエンド API のセキュリティを向上させ、ポリシーを使用して受信要求を検証します。API プロキシには次の利点があります。 - エンジニアリング帯域幅が増加 数回クリックするだけで、プロキシを ​[Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/)​、​[CloudHub](https://docs.mulesoft.com/cloudhub/)​、​[ハイブリッド](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies#hybrid-deployments.adoc)​、または​[スタンドアロン Mule](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model)​ に直接デプロイできます。Mule アプリケーションの作成方法がわからない場合でも、API Manager が自動検出を使用してアプリケーションを作成および設定するため、デプロイの完了後に API Manager によって API が自動的に追跡されます。 - カスタマイズが可能 ほとんどの場合、API Manager で生成されたプロキシはデプロイメントに適しています。ただし、Mule 環境では ​[Anypoint Studio](https://docs.mulesoft.com/studio/import-export-packages)​ を使用して、カスタム要件に合わせてプロキシを編集できます。 - ポリシーと ​[Mule API Analytics](https://docs.mulesoft.com/jp/api-manager/latest/viewing-api-analytics)​ を使用して API を保護および管理する プロキシを使用すると、Mule API Analytics へのアクセスを含め、API ゲートウェイの全機能を使用して API を保護できます。 - 検証を実装する RAML、REST、WSDL プロキシを含むほとんどのプロキシでは、API 定義を使用して、すべての受信要求に対する検証を実行できます。要件に応じて、さまざまなレベルの検証を選択できます。 - 通常の検証 ペイロード、クエリパラメーター、URI パラメーター、ヘッダー、フォームパラメーターを API 仕様で定義されたスキーマと比較します。この設定を使用すると、API 仕様の未指定のクエリパラメーターとヘッダーもバックエンドサービスに送信されます。 - 厳格な検証 API 仕様で明示的に定義されている要求、パラメーター、ヘッダーのみを受け入れ、バックエンドが受け取るパラメーターを制御することで API のセキュリティを確保します。 ## [](#関連情報)関連情報 - [API プロキシのダウンロード](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task) - [API プロキシのデプロイ](https://docs.mulesoft.com/jp/api-manager/latest/proxy-latest-concept) - [API プロキシの状況コードの処理](https://docs.mulesoft.com/jp/api-manager/latest/wsdl-raml-http-proxy-reference) # API プロキシのダウンロード 実装を変更せずにプロキシを使用して API を管理し、サーバーへの攻撃を回避します。Mule Runtime は、Mule プロキシアプリケーションをホストするサーバーです。
プロキシをダウンロードするには、「API 設定の表示」権限が必要です。
API Manager で生成したプロキシをダウンロードする手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、プロキシをダウンロードする API インスタンスの名前をクリックします。 3. **\[Actions (アクション)\]**​ をクリックして ​**\[Download Proxy (プロキシをダウンロード)\]**​ を選択します。 ## [](#関連情報)関連情報 - [環境にアクセスするための権限の付与](https://docs.mulesoft.com/jp/api-manager/latest/environment-permission-task) - [API Manager における API インスタンスの作成](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page) - [API ゲートウェイの API 自動検出の概念の確認](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-autodiscovery-overview) # API プロキシのデプロイ API プロキシを CloudHub、Runtime Fabric、またはハイブリッドクラウド環境にデプロイできます。プロキシアプリケーションに割り当てられるリソースは、使用しているプロキシの種別によって異なります。たとえば、CloudHub プロキシには、デフォルトで 0.1 vCore の CPU と 500 MB のメモリが含まれています。 必要に応じて、​[Runtime Manager](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub#change-settings-of-a-deployed-application.adoc)​ からリソースの割り当てを変更します。 ## [](#前提条件)前提条件 Runtime Fabric またはハイブリッドクラウド環境で作業する場合は、API プロキシをデプロイする前に、次の要件を満たしてください。 - Runtime Fabric - アカウントで「Manage APIs Configuratio (API 設定の管理)」および「Deploy API Proxies (API プロキシのデプロイ)」権限を取得する。 - Mule バージョン 3.8.7、3.9.1, 4.1.2、またはそれ以降を使用する。 - Hybrid: - 非公開サーバーの場合、組織用に設定された Mule Runtime Engine (Mule) インスタンスへのアクセス権を取得する。 Mule インスタンスをサーバーとして設定する方法についての詳細は、​[「Runtime Manager へのサーバーの追加」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 - Mule インスタンスと互換性のある Mule エージェントを使用して非公開サーバーを登録する。 Mule バージョン 3.8 以降の場合は、Mule エージェント 1.9.0 を使用します。Mule 4.x の場合はリリースノートで指定された Mule Agent を使用します。 ## [](#api-プロキシのデプロイ)API プロキシのデプロイ プロキシをデプロイするには、以下の手順を完了します。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Add new API (新しい API を追加)\]**​ をクリックします。 3. ランタイムとして ​**\[Mule Gateway (Mule ゲートウェイ)\]**​ を選択します。 4. **\[Proxy type (プロキシ種別)\]**​ で ​**\[Deploy a proxy application (プロキシアプリケーションをデプロイ)\]**​ を選択します。 5. プロキシアプリケーションのデプロイを選択した場合は、以下のオプションから​**対象種別**​を選択します。 - **CloudHub 2.0**​: コンテナベースのクラウドインフラストラクチャで MuleSoft によってホストされている Mule Runtime を使用する場合は、このオプションを選択します。CloudHub 2.0 プロキシには、デフォルトで 0.1 vCore の CPU が含まれています。 1. スペースを選択します。 スペースについての詳細は、​[Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) and [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about)​を参照してください。 2. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 3. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **CloudHub:**​ MuleSoft によってクラウドでホストされている Mule Runtime を使用する場合は、このオプションを選択します。CloudHub プロキシには、デフォルトで 0.1 vCore の CPU と 500 MB のメモリが含まれています。 1. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 2. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **Hybrid (ハイブリッド):**​ Runtime Manager に登録されているオンプレミスサーバーで実行される Mule Runtime インスタンスを使用する場合、このオプションを選択します。 詳細は、​[「Runtime Manager でのサーバーの登録」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 1. リストから接続先を選択するか、​**\[Add server (サーバーを追加)\]**​ をクリックします。 2. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **Self-managed Server (自己管理型サーバー):**​ JAR ファイルを作成して、Runtime Manager に登録されていないオンプレミスサーバーで実行される Mule Runtime インスタンスに API プロキシをデプロイする場合、このオプションを選択します。詳細は、[On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model)を参照してください。 API Manager で API プロキシを自己管理型サーバーにデプロイしても、プロキシはオンプレミスサーバーにデプロイされません。API Manager でプロキシをデプロイした後に、プロキシをオンプレミスサーバーにデプロイします。 . [新しい API プロキシ JAR ファイルをダウンロードします](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task)​。 . [JAR ファイルをオンプレミスサーバーにデプロイします](https://docs.mulesoft.com/mule-runtime/latest/deploy-on-premises)​。 - **Runtime Fabric:**​ Runtime Fabric で管理された Mule Runtime Engine に API プロキシをデプロイする場合、\[Runtime Fabric\] を選択します。 詳細は、​[「Runtime Fabric への API プロキシのデプロイ」](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric)​を参照してください。 1. リストから対象を選択します。 2. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 3. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 1. 以下のオプションから API を選択します。 - 管理する API を Exchange を介して共有している場合、​**\[Select API from Exchange (Exchange から API を選択)\]**​ をクリックします。 1. **\[Select API (API を選択)\]**​ の下のリストから API をクリックします。必要に応じて、特定の API を検索できます。 2. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 3. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。​**\[Conformance Status (準拠状況)\]**​ が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 - **\[Create new API (新しい API を作成)\]**​ をクリックします。 1. 新しい API アセットの​**名前**​を入力します。 2. 以下のオプションから​**アセットタイプ**​を選択します。 - **REST API:**​ アセットに含める RAML または OAS API 定義ファイルがある場合は、このオプションを選択します。 REST API の RAML または OAS ファイルをアップロードします。バージョン 2.0.0 以降ではネイティブ OAS サポートが追加されるので、OAS または RAML 仕様に推奨されるバージョンです。OAS API 仕様を API プロキシバージョン 1.0 以前にアップロードすると、API 仕様は RAML に変換されます。 - **HTTP API:**​ アセットに含める API 定義ファイルがない場合は、このオプションを選択します。 - **SOAP API:**​ WSDL API 定義ファイルまたはファイルへの外部リンクがある場合は、このオプションを選択します。 SOAP API の WSDL ファイルをアップロードするか、ファイルへのリンクを追加します。 このオプションは、現時点では Flex Gateway ランタイムでは使用できません。 3. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 4. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。\[Conformance Status (準拠状況)\] が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 1. **\[Next (次へ)\]**​ をクリックします。 2. ダウンストリーム設定を定義します。 設定を確認するには展開します。
項目名 説明 必須 注意事項

Protocol (プロトコル)

検証に HTTP と HTTPS のどちらを使用するかを指定します。

はい

HTTPS を選択する場合、インバウンドトラフィックの TLS コンテキストを指定します。

Inbound TLS (インバウンド TLS)

インバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。Mule 3 環境で HTTPS を有効にするには、​「Mule 3x での HTTPS の有効化」​を参照してください。

Port (ポート)

表示されたポートが正しくない場合に使用する番号を指定します。

はい

Base Path (ベースパス)

ホストルートに相対的なすべての API パスの URL プレフィックスを指定します。スラッシュ ​/​ で始まる必要があります。

はい

Instance label (インスタンス表示ラベル)

API の表示ラベルを指定します。

いいえ

同じ API の複数の管理インスタンスがある場合、各インスタンスを他のインスタンスと区別するための表示ラベルを追加します。

Advanced Options (詳細オプション)

Consumer endpoint (コンシューマーエンドポイント)

コンシューマーが要求の送信に使用するプロキシアプリケーションのアドレスを指定します。

いいえ

Client provider (クライアントプロバイダー)

API のクライアントプロバイダーを指定します。

はい

Anypoint Platform はデフォルトではクライアントプロバイダーとして機能します。外部クライアントプロバイダーを設定するには、​「クライアントプロバイダー」​を参照してください。

Request Timeout (要求タイムアウト)

要求がタイムアウトするまでの期間を指定します。

いいえ

Proxy Version (プロキシバージョン)

エンドポイントに使用するプロキシのバージョンを指定します。

いいえ

Service Name (サービス名)

WSDL サービスの名前。

はい

WSDL API でのみ使用できます。

Service Port (サービスポート)

WSDL サービスのポート。

はい

WSDL API でのみ使用できます。

Service Namespace (サービス名前空間)

WSDL サービスの名前空間。

はい

WSDL API でのみ使用できます。

Enable Console (コンソールを有効化)

API 仕様を公開およびテストできるかどうかを指定します。

いいえ

[Console Path (コンソールパス)]​ に別のパス (​/spec/*​ など) を指定できます。関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

Validations (検証)

提供された仕様に対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

厳格な検証 (省略可能)

クエリパラメーターに対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます+

User Domain (ユーザードメイン)

API ゲートウェイドメインを使用するかどうかを指定します。

いいえ

設定で以前にプロキシデプロイメント対象として ​[Hybrid (ハイブリッド)]​ を選択した場合は、必ずこのオプションを選択してください。Mule 3.8 以降の API ゲートウェイドメインをインストールする必要があります。

3. **\[Next (次へ)\]**​ をクリックします。 4. アップストリーム設定を定義します。 設定を確認するには展開します。
項目名 説明 必須 注意事項

Upstream URL (アップストリーム URL)

プロキシまたは API にアクセスするための URL。

はい

たとえば、Exchange の API アセットの URL を使用できます。

Outbound TLS (アウトバウンド TLS)

アウトバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。

5. **\[Next (次へ)\]**​ をクリックします。 6. 選択内容を確認し、必要に応じて編集します。 7. デプロイする準備ができたら、​**\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。または、​**\[Save (保存)\]**​ を選択して API インスタンスを保存し、後でデプロイします。 ## [](#関連情報)関連情報 - [HTTPS エンドポイントの設定](https://docs.mulesoft.com/jp/api-manager/latest/https-reference) # API プロキシの利点と影響の確認 次の表で、さまざまな種類の API プロキシを実装する主な利点と影響について説明します。 ## [](#利点)利点
利点 WSDL RAML/OAS HTTP HTTPS

API Manager でプロキシを追跡し、Mule API Analytics を生成する。自動検出が必要。

はい

はい

はい

はい

API ガバナンスのポリシーを適用する。

はい

はい

はい

はい

MuleSoft 提供のポリシーに関連するエラーを soap:fault メッセージとして送信する。

はい

いいえ

いいえ

いいえ

API 要求をシミュレーションする API コンソールがある。

デフォルトでは、次の形式の URL を使用して API コンソールを開くことができます。​<host_of_your_proxy>:<port_of_your_proxy>/console

いいえ

はい

いいえ

いいえ

## [](#影響)影響 API プロキシを経由する要求への影響は次のとおりです。
影響 WSDL RAML/OAS HTTP HTTPS

X-Forwarded-For ヘッダーを含む。

はい

はい

はい

はい

受信したヘッダー (Mule-included ヘッダーを除く) を実装 API に送信する。

Mule-included ヘッダーには、X-MULE-SESSION、X-MULE-ENCODING などがあります。

はい

はい

はい

はい

ヘッダー、本文、URI、クエリ、およびフォームパラメーター API を RAML 0.8/1.0 に対して検証する。

いいえ

はい

いいえ

いいえ

RAML で指定されているが要求に含まれていないデフォルトのパラメーター値を指定する。

いいえ

はい

いいえ

いいえ

サーバー認証用に TLS 設定で指定されたキーストアとトラストストアを使用してセキュア接続を処理する。

いいえ

いいえ

いいえ

はい

## [](#関連情報)関連情報 - [API コンソール - API コールのシミュレーション方法](https://docs.mulesoft.com/jp/apikit/latest/apikit-4-implement-rest-api) # API プロキシの状況コードの処理 Mule 4 では、次の表に示すように WSDL、RAML、HTTP、および HTTPS プロキシでエラーと要求が処理されます。Mule 4 は、プロキシ種別に応じてさまざまなエラーコードを返し、問題のある要求にはエラーコードを返しません。次の表に、WSDL、RAML、HTTP、および HTTPS プロキシが問題のある要求を受信したときに、Mule が 504、400、または 404 エラーコードを返すかどうかを示します。
エラーコード WSDL RAML OAS HTTP HTTPS

504: 要求タイムアウト

はい

はい

はい

はい

はい

400: 不正な要求 (検証結果)

はい

いいえ

はい

いいえ

いいえ

404: リソースが見つからなかった

いいえ

はい

はい

いいえ

いいえ

405: メソッドが API 仕様で許可されていない

いいえ

いいえ

はい

いいえ

いいえ

# API 定義のアップロードによる API インスタンスの作成 このページのコンテンツは、​[「API インスタンスの追加」](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page)​に移動されました。 # API 管理の入門 API Manager を使用して、API インスタンスにポリシーを適用したり、コントラクト、アラート、SLA 層を追加したりできます。さらに、CloudHub または CloudHub 2.0 で実行される API のランタイムを設定できます。Mule Runtime Engine (Mule) やハイブリッドを使用して API ランタイムをデプロイすることもできますが、最短で最も簡単な方法は API プロキシを直接 CloudHub にデプロイすることです。
スタンドアロンサーバーで API を実行している場合、​従来の API 作成フロー​を使用して API を管理します。
次の手順を使用して API を管理できます。 1. [Exchange での API アセットの作成](https://docs.mulesoft.com/jp/exchange/to-create-an-asset#create-an-api-asset) Exchange で REST、HTTP、または SOAP API アセットを作成し、API Manager でそれを API インスタンスとして管理できます。 2. [API Manager での API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page) API インスタンスは、アップストリーム用の API のプロキシです。API インスタンスはポリシーの適用をサポートし、API ゲートウェイにデプロイできます。 3. [API Manager でのポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-secure-conn) ポリシーは API の機能を拡張し、セキュリティなど特定の機能を適用します。ポリシーはアクセスとトラフィックを制御できます。たとえば、ポリシーは通常、認証、アクセス、割り当てられたコンシューム量、サービスレベルアクセス (SLA) を制御できます。 ## [](#関連情報)関連情報 - [SLA 層について](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) - [API へのアクセス権の付与について](https://docs.mulesoft.com/jp/api-manager/latest/api-contracts-landing-page) - [API プロキシについての詳細](https://docs.mulesoft.com/jp/api-manager/latest/api-proxy-landing-page) # API 自動検出設定時のデプロイメントエラー API 自動検出用に Mule ゲートウェイを設定すると、次の「failed to deploy artifact (アーティファクトのデプロイに失敗しました)」というエラーが表示される場合があります。 ```text org.mule.runtime.deployment.model.api.DeploymentException: Failed to deploy artifact [accounts] Caused by: org.mule.runtime.api.exception.MuleRuntimeException: org.mule.runtime.deployment.model.api.DeploymentInitException: PropertyNotFoundException: Couldn't find configuration property value for key ${apiId} from properties provider Domain properties - within resolver Deployment properties trying to process key apiId - within resolver global-properties configuration attributes trying to process key apiId - within resolver environment properties provider trying to process key apiId - within resolver Deployment properties trying to process key apiId - within resolver External files trying to process key apiId - within resolver Deployment properties trying to process key apiId ``` ## [](#原因)原因 この問題は、​`config.properties`​ ファイルに ​`apiId`​ プロパティを追加せず、​`api-gateway:autodiscovery`​ 要素で ​`apiId`​ 属性の値の変更に失敗した場合に発生します。自動検出プロセスは、API Manager の特定のインスタンスで実行されます。そのため、​`long`​ 型の有効な ​`apiId`​ を指定する必要があります。 API Manager を介してプロキシアプリケーションをデプロイした場合、または自動生成されたプロキシをダウンロードした場合、この設定は自動的に定義されます。 ## [](#解決策)解決策 この問題を解決する手順は、次のとおりです。 1. config.properties ファイルに移動し、次のプロパティと値のペアを追加します。 ```text apiId=[your-specific-value] ``` 2. 要素で、​`apiID`​ 属性を config.properties ファイルの ​`apiId`​ プロパティに設定します。 ```text apiId=${apiId} ``` ## [](#関連情報)関連情報 [設定プロパティの設定](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-to-configure)​ # Exchange への API グループのパブリッシュ API グループを作成または編集して必要な API インスタンスを追加したら、API グループを Exchange にパブリッシュして、コンシューマーが使用できるようにします。 ## [](#タスクの前提条件)タスクの前提条件 開始する前に、Exchange の API グループインスタンスのすべてのアセットに対する権限があることを確認してください。 ### [](#exchange-に-api-グループをパブリッシュする)Exchange に API グループをパブリッシュする 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Groups (API グループ)\]**​ をクリックします。 3. API グループの詳細ページから、パブリッシュする ​**\[API Group version (API グループバージョン)\]**​ をクリックして、​**\[API Group instance (API グループインスタンス)\]**​ をクリックします。 API グループインスタンスページが表示されます。 ![Exchange への API グループのパブリッシュ](/mulesoft/current/ja-jp/api-manager/latest/_images/publish-api-product-to-exchange.png) 4. インスタンスがまだ Exchange にパブリッシュされていない場合、ページに ​**\[Publish to Exchange (Exchange にパブリッシュ)\]**​ ボタンが表示されます。 5. **\[Publish to Exchange (Exchange へのパブリッシュ)\]**​ をクリックします。 6. **\[Publish (パブリッシュ)\]**​ ウィンドウで、API グループアセットの名前とバージョンを指定します。 7. **\[Publish (パブリッシュ)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [API グループ](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-landing-page) - [グループの作成](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-creating-groups) - [グループの変更](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-modifying-groups) - [グループの非推奨化](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-deprecating-groups) - [API グループの削除](https://docs.mulesoft.com/jp/api-manager/latest/api-groups-deleting-groups) # Flex Gateway API インスタンスの追加 Design Center またはその他のアプリケーションを使用して API を作成したら、API インスタンスを追加して、API Manager でその API を管理できます。API は、削除するまで API Manager の管理下に置かれます。 分散およびマイクロサービス環境で動作し、CI/CD 環境に適合する柔軟で高性能の API ゲートウェイを必要とする API の場合、Flex Gateway を使用します。 API インスタンスを追加するには、次の 3 つのオプションがあります。 - [**Add a new API (新しい API を追加):**](#add-api)​ API の完全に新しいインスタンスを追加するには、このオプションを選択します。 - [**Promote API from environment: (環境から API を昇格):**](#promote-api)​ Sandbox 環境などの別の環境に API インスタンスがあり、それを現在の環境または本番環境に昇格する場合、このオプションを選択します。 - [**Import API from zip file (zip ファイルから API をインポート):**](#import-api)​ 別の Anypoint Platform インスタンスから API インスタンスをエクスポートしている場合、このオプションを選択します。 API インスタンスを昇格またはインポートするときに、設定を変更するオプションはありません。ただし、新しい API インスタンスを追加する場合、ダウンストリームとアップストリームの設定を定義する必要があります。 次の図は、アップストリームおよびダウンストリームの設定と、アップストリームサービスおよびダウンストリームコンシューマーアプリケーションとの関係を示しています。この設定では、ダウンストリームサービスは、アップストリームサービスによって完了される API 要求を行うサービスです。これらの用語は、情報の方向ではなく、連動関係の方向を表します。ダウンストリームサービスは、アップストリームサービスに情報を提供する ​`POST`​ 要求を行うことができます。ただし、ダウンストリームサービスは、要求の完了には引き続きアップストリームサービスに連動します。 ![API インスタンスは、アップストリーム設定とダウンストリーム設定の間のゲートウェイにデプロイされます。](/mulesoft/current/ja-jp/api-manager/latest/_images/api-upstream-downstream-config.png) ## [](#add-api)新しい API を追加する 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Add new API (新しい API を追加)\]**​ をクリックします。 3. **\[Flex Gateway\]**​ を選択します。 4. **\[Select a gateway (ゲートウェイを選択)\]**​ の下のリストから、インストールして登録した接続済み Flex Gateway を選択します。

Flex Gateway がリストに表示されない場合、または Flex Gateway が表示されていて状況が [Disconnected (切断済み)] の場合、​「Flex Gateway のインストール」​および​「接続モードでの登録と実行」​を参照してください。

5. **\[Next (次へ)\]**​ をクリックします。 6. 以下のオプションから API を選択します。 - 管理する API を Exchange を介して共有している場合、​**\[Select API from Exchange (Exchange から API を選択)\]**​ をクリックします。 1. **\[Select API (API を選択)\]**​ の下のリストから API をクリックします。必要に応じて、特定の API を検索できます。 2. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 3. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。​**\[Conformance Status (準拠状況)\]**​ が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 - **\[Create new API (新しい API を作成)\]**​ をクリックします。 1. 新しい API アセットの​**名前**​を入力します。 2. 以下のオプションから​**アセットタイプ**​を選択します。 - **REST API:**​ アセットに含める RAML または OAS API 定義ファイルがある場合は、このオプションを選択します。 REST API の RAML または OAS ファイルをアップロードします。バージョン 2.0.0 以降ではネイティブ OAS サポートが追加されるので、OAS または RAML 仕様に推奨されるバージョンです。OAS API 仕様を API プロキシバージョン 1.0 以前にアップロードすると、API 仕様は RAML に変換されます。 - **HTTP API:**​ アセットに含める API 定義ファイルがない場合は、このオプションを選択します。 3. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 4. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。\[Conformance Status (準拠状況)\] が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 7. **\[Next (次へ)\]**​ をクリックします。 8. ダウンストリーム設定を定義します。
項目名 説明 必須 注意事項

Protocol (プロトコル)

HTTP と HTTPS のどちらを使用するかを指定します。

はい

HTTPS を選択する場合、インバウンドトラフィックの TLS コンテキストを指定します。

Inbound TLS (インバウンド TLS)

HTTPS API のインバウンドトラフィックで使用する TLS コンテキスト。

いいえ

TLS コンテキストを API に追加する前に ​Flex Gateway の TLS コンテキストを設定します​。Flex 1.4.0 以降でのみ使用できます。

Port (ポート)

表示されたポートが正しくない場合に使用する番号を指定します。

いいえ

API インスタンスは、​ベースパス​が両方のインスタンスで異なる場合、同じ対象間で同じポートを共有できます。Flex 1.2.0 以降でのみ使用できます。

Base Path (ベースパス)

ホストルートに相対的なすべての API パスの URL プレフィックスを指定します。スラッシュ ​/​ で始まる必要があります。

はい

Instance label (インスタンス表示ラベル)

API の表示ラベルを指定します。

いいえ

同じ API の複数の管理インスタンスがある場合、各インスタンスを他のインスタンスと区別するための表示ラベルを追加します。

Advanced Options (詳細オプション)

Consumer endpoint (コンシューマーエンドポイント)

コンシューマーが要求の送信に使用するプロキシアプリケーションのアドレスを指定します。

いいえ

Client provider (クライアントプロバイダー)

API のクライアントプロバイダーを指定します。

いいえ

Anypoint Platform はデフォルトではクライアントプロバイダーとして機能します。外部クライアントプロバイダーを設定するには、​「クライアントプロバイダー」​を参照してください。

9. **\[Next (次へ)\]**​ をクリックします。 10. 次のいずれかのアップストリーム設定を定義します。 - **1 つのアップストリームサービス**​ Flex Gateway バージョン 1.4.x 以前、または 1 つのアップストリームサービスを使用する Flex Gateway バージョン 1.5.x の場合、次のアップストリーム設定を定義します。
項目名 説明 必須 注意事項

Upstream URL (アップストリーム URL)

プロキシまたは API にアクセスするための URL。​/​ で終了する必要があります。

はい

たとえば、Exchange の API アセットの URL を使用できます。

Outbound TLS (アウトバウンド TLS)

アップストリームサービスへのアウトバウンドトラフィックに使用される TLS コンテキスト。

いいえ

TLS コンテキストを API に追加する前に ​Flex Gateway の TLS コンテキストを設定します​。Flex 1.4.0 以降でのみ使用できます。

- **複数のアップストリームサービス**​ Flex Gateway バージョン 1.5.x 以降は、1 つのコンシューマーエンドポイントを通じて複数のアップストリームサービスを公開する API インスタンスがサポートされます。 複数のアップストリームサービスを設定するには、​[接続モードで実行されている Flex Gateway での複数のアップストリームサービス](#traffic-management)​を参照してください。 11. **\[Next (次へ)\]**​ をクリックします。 12. 選択内容を確認し、必要に応じて編集します。 13. デプロイする準備ができたら、​**\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。または、​**\[Save (保存)\]**​ を選択して API インスタンスを保存し、後でデプロイします。 ## [](#traffic-management)接続モードで実行されている Flex Gateway での複数のアップストリームサービス Flex Gateway バージョン 1.5.x 以降は、1 つのコンシューマーエンドポイントを通じて複数のアップストリームサービスを公開する API インスタンスがサポートされます。 Flex Gateway は、トラフィックを複数のアップストリームサービスに転送できるさまざまなルートを使用して要求トラフィックを管理します。Flex Gateway はルート順と各ルートのルールを使用してトラフィックをルートに転送します。さらに、ルート内の各アップストリームサービスに加重率を追加してアップストリームサービスに送信される要求の割合を管理できます。 次の図では、さまざまなルートでフライト情報データベースへの要求やカスタマーサービスアプリケーションへの要求を管理しています。ルート 1 には 2 つのアップストリームサービスが定義されており、要求の 70% は安定したデータベースに送信され、要求の 30% はベータデータベースに送信されます。 ![Flex Gateway は複数のアップストリームへのトラフィックを管理する](/mulesoft/current/ja-jp/api-manager/latest/_images/multiple-upstreams.png) ### [](#制限)制限
制限 値 注意事項

API ごとのアップストリーム

50

各 API は 50 個のアップストリームをサポートします。50 個のアップストリームは、さまざまなルートの組み合わせで構成できます。

API あたりのルート数

50

各 API は 50 個のルートをサポートします。

ルートあたりのアップストリーム数

10

ルートルールあたりのヘッダー数

10

### [](#ルート)ルート 各 API インスタンスは最大 50 個のルートをサポートし、各ルートは最大 10 個のアップストリームサービスをサポートできます。ルートのルールと順序を定義して、ルートが受信できる要求を設定します。API インスタンスごとに少なくとも 1 つのルートが必要です。 ルートを追加する前に、わかりやすくするために省略可能な​**ルートの表示ラベル**​を入力します。 ルートを追加するには ​**\[Add Route (ルートを追加)\]**​ をクリックし、ルートを削除するには​**ゴミ箱**​アイコン (​![2%](/mulesoft/current/ja-jp/api-manager/latest/_images/trash-can-icon.png)​) をクリックします。1 つのルートのみ設定されている場合、そのルートは削除できません。 #### [](#ルートルール)ルートルール ルートルールを使用して、要求をさまざまなルートに転送できます。 ルートルールを表示および編集するには、​**\[Route Rules (ルートルール)\]**​ をクリックします。 すべてのルールは省略可能です。ルールに値がない場合、そのルールは無視されます。たとえば、ホストを指定しないと、要求が他のルートルールを満たす場合にルートは任意のホストをサービスできます。ルールを定義しないと、ルートはすべての要求をサービスできます。 異なるルートで同じアップストリームサービスをサポートできます。1 つのルートルールセットでアップストリームサービスの特定のセットに対するすべての要求を取得できない場合は、完全にカバーするために異なるルールを使用して複数のルートを定義できます。 ルールセットで定義されたルールをすべて満たす要求のみがそのルートに送られます。要求がどのルートのルールも満たさないと、Flex Gateway によって ​`404`​ エラーコードが返されます。 Flex Gateway では以下のルートルールがサポートされます。 Method ルートでサービスを提供できる要求メソッドの種別を定義します。 各ルート内に複数のメソッドを選択できます。定義されたメソッドのいずれかの要求のみがこのルートに送信されます。 サポートされるメソッドを選択する手順は、次のとおりです。 1. **\[Method (メソッド)\]**​ ドロップダウンリストを展開します。 2. すべてのサポートされるメソッドを選択します。 3. ドロップダウンリストを折りたたみます。 Path ルートでサービスを提供できる要求パスを定義します。 ルートに対して定義できる「URI テンプレート正規表現」パスは 1 つのみです。定義済みのパスがある要求しかこのルートには送信できません。 **\[Path (パス)\]**​ ルールを定義する手順は、次のとおりです。 1. **\[Path (パス)\]**​ 設定項目にパステンプレートを入力します。 Host ルートでサービスを提供できる要求ホストを定義します。 各ルートに定義できるホスト URL は 1 つのみです。定義済みのホストから行われる要求しかこのルートには送信できません。 **\[Host (ホスト)\]**​ ルールを定義する手順は、次のとおりです。 1. **\[Host (ホスト)\]**​ 設定項目にホストを入力します。 Header このルートで要求を処理するために必要なヘッダーと正規表現値を定義します。 このルールでは、ヘッダー名と正規表現値を定義します。指定されたすべてのヘッダー要件を満たす要求しかこのルートには送信できません。ルールで特に定義されていない要求に存在する追加のヘッダーは無視されます。 最大 10 個のヘッダーを定義できます。 **\[Headers (ヘッダー)\]**​ ルールを定義する手順は、次のとおりです。 1. これが最初のヘッダーではない場合は、​**\[Add header (ヘッダーを追加)\]**​ をクリックします。 2. 最初のボックスにヘッダー名を入力します。 3. 2 番目のボックスにヘッダーの正規表現値を入力します。
ヘッダーを削除するには、​ゴミ箱​アイコン (​2%​) をクリックします。
#### [](#ルート順序)ルート順序 ルートルールの使用に加えて、Flex Gateway はページにルートが表示される順序の上から順番に、要求をさまざまなルートに送信します。 要求がルートルールを満たしている場合、Flex Gateway は要求を最初のルートに送ります。 ルートの順序を定義するには、上矢印と下矢印を使用してルートを配置します。 要求が複数のルートのルートルールを満たすことができる場合、ルートの順序付けが非常に重要です。最初に、より複雑なルートルールを使用してルートを順序付ける必要があります。ルートの順序を定義しない場合、ルートは作成された順序で並び替えられます。 たとえば、ルート 1 でルールとして ​`GET`​ メソッドが定義されていて、ルート 2 でルートルールが定義されていない場合、すべての ​`GET`​ 要求はルート 1 に送信され、他のすべての要求はルート 2 に送信されます。ルート順序が逆で、ルート 1 にルートルールがなかったとしたら、Flex Gateway は ​`GET`​ 要求がルート 2 に達する前にすべての要求をルート 1 に転送します。 ### [](#アップストリームサービス)アップストリームサービス 1 つのルートで複数のアップストリームサービスを使用し、要求を似たサービスに転送できます。たとえば、すべてのトラフィックを新しいサービスに送信せずに新しいベータアップストリームサービスのパフォーマンスをテストするには、半分のトラフィックを安定アップストリームサービスに転送し、半分を新しいアップストリームサービスに転送できます。 各 API インスタンスルートは最大 50 個のアップストリームサービスをサポートできますが、各ルートに少なくとも 1 つのアップストリームサービスが必要です。 各要求がルート内のどのアップストリームサービスに送信されるかはランダムであり、以前の要求とは無関係です。アップストリームの ​**\[Weight (加重)\]**​ で、要求が特定のアップストリームサービスに送信される確率を定義します。 ルート内のアップストリームサービスはどの要求でも受信できるため、同じルート内のすべてのアップストリームサービスは同じ API コントラクトに準拠している必要があります。 アップストリームサービスを追加するには ​**\[Add Upstream (アップストリームを追加)\]**​ をクリックし、アップストリームを削除するには​**ゴミ箱**​アイコン (​![2%](/mulesoft/current/ja-jp/api-manager/latest/_images/trash-can-icon.png)​) をクリックします。1 つのアップストリームサービスのみ設定されている場合、そのアップストリームサービスは削除できません。 各アップストリームサービスに対して次の項目を設定します。
項目名 説明 必須 注意事項

Upstream URL (アップストリーム URL)

プロキシまたは API にアクセスするための URL。​/​ で終了する必要があります。

はい

たとえば、Exchange の API アセットの URL を使用できます。

Upstream Label (アップストリームの表示ラベル)

アップストリームサービスの表示ラベル。

いいえ

複数のアップストリームサービスインスタンスがある場合は、それぞれに表示ラベルを追加して、他のインスタンスと区別します。

TLS

アップストリームサービスへのアウトバウンドトラフィックに使用される TLS コンテキスト。

いいえ

TLS コンテキストを API に追加する前に ​Flex Gateway の TLS コンテキストを設定します​。TLS コンテキストを追加するには、​[Add TLS Context (TLS コンテキストを追加)]​ をクリックします。

Weight (重み)

アップストリームサービスに送信する要求の割合。

はい

この値は、複数のアップストリームサービスがある場合にのみ設定可能です。すべてのアップストリームの加重の合計は ​100%​ である必要があります。

## [](#promote-api)別の環境への API インスタンスの昇格 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Promote API from environment (環境から API を昇格)\]**​ を選択します。 3. **\[Source Environment (ソース環境)\]**​ を選択します。 4. 検索項目に API の名前を入力して、​**\[API\]**​ を選択します。 5. **\[API Version (API バージョン)\]**​ を選択します。 6. **\[API instance label (API インスタンスの表示ラベル)\]**​ を選択します。 7. 必要に応じて、除外する ​**\[Include in Promotion (昇格に含める)\]**​ オプションをオフにます。 8. **\[Promote (昇格)\]**​ をクリックします。 9. 必要に応じて、\[Runtime & Endpoint Configuration (ランタイムとエンドポイント設定)\] の詳細を確認して更新し、​**\[Save (保存)\]**​ をクリックします。 ## [](#import-api)Zip ファイルから API をインポートする 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Import API from zip file (zip ファイルから API をインポート)\]**​ を選択します。 3. **\[Choose file (ファイルを選択)\]**​ をクリックし、API インスタンス設定 zip ファイルを選択します。 4. **\[Next (次へ)\]**​ をクリックします。 5. 必要に応じて API 設定の詳細を確認して更新し、​**\[Save (保存)\]**​ をクリックします。 ## [](#注意事項)注意事項 - OpenAPI 仕様 (OAS) 3.0 はサポートされていますが、コールバック機能はサポートされていません。この問題を回避するには、Mule Runtime Engine ドメインの外部でコールバックを処理するか、コールバックを使用しない OAS 3.0 仕様を使用します。 # HTTPS API プロキシの構築 API Manager 2.x を使用すると、シークレットグループに保存したシークレットを使用して、CloudHub またはハイブリッドデプロイメント用の HTTPS ベースの API を構築できます。 インバウンドおよびアウトバウンドトラフィックの TLS コンテキストを設定することで、トラフィックのセキュリティを確保できます。 シークレットマネージャーインテグレーションは、CloudHub、ハイブリッド、およびスタンドアロンのデプロイメント上で Mule 4 を実行する API プロキシでのみサポートされます。 TLS コンテキストでサポートされるキーストアは JCEKS、PKCS12、および JKS です。 Mule 3 または Runtime Fabric デプロイメント対象で HTTPS プロキシを構築する場合は、​[「HTTPS サービスの構築」](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service)​を参照してください。 ## [](#始める前に)始める前に シークレットグループに保存されたシークレットを使用して HTTPS API プロキシを設定するには、次の要件を満たす必要があります。 - Anypoint Platform 管理者に以下の権限を要求してある: - シークレットマネージャー権限 API プロキシ用の既存の TLS コンテキストを設定するには、「​**シークレットメタデータの読み取り**​」権限が必要です。 詳細は、​[「シークレットマネージャー権限」](https://docs.mulesoft.com/jp/anypoint-security/asm-permission-concept)​リファレンスを参照してください。 - API Manager の権限 API Manager で TLS コンテキストを API プロキシに適用するには、​**「Manage API Configuration (API 設定の管理)」**​権限が必要です。 詳細は、「製品別の権限」ページの​[「API Manager」](https://docs.mulesoft.com/jp/access-management/permissions-by-product#api-manager)​のセクションを参照してください。 - [シークレットグループを作成してある](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task) **\[Secret Group Downloadable (シークレットグループをダウンロード可能)\]**​ チェックボックスをオンにします。 - [TLS コンテキストを追加してある](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#add-a-tls-context) TLS コンテキストの対象を ​**\[Mule\]**​ に設定します。 ## [](#https-api-プロキシを設定する)HTTPS API プロキシを設定する HTTPS API プロキシを設定するには、以下の手順を完了します。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Add new API (新しい API を追加)\]**​ をクリックします。 3. ランタイムとして ​**\[Mule Gateway (Mule ゲートウェイ)\]**​ を選択します。 4. **\[Proxy type (プロキシ種別)\]**​ で ​**\[Deploy a proxy application (プロキシアプリケーションをデプロイ)\]**​ を選択します。 5. プロキシアプリケーションのデプロイを選択した場合は、以下のオプションから​**対象種別**​を選択します。 - **CloudHub 2.0**​: コンテナベースのクラウドインフラストラクチャで MuleSoft によってホストされている Mule Runtime を使用する場合は、このオプションを選択します。CloudHub 2.0 プロキシには、デフォルトで 0.1 vCore の CPU が含まれています。 1. スペースを選択します。 スペースについての詳細は、​[Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) and [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about)​を参照してください。 2. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 3. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **CloudHub:**​ MuleSoft によってクラウドでホストされている Mule Runtime を使用する場合は、このオプションを選択します。CloudHub プロキシには、デフォルトで 0.1 vCore の CPU と 500 MB のメモリが含まれています。 1. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 2. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **Hybrid (ハイブリッド):**​ Runtime Manager に登録されているオンプレミスサーバーで実行される Mule Runtime インスタンスを使用する場合、このオプションを選択します。 詳細は、​[「Runtime Manager でのサーバーの登録」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 1. リストから接続先を選択するか、​**\[Add server (サーバーを追加)\]**​ をクリックします。 2. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **Self-managed Server (自己管理型サーバー):**​ JAR ファイルを作成して、Runtime Manager に登録されていないオンプレミスサーバーで実行される Mule Runtime インスタンスに API プロキシをデプロイする場合、このオプションを選択します。詳細は、[On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model)を参照してください。 API Manager で API プロキシを自己管理型サーバーにデプロイしても、プロキシはオンプレミスサーバーにデプロイされません。API Manager でプロキシをデプロイした後に、プロキシをオンプレミスサーバーにデプロイします。 . [新しい API プロキシ JAR ファイルをダウンロードします](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task)​。 . [JAR ファイルをオンプレミスサーバーにデプロイします](https://docs.mulesoft.com/mule-runtime/latest/deploy-on-premises)​。 - **Runtime Fabric:**​ Runtime Fabric で管理された Mule Runtime Engine に API プロキシをデプロイする場合、\[Runtime Fabric\] を選択します。 詳細は、​[「Runtime Fabric への API プロキシのデプロイ」](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric)​を参照してください。 1. リストから対象を選択します。 2. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 3. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 1. 以下のオプションから API を選択します。 - 管理する API を Exchange を介して共有している場合、​**\[Select API from Exchange (Exchange から API を選択)\]**​ をクリックします。 1. **\[Select API (API を選択)\]**​ の下のリストから API をクリックします。必要に応じて、特定の API を検索できます。 2. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 3. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。​**\[Conformance Status (準拠状況)\]**​ が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 - **\[Create new API (新しい API を作成)\]**​ をクリックします。 1. 新しい API アセットの​**名前**​を入力します。 2. 以下のオプションから​**アセットタイプ**​を選択します。 - **REST API:**​ アセットに含める RAML または OAS API 定義ファイルがある場合は、このオプションを選択します。 REST API の RAML または OAS ファイルをアップロードします。バージョン 2.0.0 以降ではネイティブ OAS サポートが追加されるので、OAS または RAML 仕様に推奨されるバージョンです。OAS API 仕様を API プロキシバージョン 1.0 以前にアップロードすると、API 仕様は RAML に変換されます。 - **HTTP API:**​ アセットに含める API 定義ファイルがない場合は、このオプションを選択します。 - **SOAP API:**​ WSDL API 定義ファイルまたはファイルへの外部リンクがある場合は、このオプションを選択します。 SOAP API の WSDL ファイルをアップロードするか、ファイルへのリンクを追加します。 このオプションは、現時点では Flex Gateway ランタイムでは使用できません。 3. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 4. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。\[Conformance Status (準拠状況)\] が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 1. **\[Next (次へ)\]**​ をクリックします。 2. ダウンストリーム設定を定義します。 設定を確認するには展開します。
項目名 説明 必須 注意事項

Protocol (プロトコル)

検証に HTTP と HTTPS のどちらを使用するかを指定します。

はい

HTTPS を選択する場合、インバウンドトラフィックの TLS コンテキストを指定します。

Inbound TLS (インバウンド TLS)

インバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。Mule 3 環境で HTTPS を有効にするには、​「Mule 3x での HTTPS の有効化」​を参照してください。

Port (ポート)

表示されたポートが正しくない場合に使用する番号を指定します。

はい

Base Path (ベースパス)

ホストルートに相対的なすべての API パスの URL プレフィックスを指定します。スラッシュ ​/​ で始まる必要があります。

はい

Instance label (インスタンス表示ラベル)

API の表示ラベルを指定します。

いいえ

同じ API の複数の管理インスタンスがある場合、各インスタンスを他のインスタンスと区別するための表示ラベルを追加します。

Advanced Options (詳細オプション)

Consumer endpoint (コンシューマーエンドポイント)

コンシューマーが要求の送信に使用するプロキシアプリケーションのアドレスを指定します。

いいえ

Client provider (クライアントプロバイダー)

API のクライアントプロバイダーを指定します。

はい

Anypoint Platform はデフォルトではクライアントプロバイダーとして機能します。外部クライアントプロバイダーを設定するには、​「クライアントプロバイダー」​を参照してください。

Request Timeout (要求タイムアウト)

要求がタイムアウトするまでの期間を指定します。

いいえ

Proxy Version (プロキシバージョン)

エンドポイントに使用するプロキシのバージョンを指定します。

いいえ

Service Name (サービス名)

WSDL サービスの名前。

はい

WSDL API でのみ使用できます。

Service Port (サービスポート)

WSDL サービスのポート。

はい

WSDL API でのみ使用できます。

Service Namespace (サービス名前空間)

WSDL サービスの名前空間。

はい

WSDL API でのみ使用できます。

Enable Console (コンソールを有効化)

API 仕様を公開およびテストできるかどうかを指定します。

いいえ

[Console Path (コンソールパス)]​ に別のパス (​/spec/*​ など) を指定できます。関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

Validations (検証)

提供された仕様に対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

厳格な検証 (省略可能)

クエリパラメーターに対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます+

User Domain (ユーザードメイン)

API ゲートウェイドメインを使用するかどうかを指定します。

いいえ

設定で以前にプロキシデプロイメント対象として ​[Hybrid (ハイブリッド)]​ を選択した場合は、必ずこのオプションを選択してください。Mule 3.8 以降の API ゲートウェイドメインをインストールする必要があります。

HTTPS プロキシを設定するには、​[HTTPS]​ を選択し、​[Inbound TLS (インバウンド TLS)]​ を設定する必要があります。
3. **\[Next (次へ)\]**​ をクリックします。 4. アップストリーム設定を定義します。 設定を確認するには展開します。
項目名 説明 必須 注意事項

Upstream URL (アップストリーム URL)

プロキシまたは API にアクセスするための URL。

はい

たとえば、Exchange の API アセットの URL を使用できます。

Outbound TLS (アウトバウンド TLS)

アウトバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。

5. **\[Next (次へ)\]**​ をクリックします。 6. 選択内容を確認し、必要に応じて編集します。 7. デプロイする準備ができたら、​**\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。または、​**\[Save (保存)\]**​ を選択して API インスタンスを保存し、後でデプロイします。 ## [](#api-プロキシデプロイメント)API プロキシデプロイメント API プロキシを CloudHub、ハイブリッド、またはスタンドアロンサーバーにデプロイできます。 ### [](#cloudhub-へのデプロイ)CloudHub へのデプロイ API プロキシを設定し、​**\[Proxy deployment target (プロキシデプロイメント対象)\]**​ として ​**\[CloudHub\]**​ を選択したら、シークレットがすでに設定された状態で API プロキシが自動的にデプロイされます。 シークレットは ​`mule-artifact.json`​ の ​`SecureProperties`​ でセキュアプロパティプレースホルダーとして設定されます。 提供されるプロパティの数は、選択した設定によって異なります。 ```sample inbound.keystore.keyPassword_281324 inbound.keystore.password_281324 inbound.truststore.password_281324 outbound.keystore.keyPassword_281324 outbound.keystore.password_281324 outbound.truststore.password_281324 ``` この場合、​`281324`​ サフィックスは API プロキシの API インスタンス ID です。 API プロキシの XML を調べると、これらのプロパティがトラストストア/キーストアの設定で使用されていることがわかります。 ```xml ``` ### [](#ハイブリッドへのデプロイ)ハイブリッドへのデプロイ API プロキシを設定し、​**\[Proxy deployment target (プロキシデプロイメント対象)\]**​ として ​**\[Hybrid (ハイブリッド)\]**​ を選択したら、シークレットがすでに設定された状態で API プロキシが自動的にデプロイされます。 シークレットは ​`mule-artifact.json`​ の ​`SecureProperties`​ でセキュアプロパティプレースホルダーとして設定されます。 \+ 提供されるプロパティの数は、選択した設定によって異なります。 ```sample inbound.keystore.keyPassword_281324 inbound.keystore.password_281324 inbound.truststore.password_281324 outbound.keystore.keyPassword_281324 outbound.keystore.password_281324 outbound.truststore.password_281324 ``` この場合、​`281324`​ サフィックスは API プロキシの API インスタンス ID です。 API プロキシの XML を調べると、これらのプロパティがトラストストア/キーストアの設定で使用されていることがわかります。 ```xml ``` ### [](#スタンドアロンサーバーへのデプロイ)スタンドアロンサーバーへのデプロイ スタンドアロンサーバーに API プロキシをデプロイするには、TLS コンテキストごとにセキュアプロパティを提供します。 1. API プロキシをダウンロードします。 1. API Manager で、ダウンロードする API プロキシのバージョンを選択します。 2. 画面の右上隅にある ​**\[Actions (アクション)\]**​ ボタンをクリックし、​**\[Download Proxy (プロキシをダウンロード)\]**​ を選択します。 2. **\[API Instance ID (API インスタンス ID)\]**​ の下にある API インスタンス ID をメモします。 3. スタンドアロン Mule インスタンスを実行する場合、API プロキシの API インスタンス ID と共にキーストアとキーのパスフレーズを -D 引数として提供する必要があります。 たとえば、API インスタンス ID が 15464957 の場合、次の引数を渡す必要があります。 ```sample ./bin/mule \ -M-Dinbound.keystore.keyPassword_15464957=pass123 \ -M-Dinbound.keystore.password_15464957=pass123 \ -M-Dinbound.truststore.password_15464957=pass123 \ -M-Doutbound.keystore.keyPassword_15464957=pass123 \ -M-Doutbound.keystore.password_15464957=pass123 \ -M-Doutbound.truststore.password_15464957=pass123 ``` ## [](#関連情報)関連情報 - [シークレットマネージャー](https://docs.mulesoft.com/jp/anypoint-security/index-secrets-manager) - [シークレットグループの作成](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task) - [HTTPS サービスの構築](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service) # HTTPS エンドポイントの設定 HTTP リスナー (インバウンド HTTP エンドポイント) を使用することで、最小限の設定で API プロキシを自動的にデプロイできます。このアプローチは、Anypoint Platform API の設定でセキュリティ上の問題が懸念されない場合に使用できます。そうでない場合は、HTTP リスナーではなく HTTPS リスナー (インバウンド HTTPS エンドポイント) を使用して API プロキシを設定する必要があります。 MuleSoft では、HTTPS を設定するときにユーザーが用意した証明書を必要とします。以下の証明書を使用できます。 - デモの目的で使用する自己署名証明書 - 組織内で有効なカスタム TLS 証明書 - 信頼できる証明機関 (CA) の証明書 バックエンドで自己署名証明書またはカスタム TLS 証明書を使用している場合は、対応する証明書で API プロキシリクエスターを設定する必要があります。 ビジネスユースケースに応じて、以下の推奨される方法のいずれかを使用して API プロキシを設定できます。 - [シークレットマネージャーを使用して UI で設定した証明書を使用する](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy)​: API プラットフォーム内の安全な Vault に証明書をアップロードして、シークレットマネージャーでプロキシを設定するときに証明書を使用できるようにしておき、CloudHub、Runtime Fabric、またはオンプレミスデプロイなどの対象ランタイムにセキュアな API プロキシをデプロイします。 - [すでにデプロイされている Mule ドメインで定義されている証明書を使用する](https://docs.mulesoft.com/jp/api-manager/latest/proxy-domain-support) 証明書をドメイン内で定義することで API プロキシの HTTPS リスナーが参照できるようにしておき、対象 Runtime Fabric またはオンプレミス対象にセキュアな API プロキシをデプロイします。(CloudHub は Mule ドメインをサポートしていないため、このアプローチでは使用できません)。 - Anypoint Studio で設定された証明書を使用する このアプローチでは、API プロキシをダウンロードして Anypoint Studio で開き、​[HTTPS を手動で設定します](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service)​。その後、CloudHub、Runtime Fabric、またはオンプレミスデプロイなどの対象ランタイムにプロキシをデプロイします。(対象ランタイムが CloudHub である場合は、HTTPS にはポート 8082 を使用してください)。 ## [](#関連情報)関連情報 - [HTTPS サービスの構築](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service) - [HTTPS API プロキシの構築](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy) - [シークレットマネージャー](https://docs.mulesoft.com/jp/anypoint-security/index-secrets-manager) - [Mule 4 API プロキシのドメインサポート](https://docs.mulesoft.com/jp/api-manager/latest/proxy-domain-support) - [共有リソース](https://docs.mulesoft.com/mule-runtime/latest/shared-resources) # Mule 3 API プロキシでの HTTPS の有効化 Mule 3.x API プロキシで HTTPS を有効にして、API のプライバシーと保護を強化します。HTTPS は、クライアントが実際の API と通信し、認証済みコンテンツを受信していることを確認します。 プロキシアプリケーションが HTTPS 要求をサポートできるようにする手順は、次のとおりです。 1. API Manager から、API プロキシを​[ダウンロード](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task)​して​[デプロイ](https://docs.mulesoft.com/jp/api-manager/latest/proxy-latest-concept)​します。 2. Anypoint Studio から、API プロキシ (Mule ゲートウェイ) に​[キーストア (SSL 証明書)](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls)​ を追加します。 3. 変更したプロキシを​[エクスポート](https://docs.mulesoft.com/studio/import-export-packages)​します。 4. Runtime Manager で、プロキシアプリケーションを探します。 5. **\[Settings (設定)\]**​ から、​**\[Choose File (ファイルを選択)\]**​ メニューの ​**\[Upload File (ファイルのアップロード)\]**​ を選択し、変更したプロキシを選択します。 # Mule 3.x API プロキシでの内部 Mule HTTP ヘッダーの絞り込み 内部 Mule HTTP ヘッダーがバックエンド実装に漏洩したり、応答に含まれたりしないように、API プロキシはデフォルトで次の検索条件を使用します。 - 内部 Mule HTTP ヘッダーがバックエンド実装に漏洩しないようにする場合、次のようになります。 ``​ - 内部 Mule HTTP ヘッダーが応答に含まれないようにする場合、次のようになります。 ``​ 現在、これらの検索条件ではカスタマイズを使用できません。 ## [](#関連情報)関連情報 - [API プロキシ](https://docs.mulesoft.com/jp/api-manager/latest/api-proxy-landing-page) # Mule 4 API プロキシのドメインサポート Mule Runtime Engine (Mule) では、Mule ドメイン内でこれらのリソースを定義して Mule アプリケーション間で共通リソースを共有できます。次に、他の Mule アプリケーションはこのドメインを継承します。 Mule アプリケーションは、適切に設定されていれば、ドメインで宣言された​[リソース](https://docs.mulesoft.com/mule-runtime/latest/shared-resources)​にアクセスできます。 自動生成された各プロキシは事前設定済みの Mule アプリケーションなので、同じドメインで複数の API プロキシを定義できます。同じホストとポートを使用するが、パスが異なる複数のプロキシを自動デプロイするときにドメインを作成します。 ## [](#api-プロキシのドメインの概要)API プロキシのドメインの概要 API Manager では、自動的に既存のドメインを継承するように API プロキシを設定できます。すべての API プロキシは、ドメインを参照するときに次のいずれかのリスナー設定を使用します。 - インバウンド HTTP エンドポイントの場合: `api-proxy-listener-http` - インバウンド HTTP エンドポイントの場合: `api-proxy-listener-https` API で使用されるドメインは、Runtime Fabric または CloudHub サポートドメインではサポートされていません。 **重要:**​ ドメインでいくつかの連動関係を定義できます。ドメインで定義された連動関係のバージョンが、ドメインを参照する API プロキシで定義された連動関係のバージョン以上であることを確認してください。 ドメインで定義されたすべての連動関係は、API プロキシで定義された (古いまたは新しい) 連動関係よりも優先されます。たとえば、API プロキシが HTTP トランスポートで定義された機能に連動しているが、そのトランスポートの古いバージョンを使用するドメインを参照している場合、実行時にエラーがスローされます。 ### [](#使用方法)使用方法 API プロキシリスナーは、対象ドメインで定義されたリスナー設定を使用してドメイン HTTP リスナー設定を継承する必要があります。 次のコードは、対象ドメインで定義された HTTP リスナー設定を示しています。 ```xml ``` ドメインで定義された HTTP リスナー設定の場合、API プロキシのリスナーセットアップが次のように定義されている必要があります。 ```xml ... ``` ## [](#api-プロキシで使用されるドメインを設定する)API プロキシで使用されるドメインを設定する API プロキシで使用するドメインを設定するには、以下の手順を完了します。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Add new API (新しい API を追加)\]**​ をクリックします。 3. ランタイムとして ​**\[Mule Gateway (Mule ゲートウェイ)\]**​ を選択します。 4. **\[Proxy type (プロキシ種別)\]**​ で ​**\[Deploy a proxy application (プロキシアプリケーションをデプロイ)\]**​ を選択します。 5. **\[Target Type (対象種別)\]**​ で ​**\[Hybrid (ハイブリッド)\]**​ を選択し、対象サーバーを選択します。 6. **\[Next (次へ)\]**​ をクリックします。 7. 以下のオプションから API を選択します。 - 管理する API を Exchange を介して共有している場合、​**\[Select API from Exchange (Exchange から API を選択)\]**​ をクリックします。 1. **\[Select API (API を選択)\]**​ の下のリストから API をクリックします。必要に応じて、特定の API を検索できます。 2. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 3. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。​**\[Conformance Status (準拠状況)\]**​ が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 - **\[Create new API (新しい API を作成)\]**​ をクリックします。 1. 新しい API アセットの​**名前**​を入力します。 2. 以下のオプションから​**アセットタイプ**​を選択します。 - **REST API:**​ アセットに含める RAML または OAS API 定義ファイルがある場合は、このオプションを選択します。 REST API の RAML または OAS ファイルをアップロードします。バージョン 2.0.0 以降ではネイティブ OAS サポートが追加されるので、OAS または RAML 仕様に推奨されるバージョンです。OAS API 仕様を API プロキシバージョン 1.0 以前にアップロードすると、API 仕様は RAML に変換されます。 - **HTTP API:**​ アセットに含める API 定義ファイルがない場合は、このオプションを選択します。 - **SOAP API:**​ WSDL API 定義ファイルまたはファイルへの外部リンクがある場合は、このオプションを選択します。 SOAP API の WSDL ファイルをアップロードするか、ファイルへのリンクを追加します。 このオプションは、現時点では Flex Gateway ランタイムでは使用できません。 3. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 4. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。\[Conformance Status (準拠状況)\] が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 8. **\[Next (次へ)\]**​ をクリックします。 9. ダウンストリーム設定を定義します。 設定を確認するには展開します。
項目名 説明 必須 注意事項

Protocol (プロトコル)

検証に HTTP と HTTPS のどちらを使用するかを指定します。

はい

HTTPS を選択する場合、インバウンドトラフィックの TLS コンテキストを指定します。

Inbound TLS (インバウンド TLS)

インバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。Mule 3 環境で HTTPS を有効にするには、​「Mule 3x での HTTPS の有効化」​を参照してください。

Port (ポート)

表示されたポートが正しくない場合に使用する番号を指定します。

はい

Base Path (ベースパス)

ホストルートに相対的なすべての API パスの URL プレフィックスを指定します。スラッシュ ​/​ で始まる必要があります。

はい

Instance label (インスタンス表示ラベル)

API の表示ラベルを指定します。

いいえ

同じ API の複数の管理インスタンスがある場合、各インスタンスを他のインスタンスと区別するための表示ラベルを追加します。

Advanced Options (詳細オプション)

Consumer endpoint (コンシューマーエンドポイント)

コンシューマーが要求の送信に使用するプロキシアプリケーションのアドレスを指定します。

いいえ

Client provider (クライアントプロバイダー)

API のクライアントプロバイダーを指定します。

はい

Anypoint Platform はデフォルトではクライアントプロバイダーとして機能します。外部クライアントプロバイダーを設定するには、​「クライアントプロバイダー」​を参照してください。

Request Timeout (要求タイムアウト)

要求がタイムアウトするまでの期間を指定します。

いいえ

Proxy Version (プロキシバージョン)

エンドポイントに使用するプロキシのバージョンを指定します。

いいえ

Service Name (サービス名)

WSDL サービスの名前。

はい

WSDL API でのみ使用できます。

Service Port (サービスポート)

WSDL サービスのポート。

はい

WSDL API でのみ使用できます。

Service Namespace (サービス名前空間)

WSDL サービスの名前空間。

はい

WSDL API でのみ使用できます。

Enable Console (コンソールを有効化)

API 仕様を公開およびテストできるかどうかを指定します。

いいえ

[Console Path (コンソールパス)]​ に別のパス (​/spec/*​ など) を指定できます。関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

Validations (検証)

提供された仕様に対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

厳格な検証 (省略可能)

クエリパラメーターに対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます+

User Domain (ユーザードメイン)

API ゲートウェイドメインを使用するかどうかを指定します。

いいえ

設定で以前にプロキシデプロイメント対象として ​[Hybrid (ハイブリッド)]​ を選択した場合は、必ずこのオプションを選択してください。Mule 3.8 以降の API ゲートウェイドメインをインストールする必要があります。

10. **\[Next (次へ)\]**​ をクリックします。 11. アップストリーム設定を定義します。 設定を確認するには展開します。
項目名 説明 必須 注意事項

Upstream URL (アップストリーム URL)

プロキシまたは API にアクセスするための URL。

はい

たとえば、Exchange の API アセットの URL を使用できます。

Outbound TLS (アウトバウンド TLS)

アウトバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。

12. **\[Next (次へ)\]**​ をクリックします。 13. 選択内容を確認し、必要に応じて編集します。 14. デプロイする準備ができたら、​**\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。または、​**\[Save (保存)\]**​ を選択して API インスタンスを保存し、後でデプロイします。 15. API プロキシ設定を保存したら、次のいずれかの手順を実行します。 - 選択した対象に API プロキシにデプロイする (​**\[Settings (設定)\]**​ の ​**\[Deployment Configuration (デプロイメント設定)\]**​)。 - デプロイ前に API プロキシをダウンロード (​**\[Actions (アクション)\]**​) して Anypoint Studio で編集し、対象ドメインをカスタマイズする。 ## [](#初めてドメインを設定する)初めてドメインを設定する ドメインを参照する場合、Mule は API プロキシ ​`pom.xml`​ ファイルから Maven ログイン情報を読み取り、同じセマンティック名を使用してすでにデプロイされているドメインを参照します。たとえば、前の例で指定されたバージョンの API ゲートウェイドメインの場合、セマンティック名は ​`gateway-proxy-domain-1.0.0-mule-domain`​ になります。 プロキシでドメインを使用するには、API プロキシ ​`pom.xml`​ で提供される連動関係としてドメインテンプレートが指定されていることを確認します。 初めてドメインを設定する手順は、次のとおりです。 1. 次のいずれかの方法でドメインアーティファクトを取得します。 1. [API ゲートウェイドメインテンプレート](https://anypoint.mulesoft.com/exchange/org.mule.examples/gateway-proxy-domain/)​をダウンロードします。 2. 自動生成されたプロキシで事前定義された命名規則を使用して独自のカスタムドメインを作成します。 - `api-proxy-listener-http`​: HTTP 通信用のリスナー設定 - `api-proxy-listener-https`​: HTTPS 通信用のリスナー設定 2. 実行中の Mule ディストリビューションの ​`domains`​ フォルダーに Maven アーティファクト (例: `gateway-proxy-domain-1.0.0-mule-application-template.jar`​) をコピーします。 3. `mule-application-template`​ は ​`mule-domain`​ に置き換えて、​`gateway-proxy-domain-1.0.0-mule-domain.jar`​ という文字列にします。 **ヒント:**​ アーティファクトの名前とその Maven ログイン情報が一致していることを確認します。次に例を示します。 ```xml com.mulesoft.anypoint gateway-proxy-domain 1.0.0 mule-domain ```
生成されたプロキシに Mule 4.2.2 以降からリンクするには、​domains​ フォルダーにコピーしたドメインファイルの名前を ​proxy-shared-domain.jar​ にする必要があります。
4. 使用シナリオに合わせてドメインテンプレートをカスタマイズします。 com.mulesoft.anypoint gateway-proxy-domain 1.0.0 mule-domain provided ## [](#ポートの競合の回避)ポートの競合の回避 API を正常に登録するには、一意のエンドポイント URL を使用して API プロキシを Mule インスタンスにデプロイする必要があります。自動生成されたプロキシはパス ​`http://0.0.0.0:8081`​ を使用します。 同じドメインを使用して複数のプロキシを実行している場合に競合を避けるには、プロキシパスが一意であることを確認します。また、複数のドメインが同じ Mule インスタンスにデプロイされている場合、すべてのドメインが正常にデプロイされて、デプロイ済みのプロキシで使用できるように各リスナー設定のポートが一意になっている必要があります。 ## [](#api-ゲートウェイドメインテンプレート)API ゲートウェイドメインテンプレート API プロキシをダウンロードして手動で設定する場合、​**API ゲートウェイドメインテンプレート**​を使用します。 [API ゲートウェイドメインテンプレート](https://anypoint.mulesoft.com/exchange/org.mule.examples/gateway-proxy-domain/)​は、8081 ポートでリスンする共有 HTTP リスナー設定 (「api-proxy-listener-http」) が含まれるように設定されます。共有 HTTPS リスナー設定 (「api-proxy-listener-https」) を含めることもできます。 いずれかの設定を使用するには、API ゲートウェイドメインテンプレートのコードのコメントを解除し、証明書やパスワードなどの TLS コンテキストを設定します。次のリストは、使用可能なリスナー設定を示しています。 - `api-proxy-listener-http`​: HTTP 通信で使用します。すべてのインターフェースにバインドし、ポート 8081 (デフォルト) を使用します。 - `api-proxy-listener-https`​: HTTPS 通信で使用します。すべてのインターフェースにバインドします。+ このドメインには、事前定義された ​`config.properties`​ ファイルが含まれているため、ドメインを再コンパイルすることなく設定を動的に定義できます。 次の例は、​`config.properties`​ ファイルのプロパティを示しています。 ```Properties proxy.port=8081 implementation.protocol=HTTP inbound.keystore.path=path inbound.keystore.keyPassword=changeit inbound.keystore.password=changeit inbound.keystore.algorithm= inbound.keystore.type=JKS inbound.keystore.alias=alias ```

Mule 4.2.2 以降で API ゲートウェイドメインテンプレート 1.0.x を使用している場合は、生成されたプロキシに Mule からリンクするには、ドメインの Java アーカイブ (JAR) ファイルを修正する必要があります。

  • META-INF/maven/com.anypoint.mulesoft/gateway-proxy-domain/pom.xml​ で、必要に応じて ​groupId​ の値を ​com.mulesoft.anypoint​ に変更します。

  • META-INF/mule-artifact/classloader-model.json​ で ​"groupId":​ の下にある ​com.mulesoft.anypoint​ の値を変更します。

  • META-INF/mule-artifact/classloader-model.json​ で、必要に応じて ​groupId​ の値を ​com.mulesoft.anypoint​ に変更します。

## [](#関連情報)関連情報 - [プロキシのダウンロード](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task) - [API ゲートウェイドメインテンプレート](https://anypoint.mulesoft.com/exchange/org.mule.examples/gateway-proxy-domain/) - [ランタイムドメイン](https://docs.mulesoft.com/mule-runtime/4.2/shared-resources#assoc_apps_domain) # Mule 4 のログイン情報ハッシュの設定 Mule Runtime Engine (Mule) サーバーからクライアントシークレットを非表示にすることで、クライアントログイン情報のハッシュを有効にし、API の別のセキュリティレイヤーを追加します。クライアントハッシュを有効にすると、Mule ゲートウェイはクライアントログイン情報をメモリに保存し、クライアントシークレットのみをハッシュします。 さらに、Mule ゲートウェイで暗号化とハッシュの両方を有効にした場合、メモリ内のコントラクト情報はハッシュされますが、暗号化されません。クライアントハッシュ (デフォルトでは無効) が有効になっている場合、SHA-256 ハッシュアルゴリズムが使用されます。 Mule ゲートウェイでハッシュを有効または無効にするように設定を変更してから、Mule サーバーを再起動して更新された設定を適用すると、受信要求は影響を受けず、通常どおり処理され続けます。 ## [](#クライアントログイン情報ハッシュの仕組み)クライアントログイン情報ハッシュの仕組み クライアントログイン情報が有効になっている場合、要求を受信すると、Mule ゲートウェイはその要求のクライアントログイン情報からクライアントシークレットを取得してハッシュします。次に、Mule ゲートウェイは要求を Mule に渡す前に、要求からのクライアント ID とハッシュされたクライアントシークレットをメモリに保存されているログイン情報と比較して検証します。 ## [](#クライアントログイン情報ハッシュの設定)クライアントログイン情報ハッシュの設定 クライアントハッシュを有効にするには、​`anypoint.platform.hash_clients`​ プロパティを有効にして Mule サーバーを起動します。プロパティを有効にするには、​`start`​ コマンドを実行するか、​`conf`​ ディレクトリ内の ​`wrapper.conf`​ ファイルでプロパティを設定します。 - `start`​ コマンド: `$MULE_HOME/bin/mule start -M-Danypoint.platform.hash_clients=true` - `wrapper.conf`​ プロパティ: `wrapper.java.additional.=-Danypoint.platform.hash_clients=true` 設定ファイルに ​`wrapper.java.additional.n`​ エントリを追加する場合、​``​ の各インスタンスが連続する番号になっていることを確認します。それ以外の場合、Java はプロパティを正しく解析しません。次に例を示します。 - 誤った使用法: `wrapper.java.additional.300=-Danypoint.platform.hash_clients=true` `wrapper.java.additional.300=-Dsome.other.property` - 正しい使用法: `wrapper.java.additional.300=-Danypoint.platform.hash_clients=true` `wrapper.java.additional.301=-Dsome.other.property` ## [](#クライアントログイン情報ハッシュの検証)クライアントログイン情報ハッシュの検証 Mule ゲートウェイがクライアントハッシュを有効にして開始されていることを確認するには、Log4j ロガー設定に次のエントリを追加します。 `` log4j ファイルは ​`$MULE_HOME/conf/log4j2.xml`​ にあります。 ハッシュが有効になっている場合、Mule 環境では最初の API をデプロイするときに次のメッセージが表示されます。 `API Gateway initializing with Client Hashing algorithm: SHA-256` # Mule API Analytics
Mule API Analytics​ は Flex Gateway API をサポートしていません。Flex Gateway Analytics については、Viewing Key Metrics in API Manager for Omni Gateway in Connected Modeを参照してください。
Mule API Analytics では、Mule API の使用状況とパフォーマンスに関するインサイトを得ることができます。API Manager から、Mule API Analytics ダッシュボードへのアクセス、カスタムダッシュボードの作成、チャートの作成と管理、レポートの作成ができます。API Manager から、次の種別の分析を取得できます。 - API 表示分析 - API イベント分析 - API Manager にチャートで表示されるメトリクス ポリシー違反を含めることで、データをポリシーの観点から Mule API Analytics ダッシュボード、Mule API Analytics チャート、または API Manager に表示できます。このアクションでは、ポリシーにより拒否されたまたは拒否されなかったトラフィックが追跡されます。 **\[Mule API Analytics\]**​ タブは、​`「Read API (API の読み取り)」`​権限を持つユーザーにのみ表示されます。チャートは、​`「View Analytics (Analytics の表示)」`​権限を持つユーザーに表示されます。
API Analytics は、Hyperforce デプロイメントでは使用できません。
## [](#関連情報)関連情報 - [Analytics の使用方法の確認](https://docs.mulesoft.com/jp/api-manager/latest/viewing-api-analytics) - [API Manager の Analytics チャートの使用方法の確認](https://docs.mulesoft.com/jp/api-manager/latest/analytics-chart) - [Analytics イベント API の確認](https://docs.mulesoft.com/jp/api-manager/latest/analytics-event-api) - [Analytics イベント転送の確認](https://docs.mulesoft.com/jp/api-manager/latest/analytics-event-forward) # Mule API Analytics イベント API の確認 API Manager は、管理されている Mule API ごとに分析データを収集します。Analytics イベント API を使用して、レポートとチャートでこのデータを生成できます。特定の環境または複数の API のレポートを作成したり、同じ API の別のレポートを作成したりできます。 ## [](#要件と制限事項)要件と制限事項 Analytics イベント API では 1 か月の保持ポリシーが提供され、データは最大 10 分の遅延で利用できます。10 要求/分の使用制限も適用され、1 要求につき最大 20,000 イベントを使用できます。1 分あたり 10 要求を超える要求レートは抑制されます。 この API はアドホックレポートの作成を目的として設計されています。データエクスポートツールとして使用することは意図されていません。 API を使用してレポートを作成する前に、次の要件と制限事項に注意してください。 - コールが複数の期間に重ならないようにします。 - 各 API で同じ要求を繰り返さないでください。 - Analytics イベント API には 1 分あたり 10 要求の制限が適用されます。ベストプラクティスは 1 分あたり 1 要求です。 - Analytics イベント API はデータ同期には使用しないでください。 外部システムとのイベントのデータの同期が必要な場合は、​[「Mule API Analytics イベント転送」](https://docs.mulesoft.com/jp/api-manager/latest/analytics-event-forward)​を参照してください。 ## [](#レポートの作成)レポートの作成 レート制限や IP ブラックリストによるポリシー違反などの API イベントを見つけるためのレポートを作成できます。分析サービスや Anypoint Platform が一時的に使用できない場合、Anypoint Platform はテレメトリーデータの損失を防止するために複数のデータポイントを送信することがあります。これにより、生成するレポートに重複するエントリが含まれる場合があります。 レポートを作成する手順は、次のとおりです。 1. **\[API Manager\]**​ > ​**\[Mule Analytics\]**​ > ​**\[Manage Reports (レポートを管理)\]**​ に移動し、​**\[New (新規)\]**​ をクリックします。 2. **\[Create Report (レポートを作成)\]**​ でデータソース、範囲、形式を選択します。 3. **\[Fields (項目)\]**​ で ​**\[Violated Policy Name (違反ポリシー名)\]**​ を選択します。 4. レポートを保存します。 レポートを表示する URL が表示されます。 5. URL をクリックして生成されたレポートを表示します。 ## [](#ブラウザーでのレポートの実行)ブラウザーでのレポートの実行 Analytics イベント API には、要求されたデータを使用できる開始時刻が表示されます。使用できるデータがない場合、警告メッセージが表示されます。 ブラウザーでレポートを実行するには、​**\[Manage Reports (レポートを管理)\]**​ ページに移動し、目的のレポートの ​**\[Run (実行)\]**​ をクリックします。 ![anev\_running\_report2](/mulesoft/current/ja-jp/api-manager/latest/_images/anev-running-report2.png) レポートを実行すると、要求した分析データを含む CSV または JSON ファイルが生成されます。 ### [](#curl-を使用したレポート情報の表示)curl を使用したレポート情報の表示 この手順では、curl コマンドを実行して ​`$TOKEN`​ の値を取得します。コマンドはこの応答の ​`access_token`​ JSON プロパティを取得します。 認証ヘッダーの形式は、​`Authorization: Bearer {$TOKEN.access_token}`​ です。 `jq`​ コマンドライン JSON プロセッサーの使用は、アクセストークン値を取得するための可能なソリューションの 1 つです。このアプリケーション、またはこの手順で同じ機能を果たすアプリケーションをダウンロードしてインストールします。 レポート情報をプログラムで表示する 1. 新しいターミナルウィンドウを開き、次のコマンドを実行します。 TOKEN=$(curl -s https://anypoint.mulesoft.com/accounts/login -d "username=&password=" | jq -r .access\_token) このコマンドは、Anypoint Platform の認証サーバーに要求を送信し、要求が成功すると、アクセストークンを返して ​`$TOKEN`​ 変数に保存します。この変数の値は次のように表示されます。 ```json { "access_token": "54545454-5454-5454-5454-545454545454", "token_type": "Bearer", "redirectUrl": "/accounts/#/cs/profile/home" } ``` 2. レポートの Analytics レポート API エンドポイントの要求内の ​`Authorization`​ ヘッダーにアクセストークンを付加します。 1. Mule API Analytics ダッシュボードの ​**\[Manage Reports (レポートを管理)\]**​ ページからエンドポイントをコピーします。 2. 環境のない組織の分析を取得する次の例に示すように、前のステップからの ​`$TOKEN`​ 変数を次回の要求に含めます。 ```console curl -H "Authorization: Bearer $TOKEN" "https://anypoint.mulesoft.com/analytics/1.0//events?format=csv&startDate=2016-01-01&endDate=2016-12-31&fields=Application%20Name.Client%20IP.Resource%20Path" > output.csv ``` 3. 要求が成功すると、​`curl`​ 要求を開始したディレクトリに ​`output.csv`​ ファイルが生成されます。 次の例は、環境がある組織の Analytics イベント API を照会します。 ```console curl -H "Authorization: Bearer $TOKEN" "https://anypoint.mulesoft.com:443/analytics/1.0//environments//events?format=csv&apiIds=&duration=30d" > output.csv ``` この例では、API ID <​API\_ID​> の API から過去 30 日間の分析データが取得されます。結果は CSV 形式で生成されます。 次の例は、2 つの ​`curl`​ コマンドを組み合わせてコマンドプロンプトウィンドウに値を表示します。 ```text TOKEN=$(curl -s https://anypoint.mulesoft.com/accounts/login -d "username=myusername&password=mypassword" | jq -r .access_token) curl -H "Authorization: Bearer $TOKEN" "https://anypoint.mulesoft.com/analytics/1.0/42424242-4242-4242-4242-424242424242/events?format=csv&startDate=2016-01-01&endDate=2016-11-10&fields=Application%20Name.Client%20IP.Resource%20Path" echo;echo ``` このコマンドで次の出力が生成されます。 ```text "Application Name","Client IP","Resource Path",Timestamp,"API ID","API Version ID","API Name","API Version Name" "Las Vegas T-Shirt serviceLas Vegas T-Shirt serviceLas Vegas",83.178.96.0,/,2016-10-03T04:27:02.072Z,61460,63811,"test api contracts",1 "Las Vegas T-Shirt serviceLas Vegas T-Shirt serviceLas Vegas",83.178.96.0,/,2016-10-03T05:03:38.774Z,61460,63811,"test api contracts",1 ... ``` ### [](#特定の環境のレポートの作成)特定の環境のレポートの作成 複数の環境を有効にしている組織では、このトピックで説明されている方法で照会した API イベントは「未分類」の環境のみに属します。 特定の環境で API のイベントを要求する方法は、次のとおりです。 1. 環境セレクターで環境を選択し、実行するレポートを作成します。 レポートは環境に基づいて保存されます。そのため、異なる環境に異なるレポートが存在します。 2. レポートの作成から生成されたレポート URL を UI からコピーします。 この URL には、組織 ID に加えて ​`/environment/{Environment ID}`​ も含まれます。組織と環境の作成時に Anypoint Platform は一意の ID を割り当てます。たとえば、QA 環境内の API ID は本番環境内のその ID とは異なります。 3. 特定の環境のイベントにアクセスするには、レポート URL に環境 ID を付加します。 ### [](#コマンドオプションリファレンス)コマンドオプションリファレンス 次のオプションを curl コマンドに追加できます。
オプション 説明

apiIds

クエリに含める API ID のカンマ区切りリスト。省略するか、​all​ または ​*​ を指定すると、すべての API が含まれます。

型:​ string
必須:​ いいえ
例:​ ​appIds=42,54

apiVersionIds

クエリに含める API バージョン ID のカンマ区切りリスト。 省略するか、​all​ または ​*​ を指定すると、すべての API バージョンが含まれます。 API ID の値が指定されていない場合、無視されます。

型:​ string
必須:​ いいえ
例:​ ​apiVersionIds=42,54

duration

レポートで返されるデータの対象の期間。数量を表す整数値と、単位を表す 1 文字のサフィックスで構成されます。

サフィックスは次のいずれかです。

  • d​: 日

  • h​: 時

  • m​: 分

  • s​: 秒

1 週間を対象とするには、期間として ​7d​ を指定します。30 秒を対象とするには、​30s​ を指定します。

型:​ string
必須:​ いいえ
例:​ ​duration=45m

fields

レポートに含める項目。CSV 出力では必須、JSON 出力では省略可能です。 項目のリストはカンマまたはピリオドで区切ることができます。スペースには ​%20​ を使用します。​[report-data-fields-reference]​ で任意の値を使用できます。 タイムスタンプ、API 名、API ID、API バージョン、API バージョン ID は常に含まれます。

型:​ string
必須:​ いいえ
例:​ ​fields=Hardware%20Platform.Client%20IP.Resource%20Path

format

返される値のシリアル化形式を決定します。 ​csv​ または ​json​ を入力します。

型:​ string
必須:​ はい
例:​ ​format=csv

maxResults

返すイベントの最大数。デフォルト値は ​20000​ です。

型:​ integer
必須:​ いいえ
例:​ ​maxResults=3

startDate

開始日時。​http://joda-time.sourceforge.net/apidocs/org/joda/time/format/ISODateTimeFormat.html#dateTimeParser() http://joda-time.sourceforge.net/apidocs/org/joda/time/format/ISODateTimeFormat.html#dateTimeParser()`[ISO 日時パーサー]

型:​ date
必須:​ いいえ
例:​ ​startDate=2016-01-01T08:15:30-05:00

endDate

終了日時。​http://joda-time.sourceforge.net/apidocs/org/joda/time/format/ISODateTimeFormat.html#dateTimeParser()​ を参照してください。

型:​ date
必須:​ いいえ
例:​ ​endDate=2016-11-10

## [](#レポートデータ項目リファレンス)レポートデータ項目リファレンス レポートでは、使用可能な 1 つまたは複数のデータ項目のデータを照会できます。
データ項目名 説明

Application (アプリケーション)

受信 API 要求に関連付けられたクライアント ID。

Application Name (アプリケーション名)

API 要求を実行したアプリケーションの名前 (要求と共にクライアント ID が渡された場合のみ使用可能)。

Browser (ブラウザー)

受信 API 要求に関連付けられたブラウザー種別。

City (市区郡)

API 要求の実行元の市区郡 (クライアントの IP アドレスによる推定)。

Client IP (クライアント IP)

API 要求を実行したクライアントの IP アドレス。

Continent (大陸)

API 要求の実行元の大陸 (クライアントの IP アドレスによる推定)。

Country (国)

API 要求の実行元の国 (クライアントの IP アドレスによる推定)。

Hardware Platform (ハードウェアプラットフォーム)

要求を実行したクライアントのハードウェア種別 (モバイル、タブレット、デスクトップなど)。

メッセージ ID

メッセージ ID の値。

OS Family (OS ファミリー)

クライアントの OS 種別: Mac OS X、iOS、Windows、Linux。

OS Major Version (OS メジャーバージョン)

オペレーティングシステムのメジャーバージョン。

OS Minor Version (OS マイナーバージョン)

オペレーティングシステムのマイナーバージョン。

OS Version (OS バージョン)

オペレーティングシステムのバージョン。

Postal Code (郵便番号)

API 要求の実行元の郵便番号 (クライアントの IP アドレスによる推定)。

Request Outcome (要求結果)

要求が成功したか、結果としてポリシー違反になったかを示します。

Request Size (要求サイズ)

受信クライアント要求のサイズ (バイト単位)。

Resource Path (リソースパス)

クライアント要求のパス。

Response Size (応答サイズ)

API 応答のサイズ (バイト単位)。以下の注意事項を参照してください。

Response Time (応答時間)

API 要求の処理時間。

Status Code (状況コード)

応答の HTTP 状況コード。

Timezone (タイムゾーン)

API 要求の実行元のタイムゾーン (クライアントの IP アドレスによる推定)。

User Agent Name (ユーザーエージェント名)

受信クライアント要求の完全なユーザーエージェント文字列。

User Agent Version (ユーザーエージェントバージョン)

受信クライアント要求のユーザーエージェント文字列のバージョン。

Verb (動詞)

API クライアント要求に関連付けられた REST 動詞 (GET、POST、PATCH など)。

Violated Policy Name (違反ポリシー名)

API 要求により違反となったポリシー (ある場合) の名前。

クエリ内の ​`Content-Length`​ ヘッダーの状況に応じて、次のように動作します。 - 存在する: `Response Size`​ はその値に設定されます。 - 存在せず、ペイロードが文字列: Mule API Analytics は文字列の長さを計算し、その値を報告します。 - 存在せず、ペイロードが文字列ではない: Mule API Analytics は応答サイズを -1 として報告します。 たとえば、返された出力が DataWeave ストリームであり、​`Content-Length`​ ヘッダーが存在しない場合、値が文字列ではないため、Analytics イベント API は応答サイズを報告しません。ただし、アプリケーションで文字列変換が実行されている場合、応答サイズは表示されます。 ## [](#クライアント-ip-データの制限)クライアント IP データの制限 クライアント IP データを転送しない場合は、Mule Runtime の ​`wrapper.conf`​ ファイルで ​`anypoint.platform.analytics_include_client_ip=false`​ を設定します。プロパティを設定するには、[Configuring Properties](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties)を参照してください。 クライアント IP データを転送しないことを選択した場合、​**\[City (市区郡)\]**​、​**\[Continent (大陸)\]**​、​**\[Postal Code (郵便番号)\]**​、​**\[Country (国)\]**​、​**\[Timezone (タイムゾーン)\]**​ などのローカライズされた地理データも使用できなくなります。 ## [](#関連情報)関連情報 - [Mule API Analytics の表示](https://docs.mulesoft.com/jp/api-manager/latest/viewing-api-analytics) - [jq コマンドライン JSON プロセッサー](https://stedolan.github.io/jq/) # Mule API Analytics イベント転送の確認 Mule API Analytics イベントをサードパーティシステムに転送したい場合があります。この例として、ELK や他の分析システムとの統合が考えられます。 イベントをエクスポートする 3 つの方法があります。 - API Analytics レポート API を使用してデータを取り込む。 この方法を使用する場合の 1 つの考慮事項として、API には報告可能なイベントの数と頻度に関する制限があることがあります。また、イベントが生成された時点からイベントをクエリで使用できる時点まで最大 10 分の遅延が生じる可能性があります。 - ゲートウェイから設定済みの HTTP エンドポイントまで Mule API Analytics イベントを転送する。これを CloudHub で設定するには、Runtime Manager の \[Settings (設定)\] タブから ​`anypoint.platform.analytics_base_uri`​ ゲートウェイプロパティを設定します。 このプロパティを設定すると、イベントが投稿されるベース URL が設定されます。 ![イベント転送](/mulesoft/current/ja-jp/api-manager/latest/_images/analytics-event-forwarding.png) 上記の例では、イベントは POST メソッドと圧縮用の GZIP を使用して、​`http:///v2/analytics/events`​ にパブリッシュされます。 この方法の欠点は、イベントが Anypoint Platform にパブリッシュされず、Mule API Analytics と API Manager のどちらにも API コールに関する情報が表示されないことです。 - Runtime Manager を使用して、​[外部分析ツールにデータをエクスポート](https://docs.mulesoft.com/jp/runtime-manager/sending-data-from-arm-to-external-analytics-software)​する。 ## [](#関連情報)関連情報 - [Analytics イベント API の確認](https://docs.mulesoft.com/jp/api-manager/latest/analytics-event-api) # Mule API Analytics の使用方法の確認 API Manager と Anypoint Monitoring の両方から Mule API Analytics データを表示できます。API Manager は Mule API Analytics データを最大 30 日間保持します。ただし、Anypoint Monitoring は 30 日の保持期間でさらに堅牢な API 使用状況データを提供します。 API Manager で Mule API Analytics データを表示する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[Mule API Analytics\]**​ をクリックします。 ダッシュボードから、Anypoint Platform で収集された API に関する分析に移動できます。 Anypoint Monitoring でデータを表示する方法についての詳細は、​[「Anypoint Monitoring API Analytics ダッシュボード」](https://docs.mulesoft.com/jp/monitoring/api-analytics-dashboard)​を参照してください。 Mule API の分析にアクセスすると、デフォルトで、次のチャートを表示する概要ダッシュボードが表示されます。 - **Requests by Date (日付別要求数)**​: 組織内のすべての API の要求数を示す折れ線チャート。 - **Requests by Location (場所別要求数)**​: 発信元の国別に要求数を示すマップチャート。 - **Requests by Application (アプリケーション別要求数)**​: 上位 5 つの登録済みアプリケーション別に要求数を示す棒チャート。 - **Requests by Platform (プラットフォーム別要求数)**​: プラットフォーム別に分類された要求数を示すドーナツチャート。 ![「API Manager Analytics」ダッシュボード。](/mulesoft/current/ja-jp/api-manager/latest/_images/overviewdash1.png) デフォルトでは、組織内の API に関する過去 1 日のデータがこれらのチャートに表示されます。ページの左上にある検索条件を使用して、日付範囲を変更したり、特定の API に絞り込んだりすることができます。時間範囲にはローカルタイムゾーンが反映されています。 ![選択可能な日付範囲オプションが表示された「Date Range (日付範囲)」検索条件ドロップダウンメニュー。](/mulesoft/current/ja-jp/api-manager/latest/_images/filters.png) カスタム期間を選択すると、日別要求数の折れ線チャートの要求数は正規化されません。たとえば、月次チャートには、4 時間あたりの要求数が表示されます。2 か月間の場合、同じチャートには 8 時間あたりの要求数が表示されます。カスタムダッシュボードで折れ線チャートを使用していて、カスタム期間を定義する必要がある場合は、集約期間を明示的に設定する必要があります。 概要ダッシュボードのすべてのチャートにはクロス条件で絞り込まれます。いずれかのチャートのデータを絞り込む場合、同じ検索条件がページ上の他のチャートに適用されます。たとえば、棒チャートで個々のアプリケーションをクリックすると、そのアプリケーションからのすべての要求が表示され、それらの要求の場所がマップに表示されます。各チャートのデータを絞り込む方法は、次のとおりです。
チャート データの絞り込み方法 検索条件のクリア方法

Requests by Date (日付別要求数)

チャートの領域をクリックしてドラッグし、その期間のみに絞り込みます。スライダー検索条件を適用したら、必要に応じて端をドラッグして調整できます。

絞り込まれた部分の領域の外側をクリックします。

Requests by Location (場所別要求数)

1 つ以上の国をクリックし、それらの結果のみに絞り込みます。国にカーソルを置くと、国名と、選択した期間中にその国から受信した API 要求の総数を表示するツールヒントが表示されます。

国を再度クリックするとマップがリセットされます。

Requests by Application (アプリケーション別要求数)

1 つ以上のアプリケーションの棒をクリックし、それらの結果のみに絞り込みます。アプリケーションのデータの棒にカーソルを置くと、アプリケーション名と、その期間中にそのアプリケーションから受信した合計要求数を表示するツールヒントが表示されます。

アプリケーションを再度クリックするとチャートがリセットされます。

Requests by Platform (プラットフォーム別要求数)

1 つ以上のセグメントをクリックし、それらの結果のみに絞り込みます。セグメントにカーソルを置くと、アプリケーション名と、その期間中にそのアプリケーションから受信した合計要求数を表示するツールヒントが表示されます。

セグメントを再度クリックするとチャートがリセットされます。

いずれかのチャートのデータをエクスポートするには、\[Export (エクスポート)\] アイコン (​![曲がった矢印](/mulesoft/current/ja-jp/api-manager/latest/_images/export.png)​) をクリックします。 いずれかのチャートのデータを絞り込みんで選択したデータのみを表示している場合、エクスポートアイコンをクリックすると、ページ左上の検索条件を使用して選択した日付範囲と API でそのチャートの完全データを絞り込んだ .csv ファイルのエクスポートがトリガーされます。エクスポートされるファイルは、最大 100 万レコードに制限されます。 ## [](#ダッシュボードにポリシー違反を含める)ダッシュボードにポリシー違反を含める **注意:**​ ポリシーを参照したり、ポリシー違反アラートを編集したりするには、ユーザーに​`「ポリシーの参照」`​権限セットが必要です。 詳細は、​[「権限の設定」](https://docs.mulesoft.com/jp/api-manager/latest/environment-permission-task)​を参照してください。 ダッシュボードの \[Include Policy Violations (ポリシー違反を含める)\] チェックボックスを使用して、ポリシー違反の追跡を有効または無効にします。ダッシュボードには、ポリシーによって拒否された、または拒否されなかったトラフィックが表示されます。 ![「Include Policy Violations (ポリシー違反を含める)」チェックボックスがオンの API Manager ポリシー違反チャート。](/mulesoft/current/ja-jp/api-manager/latest/_images/policy-violations-chart.png) ## [](#カスタムチャートの作成)カスタムチャートの作成 さまざまなカスタムチャートを作成して、カスタムダッシュボードに特定のデータを表示できます。 たとえば、次を表示するカスタムチャートを作成できます。 - その月の 1 日から今日までの毎時間の 1 秒あたりのトランザクション数をクライアント ID、API バージョン、または SLA 層で絞り込む。 - 過去 24 時間の 1 分あたりのレイテンシー平均を API で絞り込む、またはクライアントの地理位置情報でグループ化する。 - サブスクライブしているアプリケーションごと、違反ポリシー名ごとにグループ化されたポリシー違反数。 ポリシー違反をトリガーしたイベントが含まれるのは、違反ポリシー名でグループ化するチャートのみです。その他のチャートからはこれらのイベントが除外されます。たとえば、API が 100 個の要求を受信し、90 個が成功し、10 個がレート制限ポリシーによって拒否されるとします。違反ポリシー名でグループ化しないチャートでは、制限されなかった 90 個の要求のみに基づいて集約が計算されます。ただし、違反ポリシー名でグループ化するチャートでは、100 個すべての要求が計算に含まれます。 カスタムチャートを作成するには、\[Manage Charts (チャートを管理)\] をクリックします。 1. **\[API Manager\]**​ > ​**\[Mule API Analytics\]**​ > ​**\[Manage Charts (チャートを管理)\]**​ に移動し、​**\[New (新規)\]**​ をクリックします。 \[Create Chart (チャートの作成)\] が表示されます。 ![「Create Chart (チャートの作成)」ページ。](/mulesoft/current/ja-jp/api-manager/latest/_images/createchart.png) 2. **\[Title (タイトル)\]**​ と ​**\[Description (説明)\]**​ (省略可能) を入力します。 3. チャートの種類のグラフィックをクリックします。
アイコン チャートの種類 チャートのオプション

折れ線チャートのサムネイル画像。

折れ線チャート

Data Source (データソース)、Metric (メトリクス): メトリクス​、Total (合計)、Data Interval (データ間隔): 期間

棒チャートのサムネイル画像。

棒チャート

Data Source (データソース)、Metric (メトリクス): メトリクス​、Total (合計)、Group By (グループ化条件): カテゴリ

積み上げチャートのサムネイル画像。

積み上げチャート

Data Source (データソース)、Metric (メトリクス): メトリクス​、Total (合計)、Group By (グループ化基準): カテゴリ​、Then By (第 2 基準): カテゴリ

ドーナツチャートのサムネイル画像。

ドーナツチャート

Data Source (データソース)、Metric (メトリクス): メトリクス​、Total (合計)、Group By (グループ化条件): カテゴリ

マップチャートのサムネイル画像。

マップチャート

Data Source (データソース)、Metric (メトリクス): メトリクス​、Total (合計)

4. \[Data Source (データソース)\] の値を選択します。 - 組織内のすべての API - 特定の API 5. \[Metrics (メトリクス)\] の値 (​_メトリクス_​) と \[Total (合計)\] を選択します。 - Request Size (要求サイズ) (バイト) - Requests (要求) - Response Size (応答サイズ) (バイト) - Response Time (応答時間) (ミリ秒) 6. 折れ線チャートの場合は、\[Data Interval (データ間隔)\] の値 (​_期間_​) を選択します。 - Minutes (分) - Hours (時間) - Days (日) 7. 棒チャートと積み上げチャートの場合は、\[Group By (グループ化基準)\] のカテゴリと、チャートでサポートされている場合は \[Then By (第 2 基準)\] のカテゴリを選択します。 - API Name (API 参照名) - API バージョン - Application (アプリケーション) - Browser (ブラウザー) - City (市区郡) - Client IP (クライアント IP) - Continent (大陸) - Country (国) - Hardware Platform (ハードウェアプラットフォーム) - OS Family (OS ファミリー) - OS Major Version (OS メジャーバージョン) - OS Minor Version (OS マイナーバージョン) - OS Version (OS バージョン) - Postal Code (郵便番号) - Resource Path (リソースパス) - Status Code (状況コード) - Timezone (タイムゾーン) - User Agent Type (ユーザーエージェント種別) - User Agent Version (ユーザーエージェントバージョン) - Verb (動詞) - Violated Policy Name (違反ポリシー名) 積み上げチャートの場合は、2 つのディメンションでデータをグループ化できます。最初のディメンションで個別の列を定義し、2 つ目のディメンションでこれらの列内の積み上げを定義します。2 つ目のグループ化ディメンションでも 1 つ目と同じオプションを使用できます。 8. チャートを保存します。 カスタムチャートが表示されます。 ### [](#カスタムチャートの例-アプリケーションごとのポリシー違反)カスタムチャートの例: アプリケーションごとのポリシー違反 1. **\[API Manager\]**​ > ​**\[Mule API Analytics\]**​ > ​**\[Manage Charts (チャートを管理)\]**​ に移動し、​**\[New (新規)\]**​ をクリックします。 2. \[Title (タイトル)\] に「​**Policy Violations Per Application**​」 (アプリケーションごとのポリシー違反) と入力します。 3. \[Description (説明)\] に​**「Number of violations per subscribed application」**​ (サブスクライブしているアプリケーションごとの違反数) と入力します。 4. 積み上げチャートを選択します。 5. \[Data Source (データソース)\] と \[Metric (メトリクス)\] で、デフォルト値をそのまま使用します。 6. 積み上げチャートの 2 つのグループ化レベルを選択します。 - \[Application (アプリケーション)\] を選択し、アプリケーションごとに縦棒を表示します。 - \[Violated Policy Name (違反ポリシー名)\] を各縦棒内の積み上げとして選択します。 ![「Group By (グループ化基準)」と「Then By (第 2 基準)」の「Violated Policy Name (違反ポリシー名)」によって絞り込まれたアプリケーションが表示されている \[Create Chart (チャートの作成)\] ページの下部。](_images/create-chart-2.png) 7. チャートを保存します。 チャートが表示されます。 ![アプリケーション別のポリシー違反が表示されたチャート。](/mulesoft/current/ja-jp/api-manager/latest/_images/analytics-violated-policies-2.png) ## [](#カスタムダッシュボードの作成)カスタムダッシュボードの作成 カスタムチャートを作成した後に、独自のカスタムダッシュボードにそれらのチャートを並べて表示できます。 カスタムダッシュボードにアクセスするには、\[Custom Dashboard (カスタムダッシュボード)\] をクリックします。初めて開いたとき、カスタムダッシュボードは空白になっています。 1. **\[API Manager\]**​ > ​**\[Mule API Analytics\]**​ > ​**\[Custom Dashboard (カスタムダッシュボード)\]**​ に移動し、​**\[Edit Dashboard (ダッシュボードを編集)\]**​ をクリックします。 2. カスタムチャートを作成したことを前提とし、画面左側のドロワーからダッシュボードにチャートをドラッグアンドドロップして、必要に応じて順序を並べ替えます。 3. ダッシュボードにチャートを追加したら、開いて編集するか、\[X\] をクリックしてダッシュボードから削除することができます。 4. 完成したら、カスタムダッシュボードを保存します。 カスタムダッシュボードが表示されます。 ![いくつかのカスタムチャートが表示されたカスタムダッシュボード。](/mulesoft/current/ja-jp/api-manager/latest/_images/custom-dashboard.png) 日付範囲ピッカーを使用して、ダッシュボードのすべてのチャートの期間を調整します。 ## [](#分析データのエクスポート)分析データのエクスポート 概要ダッシュボードまたはカスタムダッシュボードに表示されたチャートから分析データをエクスポートすることができます。どちらかのダッシュボードで、\[Export (エクスポート)\] アイコン (​![曲がった矢印](/mulesoft/current/ja-jp/api-manager/latest/_images/export.png)​) をクリックして、そのチャートのデータを含む CSV ファイルをダウンロードします。 ダウンロードするデータには、選択した絞り込みオプションが反映されています。ただし、概要ダッシュボードからチャートデータをエクスポートし、チャートのサブセクションを 1 つ以上選択した場合、エクスポートされるファイルに絞り込みオプションは含まれません。エクスポートされるファイルには、そのチャートの完全データが含まれます。 ## [](#関連情報)関連情報 - [Analytics イベント API の確認](https://docs.mulesoft.com/jp/api-manager/latest/analytics-event-api) # Mule OAuth 2.0 プロバイダー Mule OAuth 2.0 プロバイダーは、MuleSoft が開発した代替の OAuth 2.0 プロバイダーで、どの MuleSoft API プラットフォーム組織 (統合組織を含む) でも使用できます。 対応する組織のログイン情報を使用して、Mule OAuth 2.0 プロバイダーを API ゲートウェイ機能のあるランタイム (Mule Runtime Engine (Mule) 3.x、4.2.0、またはそれ以降など) にデプロイする必要があります。次のサードパーティ OAuth 2.0 プロバイダーがサポートされています。 - PingFederate - OpenAM - Open ID Connect をサポートしている OAuth 2.0 プロバイダー [Mule OAuth 2.0 アクセストークン適用ポリシー](#external-oauth-2.0-token-validation-policy.adoc)​は、Mule OAuth 2.0 プロバイダーと連携するように設計されています。 ## [](#mule-oauth-2-0-プロバイダーのダウンロード)Mule OAuth 2.0 プロバイダーのダウンロード Mule OAuth 2.0 プロバイダーは Anypoint Exchange からダウンロードできます。 - Mule 3.x: [Anypoint Platform 用外部 OAuth 2.0 サーバー](https://anypoint.mulesoft.com/exchange/org.mule.templates/api-gateway-external-oauth2-provider/)​を参照してください。 - Mule 4.x: [Anypoint Platform 用 Mule OAuth 2.0 サーバー](https://anypoint.mulesoft.com/exchange/org.mule.templates/api-gateway-oauth2-provider/)​を参照してください。 この機能は、Mule 4.2.0 以降で使用できます。 ## [](#oauth-2-0-ダンス)OAuth 2.0 ダンス OAuth 2.0 プロバイダー、API、およびクライアントアプリケーションによって実行される認証は、RFC 6749 に準拠しています。この認証プロセスは ​[OAuth 2.0 ダンス](https://docs.mulesoft.com/jp/api-manager/latest/oauth-dance-about)​と呼ばれます。 Mule OAuth 2.0 プロバイダーでは、すべての​[許可種別](https://docs.mulesoft.com/jp/api-manager/latest/oauth-grant-types-about)​がサポートされています。Mule OAuth 2.0 アクセストークン適用ポリシーによって保護されているリソースへのアクセスを要求するエンティティは ​`Client`​ です。 ### [](#エンドポイント)エンドポイント API 実装で次の Mule OAuth 2.0 プロバイダーエンドポイントをコールできます。 ![mule oauth provider](/mulesoft/current/ja-jp/api-manager/latest/_images/mule-oauth-provider.png)
目的 デフォルトパス 説明

トークンの検証

/validate

トークンの有効性 (トークンの有効期限が切れていないか、トークンが失効していないか、トークンが偽物でないか) を検証するために使用します。複数の検証エンドポイントを定義し、それぞれで異なるスコープを適用できます。詳細は、「<Scopes>」を参照してください。

認証

/authorize

スクリプト言語を使用するブラウザーでクライアントが実行されている場合や、クライアントが Web サーバーである場合にトークンを取得するために使用します。

アクセス

/access_token

クライアントが Mule OAuth 2.0 プロバイダーと同じエンティティによって所有されている場合や、クライアントが保護されたリソースのオーナーと同じエンティティである場合に使用します。

トークンの失効

/revoke

[省略可能] 有効なトークンを失効させて、無効として表示します。

### [](#スコープの実装)スコープの実装 OAuth 2.0 [スコープ](https://tools.ietf.org/html/rfc6749#page-23)​を使用すると、OAuth によって保護されているリソースへのアクセスをさらに制限できます。​`READ`​、​`WRITE`​ などの語や、​`CONTRACTOR`​、​`PUBLIC`​、​`EMPLOYEES_ONLY`​ などの組織に固有の他の語を定義できます。 スコープは 3 つの異なる場所に定義できます。 - 有効なすべてのスコープを定義するユニバーサルセット定義 ​`defaultScopes`​。 ```xml ... ``` - すでに定義されているスコープの特定のサブセットを適用するための ​`/validate`​ 検証エンドポイント。 - スペース区切りリストを指定してスコープを適用できる Mule OAuth 2.0 アクセストークン適用ポリシー。 複数のスコープを指定すると、​`AND`​ ロジックが適用されます。検証されるトークンが、要求されたすべてのスコープに関連付けられている場合、ポリシーはトークンを正常に検証します。 Mule 4.2.x 以降のスコープの使用例: ```xml ... ... ``` 詳細は、​ [Anypoint Platform 用 Mule OAuth 2.0 サーバー](https://anypoint.mulesoft.com/exchange/org.mule.templates/api-gateway-oauth2-provider/)​を参照してください。 ## [](#クライアントアプリケーションキャッシュ)クライアントアプリケーションキャッシュ Anypoint Platform に接続するときのエラーが原因で Mule OAuth 2.0 プロバイダーがダウンするのを避けるために、Mule OAuth クライアントストアは、トークンが要求される有効なクライアントアプリケーションをそれぞれキャッシュします。 使用可能な接続がないときにプロバイダーが新しいトークンを要求した場合 (滅多にない)、クライアントストアはキャッシュにフォールバックします。エントリの有効期限は 30 日 (デフォルト設定) で切れます。再起動や Anypoint Platform への接続の切断の場合に備えてサービスの可用性を確保するために、ローカルにキャッシュを保持するようにこの範囲を設定できます。 すでにトークンがクライアントストアにあるクライアントアプリケーションが、Anypoint Platform から削除された場合、クライアントストアは次のトークン要求時にキャッシュからそのクライアントを削除して、プラットフォームの状況を反映します。​[Mule OAuth 2.0 アクセストークン適用ポリシー](#external-oauth-2.0-token-validation-policy.adoc)​には、正常に完了したトークンの検証の結果をキャッシュするメカニズムがあります。 ### [](#クライアントアプリケーションキャッシュメカニズムのカスタマイズ)クライアントアプリケーションキャッシュメカニズムのカスタマイズ Mule 4.2.0 以降では、キャッシュメカニズムのデフォルト値をカスタマイズできます。このオブジェクトストアには 2 つの設定可能なプロパティがあります。
プロパティ名 定義

anypoint.oauth_provider.cache_persistence_enabled

キャッシュメカニズムをローカルで保持する必要があるかどうかを定義します。このプロパティが設定されていないか、解析できない場合、デフォルト値は ​true​ です。 キャッシュ保持によって、接続なしで Anypoint Platform へのクライアント認証が許可されます。

anypoint.oauth_provider.cache_ttl_days

各クライアントアプリケーションが OAuth サーバーによってキャッシュされる日数を表します。 この値には、任意の正の浮動小数点数を指定できます。デフォルト値は ​30​ (30 日) です。

## [](#関連情報)関連情報 - [Mule OAuth 2.0 アクセストークンポリシーの使用方法](#external-oauth-2.0-token-validation-policy.adoc) - [OAuth 2.0 ダンスと OAuth 2.0 アクセストークン適用](https://docs.mulesoft.com/jp/api-manager/latest/oauth-dance-about) - [OAuth 2.0 許可種別](https://docs.mulesoft.com/jp/api-manager/latest/oauth-grant-types-about) - [起動時のログイン情報の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule4) # Mule ゲートウェイ API インスタンスの追加 Design Center またはその他のアプリケーションを使用して API を作成したら、API インスタンスを追加して、API Manager でその API を管理できます。API は、削除するまで API Manager の管理下に置かれます。 Mule Runtime に API があり、API を管理、監視、保護するために API ゲートウェイが必要な場合、Mule ゲートウェイを選択します。 API インスタンスを追加するには、次の 3 つのオプションがあります。 - [**Add a new API (新しい API を追加):**](#add-api)​ API の完全に新しいインスタンスを追加するには、このオプションを選択します。 - [**Promote API from environment: (環境から API を昇格):**](#promote-api)​ Sandbox 環境などの別の環境に API インスタンスがあり、それを現在の環境または本番環境に昇格する場合、このオプションを選択します。 - [**Import API from zip file (zip ファイルから API をインポート):**](#import-api)​ 別の Anypoint Platform インスタンスから API インスタンスをエクスポートしている場合、このオプションを選択します。 API インスタンスを昇格またはインポートするときに、設定を変更するオプションはありません。ただし、新しい API インスタンスを追加する場合、ダウンストリームとアップストリームの設定を定義する必要があります。 次の図は、アップストリームおよびダウンストリームの設定と、アップストリームサービスおよびダウンストリームコンシューマーアプリケーションとの関係を示しています。この設定では、ダウンストリームサービスは、アップストリームサービスによって完了される API 要求を行うサービスです。これらの用語は、情報の方向ではなく、連動関係の方向を表します。ダウンストリームサービスは、アップストリームサービスに情報を提供する ​`POST`​ 要求を行うことができます。ただし、ダウンストリームサービスは、要求の完了には引き続きアップストリームサービスに連動します。 ![API インスタンスは、アップストリーム設定とダウンストリーム設定の間のゲートウェイにデプロイされます。](/mulesoft/current/ja-jp/api-manager/latest/_images/api-upstream-downstream-config.png) ## [](#add-api)新しい API を追加する 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Add new API (新しい API を追加)\]**​ をクリックします。 3. **\[Mule Gateway (Mule ゲートウェイ)\]**​ を選択します。 4. 以下のオプションから​**プロキシ種別**​を選択します。 Connect to existing application (Basic Endpoint) (既存のアプリケーションへの接続 (基本エンドポイント)) アプリケーションに API ゲートウェイの自動検出が設定されている場合、このオプションを使用して Mule Runtime Engine (Mule) アプリケーションと直接やりとりします。詳細は、​[「API 自動検出」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-autodiscovery-overview)​を参照してください。 **Mule バージョン**​を選択します。 Deploy a proxy application (プロキシアプリケーションのデプロイ) API ゲートウェイの自動検出が設定されていない Mule アプリケーションであるか、Mule アプリケーションではないためにプロキシによってアプリケーションとやりとりする場合、このオプションを使用します。 詳細は、​[「API のプロキシの設定」](https://docs.mulesoft.com/jp/api-manager/latest/api-proxy-landing-page)​を参照してください。 5. プロキシアプリケーションのデプロイを選択した場合は、以下のオプションから​**対象種別**​を選択します。 - **CloudHub 2.0**​: コンテナベースのクラウドインフラストラクチャで MuleSoft によってホストされている Mule Runtime を使用する場合は、このオプションを選択します。CloudHub 2.0 プロキシには、デフォルトで 0.1 vCore の CPU が含まれています。 1. スペースを選択します。 スペースについての詳細は、​[Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) and [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about)​を参照してください。 2. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 3. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **CloudHub:**​ MuleSoft によってクラウドでホストされている Mule Runtime を使用する場合は、このオプションを選択します。CloudHub プロキシには、デフォルトで 0.1 vCore の CPU と 500 MB のメモリが含まれています。 1. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 2. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **Hybrid (ハイブリッド):**​ Runtime Manager に登録されているオンプレミスサーバーで実行される Mule Runtime インスタンスを使用する場合、このオプションを選択します。 詳細は、​[「Runtime Manager でのサーバーの登録」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 1. リストから接続先を選択するか、​**\[Add server (サーバーを追加)\]**​ をクリックします。 2. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **Self-managed Server (自己管理型サーバー):**​ JAR ファイルを作成して、Runtime Manager に登録されていないオンプレミスサーバーで実行される Mule Runtime インスタンスに API プロキシをデプロイする場合、このオプションを選択します。詳細は、[On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model)を参照してください。 API Manager で API プロキシを自己管理型サーバーにデプロイしても、プロキシはオンプレミスサーバーにデプロイされません。API Manager でプロキシをデプロイした後に、プロキシをオンプレミスサーバーにデプロイします。 . [新しい API プロキシ JAR ファイルをダウンロードします](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task)​。 . [JAR ファイルをオンプレミスサーバーにデプロイします](https://docs.mulesoft.com/mule-runtime/latest/deploy-on-premises)​。 - **Runtime Fabric:**​ Runtime Fabric で管理された Mule Runtime Engine に API プロキシをデプロイする場合、\[Runtime Fabric\] を選択します。 詳細は、​[「Runtime Fabric への API プロキシのデプロイ」](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric)​を参照してください。 1. リストから対象を選択します。 2. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 3. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 1. 以下のオプションから API を選択します。 - 管理する API を Exchange を介して共有している場合、​**\[Select API from Exchange (Exchange から API を選択)\]**​ をクリックします。 1. **\[Select API (API を選択)\]**​ の下のリストから API をクリックします。必要に応じて、特定の API を検索できます。 2. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 3. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。​**\[Conformance Status (準拠状況)\]**​ が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 - **\[Create new API (新しい API を作成)\]**​ をクリックします。 1. 新しい API アセットの​**名前**​を入力します。 2. 以下のオプションから​**アセットタイプ**​を選択します。 - **REST API:**​ アセットに含める RAML または OAS API 定義ファイルがある場合は、このオプションを選択します。 REST API の RAML または OAS ファイルをアップロードします。バージョン 2.0.0 以降ではネイティブ OAS サポートが追加されるので、OAS または RAML 仕様に推奨されるバージョンです。OAS API 仕様を API プロキシバージョン 1.0 以前にアップロードすると、API 仕様は RAML に変換されます。 - **HTTP API:**​ アセットに含める API 定義ファイルがない場合は、このオプションを選択します。 - **SOAP API:**​ WSDL API 定義ファイルまたはファイルへの外部リンクがある場合は、このオプションを選択します。 SOAP API の WSDL ファイルをアップロードするか、ファイルへのリンクを追加します。 このオプションは、現時点では Flex Gateway ランタイムでは使用できません。 3. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 4. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。\[Conformance Status (準拠状況)\] が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 1. **\[Next (次へ)\]**​ をクリックします。 2. プロキシ種別に関連するダウンストリーム設定を定義します。 Connect to existing application (Basic Endpoint) (既存のアプリケーションへの接続 (基本エンドポイント))
項目名 説明 必須 注意事項

Instance label (インスタンス表示ラベル)

API の表示ラベルを指定します。

いいえ

同じ API の複数の管理インスタンスがある場合、各インスタンスを他のインスタンスと区別するための表示ラベルを追加します。

Advanced Options (詳細オプション)

Consumer endpoint (コンシューマーエンドポイント)

コンシューマーが要求の送信に使用するプロキシアプリケーションのアドレスを指定します。

いいえ

Client provider (クライアントプロバイダー)

API のクライアントプロバイダーを指定します。

はい

Anypoint Platform はデフォルトではクライアントプロバイダーとして機能します。外部クライアントプロバイダーを設定するには、​「クライアントプロバイダー」​を参照してください。

Deploy a proxy application (プロキシアプリケーションのデプロイ)
項目名 説明 必須 注意事項

Protocol (プロトコル)

検証に HTTP と HTTPS のどちらを使用するかを指定します。

はい

HTTPS を選択する場合、インバウンドトラフィックの TLS コンテキストを指定します。

Inbound TLS (インバウンド TLS)

インバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。Mule 3 環境で HTTPS を有効にするには、​「Mule 3x での HTTPS の有効化」​を参照してください。

Port (ポート)

表示されたポートが正しくない場合に使用する番号を指定します。

はい

Base Path (ベースパス)

ホストルートに相対的なすべての API パスの URL プレフィックスを指定します。スラッシュ ​/​ で始まる必要があります。

はい

Instance label (インスタンス表示ラベル)

API の表示ラベルを指定します。

いいえ

同じ API の複数の管理インスタンスがある場合、各インスタンスを他のインスタンスと区別するための表示ラベルを追加します。

Advanced Options (詳細オプション)

Consumer endpoint (コンシューマーエンドポイント)

コンシューマーが要求の送信に使用するプロキシアプリケーションのアドレスを指定します。

いいえ

Client provider (クライアントプロバイダー)

API のクライアントプロバイダーを指定します。

はい

Anypoint Platform はデフォルトではクライアントプロバイダーとして機能します。外部クライアントプロバイダーを設定するには、​「クライアントプロバイダー」​を参照してください。

Request Timeout (要求タイムアウト)

要求がタイムアウトするまでの期間を指定します。

いいえ

Proxy Version (プロキシバージョン)

エンドポイントに使用するプロキシのバージョンを指定します。

いいえ

Service Name (サービス名)

WSDL サービスの名前。

はい

WSDL API でのみ使用できます。

Service Port (サービスポート)

WSDL サービスのポート。

はい

WSDL API でのみ使用できます。

Service Namespace (サービス名前空間)

WSDL サービスの名前空間。

はい

WSDL API でのみ使用できます。

Enable Console (コンソールを有効化)

API 仕様を公開およびテストできるかどうかを指定します。

いいえ

[Console Path (コンソールパス)]​ に別のパス (​/spec/*​ など) を指定できます。関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

Validations (検証)

提供された仕様に対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

厳格な検証 (省略可能)

クエリパラメーターに対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます+

User Domain (ユーザードメイン)

API ゲートウェイドメインを使用するかどうかを指定します。

いいえ

設定で以前にプロキシデプロイメント対象として ​[Hybrid (ハイブリッド)]​ を選択した場合は、必ずこのオプションを選択してください。Mule 3.8 以降の API ゲートウェイドメインをインストールする必要があります。

3. **\[Next (次へ)\]**​ をクリックします。 4. プロキシ種別に関連するアップストリーム設定を定義します。 Connect to existing application (Basic Endpoint) (既存のアプリケーションへの接続 (基本エンドポイント))
項目名 説明 必須 注意事項

Upstream URL (アップストリーム URL)

プロキシまたは API にアクセスするための URL。

いいえ

たとえば、Exchange の API アセットの URL を使用できます。

Deploy a proxy application (プロキシアプリケーションのデプロイ)
項目名 説明 必須 注意事項

Upstream URL (アップストリーム URL)

プロキシまたは API にアクセスするための URL。

はい

たとえば、Exchange の API アセットの URL を使用できます。

Outbound TLS (アウトバウンド TLS)

アウトバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。

5. **\[Next (次へ)\]**​ をクリックします。 6. 選択内容を確認し、必要に応じて編集します。 7. デプロイする準備ができたら、​**\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。または、​**\[Save (保存)\]**​ を選択して API インスタンスを保存し、後でデプロイします。 \== 新しい API アセットを作成する
この機能は、GovCloud 環境でのみ使用できます。他の環境で API アセットを作成する場合は、exchange::to-create-an-asset.adoc#create-an-api-assetを参照してください。
API アセットでは、インターフェースのすべて (その関数、説明、戻りコードの処理方法、連動関係など) を指定します。 アセットを作成すると、アセットタイプが設定されます。アセットタイプは変更できません。アセットのすべてのバージョンのタイプは常に同じです。 API アセットを作成する手順は、次のとおりです。 1. \[API Manager\] で、​**\[Add API (API を追加)\]**​ をクリックします。 2. ドロップダウンリストから、​**\[Create new API asset (新規 API アセットを作成)\]**​ を選択します。 3. アセットの名前を入力します。 4. ドロップダウンリストから、アセットタイプを選択します。 - REST API - RAML: RAML API 仕様ファイルを提供します。RAML 仕様には RAML ファイル (.raml) を使用する必要があります。 - REST API - OAS: OAS API 仕様ファイルを提供します。OAS 仕様には YAML (.yaml) または JSON (.json) ファイルを使用できます。Exchange では、OAS 2.0 および OAS 3.0 仕様がサポートされています。 - SOAP API - WSDL: WSDL API 仕様ファイルを提供します。SOAP 仕様ファイルには WSDL (.wsdl) または XML (.xml) ファイルを使用できます。 - AsyncAPI: YAML (.yaml) または JSON (.json) ファイル形式の AsyncAPI 仕様ファイルを提供します。 - Avro スキーマを使用した AsyncAPI: AVSC (.avsc) ファイルで Avro フラグメントを提供します。 - API 仕様フラグメント - RAML: API フラグメント RAML 仕様ファイルを提供します。フラグメント仕様には RAML ファイル (.raml) を使用する必要があります。 - API 仕様フラグメント - JSON: API フラグメント JSON 仕様 (.json) ファイルを提供します。 - API 仕様フラグメント - OpenAPI 仕様 (OAS): API フラグメント OpenAPI 仕様ファイル JSON または YAML を提供します。 - HTTP API: このアセットはファイルを必要としません。このアセットタイプでは、API Manager によって定義された API エンドポイントを提供します。 5. ファイルを必要とするアセットの場合、次の手順を実行します。 1. **\[Choose File (ファイルを選択)\]**​ をクリックし、API 仕様ファイルを見つけます。 2. API のメインファイルを選択します。 ファイルが ZIP の場合、選択したメインファイルは ZIP ファイルのルートディレクトリにある必要があります。ファイルが ZIP ではない場合、または 1 つのメインファイルのみを含む ZIP ファイルの場合、メインファイルは自動的に選択されます。 6. **GroupId**​、​**AssetId**​、​**バージョン**​、​**API バージョン**​ (GAV) を編集するには、​**\[Advanced (詳細)\]**​ をクリックします。 グループ ID、アセット ID、バージョン (GAV) は Exchange によって自動的に生成されますが、これらの値は必要に応じて変更できます。API のアセットバージョンとバージョンは個別に変更できます。詳細設定を使用して、アセットバージョンを変更します。 7. **\[Lifecycle state (ライフサイクル状態)\]**​ のオプションを選択します。デフォルトは \[Stable (安定)\] です。 8. **\[Publish (パブリッシュ)\]**​ をクリックします。 ## [](#promote-api)別の環境への API インスタンスの昇格 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Promote API from environment (環境から API を昇格)\]**​ を選択します。 3. **\[Source Environment (ソース環境)\]**​ を選択します。 4. 検索項目に API の名前を入力して、​**\[API\]**​ を選択します。 5. **\[API Version (API バージョン)\]**​ を選択します。 6. **\[API instance label (API インスタンスの表示ラベル)\]**​ を選択します。 7. 必要に応じて、除外する ​**\[Include in Promotion (昇格に含める)\]**​ オプションをオフにます。 8. **\[Promote (昇格)\]**​ をクリックします。 9. 必要に応じて、\[Runtime & Endpoint Configuration (ランタイムとエンドポイント設定)\] の詳細を確認して更新し、​**\[Save (保存)\]**​ をクリックします。 ## [](#import-api)Zip ファイルから API をインポートする 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Import API from zip file (zip ファイルから API をインポート)\]**​ を選択します。 3. **\[Choose file (ファイルを選択)\]**​ をクリックし、API インスタンス設定 zip ファイルを選択します。 4. **\[Next (次へ)\]**​ をクリックします。 5. 必要に応じて API 設定の詳細を確認して更新し、​**\[Save (保存)\]**​ をクリックします。 ## [](#注意事項)注意事項 - OpenAPI 仕様 (OAS) 3.0 はサポートされていますが、コールバック機能はサポートされていません。この問題を回避するには、Mule Runtime Engine ドメインの外部でコールバックを処理するか、コールバックを使用しない OAS 3.0 仕様を使用します。 # Mule ゲートウェイまたは Service Mesh の API アラートの追加 API を追跡および管理するには、1 つ以上の API アラートを API インスタンスに追加できます。各自の要件に基づいて、さまざまな​[種別のアラート](https://docs.mulesoft.com/jp/api-manager/latest/using-api-alerts)​を追加します。 Mule ゲートウェイまたは Service Mesh をランタイムとして使用する API の場合、このチュートリアルの手順に従ってアラートを API に追加します。 ポリシー違反アラートは​[自動ポリシー](https://docs.mulesoft.com/gateway/latest/policies-automated-overview)​に追加できません。
このチュートリアルは Mule ゲートウェイおよび Service Mesh ランタイムを対象とします。Flex Gateway をランタイムとして使用する API にアラートを追加するには、​「Flex Gateway の API アラートの追加」​を参照してください。
## [](#mule-gateway)Mule ゲートウェイまたは Service Mesh の API アラートの追加 Mule ゲートウェイまたは Service Mesh API に API アラートを追加する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、アラートを追加する API インスタンスをクリックします。 3. **\[Alerts (アラート)\]**​ > ​**\[Add alert (アラートを追加)\]**​ をクリックします。 4. アラートオプションを指定します。 - **Name (名前)**​: アラート名を入力します (例: `trial-alert`​)。 複数のアラートを同じ環境に追加する場合、アラートの名前が一意である必要があります。 - **Enabled (有効化)**​: デフォルトのオプションは ​**\[Enabled (有効化)\]**​ です。 不要な場合はアラートをいつでも削除できます。 - **Severity (重要度)**​: アラートの重要度を選択します (例: **\[Info (情報)\]**​)。 - **Alert type (アラートタイプ)**​: 作成するアラートの種別 (​**\[Request Count (要求数)\]**​ など) を選択し、アラートの適切な設定値を指定します。アラートタイプについての詳細は、​[「API アラート」](https://docs.mulesoft.com/jp/api-manager/latest/using-api-alerts#api-alerts)​を参照してください。

[For at least (次の期間以上)]​ 項目と ​[consecutive period(s) of (連続する次の期間)]​ 項目に 1 ~ 999999999 の値を入力し、期間を スライディングウィンドウ​として指定します。

5. **受信者**​を選択します。 メール通知を受信するメールを指定します。 6. **\[Create Alert (アラートを作成)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [アラートの概念の確認](https://docs.mulesoft.com/jp/api-manager/latest/using-api-alerts) - [Flex Gateway の API アラートの追加](https://docs.mulesoft.com/gateway/latest/use-api-alerts) # OAuth 2.0 ダンスと OAuth 2.0 アクセストークン適用 OAuth ダンスは、Mule OAuth 2.0 プロバイダー、API、およびクライアントアプリケーションによって実行される認証プロセスです。こ認証プロセスは、RFC 6749 に準拠しています。 ## [](#oauth-ダンス認証フロー)OAuth ダンス認証フロー 次のスクリーンショットは、OAuth ダンス認証フローを示しています。 ![oauth+policy1](/mulesoft/current/ja-jp/api-manager/latest/_images/mule-oauth-provider-dance.png) 1. トークン要求はプロバイダーに送信され、必要に応じてクライアントアプリケーションのログイン情報が指定されます。 ログイン情報は、Anypoint Platform によって生成されるクライアント ID とクライアントシークレットに対応します。 2. Mule OAuth 2.0 プロバイダーがトークンを返します。 3. HTTP 要求が、OAuth 2.0 アクセストークン適用ポリシーの適用先の保護されたリソースに対して実行されます。 保護されたリソースが自動検出によって API 定義にリンクされます。 4. OAuth 2.0 アクセストークン適用ポリシーがこの要求を傍受し、プロバイダーにトークンを検証するように伝えます。 5. トークンが正しく検証された場合: 1. トークンは許可リスト登録され、有効期限が切れるまで保持されます。 以降のこのトークンが含まれる要求は、OAuth プロバイダーに対して検証されません。 2. クライアントアプリケーションのログイン情報に関連付けられたクライアント ID が検証され、アプリケーションに API とのアクティブなコントラクトがあることが確認されます。 これは OpenAM プロバイダーには適用されません。 6. 要求がリソースに転送されます。 7. HTTP 応答が生成されます。 リクエスターは、クライアントアプリケーションのログイン情報へのアクセス権を直接取得するのではなく、OAuth プロバイダーから認証されます。クライアントアプリケーションオーナーがログイン情報を所有し、プロバイダーに API とのやりとりを許可します。保護されたリソースは、ユーザーが有効なアクセストークンを持っているため、認証済みと判断します。 ## [](#curl-を使用した保護されたリソースへの-http-要求の例)curl を使用した保護されたリソースへの HTTP 要求の例 次の例では、保護されたリソースが「http://localhost:8081/simple」に設定されています。 ### [](#http-認証ヘッダーを使用)HTTP 認証ヘッダーを使用 ```console curl -H "Authorization:Bearer " "http://localhost:8081/simple" -vvv ``` ### [](#http-クエリパラメーターを使用)HTTP クエリパラメーターを使用 ```console curl "http://localhost:8081/simple/?access_token=" -vvv ``` ## [](#関連情報)関連情報 - [OAuth 2.0 許可種別](https://docs.mulesoft.com/jp/api-manager/latest/oauth-grant-types-about) - [Mule OAuth 2.0 プロバイダー](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page) # OAuth 2.0 ポリシーの前提条件 OAuth 2.0 ポリシーを使用するための前提条件を次に示します。 - API を作成または管理するための必要な権限がある - 関連付けられたリソースを保護するようにポリシーを API インスタンスに適用する - API プラットフォームで作成され、API インスタンスに登録されたクライアントアプリケーションがある - クライアントアプリケーションのログイン情報に基づいてトークンを発行し、そのトークンを検証できる OAuth 2.0 プロバイダーがある - Mule OAuth 2.0 プロバイダーを使用している場合、組織のログイン情報を使用してランタイムも正しく設定されている必要があります。 - \[API インスタンス RAML ベース\] OAuth ダンス機能を備えた API Console を使用する場合、RAML でセキュリティスキーマを指定する必要があります。 リソースが OAuth トークン適用ポリシーで保護されている場合、保護されたリソースに送信するすべての要求内で OAuth トークンをクエリパラメーターまたは認証ヘッダーとして指定する必要があります。この使用方法についての概要を次の表に示します。
トークンを含める場所 例 注意事項

クエリパラメーター

?access_token=123

URI の一部として含めます

認証ヘッダー

Authorization:Bearer 123

ヘッダーはキーと値のペアで構成されます。 ​"Bearer" + <space> + <token, for example, 123>​

API インスタンスが RAML ベースの場合、保護されたリソースを、OAuth により保護されているとして宣言し、適用されているポリシーを API Consol が認識できるようにします。
OAuth トークン適用ポリシーにより保護されたリソースを RAML/OAS 定義で宣言することは、そのポリシーが実際に適用されることを意味するものではありません。
RAML securitySchemes 定義内に承認およびアクセストークンの URI を含めます。 また、保護するリソースおよびメソッドのメソッド名の後に securedBy ノードを追加します。 ```yaml #%RAML 1.0 title: Interop Testing version: v1.0 baseUri: http://127.0.0.1:8081/api ... securitySchemes: oauth_2_0: description: | Mule OAuth 2.0. type: OAuth 2.0 describedBy: headers: Authorization: description: | Used to send a valid OAuth 2 access token. Do not use with the "access_token" query string parameter. type: string queryParameters: access_token: description: | Used to send a valid OAuth 2 access token. Do not use together with the "Authorization" header type: string responses: 401: description: | Bad or expired token. 403: description: | Bad OAuth request. settings: authorizationUri: http://0.0.0.0:8081/authorize accessTokenUri: http://0.0.0.0:8081/access-token authorizationGrants: [authorization_code, password, client_credentials, implicit] ... /users: get: securedBy: [oauth_2_0] ``` ## [](#関連情報)関連情報 - [RAML securitySchemes](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#oauth-20) # OAuth 2.0 許可種別 OAuth 2.0 では、トークンの要求に次の許可種別を指定します。 - AUTHORIZATION\_CODE​ - IMPLICIT - RESOURCE\_OWNER\_PASSWORD\_CREDENTIALS​ - CLIENT\_CREDENTIALS RAML ベースの API の場合、OAuth 2.0 セキュリティスキーマに合わせて RAML を更新する必要があります。次の表では、RAML 許可種別と OAuth 2.0 ポリシー設定の許可種別名をマップしています。
RAML 定義で定義される認証許可種別 OAuth プロバイダーポリシーで有効化する同等の認証許可種別 埋め込み APIkit コンソールのサポート対象

[implicit]

暗黙的

はい

[client_credentials]

クライアントログイン情報

いいえ

[password]

リソースオーナーのパスワードログイン情報

いいえ

[authorization_code]

認証コード

はい

詳細は、​[「OAuth 2.0 ポリシーの前提条件の確認」](https://docs.mulesoft.com/jp/api-manager/latest/about-configure-api-for-oauth)​ドキュメントを参照してください。 ## [](#authorization-code-grant-type-認証コード許可種別)Authorization Code Grant Type (認証コード許可種別) 認証コード許可種別は、最もよく使用される最も安全な許可種別です。 この許可種別を使用してトークンを取得するには、プロバイダーへの HTTP 要求に次の情報を指定する必要があります。 - クライアントアプリケーションのクライアント ID - クライアントアプリケーションのクライアントシークレット - クライアントアプリケーション定義に指定されているリダイレクト URL ### [](#トークンを取得するためのプロバイダーへの-http-要求の例)トークンを取得するためのプロバイダーへの HTTP 要求の例 プロバイダーは [http://localhost:8081](http://localhost:8081) でアクセスでき、クライアントアプリケーションのリダイレクト URL は「http://localhost:1234」であるとします。 認証要求: ```console curl “http://localhost:8081/authorize” \ -d “response_type=code&client_id= \ &scope=&redirect_uri=http://localhost:1234” \ -X POST ``` ブラウザーにログインページが表示されます。ユーザーがログインした後、プロバイダーはリダイレクトを ​`redirect_uri`​ に送信します。このリダイレクトには、アクセスコードなど、追加のプロパティが含まれます。 応答: http://localhost:1234/?code=#/login 要求でアクセスコードをトークンエンドポイントに送信します。他にも、クライアント ID、クライアントシークレット、前のコールの情報の一部が含まれます。 トークン要求: ```console curl “http://localhost:8081/access-token” \ -d “grant_type=authorization_code&client_id=&client_secret= \ &code=&redirect_uri=” \ -X POST ``` JSON 応答: { "expires\_in":86400, "token\_type":"bearer", "refresh\_token":"", "access\_token":"" } ## [](#暗黙的)暗黙的 暗黙的許可種別は、認証コード許可種別ほど安全ではありませんが、より簡単に使用できます。JavaScript クライアントやモバイルアプリケーションではこの許可種別がよく使用されます。認証サーバーがアクセストークンを直接発行し、中間アクセスコードを発行するステップが省略されます。 ### [](#トークンを取得するためのプロバイダーへの-http-要求の例-2)トークンを取得するためのプロバイダーへの HTTP 要求の例 プロバイダーは [http://localhost:8081](http://localhost:8081) でアクセスでき、クライアントアプリケーションのリダイレクト URL は「http://localhost:1234」であるとします。 クライアント ID、実行する認証の種別、リダイレクト URL、認証するスコープを含む要求で認証エンドポイントを呼び出します。要求の構造は次の URI のようになります。 トークン要求: ```console curl “http://localhost:8081/authorize” \ -d “grant_type=implicit&client_id= \ &redirect_uri=http://localhost:1234&response_type=token” \ -X POST ``` これによりブラウザーにログインページが表示されます。ユーザーがログインした後、プロバイダーはリダイレクトを ​`redirect_uri`​ に送信します。このリダイレクトにはすでに、アクセスコードだけでなくトークンが含まれています。 応答: http://localhost:1234/#access\_token=&token\_type=bearer&expires\_in=86400 ## [](#リソースオーナーのパスワードログイン情報)リソースオーナーのパスワードログイン情報 リソースオーナーのパスワードログイン情報許可種別は、暗黙的および認証コード許可種別よりも安全性が低くなります。クライアントはユーザーのログイン情報を処理する必要があります。クライアントではユーザーに高いレベルの信頼が要求されます。この許可種別は多くの場合、保護されたリソースのコンシューマーが同じサービスのウィジェットである場合に使用されます。 ### [](#トークンを取得するためのプロバイダーへの-http-要求の例-3)トークンを取得するためのプロバイダーへの HTTP 要求の例 プロバイダーは [http://localhost:8081](http://localhost:8081) でアクセスできるとします。 ユーザー名とパスワードが含まれる POST 要求をトークンエンドポイントに送信します。 トークン要求: ```console curl "http://localhost:8081/access-token” \ -d “grant_type=password&response_type=token&username= \ &password=&client_id= \ &client_secret=" \ -X POST ``` JSON 応答の例: ```json { "expires_in":86400, "token_type":"bearer", "refresh_token":"", "access_token":"" } ``` ## [](#クライアントログイン情報)クライアントログイン情報 クライアントログイン情報許可種別は、最も安全性の低い許可種別です。この許可種別は、クライアントがリソースオーナーであるか、認証が認証サーバーによってすでに処理されている場合に使用します。この許可種別では、アクセストークンは、クライアント ID とクライアントシークレットが有効な場合に取得されます。 ### [](#トークンを取得するためのプロバイダーへの-http-要求の例-4)トークンを取得するためのプロバイダーへの HTTP 要求の例 プロバイダーは [http://localhost:8081](http://localhost:8081) でアクセスでき、クライアントアプリケーションのリダイレクト URL は「http://localhost:1234」であるとします。 ユーザー名とパスワードが含まれる POST 要求をトークンエンドポイントに送信します。 トークン要求: ```console curl “http://localhost:8081/access-token” \ -d “grant_type=client_credentials&client_id= \ &client_secret=&response_type=token” \ -X POST ``` JSON 応答: http://localhost:1234/#access\_token=&token\_type=bearer&expires\_in=86400 ## [](#関連情報)関連情報 - [Mule OAuth 2.0 プロバイダー](https://docs.mulesoft.com/jp/api-manager/latest/mule-oauth-provider-landing-page) # RAML または OAS API プロキシの構築 API Manager 2.x では、Mule 4 ベースのすべてのプロキシに、RAML または OAS タイプの API プロキシを使用できます。 ## [](#raml-または-oas-api-プロキシを設定する)RAML または OAS API プロキシを設定する RAML または OAS API プロキシを設定するには、以下の手順を完了します。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Add new API (新しい API を追加)\]**​ をクリックします。 3. ランタイムとして ​**\[Mule Gateway (Mule ゲートウェイ)\]**​ を選択します。 4. **\[Proxy type (プロキシ種別)\]**​ で ​**\[Deploy a proxy application (プロキシアプリケーションをデプロイ)\]**​ を選択します。 5. プロキシアプリケーションのデプロイを選択した場合は、以下のオプションから​**対象種別**​を選択します。 - **CloudHub 2.0**​: コンテナベースのクラウドインフラストラクチャで MuleSoft によってホストされている Mule Runtime を使用する場合は、このオプションを選択します。CloudHub 2.0 プロキシには、デフォルトで 0.1 vCore の CPU が含まれています。 1. スペースを選択します。 スペースについての詳細は、​[Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) and [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about)​を参照してください。 2. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 3. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **CloudHub:**​ MuleSoft によってクラウドでホストされている Mule Runtime を使用する場合は、このオプションを選択します。CloudHub プロキシには、デフォルトで 0.1 vCore の CPU と 500 MB のメモリが含まれています。 1. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 2. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **Hybrid (ハイブリッド):**​ Runtime Manager に登録されているオンプレミスサーバーで実行される Mule Runtime インスタンスを使用する場合、このオプションを選択します。 詳細は、​[「Runtime Manager でのサーバーの登録」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 1. リストから接続先を選択するか、​**\[Add server (サーバーを追加)\]**​ をクリックします。 2. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **Self-managed Server (自己管理型サーバー):**​ JAR ファイルを作成して、Runtime Manager に登録されていないオンプレミスサーバーで実行される Mule Runtime インスタンスに API プロキシをデプロイする場合、このオプションを選択します。詳細は、[On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model)を参照してください。 API Manager で API プロキシを自己管理型サーバーにデプロイしても、プロキシはオンプレミスサーバーにデプロイされません。API Manager でプロキシをデプロイした後に、プロキシをオンプレミスサーバーにデプロイします。 . [新しい API プロキシ JAR ファイルをダウンロードします](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task)​。 . [JAR ファイルをオンプレミスサーバーにデプロイします](https://docs.mulesoft.com/mule-runtime/latest/deploy-on-premises)​。 - **Runtime Fabric:**​ Runtime Fabric で管理された Mule Runtime Engine に API プロキシをデプロイする場合、\[Runtime Fabric\] を選択します。 詳細は、​[「Runtime Fabric への API プロキシのデプロイ」](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric)​を参照してください。 1. リストから対象を選択します。 2. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 3. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 1. 以下のオプションから API を選択します。 - 管理する API を Exchange を介して共有している場合、​**\[Select API from Exchange (Exchange から API を選択)\]**​ をクリックします。 1. **\[Select API (API を選択)\]**​ の下のリストから API をクリックします。必要に応じて、特定の API を検索できます。 2. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 3. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。​**\[Conformance Status (準拠状況)\]**​ が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 - **\[Create new API (新しい API を作成)\]**​ をクリックします。 1. 新しい API アセットの​**名前**​を入力します。 2. **アセットタイプ**​に ​**REST API**​ を選択します。 3. REST API の RAML または OAS ファイルをアップロードします。
Anypoint API Manager では、OpenAPI 仕様 (OAS) 3.0 はサポートされていますが、コールバック機能はサポートされていません。この問題を回避するには、Mule Runtime Engine ドメインの外部でコールバックを処理するか、コールバックを使用しない OAS 3.0 仕様を使用します。
4. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 5. API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。​**\[Conformance Status (準拠状況)\]**​ が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 1. **\[Next (次へ)\]**​ をクリックします。 2. ダウンストリーム設定を定義します。 設定を確認するには展開します。
項目名 説明 必須 注意事項

Protocol (プロトコル)

検証に HTTP と HTTPS のどちらを使用するかを指定します。

はい

HTTPS を選択する場合、インバウンドトラフィックの TLS コンテキストを指定します。

Inbound TLS (インバウンド TLS)

インバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。Mule 3 環境で HTTPS を有効にするには、​「Mule 3x での HTTPS の有効化」​を参照してください。

Port (ポート)

表示されたポートが正しくない場合に使用する番号を指定します。

はい

Base Path (ベースパス)

ホストルートに相対的なすべての API パスの URL プレフィックスを指定します。スラッシュ ​/​ で始まる必要があります。

はい

Instance label (インスタンス表示ラベル)

API の表示ラベルを指定します。

いいえ

同じ API の複数の管理インスタンスがある場合、各インスタンスを他のインスタンスと区別するための表示ラベルを追加します。

Advanced Options (詳細オプション)

Consumer endpoint (コンシューマーエンドポイント)

コンシューマーが要求の送信に使用するプロキシアプリケーションのアドレスを指定します。

いいえ

Client provider (クライアントプロバイダー)

API のクライアントプロバイダーを指定します。

はい

Anypoint Platform はデフォルトではクライアントプロバイダーとして機能します。外部クライアントプロバイダーを設定するには、​「クライアントプロバイダー」​を参照してください。

Request Timeout (要求タイムアウト)

要求がタイムアウトするまでの期間を指定します。

いいえ

Proxy Version (プロキシバージョン)

エンドポイントに使用するプロキシのバージョンを指定します。

いいえ

Service Name (サービス名)

WSDL サービスの名前。

はい

WSDL API でのみ使用できます。

Service Port (サービスポート)

WSDL サービスのポート。

はい

WSDL API でのみ使用できます。

Service Namespace (サービス名前空間)

WSDL サービスの名前空間。

はい

WSDL API でのみ使用できます。

Enable Console (コンソールを有効化)

API 仕様を公開およびテストできるかどうかを指定します。

いいえ

[Console Path (コンソールパス)]​ に別のパス (​/spec/*​ など) を指定できます。関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

Validations (検証)

提供された仕様に対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

厳格な検証 (省略可能)

クエリパラメーターに対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます+

User Domain (ユーザードメイン)

API ゲートウェイドメインを使用するかどうかを指定します。

いいえ

設定で以前にプロキシデプロイメント対象として ​[Hybrid (ハイブリッド)]​ を選択した場合は、必ずこのオプションを選択してください。Mule 3.8 以降の API ゲートウェイドメインをインストールする必要があります。

3. **\[Next (次へ)\]**​ をクリックします。 4. アップストリーム設定を定義します。 設定を確認するには展開します。
項目名 説明 必須 注意事項

Upstream URL (アップストリーム URL)

プロキシまたは API にアクセスするための URL。

はい

たとえば、Exchange の API アセットの URL を使用できます。

Outbound TLS (アウトバウンド TLS)

アウトバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。

5. **\[Next (次へ)\]**​ をクリックします。 6. 選択内容を確認し、必要に応じて編集します。 7. デプロイする準備ができたら、​**\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。または、​**\[Save (保存)\]**​ を選択して API インスタンスを保存し、後でデプロイします。 ## [](#関連情報)関連情報 - [API プロキシの利点と影響の確認](https://docs.mulesoft.com/jp/api-manager/latest/proxy-advantages) - [HTTPS サービスの構築](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service) - [API プロキシのデプロイ](https://docs.mulesoft.com/jp/api-manager/latest/proxy-latest-concept) # RAML/OAS ベースの API の特性およびポリシーの概念 ユーザーが参照しなければならない可能性がある RAML または OAS 定義を API が公開する場合、API 定義には、API へのコールで想定されるすべての要素が確実に記述されている必要があります。 たとえば、クライアント ID ベースのポリシーを適用すると、API に対するすべての要求にクライアント ID とクライアントシークレット (デフォルトでクエリパラメーターとして想定される) が含まれていることを意味します。ユーザー要求が却下されることを防止するため、RAML ルートに特性を作成し、API のすべての操作でこの特性を参照します。特性は次のようになります。 ```yaml traits: - client-id-required: queryParameters: client_id: type: string client_secret: type: string ``` 次に、個々の操作で次のようにこの特性を適用できます。 ```yaml /products: get: is: [client-id-required] description: Gets a list of all the inventory products. ``` ## [](#ポリシー仕様スニペットの取得)ポリシー仕様スニペットの取得 1. API ダッシュボードで ​**\[Policies (ポリシー)\]**​ をクリックします。 ポリシーのリストの RAML スニペットリンクには、API 仕様に追加する必要がある RAML trait または OAS コンポーネントが含まれています。 ![\[API Manager Policies (API Manager ポリシー)\] ページ。](_images/raml-snippet.png) 2. **\[API Specification Snippet (API 仕様スニペット)\]**​ をクリックします。 3. 仕様に適合する API タイプを選択します。 - API RAM バージョンに適合する RAML 0.8 または RAML 1.0。 ![RAML 0.8 が選択された \[API Specification Snippet (API 仕様スニペット)\] ページ。](_images/snippet-rate-limiting.png) - または API OAS バージョンに適合する OAS 2.0。 ![OAS 2.0 が選択された \[API Specification Snippet (API 仕様スニペット)\] ページ。](_images/prepare-raml-task-2b676.png) OAS スニペットは、すべてのポリシーバージョンで表示されるわけではありません。 次の表で、OAS スニペットが表示されるポリシーとバージョンを確認してください。
ポリシー バージョン

レート制限 - SLA ベース

v1.1.2 以降

Mule OAuth プロバイダーを使用する OAuth 2.0 アクセストークン適用

v1.1.3 以降

OpenAM アクセストークン適用

v1.1.3 以降

OpenID Connect アクセストークン適用

v1.1.3 以降

PingFederate アクセストークン適用

v1.1.3 以降

クライアント ID 適用

v1.1.3 以降

4. API を編集してコードを追加します。 5. API を再デプロイします。 ## [](#関連情報)関連情報 - [提供ポリシー](https://docs.mulesoft.com/jp/policies/policies-availability-by-gateway) - [カスタムポリシー](https://docs.mulesoft.com/gateway/latest/policies-custom-overview) # REST バリデーター拡張機能の設定 REST バリデーター拡張機能では、RAML または OAS 仕様を使用するスキーマ検証を要求の属性に対して実行できます。また、この拡張機能では、デフォルト値が属性に追加されます (要求でまだ設定されていない場合)。 特に記載がない限り、このドキュメントは REST バリデーター拡張機能 v2.x にのみ適用されます。Mule Runtime Engine (Mule) アプリケーション XML などの Mule アーティファクトで REST バリデーター拡張機能を使用するには、以下の作業を行う必要があります。 1. [pom.xml ファイルに連動関係を含める](#include-dependency)​。 2. [名前空間とスキーマを Mule アーティファクトに含める](#add-namespace-and-schema)​。 3. [REST バリデーター拡張機能を設定する](#configure-rest-validator-extension)​。 4. [REST バリデーター操作を使用する](#use-operations)​。 ## [](#include-dependency)pom.xml ファイルに連動関係を含める `pom.xml`​ ファイルの ​``​ セクションに次のスニペットを追加して、REST バリデーターを Mule アーティファクト (Mule アプリケーション XML など) に含めることができます。 ```XML com.mulesoft.anypoint mule-rest-validator-extension ${restValidatorVersion} mule-plugin ``` ベストプラクティスとして、使用する REST バリデーターのバージョンで ​``​ セクション内に Maven プロパティを定義することをお勧めします。 ```XML 2.1.3 ``` ## [](#add-namespace-and-schema)名前空間とスキーマを Mule アーティファクトに追加する Mule アーティファクトで REST バリデーター操作を使用するには、次の名前空間とスキーマを含めます。 ```text xmlns:rest-validator="http://www.mulesoft.org/schema/mule/rest-validator" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/rest-validator http://www.mulesoft.org/schema/mule/rest-validator/current/mule-rest-validator.xsd" ``` ## [](#configure-rest-validator-extension)REST バリデーター拡張機能を設定する REST バリデーター拡張機能を設定するには、Mule アーティファクトに次の構文を追加します。 `` このスニペットには、設定に必要な属性が含まれます。​[追加属性](#config-reference)​を指定して、拡張機能をカスタマイズできます。次の例は、戦略を非逐次化する属性を使用する方法を示しています。 ```XML ``` ## [](#use-operations)REST バリデーター操作を使用する REST バリデーターを設定したら、バリデーター操作の使用を開始できます。 **操作名** `validate-request` **説明** 設定で指定された RAML または OAS 仕様に対して要求を検証します。 **使用例** `` **属性の説明** 次の表に、属性と説明を示します。
属性 説明 必須かどうか

attributes

検証する属性を抽出する DataWeave 式。デフォルト値: #[attributes]

いいえ

payload

検証するペイロードを抽出する DataWeave 式。デフォルト値: #[payload]

いいえ

config-ref

REST バリデーターの設定。

はい

**Output (出力)** 定義されたスキーマに要求が違反していない場合、検証は正常に終了し、操作の結果で HTTP 要求属性は変更されません。違反している場合、デフォルト値がスキーマ検証に追加され、元の HTTP 要求属性と新しい HTTP 要求属性が出力に含まれます。 **エラー種別** 「validate-request」操作では、ファイルの取得時に問題が発生した場合や、検証が正常に終了しなかった場合に各種エラーが発生する可能性があります。 - `REST-VALIDATOR:BAD_REQUEST` 一部の属性がスキーマと一致しない場合、エラーが発生します。以下のような属性が検証中に考慮されます。 - フォームパラメーター - ヘッダー - クエリパラメーター - URI パラメーター - `REST-VALIDATOR:METHOD_NOT_ALLOWED` スキーマで必須リソースの特定のメソッドがサポートされていない場合、エラーが発生します。 - `REST-VALIDATOR:RESOURCE_NOT_FOUND` ルートスキーマまたは一部の関連ファイルを取得できない場合、エラーが発生します。 ## [](#config-reference)REST バリデーター拡張機能設定リファレンス 次の表で、バリデーター拡張機能で設定する属性について説明します。
属性 説明 必須かどうか

name

設定の一意の識別子。

はい

api

2.0.0 以降のバージョンの REST バリデーターを使用している場合、​raml​ 属性を使用する必要があります。これには、要求の検証の対象となる仕様ファイルの場所が含まれます。

はい

parser

要求の検証に使用されるパーサー。

  • AUTO (デフォルト)

    APIKit は、AMF を使用して検証を開始しようとします。エラーが発生した場合、RAML パーサーが検証を実行します。

  • AMF

    APIKit ルーターは AMF を使用して API を読み取り、受信要求を検証します。

  • RAML

    APIKit ルーターは RAML パーサーを使用して API を読み取り、受信要求を検証します。

いいえ

keepApiBaseUri

デプロイ済みアプリケーションの URI を使用して、仕様の ​baseUri​ プロパティを上書きできるかどうかを指定します。 コンソール操作を使用する必要がある場合、このプロパティを ​true​ に設定します。デフォルト値は ​false​ です。

2.0.0 以降のバージョンの REST バリデーターを使用している場合、​keepRamlBaseUri​ 属性を使用する必要があります。

いいえ

queryParamsStrictValidation

要求のすべてのクエリパラメーターが仕様ファイルで定義されているかどうかを検証します。一部のパラメーターが指定されていない場合、検証は失敗します。デフォルト値は ​false​ です。

いいえ

headersStrictValidation

仕様で定義されているすべての必須ヘッダーが要求で定義されているかどうかを検証します。一部のパラメーターが指定されていない場合、検証は失敗します。デフォルト値は ​false​ です。

いいえ

attributesDeserializingStrategies`

カンマで区切られた値の配列が含まれる HTTP ヘッダーの解析を許可します。

いいえ

## [](#rest-バリデーターと-apikit-の互換性リファレンス)REST バリデーターと APIKit の互換性リファレンス REST バリデーター (​`pom.xml`​ 連動関係) は、ドメインを使用してアプリケーション間で共有できます。ただし、それらのアプリケーションの一部に APIKit の連動関係もある場合、各アプリケーションのそのバージョンの APIKit と、ドメインで使用する REST バリデーターのバージョンで必要な APIKit が一致している必要があります。 次の互換性の表に従うと、たとえば、ドメインで REST バリデーター v2.2.0 を使用している場合、APIKit を使用しているすべてのアプリケーションで 1.4.2 バージョンをインポートする必要があります。
REST バリデーターバージョン ApiKit REST Module バージョン

2.2.4

1.9.0

2.2.3

1.8.3

2.2.2

1.7.0

2.2.1

1.5.3

2.2.0

1.4.2

2.1.3

1.3.17

2.1.2

1.3.11

2.1.1

1.3.5

2.1.0

1.3.5

2.0.0

1.2.0

1.2.0

1.1.16

1.1.1

1.1.1

# Service Mesh API インスタンスの追加 Design Center またはその他のアプリケーションを使用して API を作成したら、API インスタンスを追加して、API Manager でその API を管理できます。API は、削除するまで API Manager の管理下に置かれます。 Mule アダプターのデプロイメントを通して Anypoint Platform の API 管理機能を Istio サービスメッシュに拡張するには、Anypoint Service Mesh を選択します。 API インスタンスを追加するには、次の 3 つのオプションがあります。 - [**Add a new API (新しい API を追加):**](#add-api)​ API の完全に新しいインスタンスを追加するには、このオプションを選択します。 - [**Promote API from environment: (環境から API を昇格):**](#promote-api)​ Sandbox 環境などの別の環境に API インスタンスがあり、それを現在の環境または本番環境に昇格する場合、このオプションを選択します。 - [**Import API from zip file (zip ファイルから API をインポート):**](#import-api)​ 別の Anypoint Platform インスタンスから API インスタンスをエクスポートしている場合、このオプションを選択します。 API インスタンスを昇格またはインポートするときに、設定を変更するオプションはありません。ただし、新しい API インスタンスを追加する場合、ダウンストリームとアップストリームの設定を定義する必要があります。 次の図は、アップストリームおよびダウンストリームの設定と、アップストリームサービスおよびダウンストリームコンシューマーアプリケーションとの関係を示しています。この設定では、ダウンストリームサービスは、アップストリームサービスによって完了される API 要求を行うサービスです。これらの用語は、情報の方向ではなく、連動関係の方向を表します。ダウンストリームサービスは、アップストリームサービスに情報を提供する ​`POST`​ 要求を行うことができます。ただし、ダウンストリームサービスは、要求の完了には引き続きアップストリームサービスに連動します。 ![API インスタンスは、アップストリーム設定とダウンストリーム設定の間のゲートウェイにデプロイされます。](/mulesoft/current/ja-jp/api-manager/latest/_images/api-upstream-downstream-config.png) ## [](#add-api)新しい API を追加する 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Add new API (新しい API を追加)\]**​ をクリックします。 3. **\[Service Mesh\]**​ を選択します。
Anypoint Platform に API を追加したら、Anypoint Service Mesh クライアントを使用して API をサービスにバインドする必要があります。詳細は、​「Anypoint Service Mesh の設定方法」​を参照してください。
4. **\[Next (次へ)\]**​ をクリックします。 5. 以下のオプションから API を選択します。 - 管理する API を Exchange を介して共有している場合、​**\[Select API from Exchange (Exchange から API を選択)\]**​ をクリックします。 1. **\[Select API (API を選択)\]**​ の下のリストから API をクリックします。必要に応じて、特定の API を検索できます。 2. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 3. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。​**\[Conformance Status (準拠状況)\]**​ が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 - **\[Create new API (新しい API を作成)\]**​ をクリックします。 1. 新しい API アセットの​**名前**​を入力します。 2. 以下のオプションから​**アセットタイプ**​を選択します。 - **REST API:**​ アセットに含める RAML または OAS API 定義ファイルがある場合は、このオプションを選択します。 REST API の RAML または OAS ファイルをアップロードします。バージョン 2.0.0 以降ではネイティブ OAS サポートが追加されるので、OAS または RAML 仕様に推奨されるバージョンです。OAS API 仕様を API プロキシバージョン 1.0 以前にアップロードすると、API 仕様は RAML に変換されます。 - **HTTP API:**​ アセットに含める API 定義ファイルがない場合は、このオプションを選択します。 - **SOAP API:**​ WSDL API 定義ファイルまたはファイルへの外部リンクがある場合は、このオプションを選択します。 SOAP API の WSDL ファイルをアップロードするか、ファイルへのリンクを追加します。 このオプションは、現時点では Flex Gateway ランタイムでは使用できません。 3. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 4. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。\[Conformance Status (準拠状況)\] が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 6. **\[Next (次へ)\]**​ をクリックします。 7. ダウンストリーム設定を定義します。
項目名 説明 必須 注意事項

Instance label (インスタンス表示ラベル)

API の表示ラベルを指定します。

いいえ

同じ API の複数の管理インスタンスがある場合、各インスタンスを他のインスタンスと区別するための表示ラベルを追加します。

Advanced Options (詳細オプション)

Consumer endpoint (コンシューマーエンドポイント)

コンシューマーが要求の送信に使用するプロキシアプリケーションのアドレスを指定します。

いいえ

Client provider (クライアントプロバイダー)

API のクライアントプロバイダーを指定します。

はい

Anypoint Platform はデフォルトではクライアントプロバイダーとして機能します。外部クライアントプロバイダーを設定するには、​「クライアントプロバイダー」​を参照してください。

8. **\[Next (次へ)\]**​ をクリックします。 9. アップストリーム設定を定義します。
項目名 説明 必須 注意事項

Upstream URL (アップストリーム URL)

プロキシまたは API にアクセスするための URL。

いいえ

たとえば、Exchange の API アセットの URL を使用できます。

10. **\[Next (次へ)\]**​ をクリックします。 11. 選択内容を確認し、必要に応じて編集します。 12. デプロイする準備ができたら、​**\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。または、​**\[Save (保存)\]**​ を選択して API インスタンスを保存し、後でデプロイします。 ## [](#promote-api)別の環境への API インスタンスの昇格 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Promote API from environment (環境から API を昇格)\]**​ を選択します。 3. **\[Source Environment (ソース環境)\]**​ を選択します。 4. 検索項目に API の名前を入力して、​**\[API\]**​ を選択します。 5. **\[API Version (API バージョン)\]**​ を選択します。 6. **\[API instance label (API インスタンスの表示ラベル)\]**​ を選択します。 7. 必要に応じて、除外する ​**\[Include in Promotion (昇格に含める)\]**​ オプションをオフにます。 8. **\[Promote (昇格)\]**​ をクリックします。 9. 必要に応じて、\[Runtime & Endpoint Configuration (ランタイムとエンドポイント設定)\] の詳細を確認して更新し、​**\[Save (保存)\]**​ をクリックします。 ## [](#import-api)Zip ファイルから API をインポートする 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Import API from zip file (zip ファイルから API をインポート)\]**​ を選択します。 3. **\[Choose file (ファイルを選択)\]**​ をクリックし、API インスタンス設定 zip ファイルを選択します。 4. **\[Next (次へ)\]**​ をクリックします。 5. 必要に応じて API 設定の詳細を確認して更新し、​**\[Save (保存)\]**​ をクリックします。 ## [](#注意事項)注意事項 - OpenAPI 仕様 (OAS) 3.0 はサポートされていますが、コールバック機能はサポートされていません。この問題を回避するには、Mule Runtime Engine ドメインの外部でコールバックを処理するか、コールバックを使用しない OAS 3.0 仕様を使用します。 # SLA 層 - [API Manager における SLA 層の概念の確認](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers)​ - [API Manager における SLA 層の削除](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers)​ - [開発者ポータルへのアクセス](https://docs.mulesoft.com/jp/api-manager/latest/access-developer-portal-task) # SLA 層の概念の確認 サービスレベルアクセス (SLA) 層は、API で定義するユーザーアクセスのカテゴリです。層定義と SLA ベースのポリシーの組み合わせにより、特定のレベルの API へのアクセスで承認が必要かどうかが決まります。層定義では、アプリケーションで API に対して実行できる要求数を制限することもできます。SLA 層を適用するには、SLA ベースのレート制限または調整ポリシーを適用する必要があります。 API バージョンの SLA 層を定義したり、特定の層へのアクセスを要求するアプリケーションを管理したりするには、API URL を設定する必要があります。 SLA のパフォーマンスを監視して、API で承認されている SLA 層の範囲内で API が実行されていることを確認できます。 ## [](#層の定義)層の定義 層を定義する場合、層の名前を付けて制限 (コール元アプリケーションが実行できる要求数など) を定義します。また、この層レベルのアプリケーションアクセス要求が自動的に承認されるのか、手動による承認が必要なのかも指定します。 API バージョンの詳細ページの \[SLA Tiers (SLA 層)\] には、SLA 層定義の概要 (その層に登録されているアプリケーション数、層名、制限、状況、必要な承認種別などの情報) が表示されます。 提供されたコントロールを使用して、層を編集および削除できます。 ### [](#階層化された-sla)階層化された SLA API Manager では、複数の SLA 制限がサポートされています。 1 つの SLA 層に複数のスループット制限を設定できます。​_gold_​ という名前の 1 つの SLA 層では、要求を 100 件/秒および 10,000/日に制限できます。この手法を使用すると、​_gold_​ 層に登録されているアプリケーションの要求が 100 件/秒のバースト制限を超えなくなります。アプリケーションによって API が圧迫されなくなり、登録済みアプリケーションの想定要求数が 10,000 件/日になります。SLA で参照可能フラグを設定すると、登録時に最初の制限がアプリケーション開発者に表示されなくなります。1 つの制限のみを定義している場合は、非表示にできません。 #### [](#レスポンスヘッダー)レスポンスヘッダー 要求の応答には、SLA 制限に関する情報と、SLA で許可される残りのスペア容量に関する情報をユーザーに通知する 3 つのヘッダーがあります。要求スループットを制限する複数のポリシーがこの SLA で適用される場合、1 つのヘッダーセットで、設定済みの最も拘束性のあるポリシーに関するスペア容量のみが報告されます。 たとえば、API のユーザーが次のヘッダーが含まれる応答を受信するとします。 X-RateLimit-Limit: 20 X-RateLimit-Remaining: 14 X-RateLimit-Reset: 19100 この場合、応答では、次の 19100 ミリ秒内に SLA であと 14 件の要求のみが許可され、この時間枠内の許容件数は 20 件に設定されていることがユーザーに通知されます。 ## [](#層の適用)層の適用 SLA 層を適用するには、SLA ベースのレート制限または調整ポリシーを適用する必要があります。これらのポリシーでは、API をコンシュームするすべてのアプリケーションが特定の層にアクセスするための登録を行い、API へのコールでクライアントログイン情報を渡す必要があります。これにより、Anypoint Platform はアプリケーションを識別したり、コントラクトされた層にアプリケーションを関連付けたり、スループット制限を適用したりできます。 ## [](#層の編集)層の編集 その層を使用することをすでに承認されているアプリケーションが含まれる層を編集すると、それらのアプリケーションは編集した層の条件にすぐに準拠します。そのため、警告せずにスループット値を変更すると、API ユーザーに迷惑がかかる可能性があります。 元々手動による承認を要求するように層を設定している場合、自動承認を許可するように変更すると、API Manager で待機中の承認要求が承認されます。 ## [](#アプリケーションの管理)アプリケーションの管理 API の SLA を定義したら、アプリケーション開発者からのアクセス要求の承認または失効を Exchange ポータルで行うことができます。このアクションにより、アプリケーションのコンシュームが SLA にバインドされます。開発者が承認範囲を超える SLA 層の API へのアクセスを要求した場合、別の SLA 層を適用して要求を上書きできます。 手動で承認するように層を設定した場合、開発者がアプリケーションのアクセスを要求したときにメール通知が送信されます。API バージョンの詳細ページでアプリケーションを確認し、要求の承認、拒否、失効を行うことができます。開発者が層を変更するように要求した場合も、変更要求を確認して新しい層でアプリケーションを承認するか、変更要求を拒否できます。 ## [](#層を非推奨にする)層を非推奨にする アプリケーションを SLA 層に割り当てたら、層を非推奨にして開発者がその層に新しいアプリケーションをサインアップしないようにすることができます。アプリケーションが割り当てられている SLA 層は削除できません。 層を非推奨にする手順は、次のとおりです。 1. 新しい層を作成して、新しい層名をアプリケーションオーナーに通知します。 2. 既存の非推奨の層へのアプリケーションアクセスを失効させます。 3. アプリケーションオーナーに新しい層を使用して API へのアクセスを再要求するように依頼します。 ## [](#層を削除する)層を削除する すべてのアプリケーションオーナーが新しい層にサインアップして、新しい層への移行を承認したら、非推奨の層を削除できます。 層を削除する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. メニューで、​**\[API Administration (API 管理)\]**​ を選択します。 3. API インスタンス名をクリックします。 4. API ダッシュボードで、メニューから ​**\[SLA Tiers (SLA 層)\]**​ を選択します。 5. 削除する層で、​**\[More actions (追加アクション)\]**​ メニューから ​**\[Delete (削除)\]**​ を選択します。 ## [](#関連情報)関連情報 - [API などのアセットの共有について](https://docs.mulesoft.com/jp/exchange/about-sharing-assets) - [API へのアクセスを要求する方法](https://docs.mulesoft.com/jp/exchange/to-request-access) - [Exchange ポータル](https://docs.mulesoft.com/jp/exchange/about-portals) - [レート制限 SLA ポリシーの確認](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) - [アクセス要求の承認または拒否](https://docs.mulesoft.com/jp/api-manager/latest/manage-client-apps-latest-task) # SOAP API プロキシの構築 API Manager 2.x では、SOAP ベースの Web サービスに SOAP API プロキシを使用できます。SOAP プロキシには、バックエンドサービスを説明する WSDL 定義が必要です。WSDL は、API プロキシが受信要求の検証を実行し、対応する API エンドポイントのアウトバウンド要求を適切に転送する方法を定義します。 ## [](#soap-プロキシスキーマの検証)SOAP プロキシスキーマの検証 API に対する検証が有効かどうかに関係なく、SOAP 要求検証機能で常に次の点が確認されます。 - インバウンド要求に有効な SOAP アクションが設定されている。 - ペイロードが有効な SOAP エンベロープである。 API に対する検証が有効の場合は、SOAP 要求検証機能で、​`body`​ タグのコンテンツが WSDL で定義されているものと一致しているかどうかも確認されます。インバウンド要求の SOAP アクションが WSDL の同じ名前の操作と照合されます。その後、要素の名前空間 URI と操作に関連付けられた名前が受信要求の同じ詳細と一致することがプロキシによって検証されます。 この検証に失敗した場合、必要な名前空間 URI と要素名を通知するエラーメッセージが生成されます。インバウンド要求の SOAP アクションが空の場合、アプリケーションは名前空間 URI と受信要求要素の要素名を WSDL で定義されたすべての操作と照合します。 受信要求と一致する最初の操作により、検証が成功したかどうかが決まります。照合に失敗した場合、要求の要素の推奨タグ名を含むエラーメッセージが生成されます。 ## [](#プロキシアプリケーションからの-wsdl-の取得)プロキシアプリケーションからの WSDL の取得 SOAP プロキシを使用すると、バックエンド Web サービスは要求を送信 (POST) したり、サービス WSDL を取得 (GET) したりできます。GET 要求は、クエリパラメーターとして ​`wsdl`​ または ​`WSDL`​ を使用する HTTP GET メソッドによって実行されます。 - `[http://my-proxy-url:myProxyPort?wsdl](http://my-proxy-url:myProxyPort?wsdl)` - `[http://my-proxy-url:myProxyPort?WSDL](http://my-proxy-url:myProxyPort?WSDL)` ## [](#基本認証ログイン情報を使用したリモートロケーションからの-wsdl-の設定)基本認証ログイン情報を使用したリモートロケーションからの WSDL の設定 `basicauth.properties`​ 設定ファイルで ​`basic.auth.user`​ および ​`basic.auth.password`​ アプリケーションプロパティを設定することで、リモートロケーションでホストされている保護された WSDL にアクセスできます。次に、これらのプロパティはバリデーターモジュールに渡されます。 ```xml ``` これらのプロパティで認証値を指定しない場合、WSDL は認証されずに取得されます。 ## [](#tls-を使用した-wsdl-の取得)TLS を使用した WSDL の取得 SOAP プロキシ v2.1.0 を使用すると、デフォルトで TLS コンテキスト設定を使用してリモートロケーションから WSDL を取得できます。この操作で使用する TLS コンテキストは、プロキシのアウトバウンド設定と同じです。 ## [](#soap-プロキシを設定する)SOAP プロキシを設定する SOAP プロキシを設定するには、以下の手順を完了します。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Add new API (新しい API を追加)\]**​ をクリックします。 3. ランタイムとして ​**\[Mule Gateway (Mule ゲートウェイ)\]**​ を選択します。 4. **\[Proxy type (プロキシ種別)\]**​ で ​**\[Deploy a proxy application (プロキシアプリケーションをデプロイ)\]**​ を選択します。 5. プロキシアプリケーションのデプロイを選択した場合は、以下のオプションから​**対象種別**​を選択します。 - **CloudHub 2.0**​: コンテナベースのクラウドインフラストラクチャで MuleSoft によってホストされている Mule Runtime を使用する場合は、このオプションを選択します。CloudHub 2.0 プロキシには、デフォルトで 0.1 vCore の CPU が含まれています。 1. スペースを選択します。 スペースについての詳細は、​[Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) and [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about)​を参照してください。 2. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 3. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **CloudHub:**​ MuleSoft によってクラウドでホストされている Mule Runtime を使用する場合は、このオプションを選択します。CloudHub プロキシには、デフォルトで 0.1 vCore の CPU と 500 MB のメモリが含まれています。 1. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 2. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **Hybrid (ハイブリッド):**​ Runtime Manager に登録されているオンプレミスサーバーで実行される Mule Runtime インスタンスを使用する場合、このオプションを選択します。 詳細は、​[「Runtime Manager でのサーバーの登録」](https://docs.mulesoft.com/jp/runtime-manager/servers-create)​を参照してください。 1. リストから接続先を選択するか、​**\[Add server (サーバーを追加)\]**​ をクリックします。 2. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 - **Self-managed Server (自己管理型サーバー):**​ JAR ファイルを作成して、Runtime Manager に登録されていないオンプレミスサーバーで実行される Mule Runtime インスタンスに API プロキシをデプロイする場合、このオプションを選択します。詳細は、[On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model)を参照してください。 API Manager で API プロキシを自己管理型サーバーにデプロイしても、プロキシはオンプレミスサーバーにデプロイされません。API Manager でプロキシをデプロイした後に、プロキシをオンプレミスサーバーにデプロイします。 . [新しい API プロキシ JAR ファイルをダウンロードします](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task)​。 . [JAR ファイルをオンプレミスサーバーにデプロイします](https://docs.mulesoft.com/mule-runtime/latest/deploy-on-premises)​。 - **Runtime Fabric:**​ Runtime Fabric で管理された Mule Runtime Engine に API プロキシをデプロイする場合、\[Runtime Fabric\] を選択します。 詳細は、​[「Runtime Fabric への API プロキシのデプロイ」](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric)​を参照してください。 1. リストから対象を選択します。 2. **\[Runtime Version (ランタイムバージョン)\]**​ で、次の操作を実行します。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ を選択します。 2. Mule Runtime の ​**\[Version (バージョン)\]**​ を選択します。 3. **\[Java version (Java バージョン)\]**​ を選択します。 3. **\[Proxy app name (プロキシアプリケーション名)\]**​ を入力します。 1. 以下のオプションから API を選択します。 - 管理する API を Exchange を介して共有している場合、​**\[Select API from Exchange (Exchange から API を選択)\]**​ をクリックします。 1. **\[Select API (API を選択)\]**​ の下のリストから API をクリックします。必要に応じて、特定の API を検索できます。 2. 最新バージョンを使用していない場合は、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ を更新します。 Exchange でのバージョンについての詳細は、[アセットバージョン](https://docs.mulesoft.com/jp/exchange/asset-versions)を参照してください。 3. **\[RAML/OAS\]**​ アセットタイプを選択した場合は、API の ​**\[Conformance Status (準拠状況)\]**​ を表示して、API が準拠していることを確認します。​**\[Conformance Status (準拠状況)\]**​ が非準拠の場合、デプロイ後に​**ガバナンスレポート**​を表示して、準拠の問題を見つけて修正します。​**ガバナンスレポート**​についての詳細は、[API インスタンスの管理](https://docs.mulesoft.com/jp/api-manager/latest/govern-api-instances)を参照してください。 - **\[Create new API (新しい API を作成)\]**​ をクリックします。 1. 新しい API アセットの​**名前**​を入力します。 2. **アセットタイプ**​として ​**SOAP API**​ を選択します。 3. メソッドとして、​**\[Upload a WSDL (WSDL をアップロード)\]**​ または ​**\[Use an external link (外部リンクを使用)\]**​ を選択します。 4. 必要に応じて、​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ 項目を更新します。 1. **\[Next (次へ)\]**​ をクリックします。 2. ダウンストリーム設定を定義します。 設定を確認するには展開します。
項目名 説明 必須 注意事項

Protocol (プロトコル)

検証に HTTP と HTTPS のどちらを使用するかを指定します。

はい

HTTPS を選択する場合、インバウンドトラフィックの TLS コンテキストを指定します。

Inbound TLS (インバウンド TLS)

インバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。Mule 3 環境で HTTPS を有効にするには、​「Mule 3x での HTTPS の有効化」​を参照してください。

Port (ポート)

表示されたポートが正しくない場合に使用する番号を指定します。

はい

Base Path (ベースパス)

ホストルートに相対的なすべての API パスの URL プレフィックスを指定します。スラッシュ ​/​ で始まる必要があります。

はい

Instance label (インスタンス表示ラベル)

API の表示ラベルを指定します。

いいえ

同じ API の複数の管理インスタンスがある場合、各インスタンスを他のインスタンスと区別するための表示ラベルを追加します。

Advanced Options (詳細オプション)

Consumer endpoint (コンシューマーエンドポイント)

コンシューマーが要求の送信に使用するプロキシアプリケーションのアドレスを指定します。

いいえ

Client provider (クライアントプロバイダー)

API のクライアントプロバイダーを指定します。

はい

Anypoint Platform はデフォルトではクライアントプロバイダーとして機能します。外部クライアントプロバイダーを設定するには、​「クライアントプロバイダー」​を参照してください。

Request Timeout (要求タイムアウト)

要求がタイムアウトするまでの期間を指定します。

いいえ

Proxy Version (プロキシバージョン)

エンドポイントに使用するプロキシのバージョンを指定します。

いいえ

Service Name (サービス名)

WSDL サービスの名前。

はい

WSDL API でのみ使用できます。

Service Port (サービスポート)

WSDL サービスのポート。

はい

WSDL API でのみ使用できます。

Service Namespace (サービス名前空間)

WSDL サービスの名前空間。

はい

WSDL API でのみ使用できます。

Enable Console (コンソールを有効化)

API 仕様を公開およびテストできるかどうかを指定します。

いいえ

[Console Path (コンソールパス)]​ に別のパス (​/spec/*​ など) を指定できます。関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

Validations (検証)

提供された仕様に対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます。

厳格な検証 (省略可能)

クエリパラメーターに対してインバウンド要求を検証するかどうかを指定します。

いいえ

関連付けられた API 定義がある場合にのみ使用できます。Mule 3 以降でのみ使用できます+

User Domain (ユーザードメイン)

API ゲートウェイドメインを使用するかどうかを指定します。

いいえ

設定で以前にプロキシデプロイメント対象として ​[Hybrid (ハイブリッド)]​ を選択した場合は、必ずこのオプションを選択してください。Mule 3.8 以降の API ゲートウェイドメインをインストールする必要があります。

3. **\[Next (次へ)\]**​ をクリックします。 4. アップストリーム設定を定義します。 設定を確認するには展開します。
項目名 説明 必須 注意事項

Upstream URL (アップストリーム URL)

プロキシまたは API にアクセスするための URL。

はい

たとえば、Exchange の API アセットの URL を使用できます。

Outbound TLS (アウトバウンド TLS)

アウトバウンドトラフィックを保護するための TLS コンテキストを指定します。

いいえ

Mule 4 以降でのみ使用できます。コンテキストを表示できない場合は、適切な権限があることを確認してください。

5. **\[Next (次へ)\]**​ をクリックします。 6. 選択内容を確認し、必要に応じて編集します。 7. デプロイする準備ができたら、​**\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。または、​**\[Save (保存)\]**​ を選択して API インスタンスを保存し、後でデプロイします。 ## [](#xsd-ファイルでインポートが見つからない場合の-soap-プロキシのトラブルシューティング)XSD ファイルでインポートが見つからない場合の SOAP プロキシのトラブルシューティング 不適切な WSDL 定義が原因で、SOAP プロキシがデプロイメント中に失敗する場合があります。たとえば次のエラーは、WSDL の一部である XSD ファイルの 1 つにインポートが見つからないことを示しています。 ```text org.xml.sax.SAXParseException; systemId: http://localhost:8080/?wsdl304785538; lineNumber: 2; columnNumber: 52; src-resolve.4.2: Error resolving component 'myNamespace:myElement’. It was detected that 'myNamespace:myElement' is in namespace 'http://my.namespace.url', but components from this namespace are not referenceable from schema document 'http://localhost:8080/?wsdl304785538'. If this is the incorrect namespace, perhaps the prefix of 'myNamespace:myElement' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'http://localhost:8080/?wsdl304785538'. ``` この問題は、WSDL ファイルで使用されている要素の定義が、現在の WSDL ファイルの名前空間とは異なる名前空間を使用する外部 XSD 内にある場合に発生します。 この問題は、適切なインポートを WSDL ファイルに追加することで解決できます。たとえば、前の例での例外の場合、WSDL ファイルの ​`types`​ 要素に次のインポートが含まれている必要があります ```text ``` ## [](#関連情報)関連情報 - [API プロキシ](https://docs.mulesoft.com/jp/api-manager/latest/api-proxy-landing-page) - [Exchange からのインポートによる API インスタンスの作成](#manage-exchange-api-task.adoc) - [API の TLS コンテキストの設定](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy) # アクセス要求の承認または拒否 ユーザーは Anypoint Exchange から API インスタンスへの​[アクセス権を要求](https://docs.mulesoft.com/jp/exchange/to-request-access)​した後に、API Manager からの要求を手動で承認または拒否できます。 ## [](#タスクの前提条件)タスクの前提条件 要求を手動で承認または拒否するには、以下が必要です。 - アプリケーションの SLA 層を設定済み - 組織のシステム管理者、API Manager 環境システム管理者、または「Manage Contracts (コントラクトの管理)」権限 ## [](#要求を手動で承認する)要求を手動で承認する API へのアクセス要求を承認または拒否するには、次の手順を実行します。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、アクセス権を要求している API インスタンスの名前をクリックします。 3. **\[Contracts (コントラクト)\]**​ をクリックします。 要求が表示されます。 4. **\[Approve (承認)\]**​ または ​**\[Reject (拒否)\]**​ をクリックして、アクセス要求を承認または拒否します。 ## [](#関連情報)関連情報 - [Exchange からの API インスタンスへのアクセス権の要求](https://docs.mulesoft.com/jp/exchange/to-request-access) - [API インスタンスコントラクトの削除](https://docs.mulesoft.com/jp/api-manager/latest/remove-client-app-latest-task) - [クライアントアプリケーションのクライアント ID とクライアントシークレットログイン情報の取得](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task) # アセットポータルおよび開発者ポータルへのアクセス システム管理者は API のリソースとメソッドを表示し、Anypoint Exchange (Exchange) からの他の詳細 (パブリッシュ日、モッキングサービスなど) にアクセスできます。API はアセットポータル (非公開) または公開ポータルで表示できます。 ## [](#アセットポータルへのアクセス)アセットポータルへのアクセス アセットポータルにアクセスする前に、次のいずれかの条件を満たしていることを確認します。 - ポータルが組織の公開開発者ポータルにリストされている。 - ポータルは非公開であるが、ポータル閲覧者アクセス権がある。 アセットポータルにアクセスする手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、アクセスする API インスタンスの名前をクリックします。 3. **\[Actions (アクション)\]**​ をクリックして ​**\[View API in Exchange (Exchange で API を表示)\]**​ を選択します。 選択したアセットのポータルが Exchange ウィンドウに表示されます。ポータルを共有して Anypoint Exchange で​[ポータルを公開](https://docs.mulesoft.com/jp/exchange/about-portals)​することもできます。 ## [](#公開ポータルへのアクセス)公開ポータルへのアクセス 組織の公開ポータルにアクセスする手順は、次のとおりです。 1. **\[Exchange\]**​ > ​**\[Public portal (公開ポータル)\]**​ に移動します。 2. 開発者ポータルページから、アクセスするアセットを選択します。 ## [](#関連情報)関連情報 - [Anypoint Platform 開発者ポータル](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/) # アラートの概念の確認 Anypoint Platform は、要求動作、パフォーマンスの問題、クライアントアプリケーションコントラクトに関するアクション、ランタイムイベントについて警告します。 プラットフォームは、次の 3 種類のアラートをサポートしています。 - API アラート - コントラクトアラート - ランタイムアラート API アラートとコントラクトアラートは、Anypoint API Monitoring によって管理されます。 ランタイムアラートは、Anypoint Runtime Manager (Runtime Manager) によって管理されます。 新しい API Monitoring アラートの使用方法については、​[「Flex Gateway API アラートの使用」](https://docs.mulesoft.com/gateway/latest/use-api-alerts)​を参照してください。
API Monitoring の代わりに API Manager で従来の Analytics ベースの API アラートをすでに使用しているお客様は、2024 年 11 月 30 日まで引き続きこの機能にアクセスできます。この機能は、新規クライアントでは使用できません。
API アラートは、Hyperforce デプロイメントでは使用できません。
## [](#api-アラート)API アラート 次のような異常な API 動作にフラグを付ける API アラートを追加および設定します。 - 60 秒を超える API 応答時間 - 30 秒間で 1000 件を超える API 要求 [「API アラートの追加」](https://docs.mulesoft.com/jp/api-manager/latest/add-api-alert-task)​を参照してください。 API Manager では、次の API アラートを API インスタンスに追加できます。 - **Policy Violation (ポリシー違反)** API を管理する 1 つ以上のポリシーで違反が発生する。 - **Request Count (要求数)** ユーザーが指定された期間で許可されている回数を超えて API にアクセスを要求する。 1 ~ 999999999 の期間値を指定します。データのバーストを回避するために、期間は絶対時間 (分) 範囲ではなく、スライディングウィンドウとして実装されます。 [「スライディングウィンドウ」](https://www.techopedia.com/definition/869/sliding-window)​を参照してください。 - **Response Code (応答コード)** API が要求を受信したときに、400、401、403、404、408、500、502、503 のいずれかの HTTP コードを返す。 - **Response Time (応答時間)** API の応答時間が指定されたタイムアウト期間を超えている。 API アラートは、状態が変更されたときにみトリガーされます。新しく作成されたアラートで状態が定義されていないために、最初の状態の変更が検出されない可能性があります。 API アラートを設定するときに、アラートに関するメール通知を受信するビジネスグループユーザーを選択します。通知には、重要度レベルで指定されたようにアラートをトリガーするイベントに関する情報が含まれます。ユーザーは以下を受信します。 - 1 つは、アラートについて説明するメールです。 `Your API, CesarDemoAPI - Basic:151 (Environment: "NewOne"), has received greater than 2 requests within 1 consecutive periods of 1 minute.` - もう 1 つは、アラートがいつ解決されるかを通知するメールです。 `Your API Version, jsonplaceholderapi - 1.0.development, is no longer in an alert state.The number of policy violations was not greater than 1 in the last 1 consecutive periods of 1 minute.` アラートがトリガーされた後、API Manager は 2 つの通知メールの最初のセットを送信し、次のアラート期間が始まるまでアラートのリスンを停止します。この方法で反復する通知メールが防止されます。 注意: API アラートは ​`no-reply@mulesoft.com`​ から送信されます。これはカスタマイズできません。 アラートメールは、対応するスライディングウィンドウが完全に終了する前に送信できます。 アラート条件はスライディングウィンドウに基づいて評価されますが、ウィンドウのすべてのメトリクスが取得される前に条件が満たされる可能性があります。たとえば、アラート条件が「5 分間のウィンドウでのエラー数 > 1」に設定されており、最初の 1 分間に 10 件のエラーが発生した場合、スライディングウィンドウが残り 4 分間メトリクスを累積し続けていても、アラートメールは最初の 1 分で送信されます。 ## [](#コントラクトアラート)コントラクトアラート API Manager は、コントラクトに関するアクションが発生したときに自動的にユーザーに通知します。たとえば、クライアントアプリケーションが API インスタンスへのアクセスを要求すると、API Manager は要求の状況が含まれる通知を送信します。設定によって、状況で示される内容 (要求の手動承認が保留中であることや要求が自動承認されたこと) が決まります。 次のアクションで、コントラクトアラートがトリガーされます。
Table 1. コントラクト
アクション 受信者 説明

コントラクトが承認された

クライアントアプリケーションオーナー

要求アクセスが承認されたことがユーザーに通知されます。

コントラクトが自動承認された

組織のシステム管理者、環境管理者、コントラクトマネージャー

要求アクセスが自動承認されたことがユーザーに通知されます。

コントラクトが保留中

組織のシステム管理者、環境管理者、コントラクトマネージャー

要求アクセスが保留中であることがユーザーに通知されます。

保留中のコントラクトが拒否された

クライアントアプリケーションオーナー

要求アクセスが拒否されたことがユーザーに通知されます。

失効済みのコントラクトが復元された

クライアントアプリケーションオーナー

要求アクセスが復元されたことがユーザーに通知されます。

承認済みのコントラクトが失効した

クライアントアプリケーションオーナー

要求アクセスが失効したことがユーザーに通知されます。

コントラクト層が変更された

クライアントアプリケーションオーナー

コントラクト層が変更されたことがユーザーに通知されます。

要求されたコントラクト層の変更が承認された

クライアントアプリケーションオーナー

要求された層の変更が承認されたことがユーザーに通知されます。

要求されたコントラクト層の変更が拒否された

クライアントアプリケーションオーナー

要求された層の変更が拒否されたことがユーザーに通知されます。

コントラクト層の変更が要求された

組織のシステム管理者、環境管理者、コントラクトマネージャー

コントラクト層の変更のレビューが保留中であることがユーザーに通知されます。

Table 2. グループコントラクト
アクション 受信者 説明

コントラクトが承認された

クライアントアプリケーションオーナー

要求アクセスが承認されたことがユーザーに通知されます。

コントラクトが自動承認された

グループ管理者

要求アクセスが自動承認されたことがユーザーに通知されます。

承認済みのコントラクトが失効した

クライアントアプリケーションオーナー

要求アクセスが失効したことがユーザーに通知されます。

失効済みのコントラクトが復元された

クライアントアプリケーションオーナー

要求アクセスが復元されたことがユーザーに通知されます。

保留中のコントラクトが拒否された

クライアントアプリケーションオーナー

要求アクセスが拒否されたことがユーザーに通知されます。

コントラクトが保留中

グループ管理者

要求アクセスが保留中であることがユーザーに通知されます。

コントラクト層が変更された

クライアントアプリケーションオーナー

コントラクト層の変更のレビューが保留中であることがユーザーに通知されます。

要求されたコントラクト層の変更が承認された

クライアントアプリケーションオーナー

要求された層の変更が承認されたことがユーザーに通知されます。

要求されたコントラクト層の変更が拒否された

クライアントアプリケーションオーナー

要求された層の変更が拒否されたことがユーザーに通知されます。

コントラクト層の変更が要求された

グループ管理者

コントラクト層の変更のレビューが保留中であることがユーザーに通知されます。

コントラクトアラートは ​no-reply@mulesoft.com​ から送信されます。これはカスタマイズできません。

## [](#ランタイムアラート)ランタイムアラート Runtime Manager のアラートは、API アラートやコントラクトアラートとは異なります。たとえば、Runtime Manager は、CPU 使用量、セキュアなデータゲートウェイの状況、デプロイメントの成功または失敗にフラグを付けます。​[「Runtime Manager アラート」](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager)​を参照してください。 ## [](#flex-gateway-のアラート)Flex Gateway のアラート Flex Gateway のアラートは、API アラートやコントラクトアラートとは異なります。たとえば、Flex Gateway には​**アラートロジック**​オプションと、​**メール通知**​の件名やメッセージをカスタマイズする機能があります。詳細は、​[「Flex Gateway API アラートの使用」](https://docs.mulesoft.com/gateway/latest/use-api-alerts)​を参照してください。 ## [](#アラートのレート制限)アラートのレート制限 Anypoint Platform では、アラートをトリガーする頻度とメール通知を送信する頻度を決定するレート制限が適用されます。 適用される制限についての詳細は、​[「アラートのレート制限」](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager#rate-limits-on-alerts)​を参照してください。 ## [](#関連情報)関連情報 - [API アラートの追加](https://docs.mulesoft.com/jp/api-manager/latest/add-api-alert-task) - [API アラートのテスト](https://docs.mulesoft.com/jp/api-manager/latest/test-alert-task) - [API アラートの表示と削除](https://docs.mulesoft.com/jp/api-manager/latest/view-delete-alerts-task) - [API アラートの編集、有効化、無効化](https://docs.mulesoft.com/jp/api-manager/latest/edit-enable-disable-alerts-task) # クライアントアプリケーション、コントラクト、ログイン情報 ログイン情報は、クライアント ID とクライアントシークレットの 2 つのキーで構成されます。Anypoint API Manager (API Manager) は、次の種別のログイン情報を使用します。 - クライアントアプリケーション - 組織 - 基本認証ポリシー - SOAP API プロキシ ## [](#クライアントアプリケーションログイン情報)クライアントアプリケーションログイン情報 組織の管理者が Anypoint Exchenge (Exchange) でアプリケーションへのアクセス権を付与すると、API インスタンスとアプリケーションとの間でコントラクトが自動的に作成されます。コントラクトは、SLA 層 (指定されている場合のみ) に基づいてアプリケーションにアクセス権を付与します。API インスタンスとアプリケーションとの間には、一度に 1 つのコントラクトのみが存在できます。 ユーザーが Exchange の API へのアクセスを要求した場合、API に SLA が含まれていなければ、要求は自動的に承認されます。API に SLA 層が含まれている場合は、SLA 層の有無に関係なく要求を自動的に承認するように設定するか、または承認を手動で要求できます。 クライアントアプリケーションログイン情報は、新しいアプリケーションを作成して API アクセスを要求したときに生成されます。API がクライアント ID 適用ポリシーによって保護されている場合、API 要求にこれらのログイン情報を含める必要があります。組織のシステム管理者は、ヘッダーまたはクエリパラメーターのいずれかとしてログイン情報を受け入れるようにこの適用ポリシーを設定できますが、ヘッダーを使用した方が安全です。 クライアントアプリケーションログイン情報についての詳細は、以下を参照してください。 - [API へのアクセス権の要求](https://docs.mulesoft.com/jp/exchange/to-request-access)​。 - [API インスタンスコントラクトの表示](https://docs.mulesoft.com/jp/api-manager/latest/view-api-contracts)​。 - [要求へのアクセス権限の付与](https://docs.mulesoft.com/jp/api-manager/latest/manage-client-apps-latest-task)​。 - [API インスタンスコントラクトの削除](https://docs.mulesoft.com/jp/api-manager/latest/remove-client-app-latest-task)​。 - [登録済みクライアントアプリケーションのログイン情報の取得](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task)​。 クライアントアプリケーションのログイン情報を内部に適用するデフォルトポリシーは次のとおりです。 - [レート制限 SLA](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) - [Mule OAuth 2.0 アクセストークン適用](#external-oauth-2.0-token-validation-policy.adoc)​ (Mule v3.8.5 以降) - [PingFederate OAuth 2.0 トークン適用](#policy-ping-federate.adoc)​ (Mule v3.8.5 以降) - [OpenID Connect OAuth 2.0 トークン適用](https://docs.mulesoft.com/gateway/latest/policies-included-openid-token-enforcement)​ (Mule v3.8.5 以降) - [JWT 検証](https://docs.mulesoft.com/gateway/latest/policies-included-jwt-validation)​ (Mule v3.8.5 以降) クライアント ID 適用ポリシーの設定および適用方法は、​[「クライアント ID 適用ポリシー」](https://docs.mulesoft.com/gateway/latest/policies-included-client-id-enforcement)​を参照してください。 ## [](#組織のログイン情報)組織のログイン情報 組織のログイン情報は、Anypoint Platform を使用して Mule Runtime Engine (Mule) を組織にリンクするときに、特定の環境、組織、またはビジネスグループを一意に識別する方法を提供します。Mule はこれらのログイン情報を使用して、組織に接続してアクセスします。 たとえば、環境のログイン情報を使用して、API 自動検出を介してローカルの Anypoint Studio (Studio) Mule デプロイメントを API Manager に接続します。この接続により、Studio でデプロイされた API を API Manager で管理できます。​[「環境の概念の確認」](https://docs.mulesoft.com/jp/api-manager/latest/environments-concept)​および​[「API 自動検出」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-autodiscovery-overview)​を参照してください。 組織のログイン情報の設定と取得についての詳細は、以下を参照してください。 - [Mule Runtime 4 の組織のログイン情報の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule4)​。 - [Mule Runtime 3 の組織のログイン情報の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule3)​。 ## [](#基本認証ポリシーログイン情報)基本認証ポリシーログイン情報 簡易認証のデフォルトポリシーは、要求に対してログイン情報を強制的に提供させることで API を保護します。これらのログイン情報は、要求の ​`Authorization`​ ヘッダーを取り込みます。簡易認証ポリシーを使用した API 要求の作成についての詳細は、​[「基本認証: シンプルポリシー」](https://docs.mulesoft.com/gateway/latest/policies-included-basic-auth-simple)​を参照してください。 Lightweight Directory Access Protocol (LDAP) 認証のデフォルトポリシーは、LDAP 認証メカニズムを使用して API アクセスを制限します。LDAP 認証は、API 要求に対して ​`Authorization`​ ヘッダーでログイン情報を強制的に提供させ、設定されている LDAP インスタンスに対して、提供されている LDAP コンテキストにおいてログイン情報が正しいかどうかを判断するように要求します。LDAP 認証ポリシーの設定についての詳細は、​[「基本認証: LDAP ポリシー」](https://docs.mulesoft.com/gateway/latest/policies-included-basic-auth-ldap)​を参照してください。 ## [](#soap-api-プロキシログイン情報)SOAP API プロキシログイン情報 基本認証ログイン情報を設定することで、リモートロケーションでホストされている WSDL を保護できます。SOAP API プロキシの構築についての詳細は、​[「SOAP API プロキシの構築」](https://docs.mulesoft.com/jp/api-manager/latest/building-soap-proxy)​を参照してください。 # クライアントアプリケーションの移行 以前に異なる API 管理ソリューションを使用していた場合には、アプリケーションのクライアントログイン情報が Anypoint Platform の外部で管理されていることがあります。Anypoint Platform でログイン情報を使用するためには、これらのクライアントアプリケーションのクライアント ID とクライアントシークレットログイン情報を使用して、事前にクライアントアプリケーションを Anypoint Platform に移行する必要があります。 クライアントアプリケーションでは、組織が Anypoint Platform クライアントプロバイダーまたは外部クライアントプロバイダーに関連付けられている API をコンシュームできます。それぞれのシナリオの手順は異なります。 - [Anypoint Platform クライアントプロバイダーを使用している API でのクライアントアプリケーションの移行](#migrate_with_internal) - [外部クライアントプロバイダーを使用している API でのクライアントアプリケーションの移行](#migrate_with_external) ## [](#前提条件)前提条件 クライアントアプリケーションを移行する前に: - 必要なトークンとログイン情報を取得します。 - 移行するクライアントアプリケーションのクライアント ID とクライアントシークレット - Anypoint Platform [トークン](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/pages/Authentication/) - [スコープと制限](#考慮事項)​を確認してください。 ## [](#considerations)スコープと制限 クライアントアプリケーションを Anypoint Platform に移行する前に、次のスコープと制限を確認してください。 - アプリケーションがコンシュームする API の組織で外部クライアントプロバイダー (例: PingFederate や Okta) が登録されている場合は、​[「外部クライアントプロバイダーが登録されている組織」](#external_client)​を参照してください。 - アプリケーションのクライアント ID やクライアントシークレットを更新しようとしないでください。 この機能はサポートされていません。 - クライアント ID は、Anypoint Platform 内では一意です。2 つの異なるアカウントで同じクライアント ID を使用しないでください。 重複を回避するため、アカウントに対しては一意のクライアント ID を指定してください。 - 同じユーザーを使用して 500 件を超えるアプリケーションを作成しないでください。 - 重複する名前のアプリケーションを作成しないでください。 - クライアント ID を変更する場合は、必ず先にクライアントアプリケーションを削除してから再登録してください。 - クライアントログイン情報がクライアントプロバイダー上の既存の組織 ID のログイン情報と一致する場合、アプリケーションはそのクライアントに関連付けられます。 反対に、指定したクライアントログイン情報が一致しない場合、クライアントアプリケーションは既存のクライアントには関連付けられずに作成されます。 ## [](#migrate_with_internal)Anypoint Platform クライアントプロバイダーを使用している API でのクライアントアプリケーションの移行 クライアントアプリケーションを移行するには、次の手順を実行します。 1. テキストエディターを開いて次のコマンドを貼り付けます。 ```text curl --location --request POST 'https://anypoint.mulesoft.com/exchange/api/v1/organizations/:orgId/applications' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data-raw '{ "clientId": , "clientSecret": , "grantTypes": [], "name": , "redirectUri": [] }' ``` 2. `orgId`​ パラメーターはルート組織の ID に、本文のコンテンツは適切なアプリケーション​[プロパティ](#properties)​に置き換えます。 3. コマンドプロンプトに対してこのコマンドを実行します。 ## [](#migrate_with_external)外部クライアントプロバイダーを使用している API でのクライアントアプリケーションの移行 外部クライアントプロバイダーが登録されている組織に対してアプリケーションを作成する場合は、API インスタンス ID (API Manager UI で取得可能) を使用して、コンシュームする API に直接アプリケーションを関連付けることができます。 PingFederate 外部クライアントプロバイダーまたは Anypoint Platform クライアントプロバイダーを使用している場合は、API の参照時にクライアント ID とクライアントシークレットを含めることができます。OpenID 動的クライアント登録を使用して登録される Okta や Keycloak などのプロバイダーを使用している場合は、クライアント ID とクライアントシークレットログイン情報を定義することはできません。 クライアントアプリケーションを移行するには、次の手順を実行します。 1. テキストエディターを開いて次のコマンドを貼り付けます。 ```text curl --location --request POST 'https://anypoint.mulesoft.com/exchange/api/v1/organizations/:orgId/applications?apiInstanceId=:myApiInstanceId' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data-raw '{ "clientId": , "clientSecret": , "grantTypes": [ ], "name": , "redirectUri": [ "https://anypoint.mulesoft.com/apiplatform/:orgId/authentication/oauth2.html", "https://anypoint.mulesoft.com/apiplatform/:orgId/admin/authentication/oauth2.html", "https://api-notebook.anypoint.mulesoft.com/authenticate/oauth.html" ] }' ``` 2. コマンドスニペットの ​`orgId`​ パラメーターは組織の ID に、​`apiInstanceId`​ は API インスタンス ID に、本文のコンテンツは適切なアプリケーション​[プロパティ](#プロパティ)​に置き換えます。 3. コマンドプロンプトに対してこのコマンドを実行します。 ## [](#properties)移行コマンドプロパティリファレンス 移行コマンドのプロパティには、以下の推奨事項に基づいて値を指定してください。 - `clientId`​: <クライアント ID> - `clientSecret`​: <クライアントシークレット> - (省略可能)​`description`​: <アプリケーション情報の説明> このプロパティはアプリケーションページに表示されます。 - `name`​: <作成するアプリケーションの名前> このプロパティは、アクセスを要求する前にアプリケーションを選択するときに表示されます。 - `redirectUri`​: - (省略可能) ​`url`​: <クライアントアプリケーションの URL> このプロパティはアプリケーションページに表示されます。 - `grantTypes`​: - `Resource Owner Grant`​: "password" - `Implicit Grant`​: "implicit" - `Client Credentials Grant`​ "client\_credentials" - `Authorization Code`​: "authorization\_code" - `Refresh Token`​: "refresh\_token" (この許可種別を使用するには認証コードが必要です。) 外部クライアントプロバイダーでサポートされる許可種別については、クライアントプロバイダーのドキュメントを参照してください。 # クライアント管理用の複数のクライアントプロバイダーの設定 複数のクライアントプロバイダーを使用して、ビジネス組織のセキュリティや規制を適用しやすくすることができます。これらのクライアントプロバイダー (OpenAM や PingFederate など) を使用することで、クライアントのログイン情報やアクセストークンなどの運営データを保護できます。 Anypoint Platform ネイティブクライアントプロバイダー (デフォルト) を使用するか、外部クライアントプロバイダーを設定するか、Anypoint Platform ネイティブクライアントプロバイダーと外部クライアントプロバイダーの両方を使用できます。組織や環境ごとに異なるクライアントプロバイダーを割り当てるには、組織で実装するクライアントプロバイダーでの OAuth による認証を事前にクライアントアプリケーションで有効化しておく必要があります。 API Manager 2.2.14 では、複数のクライアント ID プロバイダー (IdP) をサポートするようになったため、デフォルトの Anypoint Platform ネイティブクライアント IdP または 1 つ以上の外部クライアント IdP を環境で使用できます。 クライアントプロバイダーは次のように使い分けることができます。 - 本番、QA、Sandbox などの環境ごと - 内部 API と外部 API
クライアントプロバイダーが内部 API に合わせて設定されている場合でも、Anypoint Platform と通信できるように、公開インターネットからもアクセス可能である必要があります。
## [](#複数の外部クライアントプロバイダーを使用する仕組み)複数の外部クライアントプロバイダーを使用する仕組み 外部クライアントプロバイダーを有効にすると、クライアントプロバイダーは、クライアントアプリケーションが API にアクセスできるようにするトークンを発行する認証サーバーとして機能します。クライアントアプリケーションへのアクセスを要求すると、対応するクライアント ID とクライアントシークレットが API 仕様で指定されている IdP で作成されます。 API がクライアント ID 適用ポリシーを適用し、OAuth ポリシーを適用しない場合でも、クライアントアプリケーションは外部クライアントプロバイダーで作成されます。 OAuth ポリシーが API ゲートウェイにデプロイされると、プラットフォームは IdP 設定 (トークン URL やトークンイントロスペクション URL など) を自動的にポリシーに挿入します。 外部 IdP が 1 つも有効化されていない場合は、Access Manager がデフォルトの認証サーバーとして機能します。 ## [](#ユースケース)ユースケース 複数の外部クライアントプロバイダーの実装方法についての理解を深めるために、「Good Weather」という名前の気象予報会社の例を考えてみましょう。Good Weather は、特定の場所の大気の現在の状態に関する定量的なデータを収集し、気象学を使用して、その現在の状態が経時的にどのように変化するかを予測します。 Good Weather では、ルート組織の下でいくつかのサブ組織が稼動しています。これらのサブ組織は、実行する機能 (エンジニアリングや予報など) によって分かれています。予報部門は、さまざまなソースから最新の気象データを調査して収集します。このデータは、さまざまなクライアントアプリケーションでコンシュームされます。気象予報データをホストするアプリケーションはエンジニアリング部門が管理しています。 Good Weather では、気象予報データの正確さとセキュリティを保証する必要があるため、気象予報関連の API は予報部門の従業員のみがアクセスできるようになっています。また Good Weather では、本番用 API が常に唯一の信頼できる情報源であることを保証したいと考えています。 セキュリティを確保して、組織、環境、API ごとのアクセス分離を保証するため、Good Weather の IT チームは、予報部門に対して外部クライアントプロバイダーを設定します。 ## [](#複数のクライアントプロバイダーのオンボーディング)複数のクライアントプロバイダーのオンボーディング 複数のクライアントプロバイダーをオンボーディングするための手順は、クライアントプロバイダーと社内のビジネス組織がどのように設定されているかによって異なります。 - 外部クライアントプロバイダーが設定されていない場合 環境や API の作成と変更は、以前と同じ手順で行えます。作成した環境には、ネイティブ Anypoint Platform クライアントプロバイダーが割り当てられます。既存の API や環境への影響はありません。 - 外部クライアントプロバイダーが設定されている場合 環境で PingFederate などの外部クライアントプロバイダーが設定されている場合は、複数クライアントプロバイダー機能をオンボーディングした時点で、クライアントプロバイダーが自動的に移行されます。ただし、新しい環境を作成したときは、アクセス管理で正しいクライアントプロバイダーを環境に手動で割り当てる必要があります。 **ベストプラクティス** API を保護する溜め、環境ごとに 1 つの外部クライアントプロバイダーを作成してください。本番環境には既存のクライアントプロバイダーを割り当て、新しいプロバイダーは QA や他の環境 (Sandbox など) に追加します。ただし、管理 API とそれらのコンシューマーへの潜在的な影響を確認してください。 本番環境と本番以外の環境で同じ IdP を使用しないでください。複数の本番環境や、複数の本番以外の環境では同じ IdP を使用できます。 複数のクライアントプロバイダーを設定する場合、ネイティブ Anypoint Platform クライアントプロバイダーと外部クライアントプロバイダーの両方を同じ環境で使用できます。 複数のクライアントプロバイダーを実装する前に、​[ガイドライン](#guidelines)​を参照してください。 ## [](#guidelines)複数のクライアントプロバイダーを実装するためのガイドライン Anypoint Platform で複数のクライアントプロバイダーを実装する前に、以下の点を慎重に確認して理解してください。 - API が次の条件を満たす場合は、クライアントプロバイダーの既存の API インスタンスを変更することはできません。 - コントラクトを持っている - PingFederate ポリシーや OpenID ポリシーなどのプロバイダー関連のポリシーが適用されている (ただし、クライアントプロバイダーの種別が変更されていない場合は例外) - API グループに属している - 以前に API の昇格およびインポート時に外部クライアントプロバイダーを環境に割り当てなかった場合、API Manager 2.2.14 以降では、ネイティブプロバイダーがデフォルトで使用されます。 これらの API には、適切な外部クライアントプロバイダーを割り当て直すことができます。 - 以前にネイティブプロバイダーを使用していた環境に外部クライアントプロバイダーを割り当てる場合は、次のようになります。 - 該当の環境の既存の API では、Anypoint Platform のネイティブクライアントプロバイダーが引き続き使用されます。 - 新しい API では、新しい外部 IdP が使用されます。 - デフォルトのネイティブ Anypoint Platform クライアントプロバイダーおよび 1 つ以上の外部クライアントプロバイダーを使用できます。 ネイティブ Anypoint Platform プロバイダーを使用するために外部プロバイダーを無効にする必要はありません。 - 環境からクライアントプロバイダーを削除した後も、そのクライアントプロバイダーを使用していたすべての既存 API とクライアントアプリケーションは動作を継続できます。 - クライアントプロバイダーをルート組織から削除すると、そのクライアントプロバイダーを使用していたすべての既存 API とクライアントアプリケーションは、デフォルトのネイティブ Anypoint Platform クライアントプロバイダーを使用するようになります。 コントラクトはそのまま残りますが、設定が削除されているため、該当するプロバイダーを認証していたポリシーは失敗します。 ## [](#ロールに基づいて複数のクライアントプロバイダーを実装するためのタスク)ロールに基づいて複数のクライアントプロバイダーを実装するためのタスク ロールと組織のニーズに応じて、下記のタスクを実行して複数のクライアントプロバイダーを実装します。
タスク ロール 実行する場所 注意事項

デフォルトを含む複数の IdP を環境に割り当てる。

Business Group Administrator (ビジネスグループ管理者)

アクセス管理

複数の IdP を使用することで、API Manager での API 設定で IdP を選択できるようになりますので、複数のチームが同じ環境を使用して API を構築していて、それぞれが別々の IdP を使用したい場合に便利です。また、内部コンシューマーと外部コンシューマー向けに別々の API インスタンスを作成していて、コンシューマー別に異なる IdP が必要なユースケースでも便利です。

IdP 設定を変更する前に、API コンシューマーへの中断が発生する可能性に関する通知を受け取る。

Business Group Administrator (ビジネスグループ管理者)

アクセス管理

なし

クライアント管理者ページにおいて、アプリケーションが属するクライアントプロバイダーの確認で、同じ名前の異なるアプリケーションを区別できるようにする。

API Manager 管理者

アクセス管理

なし

ビジネスグループ管理者によって設定されたデフォルトの IdP に自動的にマップするように API Manager で API を設定する。別の IdP が使用できる場合は、オーナーが変更できるようにする。

API オーナー

API Manager

なし

1 つの環境から別の環境に API を昇格またはインポートするときに、対象環境から IdP を指定します。

API オーナー

API Manager

ターゲット環境で IdP が 1 つ (デフォルト) しか存在しない場合は、自動的に API に割り当てられます。

特定の環境に存在する API インスタンスに基づいて API へのアクセスを要求する。

アプリケーションユーザー

Exchange

アクセスを要求する API を選択する場合は、最初にアクセスを要求する API インスタンスを選択する必要があります。API インスタンスは、環境に基づいて絞り込まれます。

## [](#複数のクライアントプロバイダーを設定するためのユーザーフロー)複数のクライアントプロバイダーを設定するためのユーザーフロー Good Weather のユースケースに戻りましょう。同社は、以下のフローを使用して組織で複数の外部クライアントプロバイダーを実装しています。 ![複数の外部クライアントプロバイダーを設定するためのユーザーフロー](/mulesoft/current/ja-jp/api-manager/latest/_images/multiple-IdP-user-flow.png) 図に示されているように、最初に外部クライアントプロバイダーを設定してから、適切な環境に割り当てます。特定の環境内で API を作成または修正すると、新しいクライアントプロバイダーが表示されます。適切なクライアントプロバイダーを選択し直すことができます。 1 つの環境から別の環境に API を昇格するときに、次のいずれかを行うことでポリシーの不一致を防止します。 - 両方の環境で同じプロバイダー種別 (PingFederate や OpenAm など) を使用する。 - 昇格した API に適用されているプロバイダー関連のポリシーをすべて削除する。 API コンシューマーは、特定の環境の API インスタンスに基づいて API へのアクセスを要求できます。 ## [](#複数のクライアントプロバイダーを設定する)複数のクライアントプロバイダーを設定する 複数の外部クライアントプロバイダーを設定する手順は次のとおりです。 1. **\[Access Management (アクセス管理)\]**​ で、最初に​[クライアント管理](https://docs.mulesoft.com/jp/access-management/managing-api-clients)​を有効化します。 クライアントプロバイダーを組織で実装するためには、Anypoint 管理者として事前に OAuth によるクライアントアプリケーションの認証を有効化する必要があります。 2. **\[Access Management (アクセス管理)\]**​ で環境に​[クライアントプロバイダーを割り当てます](https://docs.mulesoft.com/jp/access-management/environments#add-an-idp-to-an-existing-environment)​。 Anypoint 管理者として、クライアントプロバイダーを設定して特定の環境に割り当てます。 3. **API Manager**​ で、新しい IdP を使用して API を​[作成または修正します](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page)​。 API オーナーとして、API を作成するか、Anypoint Exchange から API をインポートするか、または API Manager で API を修正します。必要に応じて、API を 1 つの環境から別の環境に昇格するか、もしくは前述のように API をインポートまたはエクスポートします。 4. **API Manager**​ で​[ポリシーを設定します](https://docs.mulesoft.com/gateway/latest/policies-automated-overview)​。 API Manager 管理者として、関連付けられているクライアントプロバイダーに基づいて API にポリシーを適用できます。 5. **Exchange**​ で、ビジネス組織の特定の環境内で API インスタンスへの​[アクセスを要求します](https://docs.mulesoft.com/jp/exchange/to-request-access)​。 API コンシューマーとして、登録されているクライアントアプリケーションから非公開 Exchange または公開ポータルを使用して、API インスタンスへのアクセスを要求できます。 ## [](#関連情報)関連情報 - [Exchange からのインポートによる API インスタンスの作成](#manage-exchange-api-task.adoc) - [アクセス管理プロバイダーでのクライアントプロバイダーの管理](https://docs.mulesoft.com/jp/access-management/managing-api-clients) - [複数のクライアントプロバイダーを持つ API のインポート](https://docs.mulesoft.com/jp/api-manager/latest/import-api-task) - [複数のクライアントプロバイダーを持つ API のエクスポート](https://docs.mulesoft.com/jp/api-manager/latest/export-api-latest-task) - [複数のクライアントプロバイダーを持つ API の昇格](https://docs.mulesoft.com/jp/api-manager/latest/promote-api-task) # トラブルシューティング API Manager タスクを実行すると、問題が発生したり、エラーメッセージが表示されたりする場合があります。このセクションでは、次のトピックについて説明します。 - [ポリシー作成時のデプロイエラー](https://docs.mulesoft.com/jp/api-manager/latest/troubleshooting-archetype-error-when-creating-policy)​ - [自動検出設定時のデプロイエラー](https://docs.mulesoft.com/jp/api-manager/latest/troubleshooting-config-properties-apiid-error) # ポリシーのパッケージ化、スコープ、サイズ ポリシーは次のもので構成されます。 - YAML ファイル ポリシーの設定可能なパラメーターを定義します。ポリシーの入力を表示するために UI によってレンダリングされます。 - XML テンプレート ポリシーの実装が含まれています。 - テンプレートの POM ポリシーの連動関係を定義します。パッケージの種類は ​`mule-policy`​ である必要があります。 - リソース (省略可能) ポリシーが証明書など他のリソースに依存する場合は、ポリシーの一部としてリソースを定義します。 - mule-artifact.json 記述子 分類子を ​`mule-policy`​ として指定します。 詳細は、ヘッダーポリシーを参照してください。 ## [](#ポリシーのスコープ)ポリシーのスコープ ポリシーは、アプリケーションや他のポリシーから分離されていますが、ポリシーからの情報を公開する方法があります。ポリシーについての認証情報は、セキュリティコンテキストプリンシパルオブジェクトで伝播できます。 ポリシーはメッセージのコンテンツを変更できます。Mule 4.1.0 以降では、メッセージが ​`source`​ ポリシーの ​`execute-next`​ の前、または ​`operation`​ ポリシーの場合はその後で変更されると、デフォルトでは変更内容が伝播されません。変更内容の伝播を有効にするには、各ポリシーで ​`propagateMessageTransformations`​ フラグを有効にします。 **例**​ ポリシーは、​`execute-next`​ を定義しない、またはフローに到達しないようにする (たとえば、choice に配置する) ことで、フローの実行を避けることができます。 ポリシーに設定された変数にはポリシーのスコープのみがあります。また、フローで定義された変数はポリシーに表示されません。 ## [](#ポリシーのサイズ)ポリシーのサイズ ポリシーのサイズは連動関係に基づいて異なります。Mule Runtime がポリシーをポーリングするとき、初回は取得するのに時間がかかりますが、取得されたポリシーはファイルシステムにキャッシュされます。オフラインでも使用可能になり、またポリシー取得時の待ち時間も短縮されます。 ## [](#関連情報)関連情報 - [ポリシー](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) # ポリシー作成時のアーキタイプエラー ポリシーの作成時に既存のファイルがあるディレクトリからアーキタイプを実行しようとすると、「Directory already exists (ディレクトリがすでに存在します)」というエラーが発生する場合があります。このエラーは、環境にインストールされている Maven のバージョンによって異なる可能性があります。 次のコードスニペットは、maven-archetype-plugin バージョン 3.1.1 で生成されたエラーを示しています。 ```text mvn -Parchetype-repository archetype:generate \ [INFO] Parameter: basedir, Value: C:\Users\32481\AnypointStudio\studio-workspace\mycustompolicy [INFO] Parameter: package, Value: mule-policy [INFO] Parameter: groupId, Value: 6344d2e6-eff9-4020-b792-719c463d5b92 [INFO] Parameter: artifactId, Value: ClientIdCustomPolicy [INFO] Parameter: packageName, Value: mule-policy [INFO] Parameter: version, Value: 1 [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Skipping mycustompolicy [INFO] This project has been banned from the build due to previous failures. [INFO] ------------------------------------------------------------------------ [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 05:14 min [INFO] Finished at: 2019-07-03T14:07:26+08:00 [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate (default-cli) on project mycustompolicy: Directory ClientIdCustomPolicy already exists - please run from a clean directory -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException. ``` ## [](#原因)原因 この問題は、アーキタイプが配置されるディレクトリがすでに存在するために発生します。そのディレクトリは、以前のアーキタイプの実行試行中に作成された可能性があります。 ## [](#解決策)解決策 この問題を解決するには、既存のアーキタイプディレクトリを削除して、コマンドを再実行します。 # レート制限ポリシー v1.2.0 の適用 レート制限 1.2.0 には、レート制限 1.0.0 および 1.1.0 の機能と、キー依存識別子別にクォータを適用する機能があります。このポリシーは Mule 4.1.0 以降で使用できます。 この識別子は文字列にマップする DataWeave 式で、セレクターキーを作成します。レート制限 1.0.0 および 1.1.0 では、ポリシーを API に適用するときに、設定された制限と ID を使用してポリシーごとにレート制限アルゴリズムが 1 つだけ作成されます。1.2.0 では、セレクターキーは ID の一部です。したがって、各セレクターキーに 1 つのアルゴリズムが作成され、それぞれに独自のクォータがあります。 ポリシーを適用するときに識別子を指定します。 ![\[Apply Rate limiting policy (レート制限ポリシーを適用)\] ページ。](_images/rate-limit-identifier.png) この例では、レート制限をすべてのメソッドに適用します。クォータはメソッドごとに独立しています (3 要求/10 秒)。このようなポリシー設定は、次に示す仮説期間にわたってイベントが発生する可能性があります。 ![受け入れられた POST 要求と GET 要求の記号と、拒否された POST 要求と GET 要求の記号が、10 秒間隔のウィンドウサイズを示す大括弧付きのタイムライン上に表示された図。](/mulesoft/current/ja-jp/api-manager/latest/_images/three-req-per-10.png) この例は次を示しています。 - すべての HTTP メソッドでは 10 秒おきに 3 つの要求が許可されます (この例では、API に対して GET 要求と POST 要求のみが実行されている)。 - レート制限ポリシーは、固定されたウィンドウで機能します (ウィンドウサイズの括弧を参照)。 - ウィンドウ開始時間は独立しています。エンジンはメソッドの最初の要求を受信するとレート制限アルゴリズムをスプールする遅延作成戦略を使用します。 ## [](#非必須パラメーターの識別子を使用したレート制限の適用方法)非必須パラメーターの識別子を使用したレート制限の適用方法 識別子は非必須パラメーターです。識別子はデフォルトで空白になっており、次のようにレート制限ポリシーの以前のすべてのバージョンとの互換性を保持しています。 - 未設定 (空白) の場合、1 つのバケットを使用してポリシーポイントカットによって照合されたすべての要求にクォータ制限が適用されます。 - 必須の HTTP ヘッダーに設定されている場合、ヘッダーの大文字と小文字を区別した値ごとに独自のクォータが使用されます。クォータは遅延作成されます。 - 非必須の HTTP ヘッダー、カスタムヘッダー、ペイロード、クエリパラメーターまたは式に設定されている場合、値ごとに独自のクォータが使用されます。 識別子が要求で送信されない場合、デフォルトで空の識別子に設定され、独自のクォータが使用されます。この動作では、未制御のクライアントによってコンシュームされる API にレート制限ポリシーを適用できると同時に、識別子を送信するクライアントの特別なバケットに対応します (内部の制御されたサービスの場合がある)。 次の画像は後者を示し、DataWeave 式 ​`#[attributes.queryParam[‘customIdentifier’]]`​ をポリシー識別子として使用する 3 要求/10 秒のクォータに相当します。 ![\[Apply Rate limiting policy (レート制限ポリシーを適用)\] ページ。](_images/rate-limit-identifier.png) この場合、次のアクションが発生します。 - 識別子のない要求はすべて空の識別子に解決されます。したがって、1 つのレート制限アルゴリズムを使用します。 - 識別子ごとに異なるバケットと独自の独立したクォータが使用されます。 ## [](#dataweave-式を使用したレート制限の適用方法)DataWeave 式を使用したレート制限の適用方法 レート制限エンジンは HTTP に依存せず、DataWeave 式の解決のみに左右されます。複雑なレート制限シナリオに対応するために識別子式を変更することができます。 たとえば、すべてのクラス A および C の LAN 要求に 1 つのバケット、それ以外の要求に別のバケットを使用する識別子をレート制限ポリシーに設定できます。 ![識別子属性が強調表示された \[Apply Rate limiting policy (レート制限ポリシーを適用)\] ページ。](_images/dw-apply-limiting.png) この設定では、要求を実行した IP の地域に対応する false または true のバケットが作成されます。 false と true は、HTTP ではなく、ブール値のドメインに対応しますが、エンジンでは解決された式が文字列として扱われるので、ポリシーは正しく機能します。 使用可能な識別子は、DataWeave を使用して要求から結果を抽出する必要がありますが、その他にはお客様の想像力以外の制約はありません。 **注意:**​ HTTP RFC は、ヘッダー名を大文字と小文字を区別するものとして宣言します。ヘッダー名は MuleSoft HTTP Connector によって小文字に変更されます。DataWeave はキーに依存します。したがって、識別子式を作成するときには、小文字のヘッダーを参照するようにしてください。 ### [](#無制限の識別子セット)無制限の識別子セット すべての識別子に 1 つのアルゴリズムが存在する必要があるので、(すべての識別子に少なくとも 1 つの要求がある場合は) 同じ量のアルゴリズムをメモリ内でホストしなければならないため、DataWeave 式を作成するときには、無制限の co ドメイン (大規模なドメイン) を返さないように注意します。たとえば、DataWeave 式で、インターネットに公開されたランタイムでの識別子として ip が使用されるとします。インターネット上のすべての公開 IPv4 IP がこのランタイムに対して要求を実行する場合、1 つのランタイムで 3,706,452,992 個のアルゴリズムが実行されます。アルゴリズムあたりの平均が 250 バイトであれば、レート制限アルゴリズムは約 1 テラバイトになります。 MuleSoft では、結果のセットをできるだけ小さくするために、有限個の識別子に解決される DataWeave 式を使用することをお勧めします。 ### [](#anypoint-service-mesh-のレート制限)Anypoint Service Mesh のレート制限 レート制限ポリシーは、次の制限を除き、Anypoint Service Mesh (Mule 以外のアプリケーション) と同様に機能します。 - このポリシーでは、識別子によるサブバケット化がサポートされない (1 つのバケットのみ)。 - このポリシーでは、ヘッダーを公開するオプションが提供されない。 # 別の環境への API インスタンスの昇格 API インスタンスを別の環境に昇格する前に、​`「Manage APIs Configuration (API 設定の管理)」`​権限があることを確認します。 エンティティを参照する権限とその宛先を管理する権限の両方がある場合にのみ、ポリシーやアラートなどのエンティティを昇格できます。たとえば、ポリシーを昇格するには、​`「View Policies (ポリシーの参照)」`​権限と​`「Manage Policies (ポリシーの管理)」`​権限が必要です。 API インスタンスを昇格する手順は、次のとおりです。 ## [](#promote-api)別の環境への API インスタンスの昇格 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、​**\[Add API (API を追加)\]**​ をクリックし、​**\[Promote API from environment (環境から API を昇格)\]**​ を選択します。 3. **\[Source Environment (ソース環境)\]**​ を選択します。 4. 検索項目に API の名前を入力して、​**\[API\]**​ を選択します。 5. **\[API Version (API バージョン)\]**​ を選択します。 6. **\[API instance label (API インスタンスの表示ラベル)\]**​ を選択します。 7. 必要に応じて、除外する ​**\[Include in Promotion (昇格に含める)\]**​ オプションをオフにます。 8. **\[Promote (昇格)\]**​ をクリックします。 9. 必要に応じて、\[Runtime & Endpoint Configuration (ランタイムとエンドポイント設定)\] の詳細を確認して更新し、​**\[Save (保存)\]**​ をクリックします。 API インスタンスの昇格は API 定義にのみ影響します。インスタンスにサブスクライブしている既存のデプロイ済みアプリケーションには影響しません。昇格後、​**API 表示ラベル**​はそのままですが、​**API インスタンス ID**​ が変更されます。 昇格された API インスタンスをサブスクライブする必要がある既存のアプリケーションの場合: 1. アプリケーション内の ​**API インスタンス ID**​ を更新します。 2. クライアント ID とシークレットは環境ごとに異なるため、アプリケーションのクライアント ID とシークレットを更新します。 ## [](#関連情報)関連情報 - [環境にアクセスするための権限の付与](https://docs.mulesoft.com/jp/api-manager/latest/environment-permission-task) - [環境](https://docs.mulesoft.com/jp/access-management/environments) - [API Manager における API インスタンスの作成](https://docs.mulesoft.com/jp/api-manager/latest/api-instance-landing-page) # 接続アプリケーションを使用したクライアントアプリケーションの作成 自動化のユースケースでは、接続アプリケーションを使用してクライアントアプリケーションの作成と管理ができます。 接続アプリケーションは、機密情報を共有したりサードパーティにアプリケーションの完全な制御権を付与したりすることなく、ユーザーが自分のアクセスを委任するのに役立ちます。接続アプリケーションによって実行されたアクションは監査され、ユーザーはいつでもアクセスを取り消すことができます。 ## [](#接続アプリケーションの作成)接続アプリケーションの作成 接続アプリケーションを作成するには、「[開発者向けの接続アプリケーション](https://docs.mulesoft.com/jp/access-management/connected-apps-developers)」を参照してください。 クライアントアプリケーションを管理する接続アプリケーションを作成する場合、必ず以下の操作を行います。 1. **\[Type (種別)\]**​ で ​**\[App acts on its own behalf (client credentials) (アプリケーションが自身のために行動する (クライアントログイン情報))\]**​ を選択します。 2. **\[Application Creator (アプリケーション作成者)\]**​ スコープを追加します。 ![「App acts on its own behalf (client credentials) (アプリケーションが自身のために行動する (クライアントログイン情報))」 と 「Application Creator (アプリケーション作成者)」 の場所を示しているスクリーンショット](https://docs.mulesoft.com/jp/api-manager/latest/connected-app-client-apps.png)
1[App acts on its own behalf (client credentials) (アプリケーションが自身ために行動する (クライアントログイン情報))]​ 種別
2[Application Creator (アプリケーション作成者)]​ スコープを追加するための ​[Add Scopes (スコープを追加)]​ ボタン
新しい接続アプリケーションでクライアントアプリケーションを作成し、作成したクライアントアプリケーションを管理できるようになりました。 ## [](#クライアントアプリケーション管理)クライアントアプリケーション管理 接続アプリケーションでクライアントアプリケーションを作成すると、接続アプリケーションのオーナーが新しいクライアントアプリケーションのオーナーになります。このオーナーは、API Manager を使用して他のユーザーをオーナーとして追加することができます。 接続アプリケーションでは、作成したクライアントアプリケーションを管理できるほか、次のアクションを実行できます。 - ユーザーをクライアントアプリケーションのオーナーとして追加する - API インスタンスへのアクセス権を要求する - 層の変更を要求する - クライアントアプリケーションのシークレットをリセットする 接続アプリケーションをクライアントアプリケーションのオーナーとして追加することはできません。接続アプリケーションでは、接続アプリケーションで作成したクライアントアプリケーションのみを管理できます。 ## [](#api-manager-api-を使用したクライアントアプリケーションの作成)API Manager API を使用したクライアントアプリケーションの作成 接続アプリケーションを作成したら、API Manager API に対して要求を実行してクライアントアプリケーションを作成および管理できます。 このセクションでは、クライアントアプリケーションの作成方法のみが示されています。クライアントアプリケーションを管理するための API Manager API 要求についての詳細は、 [API Manager API のドキュメント](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/)​を参照してください。 API Manager API を使用してクライアントアプリケーションを作成する手順は、次のとおりです。 1. 次の情報を収集して認証トークンを取得します。 - ``​: 接続アプリケーションの ​**ID** - ``​: 接続アプリケーションの​**シークレット**​。 2. プレースホルダーを次の内容に置き換えたら、次の要求を実行して認証トークンを取得します。 ```ssh curl --location --request POST 'https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token' \ --header 'Content-Type: application/json' \ --data-raw '{ "grant_type": "client_credentials", "client_id": "", "client_secret": "" }' ``` 3. 次の情報を収集してクライアントアプリケーションを作成します。 - ``​: 接続アプリケーションを作成する組織の​**組織 ID** - ``​: クライアントアプリケーションを作成している API インスタンスの API インスタンス ID - クライアントアプリケーションパラメーター: - `name`​: アプリケーションの名前 - `description`​: アプリケーションの説明 - `url`​: アプリケーションの URL - `redirectURI`​: リダイレクト URI の配列 - `grantTypes`​: 許可種別の配列 (例: `「password」`​、​`「implicit」`​、​`「client_credentials」`​、​`「authorization_code」`​、​`「refresh_token」`​) - `apiEndpoints`​: リダイレクト URI を自動的に登録するかどうかを示す「true」または「false」の値。 4. プレースホルダーを次の内容に置き換えたら、次の要求を実行してクライアントアプリケーションを作成します。 ```ssh curl --X POST 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations//applications?apiVersionId=' \ --header 'Authorization: bearer ' \ --header 'Content-Type: application/json' \ --data '{ "redirectUri": ["http://example.com/"], "apiEndpoints": false, "name": "Sample Client Apps Name", "description": "Create this App for Sample Client Apps via API 1", "url": "https://www.example.com/app-test1" } ' ``` ## [](#関連情報)関連情報 - [Exchange からの API インスタンスへのアクセス権の要求](https://docs.mulesoft.com/jp/exchange/to-request-access) - [API インスタンスコントラクトの削除](https://docs.mulesoft.com/jp/api-manager/latest/remove-client-app-latest-task) - [クライアントアプリケーションのクライアント ID とクライアントシークレットログイン情報の取得](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task) # 環境にアクセスするための権限の付与 環境内で API Manager 操作に完全にアクセスできるようにするには、ユーザーに API Manager 環境管理者権限が必要です。API Manager 環境管理者ロールは、API Manager のみで実行されるタスクに関連付けられます。API Manager 関連の操作の権限は Anypoint アクセス管理から変更できます。 ロールに関する注意事項を次に示します。 - ある特定のビジネスグループのユーザーに割り当てられたロールおよび権限は、異なるビジネスグループの同じユーザーに割り当てられたロールおよび権限とは無関係です。 - ロールはビジネスグループ固有であるため、ユーザーアイコンの横にあるメニューをクリックして、ロールを管理する適切なビジネスグループ内にいることを確認してください。 次の図は、各権限で有効になるタスクを示しています。 ![権限のリレーション](/mulesoft/current/ja-jp/api-manager/latest/_images/apim-permissions-relationships.png) この図では、環境管理者にすべての機能および権限へのアクセス権があります。 外側の権限が内側の権限に権限を付与します。たとえば、​`「アラートの管理」`​は、「アラートの表示」と「API 設定の表示」に権限を付与します。 API Manager では、次の追加の環境レベル権限がサポートされます。
権限 説明 注意事項

API プロキシのデプロイ

API プロキシをデプロイまたは再デプロイします。

Runtime Manager とハイブリッドのアクセス権が必要です。このロールでは、API Manager からのデプロイメントアクセスが有効になりますが、Runtime Manager またはハイブリッドの連動関係のため、デプロイメントの成功は保証できません。

アラートの管理

アラートを作成、編集、および削除します。

API 設定の管理

Exchange から API をインポートします。

この権限を持つユーザーは、API を別の環境に昇格したり、API の設定を編集したり、API を削除したりすることもできます。

これは環境ごとの権限です。API の表示を組織内の特定のユーザーに制限することはできません。

コントラクトの管理

コントラクトのデプロイ、拒否、失効を行います。

また、この権限は層を超えてユーザーに付与されます。

ポリシーの管理

ポリシーの作成、編集、削除、有効化、無効化、並び替えを行います。

アラートの表示

アラートをリストしたり、アラートの設定の概要を表示したりします。

API 設定の表示

API をリストしたり、表示したりします。

API をリストしたり、API の設定の概要を表示したり、プロキシをダウンロードしたりします。

これは環境ごとの権限です。API の表示を組織内の特定のユーザーに制限することはできません。

コントラクトの表示

コントラクトとその設定を表示します。

SLA 層とそれらの設定をリストすることもできます。

ポリシーの表示

ポリシーのリストを表示したり、ポリシーの設定を表示したりします。

## [](#権限の付与)権限の付与 API Manager から環境権限をロールに付与する手順は、次のとおりです、 1. **\[Access Management (アクセス管理)\]**​ > ​**\[Users (ユーザー)\]**​ > ​**_権限を付与するユーザー_**​ > ​**\[API Manager\]**​ > \[Permissions (権限)\] をクリックします。 2. ユーザーの権限を選択し、​![「青色のプラスアイコン」](/mulesoft/current/ja-jp/api-manager/latest/_images/blue-plus.png)​ をクリックして権限を保存します。 ![「Access Management (アクセス管理)」 で権限を設定する方法](/mulesoft/current/ja-jp/api-manager/latest/_images/apim-user-perms.png)

次の API Manager 1.x ロールは API Manager 2.x と互換性がありません。

  • API Versions Owner (API バージョンオーナー)

  • API Creator (API 作成者)

  • Portals Viewer (ポータル閲覧者)

## [](#関連情報)関連情報 - [別の環境への API インスタンスの昇格](https://docs.mulesoft.com/jp/api-manager/latest/promote-api-task) # 環境の切り替え この手順では、組織に複数の環境を追加済みであることを前提とし、API を環境間で切り替える方法について説明します。環境が追加されていない場合は、切り替えようとするときに環境が表示されません。\[Exception: The Unclassified environment (例外: 未分類の環境)\] が表示される場合があります。以前のバージョンの API Manager から API をアップグレードした場合は、API が未分類の環境にある可能性があります。これらの API を分類する必要があります。下記のリンクを参照してください。

API Manager では、設計環境への切り替えはできません。

この手順は、​**\[Access Management (アクセス管理)\]**​ > ​**\[Environments (環境)\]**​ > ​**\[Add Environment (環境を追加)\]**​ で複数の環境を追加したことを前提とします。 1. API Manager で環境コントロールをクリックします。次の例では、このコントロールに「SANDBOX」という表示ラベルが付いています。 ![環境 Sandbox が選択された 「API Manager」 の 「API Administration (API 管理)」。](/mulesoft/current/ja-jp/api-manager/latest/_images/environment3.png) 2. \[Switch Environment (環境を切り替え)\] で、表示された使用可能な環境のいずれかを選択します。 3. **\[Switch (切り替え)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [環境](https://docs.mulesoft.com/jp/access-management/environments) - [API Manager における環境への API インスタンスの分類](https://docs.mulesoft.com/jp/api-manager/latest/classify-api-task) # 環境の概念の確認 Anypoint Platform の戦略コンポーネントの環境がサポートされるようになり、バージョン名を作成して環境を反映させる必要がなくなりました。システム管理者は、環境ごとに権限を付与します。環境アクセス権限を付与されたユーザーは、特定の環境内の操作にフルアクセスできます。 ![環境 Sandbox が選択された 「API Manager」 の 「API Administration (API 管理)」。](/mulesoft/current/ja-jp/api-manager/latest/_images/environment3.png) API Manager 環境管理者は、API Manager 内のアクションにのみ関連します。「API Manager 環境管理」権限では、次の操作を実行できます。 - 自分の API を作成および変更したり、他のユーザーが作成した API を変更したりする - ポリシーを適用する - SLA を定義する - アラートを作成する 組織のシステム管理者は、以下のリンクされたトピックの説明に従って権限をユーザーに付与します。 API Manager に移動すると、デフォルト環境の名前が記載された環境コントロールが表示されます。この例のデフォルト環境は、Sandbox です。 ![環境 Sandbox が選択された 「API Manager」 の 「API Administration (API 管理)」。](/mulesoft/current/ja-jp/api-manager/latest/_images/environment3.png) 環境コントロールをクリックすると、本番環境と Sandbox 環境のリストが表示されます。 Autodiscovery を介して Mule Runtime を API Manager に接続するには、次のいずれかのログイン情報のペアを指定する必要があります。 - 環境のクライアント ID とクライアントシークレット - API を登録した組織のクライアント ID とクライアントシークレット - API を登録した組織の親のクライアント ID とクライアントシークレット。 たとえば、親ビジネスグループ (BG) として ABC 社、その親の子として ABC-BG1 および ABC-BG2 があるとします。ABC のログイン情報を使用して、ABC-BG1 API を追跡できます。 - ABC - ABC-BG1 - ABC-BG2 ## [](#未分類の-api-および権限の概念の確認)未分類の API および権限の概念の確認 以前のバージョンの API Manager から API Manager 2.x に API をアップグレードすると、API が未分類の環境に含まれる可能性があります。環境に関連付けていない他の API (Design Center で作成した API、Exchange にパブリッシュした API、Exchange から管理するようにセットアップした API など) も、API Manager で未分類として表示されます。API を管理するには、API を分類する必要があります。API を分類するまで、以前のリリースのユーザー権限がすべての操作に適用されます。分類後、ユーザーに付与する環境ごとの権限が適用されます。 ## [](#関連情報)関連情報 - [環境](https://docs.mulesoft.com/jp/access-management/environments) - [API Manager における環境への API インスタンスの分類](https://docs.mulesoft.com/jp/api-manager/latest/classify-api-task) - [環境にアクセスするための権限の付与](https://docs.mulesoft.com/jp/api-manager/latest/environment-permission-task) - [API ゲートウェイの API 自動検出の概念の確認](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-autodiscovery-overview) - [Mule 4 アプリケーションでの Mule ゲートウェイの API 自動検出の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule4) - [Mule 3 アプリケーションでの Mule ゲートウェイの API 自動検出の設定](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule3) # 環境への API インスタンスの分類 API Manager 2.x にアップグレードすると、API は未分類の環境に配置されます。未分類の API を分類して管理するか、別の方法で API を管理する必要があります。 API Manager では、組織と環境のどちらのログイン情報でも API を追跡できますが、環境のログイン情報に関連付けられている権限の方が限定的であるため、環境のログイン情報を使用することをお勧めします。ログイン情報を変更したら、Mule Runtime を再起動する必要があります。再起動すると、ダウンタイムが生じる可能性があります。変更方法についての詳細は、以下の​[環境のログイン情報を使用した Mule サーバーの設定 (高度な分類: 省略可能)](#環境のログイン情報を使用した-mule-サーバーの設定-高度な分類-省略可能)​ を参照してください。この作業を行ったら、API Manager で推奨される環境に API を分類できます。 特定の環境のログイン情報を使用する場合、次の作業は実行できません。 - 別の環境からの API の追跡 - 別の組織からの API の追跡 これらのいずれかの方法で API を追跡する必要がある場合、組織のログイン情報を使用します。 使用している Mule Runtime のバージョンに応じて、​[「Mule Runtime 4 の組織のログイン情報の設定」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule4)​または​[「Mule Runtime 3 の組織のログイン情報の設定」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-org-credentials-mule3)​に従います。 環境のログイン情報を使用して API を追跡する必要がある場合は、詳細セクションを参照してください。 ## [](#api-manager-での-api-インスタンスの分類)API Manager での API インスタンスの分類 1. API Manager で環境コントロール (この例の表示ラベルは SANDBOX) をクリックします。 ![環境 Sandbox が選択された 「API Manager」 の 「API Administration (API 管理)」。](/mulesoft/current/ja-jp/api-manager/latest/_images/environment3.png) API を分類する適切な環境がない場合、\[Access Management (アクセス管理)\] で環境を作成します。 詳細は、​[「新しい環境の作成方法」](https://docs.mulesoft.com/jp/access-management/environments#to-create-a-new-environment)​と​[「環境の概念の確認」](https://docs.mulesoft.com/jp/api-manager/latest/environments-concept)​を参照してください。 2. **\[Unclassified (未分類)\]**​ を選択します。 ![環境が表示された 「Switch Environment (環境の切り替え)」 ダイアログ。](/mulesoft/current/ja-jp/api-manager/latest/_images/switch-environment.png) 3. **\[Switch (切り替え)\]**​ をクリックします。 未分類の API のリストが表示されます。 ![未分類の API のリストが表示された 「API Administration (API 管理)」 ダイアログ。](/mulesoft/current/ja-jp/api-manager/latest/_images/classify.png) 4. **\[Classify (分類)\]**​ をクリックします。 5. **\[Target Environment (対象環境)\]**​ で、使用可能な環境のリストから API の環境を選択します。たとえば、​**\[Test (テスト)\]**​ を選択します。 6. **\[Instance name (インスタンス名)\]**​ に、必要に応じて一意のインスタンス名を入力します。たとえば、​`abc-api-1`​ と入力します。 環境では、API に複数のインスタンスを設定できます。そのため、一意に識別できるインスタンス名にする必要があります。 ![「Target environments (対象環境)」 項目と 「Instance name (インスタンス名)」 項目に値の例が入力されている 「Classify (分類)」 ダイアログボックス。](/mulesoft/current/ja-jp/api-manager/latest/_images/classify-instance.png) ### [](#api-analytics-の影響)API Analytics の影響 API Manager の Crowd の前のバージョンでは、すべてのダッシュボードが組織で共有されていました。Crowd では、各ダッシュボードが特定の環境にリンクします。 すべての API を分類すると、移行前の API のカスタムレポートは機能しなくなります。 ### [](#環境のログイン情報を使用した-mule-サーバーの設定-高度な分類-省略可能)環境のログイン情報を使用した Mule サーバーの設定 (高度な分類: 省略可能) この設定を使用して、環境のログイン情報を使用する API を追跡できます。この設定では、サーバーを再起動する必要があります。 後続のセクションは、移行前のプロキシのデプロイ方法に応じて API を分類するのに役立ちます。 ### [](#api-manager-を介してデプロイされたプロキシを使用して-api-インスタンスを管理する)API Manager を介してデプロイされたプロキシを使用して API インスタンスを管理する API が Runtime Manager でデプロイされている場合: 1. \[API Administration (API 管理)\] で、API インスタンスの ​**API 名**​をクリックします。 2. **\[Runtime & Endpoint Configuration (ランタイムとエンドポイント設定)\] > \[Save & Deploy (保存してデプロイ)\]**​ をクリックします。 3. **\[Runtime version (ランタイムバージョン)\]**​ を選択します。 4. **\[Save & Apply (保存して適用)\]**​ をクリックします。 API がオンプレミスのスタンドアロンランタイムでデプロイされている場合: 1. \[API Administration (API 管理)\] で、API インスタンスの ​**API 名**​をクリックします。 2. **\[Runtime & Endpoint Configuration (ランタイムとエンドポイント設定)\] > \[Save & Deploy (保存してデプロイ)\]**​ をクリックします。 3. Mule エージェント 1.9 以降のランタイムバージョンを指定します。 4. **\[Save & Apply (保存して適用)\]**​ をクリックします。 既存のサーバーを更新する手順は、次のとおりです。 1. SSH を使用して、スタンドアロンランタイムサーバーにアクセスします。 2. ランタイムエージェント 1.9 以降をダウンロードします。 3. API ゲートウェイランタイムエージェントを更新します。 4. ゲートウェイを再起動します。 ### [](#runtime-manager-を介してデプロイされた基本エンドポイントまたはプロキシを使用して-api-インスタンスを管理する)Runtime Manager を介してデプロイされた基本エンドポイントまたはプロキシを使用して API インスタンスを管理する API が Runtime Manager でデプロイされている場合: 1. Access Manager に移動します。 2. \[Environments (環境)\] をクリックします。 3. 使用する環境名をクリックします。 4. クライアント ID とクライアントシークレットをコピーします。 Runtime Manager でアプリケーションを更新する手順は、次のとおりです。 1. Runtime Manager でプロキシアプリケーションに移動します。 2. \[Settings (設定)\] をクリックします。 3. \[Properties (プロパティ)\] をクリックします。 4. 次のプロパティの値を環境の値に変更します。 - Anypoint.platform.client\_id - Anypoint.platform.client\_secret 5. \[Apply changes (変更を適用)\] をクリックします。 スタンドアロン Mule Runtime でデプロイされたアプリケーションを更新する手順は、次のとおりです。 1. SSH を使用して、アプリケーションがデプロイされているスタンドアロンランタイムサーバーにアクセスします。 2. ランタイムエージェント 1.9.x をダウンロードします。 3. ランタイムエージェントを更新します。 4. Mule Runtime を再起動します。 ### [](#その他のデプロイメント)その他のデプロイメント このセクションでは、Runtime Manager でエージェントを更新またはサーバーを登録せずに API 環境を使用できるように Mule Runtime を準備するために必要な手動の手順について説明します。 環境のクライアント ID とクライアントシークレットの取得 1. Access Manager に移動します。 2. \[Environments (環境)\] をクリックします。 3. 使用する環境名をクリックします。 4. クライアント ID とクライアントシークレットをコピーします。 Runtime Manager でのアプリケーションの更新 1. Runtime Manager でプロキシアプリケーションに移動します。 2. \[Settings (設定)\] をクリックします。 3. \[Properties (プロパティ)\] をクリックします。 4. 次のプロパティの値を環境の値に変更します。 - anypoint.platform.client\_id - anypoint.platform.client\_secret スタンドアロンランタイムの更新 1. SSH を使用して、更新するランタイムサーバーにアクセスします。 2. `//wrapper.conf`​ ファイルを編集します。 3. 次のプロパティの値を環境の値に変更します。 - anypoint.platform.client\_id - anypoint.platform.client\_secret 4. Mule Runtime を再起動します。 ## [](#関連情報)関連情報 - [サーバーのシャットダウン、再起動、削除方法 (ハイブリッド)](https://docs.mulesoft.com/jp/runtime-manager/servers-actions) # 登録済みクライアントアプリケーションのクライアントログイン情報の取得 [登録済みクライアントアプリケーション](https://docs.mulesoft.com/jp/exchange/to-request-access)​のオーナーは、アプリケーションと API の間でコントラクトを作成した後で API にアクセスするときに、クライアント ID とクライアントシークレットの提供が求められる場合があります。 クライアント ID とクライアントシークレットログイン情報の提供は、その API に適用されるポリシーに基づいて要求されます。たとえば、API オーナーがクライアント ID 適用ポリシーを適用している場合は、アプリケーションのクライアント ID と、必要に応じて API にアクセスするためのクライアントシークレットを提供する必要があります。 ログイン情報にアクセスするには、ルート組織のシステム管理者権限があるか、クライアントアプリケーションのオーナーである必要があります。 クライアントアプリケーションのログイン情報を取得する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. **\[Client Applications (クライアントアプリケーション)\]**​ をクリックします。 3. 詳細ペインから、クライアントのログイン情報を確認するアプリケーションをクリックします。 ウィンドウに、選択したアプリケーションのクライアント ID とクライアントシークレットのログイン情報が表示されます。 4. または、登録済みクライアントアプリケーションのクライアント ID のみを取得する必要がある場合は、適切なバージョンの API を選択し、​**\[Contracts (コントラクト)\]**​ をクリックします。 アプリケーションオーナーは、API Manager へのアクセス権を持っていない場合には Exchange で​[アプリケーションログイン情報](https://docs.mulesoft.com/jp/exchange/about-my-applications)​を表示できます。 5. 詳細を表示するには、特定の API コントラクトをクリックします。 ## [](#関連情報)関連情報 - [クライアントアプリケーションの登録](https://docs.mulesoft.com/jp/exchange/to-request-access) [https://docs.mulesoft.com/exchange/about-my-applications](https://docs.mulesoft.com/exchange/about-my-applications)