Test en production (API Dry Run)

Equinix Fabric prend en charge une capacité Dry Run API directement dans l'environnement de production.
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

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

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

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

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

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

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

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

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

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 ?

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.