Commencez par définir l’événement métier que l’intégration doit traiter. Identifiez l’action nécessaire du système destinataire et la source faisant foi lorsque les données divergent.
Rédigez le contrat d’interface autour de l’événement
| Élément du contrat | Question à résoudre |
|---|---|
| Déclencheur | Que s’est-il passé et quel système l’a confirmé ? |
| Identité | Quels identifiants de compte et d’événement restent stables entre systèmes ? |
| Contenu du message | Quels champs sont requis, facultatifs ou sensibles ? |
| Accusé de réception | Quelle réponse prouve la réception ou l’achèvement ? |
| Défaillance | Quelles actions sont réessayées, attendent, s’arrêtent ou nécessitent un examen ? |
| Correction | Comment un changement ultérieur se réfère-t-il à l’événement initial ? |
Par exemple, une décision de vérification nécessite plus qu’une étiquette copiée dans une autre base. Définissez sa date et heure d’effet, sa version et l’action autorisée par cet état. Limitez l’accès aux données à ce dont le processus destinataire a besoin.
Attribuez la responsabilité d’un état de transaction incertain
Lorsque le délai d’une requête expire, identifiez qui détermine si l’action a eu lieu. Une nouvelle tentative ne doit pas créer un doublon involontaire, et l’absence d’accusé de réception ne doit pas être considérée comme une preuve d’échec sans vérifier le contrat.
Précisez la supervision des événements retardés ou rejetés et l’équipe chargée de les résoudre. L’opérateur doit pouvoir distinguer des événements en attente de traitement par l’intégration d’une décision encore en attente d’examen humain.
Testez le changement autant que la connexion initiale
Utilisez un événement valide, un champ requis manquant, une demande en double, une correction reçue dans le désordre et une panne temporaire de la source. Comparez les données résultantes dans les deux systèmes. Conservez assez d’identifiants et d’informations d’état pour examiner chaque résultat.
Testez ensuite un changement de version ou l’ajout d’un champ facultatif selon les règles de compatibilité convenues. Définissez le responsable de mise en production, les critères de retour à la version précédente et le processus de notification des changements fournisseur. Une première connexion réussie n’est qu’une partie du cycle de vie d’une intégration.
Préparez un cahier des charges d’intégration utile
Fournissez les systèmes, la documentation disponible, des exemples d’événements et le processus à améliorer. Incluez l’état d’échec que votre équipe ne peut pas expliquer aujourd’hui. Pour remplacer le système central de comptes, évaluez aussi le périmètre PAM et les travaux de migration.
Demandez un examen d’interface avec ces éléments. La proposition doit nommer les livrables, les dépendances et les preuves de recette.