Skip to main content

Tests de l'API de gestion des incidents

Ce guide fournit des approches de test spécifiques et des exemples pour l'API Equinix Trouble Ticket, en s'appuyant sur les principes généraux de test d'API.

Aperçu de l'API de gestion des incidents

L'API Trouble Ticket permet aux clients d'interagir par programmation avec le soutien Equinix, en créant des tickets de soutien pour les problèmes ayant un impact sur le service dans diverses catégories:

  • Problèmes de connexion croisée
  • Problèmes de connectivité réseau
  • Incidents énergétiques
  • préoccupations environnementales
  • pannes matérielles
  • Incidents de sécurité
  • Assistance aux services gérés

Types de problèmes liés aux billets d'incident

L'API de gestion des incidents prend en charge différentes catégories de problèmes, chacune ayant des codes de problèmes spécifiques:

Problem CategoryDescriptionExample Codes
Cross ConnectPhysical cable connection issuescc01, cc02, cc03
NetworkNetwork connectivity problemsnet01, net02
EnvironmentHVAC, cooling, environmental issuesenv01, env02, env03, env04
HardwareEquipment and hardware failureshdw01
PowerPower-related incidentspwr01, pwr02
SecuritySecurity access and badge issuessec01, sec02
Managed ServicesManaged service support requestsms01-ms13
SmartViewSmartView monitoring issuessv01-sv05

Flux de travail de test des billets d'incident

Avant de tester l'API de gestion des incidents, assurez-vous d'avoir:

  • Un compte développeur Equinix avec autorisations de gestion des incidents
  • Identifiants d'API valides (ID client et secret client)
  • Accès aux emplacements et cages IBX appropriés
  • Comprendre l'authentification API

Création d'un billet d'incident

import requests
import json
from datetime import datetime, timedelta

# Setup authentication
auth_url = "https://api.equinix.com/oauth2/v1/token"
auth_payload = {
"grant_type": "client_credentials",
"client_id": "YOUR_CLIENT_ID",
"client_secret": "YOUR_CLIENT_SECRET"
}

auth_response = requests.post(auth_url, data=auth_payload)
token = auth_response.json()["access_token"]

# Test creating a trouble ticket order
base_url = "https://api.equinix.com"
headers = {
"Authorization": f"Bearer {token}",
"Content-Type": "application/json"
}

# Example: Create a network connectivity trouble ticket
request_payload = {
"customerReferenceNumber": "TT-TEST-001",
"ibxLocation": {
"ibx": "CH1",
"cages": [
{
"cage": "CH1:05:000750",
"accountNumber": "12345",
"cabinets": [
"CH1:05:000750:01"
]
}
]
},
"serviceDetails": {
"incidentDateTime": (datetime.utcnow() - timedelta(hours=1)).isoformat() + "Z",
"problemCode": "net01", # Network connectivity issue
"additionalDetails": "TEST: Network connectivity issue - API testing"
},
"contacts": [
{
"contactType": "ORDERING",
"userName": "test_ordering_user"
},
{
"contactType": "NOTIFICATION",
"userName": "test_notification_user"
},
{
"contactType": "TECHNICAL",
"userName": "test_technical_user",
"workPhone": "555-0123",
"workPhonePrefToCall": "ANYTIME"
}
]
}

create_response = requests.post(
f"{base_url}/v1/orders/troubleticket",
headers=headers,
data=json.dumps(request_payload)
)

# Verify response
assert create_response.status_code == 201, f"Failed to create trouble ticket: {create_response.text}"
order_number = create_response.json()["OrderNumber"]

print(f"Successfully created trouble ticket order: {order_number}")

Validation du lieu et du type de problème lors des tests

# Test retrieving available locations
locations_response = requests.get(
f"{base_url}/v1/orders/troubleticket/locations",
headers=headers
)

assert locations_response.status_code == 200, f"Failed to retrieve locations: {locations_response.text}"
locations = locations_response.json()["locations"]

print(f"Available locations: {len(locations)}")

# Test retrieving problem types
types_response = requests.get(
f"{base_url}/v1/orders/troubleticket/types",
headers=headers
)

