# Test en production (API Dry Run)

Equinix Fabric prend en charge une capacité Dry Run **API** directement dans l'environnement de production.<br />Dry Run vous permet de simuler en toute sécurité des appels API pris en charge pour vérifier les charges utiles des requêtes, la logique commerciale et la disponibilité des ressources **sans** provisionner d'infrastructure ni encourir de frais.

Utilisez Dry Run lorsque vous validez de nouvelles intégrations, testez des changements d'automatisation ou confirmez qu'une requête complexe aboutira avant de l'exécuter "pour de vrai".

## Comment fonctionne Dry Run[​](#comment-fonctionne-dry-run "Direct link to Comment fonctionne Dry Run")

La fonction Dry Run est activée en ajoutant un paramètre de requête tel que `dryRun=true` à une requête API prise en charge.

Lorsque le paramètre Dry Run est présent, la plateforme Fabric effectue uniquement la validation côté serveur \*\*\*\* , au lieu d'effectuer la transaction complète. Plus précisément, la plateforme

* **Validez les entrées** - Vérifiez que les champs obligatoires sont présents et correctement formatés, et que les valeurs telles que les métros, les codes IBX, la bande passante et les types de paquets sont valides.
* **Vérifiez la logique métier** - Effectuez des vérifications externes et internes, par exemple pour confirmer qu'un métro, un port ou un routeur en nuage est disponible pour l'opération demandée.
* **Sauter la persistance et le provisionnement** - Aucun enregistrement de base de données n'est créé, aucun ordre de travail n'est généré et aucune ressource physique ou logique n'est réservée, mise à jour ou supprimée.

Les contrôles d'authentification, d'autorisation et de quota sont toujours appliqués de la même manière qu'un appel en direct.

::::important Dry Run ne contourne aucune autorisation ou exigence de compte. Si votre appel de production est rejeté en raison de droits manquants ou d'un état de compte invalide, l'appel Dry Run sera également rejeté. ::::

## Ressources et opérations soutenues[​](#ressources-et-opérations-soutenues "Direct link to Ressources et opérations soutenues")

Le fonctionnement à sec est disponible pour des ressources et des opérations Fabric v4 spécifiques.

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

Pour tous les autres points de terminaison et opérations, les appels qui incluent `dryRun=true` se comportent comme des requêtes de production standard.

## Comprendre les réponses aux essais à sec[​](#comprendre-les-réponses-aux-essais-à-sec "Direct link to Comprendre les réponses aux essais à sec")

La réponse renvoyée par un Dry Run est conçue pour refléter fidèlement ce que vous verriez lors d'un appel de production en direct, avec quelques différences importantes.

### Validation réussie[​](#validation-réussie "Direct link to Validation réussie")

Si la demande passe tous les contrôles de validation, l'API renvoie **`200 OK`**.

* **Identificateurs de ressources** - Les champs tels que `uuid` ou `href` peuvent être `null` ou omis, car aucune ressource n'est réellement créée lors d'un Dry Run.
* **Numéros de commande** - Aucun numéro de commande ou autre identifiant commercial n'est généré.
* **Effets secondaires** - Il n'y a pas d'approvisionnement, de modification ou de suppression de ressources.

Vous pouvez utiliser cette réponse pour confirmer que la structure de votre charge utile, les valeurs et les transitions d'état demandées sont acceptables avant de soumettre une requête réelle sans `dryRun=true`.

### Erreurs de validation[​](#erreurs-de-validation "Direct link to Erreurs de validation")

Si la demande échoue à la validation, l'API renvoie les **mêmes codes d'état HTTP et structures d'erreur** qu'un appel de production en direct (par exemple, `400 Bad Request` pour une entrée non valide).

Les échecs de validation typiques sont les suivants :

