# 本番環境でのテスト（APIドライラン）

Equinix Fabricは、**APIドライラン** 機能を本番環境で直接サポートしています。<br />\*\* ドライランでは、サポートされているAPIコールを安全にシミュレートし、リクエストのペイロード、ビジネスロジック、リソースの可用性を検証できます。\*\*インフラストラクチャのプロビジョニングや料金の発生はありません。

ドライランは、新しい統合の検証、オートメーションへの変更のテスト、複雑なリクエストが成功するかどうかの確認を、"実際に "実行する前に行う場合に使用します。

## ドライランの仕組み[​](#ドライランの仕組み "Direct link to ドライランの仕組み")

ドライランは、サポートされている API リクエストに `dryRun=true` のようなクエリパラメータを追加することで有効になります。

\*\*Dry Runパラメータが存在する場合、Fabricプラットフォームは、完全なトランザクションを完了する代わりに、\*\*サーバー側の検証のみを実行します。具体的には、プラットフォームは以下を行います：

* **入力の検証** - 必須フィールドが存在し、正しくフォーマットされていること、メトロ、IBXコード、帯域幅、パッケージタイプなどの値が有効であることを確認します。
* **ビジネスロジックの検証** - メトロ、ポート、またはクラウドルーターが要求された操作で利用可能かどうかの確認など、外部および内部のチェックを実行します。
* **永続化とプロビジョニングのスキップ** - データベースレコードの作成、作業指示の生成、物理または論理リソースの予約、更新、削除は行われません。

認証、承認、クォータ・チェックは、ライブ・コールと同様に実施されます。

:::重要 ドライランは、許可やアカウント要件をバイパスするものではありません。権限の欠落や無効なアカウント状態のために本番コールが拒否される場合、ドライランコールも拒否されます。 ::::

## サポートされるリソースとオペレーション[​](#サポートされるリソースとオペレーション "Direct link to サポートされるリソースとオペレーション")

ドライ・ランは、特定のFabric v4リソースとオペレーションで利用可能です。

| **Domain / Resource** | **API Endpoint**           | **Supported Operations** |
| --------------------- | -------------------------- | ------------------------ |
| Cloud Routers         | `/fabric/v4/routers`       | Create                   |
| Connections           | `/fabric/v4/connections`   | Create, Update           |
| Networks              | `/fabric/v4/networks`      | Create                   |
| Ports                 | `/fabric/v4/ports`         | Create, Update, Delete   |
| Service Tokens        | `/fabric/v4/serviceTokens` | Create, Update           |

他のすべてのエンドポイントと操作では、`dryRun=true`を含む呼び出しは標準のプロダクションリクエストのように動作します。

## ドライランレスポンスの理解[​](#ドライランレスポンスの理解 "Direct link to ドライランレスポンスの理解")

ドライ・ランから返される応答は、本番の通話とほぼ同じように設計されていますが、いくつかの重要な違いがあります。

### 検証の成功[​](#検証の成功 "Direct link to 検証の成功")

リクエストがすべての検証チェックに合格すると、APIは\*\*`200 OK`\*\* を返します。

* **リソース識別子** - `uuid` や `href` などのフィールドは `null` または省略可能です。
* **注文番号** - 注文番号やその他の商業識別子は生成されません。
* **副作用** - リソースのプロビジョニング、変更、削除は行われません。

この応答を使用して、`dryRun=true`なしでライブリクエストを送信する前に、 ペイロードの構造、値、要求された状態遷移が受け入れられることを確認できます。

### 検証エラー[​](#検証エラー "Direct link to 検証エラー")

リクエストが検証に失敗した場合、APIは**本番の呼び出しが返すのと同じHTTPステータスコードとエラー構造** を返します（例えば、無効な入力に対して`400 Bad Request`）。

典型的な検証の失敗例

* **無効なロケーションデータ** - サポートされていない、またはスペルが間違っているメトロまたはIBXコード。
* **サポートされていないリソースの状態遷移** - `PROVISIONING` などの一時的な状態にあるリソースを変更または削除しようとしました。
* **満たされていない依存関係** - たとえば、アクティブな仮想接続やサービス・トークンがまだ関連付けられているポートを削除しようとした場合。

これらのエラーは、本番リソースに変更を加えないドライ・ラン中に返されます。

## ドライランとポートの使用[​](#ドライランとポートの使用 "Direct link to ドライランとポートの使用")

fabric/v4/ports\` エンドポイントは、Dry Run とともに使用すると、豊富な検証動作を公開します。

### ポートの作成[​](#ポートの作成 "Direct link to ポートの作成")

ポートのドライラン作成要求を送信する場合は、`POST /fabric/v4/ports?dryRun=true`操作を使用してください：

* APIは、要求されたメトロ、IBX、およびその他のロケーション属性を検証します。
* パッケージとインターフェースのプロパティ（`interfaceSpeed`、`bandwidth`、`encapsulation` など）は互換性と可用性をチェックします。
* 物理的なポートは予約されず、注文も作成されません。

::::note ポートの一括作成は、パブリックFabric APIではサポートされていません。各Dry Run作成リクエストは単一のPortを記述する必要があります。 ::::

### ポートの更新[​](#ポートの更新 "Direct link to ポートの更新")

PATCH /fabric/v4/ports/{uuid}?dryRun=true\` オペレーションを使用して、ポート構成の変更を適用する前に安全にテストしてください：

* ポートの記述的なプロパティ（例えば`name`）や、`encapsulation`のような設定属性の更新を検証することができます。
* APIは状態の規則を強制します。過渡的な状態（`PROVISIONING`など）にあるポートを更新しようとすると、エラーが返されます。ほとんどの更新では、ポートは通常 `ACTIVE` 状態でなければなりません。
* 例えば、ポートに既存の接続やサービスプロファイルがあり、その変更によって無効になってしまう場合は、`encapsulation`を変更することはできません。

ドライ・ラン中はポートに変更は適用されず、検証結果と関連するエラー・メッセージが表示されるだけです。

### ポートの削除[​](#ポートの削除 "Direct link to ポートの削除")

DELETE /fabric/v4/ports/{uuid}?dryRun=true\` オペレーションを使用して、削除要求が成功するかどうかを検証します：

* APIはポートが存在し、削除可能な状態（通常は`ACTIVE`）であることを確認します。
* APIは、アクティブな接続、サービス・トークン、その他の依存サービスがまだポートにバインドされていないことを保証します。

依存関係が検出された場合、ドライラン削除コールは、ポートを削除または変更せずに、ライブ削除要求が返すのと同じエラーを返します。

## ドライランの使用時期[​](#ドライランの使用時期 "Direct link to ドライランの使用時期")

これらのシナリオでは、ドライランの使用を検討してください：

* **新しい自動化を展開する前に** - 生成された API リクエストが構造的に正しく、Fabric のビジネスルールを尊重していることを検証します。
* **本番環境でテストする場合** - 実際のアカウント・データ（ポート、接続、ネットワーク、クラウド・ルーター、およびサービス・トークン）が意図した操作をサポートしていることを、実行前に確認してください。
* **トラブルシューティング用** - 失敗するシナリオを安全に再現し、どの検証ルールまたは依存関係が変更をブロックしているかを理解します。

ドライランが成功し、必要な調整が行われた後、`dryRun=true`を指定せずに同じリクエストを再送することで、実際の操作を実行することができます。