Intégrer sans API source : préparer un transfert CSV
Un export peut aider lorsque l’API source nécessaire manque. Un exemple précise format, correspondance des projets, répétition et confirmation.
Choisir un mode de transfert disponible
Vérifiez d’abord si les données nécessaires sont accessibles par un export pris en charge. Le middleware, logiciel intermédiaire entre les systèmes, traite ces entrées ; il ne crée pas un accès que la source ne propose pas.
Entrée disponible | Capacité de la cible | Transfert possible |
|---|---|---|
Fichier d’export structuré | Import de fichier adapté | Produire un fichier d’import contrôlé |
Fichier d’export structuré | API adaptée | Contrôler et faire correspondre les données, puis transférer par API |
Interface utilisateur seule | Écran de saisie adapté | Évaluer séparément le parcours à l’écran |
La dernière option exige de reconnaître de façon fiable les éléments manipulés et le résultat. Microsoft décrit pour cela les sélecteurs d’interface. Après une modification de l’interface, leur adéquation doit être vérifiée ; une suite de clics enregistrée ne prouve pas seule que les données ont été reçues.
Consigner un contrat de fichier détaillé
Une entreprise de logiciels fictive choisit la deuxième option. Son ancien outil de suivi du temps n’offre aucune API pour les temps approuvés, mais permet un export quotidien. Un traitement intermédiaire doit en tirer une ligne à ajouter à un brouillon de facturation dans l’ERP. Pour notre propre exemple, l’accord prévoit UTF-8, la virgule comme séparateur et cet en-tête :
entryId,projectRef,approvedMinutes,approvalState
T-81,PR-42,90,approvedLa ligne signifie que l’enregistrement source stable T-81 contient du temps de travail approuvé en minutes pour le projet PR-42. Celui-ci est explicitement rattaché au projet ERP ERP-903. Seules les lignes approuvées peuvent poursuivre le parcours. Champs et identifiants sont notre conception, pas un schéma Odoo ou d’un autre fournisseur. RFC 4180 décrit des conventions CSV ; le contrat d’import concret doit correspondre au produit. La documentation Odoo illustre, par exemple, l’usage d’identifiants externes dans les imports et les relations.
Séparer résultats confirmés et résultats incertains
Pour un transfert confirmé, le traitement intermédiaire doit relier l’enregistrement source à la référence cible. Une ligne inchangée dont la réception a déjà été confirmée ne doit pas créer une autre ligne de brouillon. Si cet enregistrement change ensuite, il s’agit d’une correction métier ; notre conception la met en attente de clarification.
Si la connexion s’interrompt après l’envoi, la cible peut déjà avoir écrit les données. Avant de réessayer, il faut établir l’état au moyen d’une référence cible adaptée. Si la cible ne permet pas cette vérification, l’opération reste incertaine et doit être traitée. Le transport réussi du fichier ne confirme pas seul une écriture ERP.
Convenir des résultats attendus avant la réalisation
Ces cas seraient à valider dans un environnement de test adapté :
La première ligne approuvée crée une ligne de brouillon de
90minutes dans le projet associé.Une répétition identique après confirmation du succès ne crée aucune ligne supplémentaire.
Une référence de projet inconnue reste ouverte avec un motif de clarification.
Le même enregistrement avec
120minutes est retenu comme correction, sans remplacer silencieusement la valeur confirmée.
Dans cet exemple, l’équipe accepte un traitement quotidien à 18:00, dans le fuseau Europe/Berlin, pour des brouillons de facturation ultérieurs. Si des valeurs à jour sont nécessaires en cours de journée, le transfert doit être réévalué. Responsabilité de l’export, traitement des erreurs et retour d’information font donc partie de l’accord.
Sources
À lire aussi
Tous les articles
Interfaces & intégration avec ASES
ERP, CRM et boutique bien connectés