Essais en production (exécution à blanc de l'API)

Equinix Fabric prend en charge une fonctionnalité de test à blanc d'API directement dans l'environnement de production. Dry Run vous permet de simuler en toute sécurité les appels d'API pris en charge afin de vérifier les charges utiles des requêtes, la logique d'affaires et la disponibilité des ressources sans provisionner d'infrastructure ni encourir de frais.

Utilisez le mode simulation lorsque vous validez de nouvelles intégrations, testez des modifications d'automatisation ou confirmez qu'une requête complexe aboutira avant de l'exécuter « pour de vrai ».

Comment fonctionne un essai à blanc ?

Le mode d'exécution à blanc est activé 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 une validation côté serveur, au lieu de finaliser la transaction complète. Plus précisément, la plateforme effectue les opérations suivantes:

• Valider les entrées – Vérifiez que les champs obligatoires sont présents et correctement formatés, et que les valeurs telles que les zones métropolitaines, les codes IBX, la bande passante et les types de forfaits sont valides.
• Vérifier la logique d'affaires – Effectuer des vérifications externes et internes, par exemple en confirmant qu'un routeur Metro, Port ou Cloud est disponible pour l'opération demandée.
• Ignorer la persistance et l'approvisionnement – 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.

L’authentification, l’autorisation et les contrôles de quota sont toujours appliqués de la même manière que pour un appel en direct.

important

La simulation à blanc ne contourne aucune autorisation ni exigence de compte. Si votre appel de production est rejeté en raison d'autorisations manquantes ou d'un état de compte invalide, l'appel de simulation à blanc sera également rejeté.

Ressources et opérations prises en charge

Le mode Dry Run est disponible pour certaines ressources et opérations de 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

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 en mode simulation

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

Validation réussie

Si la requête réussit tous les contrôles de validation, l'API retourne 200 OK.

• Identifiants 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'une exécution à blanc.
• Numéros de commande – Aucun numéro de bon de commande ni autre identifiant commercial n'est généré.
• Effets secondaires – Aucune mise à disposition, modification ou suppression de ressources n'a lieu.

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

Erreurs de validation

Si la requête échoue à la validation, l'API retourne les mêmes codes d'état HTTP et structures d'erreur qu'un appel de production en direct renverrait (par exemple, 400 Bad Request pour une entrée invalide).

Les erreurs de validation typiques incluent:

• Données de localisation invalides – Code Metro ou IBX non pris en charge ou mal orthographié.
• Transitions d'état de ressource non prises en charge – Tentative de modification ou de suppression d'une ressource qui se trouve dans un état transitoire tel que PROVISIONING.
• Dépendances non satisfaites – Par exemple, tenter de supprimer un port auquel sont encore associées des connexions virtuelles ou des jetons de service actifs.

Ces erreurs sont retournées lors de l'exécution à blanc sans aucune modification des ressources de production.

Utilisation d'un essai à blanc avec les 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 requête de création à blanc pour un port:

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

La création de ports en masse n'est pas prise en charge par l'API Fabric publique. Chaque requête de création à blanc 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 modifications de configuration des ports 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: toute tentative de mise à jour d'un port dans un état transitoire (tel que PROVISIONING) renverra une erreur. Le port doit généralement être à l'état ACTIVE pour la plupart des mises à jour.
• Les règles de dépendance sont également appliquées: par exemple, vous ne pouvez pas modifier « encapsulation » si le port possède des connexions existantes ou des profils de service qui seraient invalidés par la modification.

Aucun changement n'est appliqué au port lors d'une exécution à blanc ; vous ne recevez que le résultat de la validation et tous les messages d'erreur associés.

Supprimer les ports

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

• L'API vérifie que le port existe et qu'il est dans un état permettant sa suppression (généralement ACTIVE).
• L'API garantit qu'aucune connexion active, aucun jeton de service ni aucun autre service dépendant n'est encore lié au port.

Si des dépendances sont détectées, l'appel de suppression à blanc renvoie la même erreur qu'une requête de suppression réelle, sans supprimer ni modifier le port.

Quand utiliser le mode d'essai à sec

Envisagez d'utiliser la simulation à blanc dans les scénarios suivants:

• Avant de déployer une nouvelle automatisation – Vérifiez que les requêtes API générées sont structurellement correctes et respectent les règles d'affaires de Fabric.
• Lors des tests en production – Vérifiez que les données réelles du compte (ports, connexions, réseaux, routeurs infonuagiques et jetons de service) prennent en charge l'opération prévue avant de l'exécuter.
• Pour le dépannage – Reproduisez les scénarios d'échec en toute sécurité afin de comprendre quelle règle de validation ou dépendance bloque une modification.

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