* **Données de localisation non valides** - Un code Metro ou IBX non pris en charge ou mal orthographié.
* **Unsupported resource state transitions** - Tentative de modification ou de suppression d'une ressource qui est dans un état transitoire tel que `PROVISIONING`.
* **Dépendances non satisfaites** - Par exemple, vous essayez de supprimer un port auquel sont encore associés des connexions virtuelles ou des jetons de service actifs.

Ces erreurs sont renvoyées lors d'un essai à blanc sans modification des ressources de production.

## Utilisation de Dry Run avec Ports[​](#utilisation-de-dry-run-avec-ports "Direct link to Utilisation de Dry Run avec Ports")

Le point de terminaison `/fabric/v4/ports` expose un comportement de validation riche lorsqu'il est utilisé avec Dry Run.

### Créer des ports[​](#créer-des-ports "Direct link to Créer des ports")

Utilisez l'opération `POST /fabric/v4/ports?dryRun=true` lorsque vous soumettez une demande de création de Dry Run pour un Port :

* L'API valide les attributs Metro, IBX et autres attributs de localisation demandés.
* Les propriétés des paquets et des interfaces (telles que `interfaceSpeed`, `bandwidth`, et `encapsulation`) sont vérifiées pour la compatibilité et la disponibilité.
* Aucun port physique n'est réservé et aucune commande n'est créée.

::::note La création de ports en vrac n'est pas prise en charge par l'API Fabric publique. Chaque demande de création de Dry Run doit décrire un seul port. ::::

### Ports de mise à jour[​](#ports-de-mise-à-jour "Direct link to Ports de mise à jour")

Utilisez l'opération `PATCH /fabric/v4/ports/{uuid}?dryRun=true` pour tester en toute sécurité les changements de configuration du port avant de les appliquer :

* Vous pouvez valider les mises à jour des propriétés descriptives d'un Port (par exemple, `name`) ou des attributs de configuration tels que `encapsulation`.
* L'API applique des règles d'état : les tentatives de mise à jour d'un port qui est dans un état transitoire (tel que `PROVISIONING`) renverront une erreur. Le port doit généralement être dans un état "ACTIF" pour la plupart des mises à jour.
* Les règles de dépendance sont également appliquées : par exemple, vous ne pouvez pas changer `encapsulation` si le Port a des connexions existantes ou des Profils de Service qui seraient invalidés par le changement.

Aucune modification n'est appliquée au port lors d'une exécution à sec ; vous recevez uniquement le résultat de la validation et les éventuels messages d'erreur associés.

### Supprimer les ports[​](#supprimer-les-ports "Direct link to Supprimer les ports")

Utilisez l'opération `DELETE /fabric/v4/ports/{uuid}?dryRun=true` pour valider si une requête de suppression aboutirait :

* L'API vérifie que le port existe et qu'il est dans un état qui permet la suppression (typiquement `ACTIVE`).
* L'API garantit qu'aucune connexion active, qu'aucun jeton de service ou qu'aucun autre service dépendant n'est encore lié au port.

Si des dépendances sont détectées, l'appel de suppression Dry Run renvoie la même erreur qu'une demande de suppression en direct, sans supprimer ou modifier le port.

## Quand utiliser la marche à blanc ?[​](#quand-utiliser-la-marche-à-blanc- "Direct link to Quand utiliser la marche à blanc ?")

Envisagez d'utiliser Dry Run dans les scénarios suivants :

* **Avant de déployer une nouvelle automatisation** - Validez que les demandes d'API générées sont structurellement correctes et respectent les règles commerciales de Fabric.
* **Lors des tests en production** - Confirmez que les données réelles du compte (ports, connexions, réseaux, routeurs cloud et jetons de service) prennent en charge l'opération prévue avant de l'exécuter.
* **Pour le dépannage** - Reproduisez des scénarios d'échec en toute sécurité pour comprendre quelle règle de validation ou quelle dépendance bloque une modification.

Après un essai réussi et les ajustements nécessaires, vous pouvez renvoyer la même requête sans `dryRun=true` pour effectuer l'opération réelle.