Liste de contrôle de mise en production

Utilisez cette liste de contrôle avant d'activer une intégration partenaire pour des installations en production.

Configuration de la Partner Console

• Votre profil de partenaire est complet.
• L'URL de votre logo, votre site web, votre catégorie et votre description sont exacts.
• Votre méthode de liaison des données est configurée : Direct Link ou Linking Identifier.
• La liaison des installations a été testée avec au moins une installation réelle.
• Le bon type de clé est utilisé :
  • Dryrun pour les tests d'écriture non destructifs.
  • Read-only pour une consommation des données en toute sécurité.
  • Live uniquement lorsque vous êtes prêt à modifier des données de production.

Authentification et gestion des clés

• Les clés secrètes sont stockées uniquement côté serveur.
• Les clés ne sont pas intégrées dans des applications côté client, des applications mobiles, des dépôts publics ou des tickets d'assistance.
• La rotation et la révocation des clés ont été testées.
• Votre équipe sait quelle clé est utilisée par chaque environnement.

Validation des données

• Les champs obligatoires sont présents pour chaque endpoint que vous appelez.
• Les identifiants d'installation correspondent à la méthode de liaison configurée.
• Les ID provenant de votre système sont stables et ne changent pas d'une synchronisation à l'autre.
• Les importations volumineuses sont divisées en lots respectant les limites documentées.
• Les éléments de lot en échec peuvent être identifiés et renvoyés.

Test des endpoints

Avant le lancement, testez chaque endpoint dont dépend votre intégration :

• Les organisations et les installations peuvent être lues.
• Les membres peuvent être enregistrés et mis à jour.
• Les formules d'abonnement, les zones d'accès et les heures d'accès se synchronisent correctement.
• Les enregistrements d'entrée sont acceptés et peuvent être rapprochés de votre système.
• Les instantanés de rapports utilisent la période de reporting et les indicateurs attendus.
• Les flux des contrôleurs de porte/portail sont testés sur du matériel réel, le cas échéant.

Préparation des Access Time Windows

Si l'intégration fournit des Access Time Windows :

• Les exemples absolus et hebdomadaires satisfont à la liste de contrôle de certification des producteurs.
• Les epochs sont des secondes Unix entières non entourées de guillemets ; les limites exactes [from, to) ont été testées.
• Les valeurs UTC par défaut, les fuseaux horaires IANA personnalisés de l'intégration et les changements d'heure d'été pertinents ont été vérifiés.
• Un flux de révisions par membre/source unique, durable et croissant coordonne les mises à jour incrémentielles, le rapprochement et les nouvelles tentatives.
• Les opérateurs comprennent les comportements en cas d'omission, de remplacement complet, d'idempotence, de conflit, d'obsolescence et de [] explicite.
• Chaque scope_key, y compris default, dispose d'une correspondance Performance Hub approuvée ; il a été vérifié que les clés inconnues entraînent un refus par défaut.
• La fréquence d'actualisation attendue de l'intégration, l'ancienneté maximale des sources, le comportement en cas de source obsolète et les alertes sont configurés.
• Il a été démontré qu'un échec de récupération en amont n'émet pas d'instantané vide ou partiel.
• La convergence du flux de staging, l'annulation/la révocation et les limites de début et de fin sur les portes physiques respectent les objectifs convenus.
• Les règles habituelles et les autorisations permanentes ont été vérifiées comme solutions de repli, et les plages ne peuvent pas contourner la désactivation d'un utilisateur, blockAllAccess, la maintenance ou le géorepérage.

Préparation du contrôle d'accès

Pour les intégrations de contrôle d'accès :

• Votre système prend la décision d'accès avant d'appeler Performance Hub.
• L'intégration gère device_offline, maintenance_mode_active et unlock_confirmation_timeout.
• Les opérateurs savent qu'un délai d'expiration signifie que le déverrouillage n'a pas été confirmé.
• Vos journaux stockent l'event_id et le command_id renvoyés.
• Vous disposez d'une procédure de repli manuelle pour le personnel de l'installation.

Gestion des erreurs et nouvelles tentatives

• Les réponses 400, 401, 403, 404, 409 et 422 sont remontées aux opérateurs ou aux équipes d'assistance au lieu d'être réessayées aveuglément.
• Les réponses 429, 500, 502, 503 et 504 utilisent une logique de nouvelles tentatives limitée avec backoff.
• Les échecs répétés déclenchent une alerte dans votre système.
• L'intégration n'abandonne jamais silencieusement les enregistrements en échec.

Observabilité

• Vos journaux incluent l'endpoint, l'horodatage, l'identifiant d'installation, l'ID de l'enregistrement source, le résultat de la requête et le corps de la réponse.
• Votre équipe d'assistance peut effectuer des recherches par ID de membre, ID d'installation, ID d'enregistrement d'entrée ou ID d'événement de déverrouillage.
• Vous disposez d'un moyen de rejouer ou de rapprocher les synchronisations en échec.

Lancement en production

• Performance Hub a confirmé votre accès en production.
• Au moins une installation en production a activé votre intégration.
• Votre clé de production est active.
• Vos contacts opérationnels et techniques sont à jour.
• Votre procédure d'assistance est documentée pour les clients.

Une fois ces vérifications terminées, votre intégration configurée apparaîtra dans l'annuaire des partenaires Performance Hub, au sein de la plateforme principale Performance Hub.