assert types_response.status_code == 200, f"Failed to retrieve problem types: {types_response.text}"
problem_types = types_response.json()["troubleTicketTypes"]

print(f"Available problem types: {len(problem_types)}")

Scénarios d'erreurs de test

Testez toujours la gestion des erreurs de votre implémentation d'API:

import requests
import json
from datetime import datetime, timedelta

# Setup authentication
auth_url = "https://api.equinix.com/oauth2/v1/token"
auth_payload = {
"grant_type": "client_credentials",
"client_id": "YOUR_CLIENT_ID",
"client_secret": "YOUR_CLIENT_SECRET"
}

auth_response = requests.post(auth_url, data=auth_payload)
token = auth_response.json()["access_token"]

# Prepare request
base_url = "https://api.equinix.com"
headers = {
"Authorization": f"Bearer {token}",
"Content-Type": "application/json"
}

# Test with invalid problem code
invalid_payload = {
"customerReferenceNumber": "TT-ERROR-TEST-001",
"ibxLocation": {
"ibx": "CH1",
"cages": [{"cage": "CH1:05:000750", "accountNumber": "12345"}]
},
"serviceDetails": {
"incidentDateTime": (datetime.utcnow() - timedelta(hours=1)).isoformat() + "Z",
"problemCode": "INVALID_CODE", # Invalid problem code
"additionalDetails": "TEST: Invalid problem code test"
},
"contacts": [
{"contactType": "ORDERING", "userName": "test_user"},
{"contactType": "NOTIFICATION", "userName": "test_user"}
]
}

error_response = requests.post(
f"{base_url}/v1/orders/troubleticket",
headers=headers,
data=json.dumps(invalid_payload)
)

# Verify error response
assert error_response.status_code == 400, f"Expected error but got: {error_response.status_code}"
error_data = error_response.json()
assert "errors" in error_data, "Error response format not as expected"

print("Successfully validated error handling for invalid problem code")
print(json.dumps(error_data, indent=2))

Meilleures pratiques pour les tests d'API de gestion des incidents

Remarque importante: L'API de gestion des tickets d'incident d'Equinix est un système de production qui crée de véritables billets d'assistance. Suivez toujours ces bonnes pratiques de test afin d'éviter toute surcharge de travail.

  1. Créer un compte de test dédié: Demandez un compte distinct pour les tests si possible.
  2. Utilisez des demandes de test clairement identifiées: Préfixez toujours les descriptions par « TEST: » pour aider le personnel de soutien à identifier les demandes de test.
  3. Utilisez des dates et des heures d'incident valides: assurez-vous que la date et l'heure de l'incident sont correctement formatées et ne sont pas dans le futur.
  4. Valider l'accès aux emplacements: Utilisez le point de terminaison des emplacements pour vérifier les emplacements IBX accessibles avant de créer des tickets.
  5. Testez avec des codes d'erreur valides: Validez toujours les codes d'erreur à l'aide du point de terminaison de type
  6. Veuillez inclure toutes vos coordonnées complètes: assurez-vous que tous les contacts requis (COMMANDE, AVIS) sont fournis.
  7. Nettoyage des ressources de test: Collaborez avec le soutien pour fermer immédiatement les tickets de test dès leur création.
  8. Test de gestion des erreurs: Vérifiez la bonne gestion des erreurs et les codes de réponse.

Considérations relatives à l'automatisation

Lors de la création d'une automatisation autour de l'API de gestion des incidents:

  • Mettre en œuvre une gestion des erreurs et des tentatives de nouvelle connexion appropriées en cas de défaillance de l'API.
  • Validation des champs obligatoires et des formats de données
  • Inclure la journalisation d'audit de toutes les activités de création de billets
  • S'assurer que les heures des incidents sont correctement consignées et formatées.
  • Vérifiez les informations relatives à l'emplacement et au code du problème avant de soumettre.
  • Envisagez la mise en place de flux d'approbation pour la création de tickets de production.
  • Veuillez inclure des coordonnées complètes pour une résolution plus rapide.

Ressources additionnelles

Cette page vous a-t-elle été utile ?