Si vous disposez d’un ensemble de tests d’intégration pour les tests d’API internes à l’aide d’Insomnia, vous pouvez télécharger vos collections de tests Insomnia sur Dotcom-Monitor pour les tests d’API à partir de 40+ emplacements dans le monde.

Dotcom-Monitor prend en charge diverses options, telles que l’alerte sur les erreurs qui se produisent lors de la surveillance, la spécification des emplacements de surveillance, ainsi que la configuration de votre planificateur de surveillance et de vos filtres, et la configuration de rapports sur les résultats de la surveillance. Avec des contrôles de surveillance programmés toutes les minutes à toutes les 3 heures, votre équipe bénéficiera d’un haut niveau de flexibilité dans la configuration de la surveillance.

Avant de commencer

Insomnia Demande de collections et de documents de conception


Avant de commencer la configuration de l’appareil, notez que Dotcom-Monitor prend en charge l’importation des collections de demandes Insomnia et des documents de conception. Cependant, il existe une différence dans la façon dont nous traitons les documents de conception importés et les collections de demandes
.


Pour
télécharger une collection ou un document Insomnia sur Dotcom-Monitor, assurez-vous d’exporter les données Insomnia vers un fichier JSON.

Lorsque vous téléchargez un document de conception Insomnia sur Dotcom-Monitor et exécutez un test de surveillance, nous exécutons uniquement la première suite de la liste des suites de tests. Toutes les autres suites de tests du document sont ignorées.

Lorsque vous téléchargez une collecte de demandes d’insomnie sur Dotcom-Monitor, nous exécutons la collecte et vérifions la réponse pour toute erreur de réseau et de code de réponse comme 404, 401, 500, etc.

Configuration d’un dispositif de surveillance de la collecte de l’insomnie

Pour un aperçu rapide de la façon de créer un dispositif de surveillance, veuillez lire l’article Création d’un dispositif de surveillance de la base de connaissances.

Si vous envisagez de configurer la surveillance pour un groupe de collections Insomnia, nous vous recommandons de définir une collection par appareil. Pour plus de détails, consultez l’article Limitations de Multi-Target de notre wiki.

Une demande HTTP dans la collection représente une tâche de surveillance distincte et sera facturée en fonction de votre colis. Voir aussi
le
approximatif Matrix de tarification pour la surveillance WebView Article de la Base de connaissances. pbail contact votre Dotcom-Moniteur Unccount (ccount) Executive avec quelconque questionne.

Si vous souhaitez que Dotcom-Monitor génère des alertes et envoie des notifications d’alerte
lorsqu’une condition définie par les tests n’est pas remplie ou que des erreurs réseau ont été détectées lors de l’exécution de la collecte
, assurez-vous de configurer les paramètres d’alerte de l’appareil.

Importation d’un document de collection et de conception d’insomnie

Cliquer importation et sélectionnez un fichier JSON avec une collection ou un document Insomnia à télécharger. Lla Script d’insomnie s’affichera dans le Demandes de recouvrement section.

Délai d’attente de la collection

Le délai d’attente de collecte, mesuré en secondes, détermine la durée pendant laquelle l’appareil doit attendre la fin des demandes et des tests d’insomnie avant de mettre fin à la tâche et de générer une erreur.

Préparer le script

Voir l’article Utilisation de Prepare Script .

Sécuriser les données dans les demandes

Consultez la procédure de protection des informations sensibles envoyées avec les demandes Insomnia dans l’article Sécuriser les données sensibles dans les demandes Insomnia avec Dotcom-Monitor .

Ignorer les erreurs réseau

Les erreurs réseau peuvent inclure des erreurs de résolution DNS, des délais d’attente/erreurs de connexion TCP ou des cas où le serveur termine ou réinitialise la connexion avec un code d’état de réponse 4xx ou 5xx (et aucune donnée). Par défaut, Dotcom-Monitor génère des erreurs et envoie des notifications d’alerte sur les erreurs réseau Insomnia qui se sont produites pendant l’exécution. Si les erreurs réseau ne sont pas votre préoccupation ou s’il s’agit d’un comportement système attendu, vous pouvez configurer votre appareil de surveillance Insomnia Collection pour filtrer ce type d’erreur.

Si l’option Ignorer les erreurs réseau est définie sur Oui, Dotcom-Monitor ne génère pas d’erreur en cas d’échec des demandes de la collection Insomnia et ne change pas l’état du périphérique en Alerte. Cependant, vous verrez des erreurs HTTP dans les rapports de session de surveillance. Dans ce scénario, la suite de tests de collection va être utilisée pour vérifier la validité de la réponse.

En règle générale, il est recommandé d’activer l’option Ignorer les erreurs réseau si vous souhaitez recevoir des résultats de surveillance entièrement basés sur les tests importés avec votre collection Insomnia.

Supposons que nous ayons un document Insomnia vérifiant le code d’erreur 401 en réponse à une saisie incorrecte des informations de connexion.

Si l’option Ignorer les erreurs réseau est définie sur Oui dans Dotcom-Monitor et que le code d’état de réponse non autorisé 401 est reçu dans la réponse, le système ignorera l’erreur et interprétera la vérification de surveillance comme réussie.

Si l’option Ignorer les erreurs réseau est définie sur Non pour le même périphérique de surveillance de la collecte d’insomnie, le système génère une erreur sur toutes les erreurs réseau reçues lors de l’exécution de la collecte, y compris la réponse 401 non autorisée . L’état de l’appareil sera défini sur Alerte.

Ignorer les codes d’erreur

Reportez-vous à la section Ignorer les erreurs de requête Web pour les services Web et la surveillance de l’infrastructure Internet

Surveillance des API basées sur OAuth 2.0

En général, un appel d’API de service à l’aide d’OAuth 2.0 comprend deux étapes exécutées de manière séquentielle : premièrement, l’obtention d’un jeton d’accès à l’API à l’aide du mécanisme d’authentification du jeton du porteur. Deuxièmement, utiliser le jeton de porteur attribué pour demander des données personnalisées au service.

Toutefois, en raison d’un problème d’insomnie non résolu lors de la récupération des jetons d’accès OAuth dans de nouveaux environnements, cette authentification basée sur des jetons échoue lors de l’importation dans Dotcom-Monitor. En d’autres termes, la deuxième requête perd sa référence au jeton porteur obtenu avec la première requête.

Pour contourner ce problème, un appel d’API qui nécessite un jeton de porteur peut être traité en une seule requête dans Insomnia.

Pour importer et surveiller votre collection Insomnia avec Dotcom-Monitor, évitez de demander un jeton d’authentification lors du premier appel d’API de votre collection. Au lieu de cela, configurez l’authentification directement dans votre demande de données à l’aide du type d’authentification OAuth 2.

 

De cette façon, la collection Insomnia sera importée et exécutée correctement dans Dotcom-Monitor.