Dans le cadre d’un projet mené pour un client, j’ai eu à mettre en place une intégration entre deux systèmes : un outil métier interne appelé Sirius et l’ERP Odoo. Les données à synchroniser venaient d’une base SQL Server, qui regroupait des infos bien structurées comme les clients, les produits, les factures, etc. Les volumes étaient assez importants — on parle de plusieurs centaines de milliers d’enregistrements — et la synchronisation devait se faire régulièrement pour garder les deux systèmes à jour.
Le but du projet était de synchroniser automatiquement les données de Sirius vers Odoo, en gérant tout le cycle de vie des données : création, mise à jour, suppression. Pour cela, on s’est appuyé sur les API XML-RPC d’Odoo, qui permettent d’interagir directement avec ses modèles de données.
Pour s’assurer qu’on n’envoie que ce qui a changé, on a mis en place un mécanisme de Capture de Changement de Données (ou CDC) côté SQL Server. Grâce à ça, on pouvait détecter avec précision les nouvelles données, les modifs et les suppressions à traiter, sans avoir à tout recharger à chaque fois.
C’est SnapLogic, une plateforme iPaaS, qui a servi à construire l’ensemble des flux. Je découvrais l’outil pour la première fois, et j’ai pu exploiter son interface visuelle ainsi que ses nombreux Snaps — des composants prêts à l’emploi — pour créer des pipelines capables d’extraire, transformer et envoyer les données vers Odoo. Ce projet a été une vraie immersion dans SnapLogic : j’y ai vu ses points forts, ses particularités, mais aussi les petites surprises auxquelles il faut faire attention quand on débute.
Dans cet article, je vous partage donc un retour d’expérience concret : mes premières impressions sur SnapLogic, les choix techniques, les problèmes rencontrés, et ce que j’ai appris pour mieux aborder ce type de projet à l’avenir.
Scinder ses pipelines pour mieux maîtriser l’exécution
Quand on construit un pipeline un peu complexe, il peut être tentant de tout faire en une seule fois. Pourtant, attention : si on insère des données dans une table puis qu’on l’utilise juste après dans le même pipeline (par exemple via une procédure stockée), des lenteurs extrêmes peuvent apparaître. En effet, SnapLogic lance en cascade les snaps sans attendre la fin du snap précédent qu’il soit en parallèle ou à la suite. Par conséquent, les données ne sont pas encore là quand on en a besoin et l’exécution de la procédure stockée en gardant est plus que ralentie. Pour éviter ce problème, il vaut mieux scinder le pipeline en deux : un pour l’insertion, un autre pour exploiter les données. Ainsi, on s’assure que tout est prêt avant de continuer et on évite des heures de debug inutiles. Cela pourrait sembler être une bonne pratique de code générale, cependant, sur Snaplogic il n’existe pas de snap qui permettent de « stopper » le traitement avant la fin de l’exécution d’une certaine partie. De ce fait on est obligé de séparer les traitements dépendants.
Exemple d’un flux scindé au maximum qui laisse place à un pipeline master pour l’orchestration:
1ere étape : vider les tables
2eme étape: Remplissage des tables temporaires
3eme étape: Exécution Procédure stockée
4eme étape : Pipeline Master
Quand les connecteurs SnapLogic montrent leurs limites
SnapLogic propose beaucoup de connecteurs prêts à l’emploi, ce qui simplifie l’intégration. Néanmoins, certains connecteurs ont des limites qui compliquent leur usage. Ces limites concernent souvent la taille des lots, les types de données acceptés, ou encore la performance (timeouts, quotas).
Voici quelques exemples courants, leurs limites et des solutions possibles :
Snap JDBC (bases relationnelles) : problèmes avec gros volumes, timeouts, ou SQL avancé.
Solution : segmenter les lots, gérer les transactions dans la base, optimiser les requêtes.Snap Salesforce : soumis aux quotas API, taille des lots limitée, problèmes avec mises à jour partielles.
Solution : planifier les appels, utiliser les batchs optimisés, privilégier les mises à jour complètes.Snap REST : pas toujours de retries automatiques, timeouts parfois courts, difficultés avec gros payloads.
Solution : implémenter les retries via scripts, fragmenter les grosses charges, ajuster les timeouts.Snap FTP / SFTP : limité en taille et nombre de fichiers, risques de timeouts et incompatibilités.
Solution : bien configurer les timeouts, tester la compatibilité serveur, fragmenter les transferts volumineux.Snap AWS S3 : gestion complexe des permissions, limites sur la taille des fichiers.
Solution : configurer les droits en amont, utiliser le multipart upload pour gros fichiers.
Ces limites ne sont pas toujours bien documentées. Ainsi, il faut souvent tester et ajuster les pipelines. Connaître ces restrictions dès le départ aide à concevoir des flux plus robustes et à anticiper les contournements.
Colonnes absentes : un piège méconnu
SnapLogic ignore complètement les colonnes vides dans certains documents. Contrairement à ce que l’on pourrait penser, il ne les traite pas comme des champs vides ou nuls, mais comme inexistantes. Cette spécificité peut poser problème lors de transformations ou exports, surtout si on attend une structure uniforme. Par conséquent, il est préférable d’initialiser les champs manquants avec une valeur par défaut, via un Mapper ou un script. De la même façon, si je réalise un ‘select’ sur une table vide, Snaplogic ne sortira même pas le nom des colonnes en sortie.
Se connecter à l’API Odoo via XML-RPC : la solution Python
SnapLogic facilite les intégrations avec APIs REST ou SOAP via ses Snaps dédiés. Cependant, l’API Odoo, qui utilise XML-RPC, est plus complexe à gérer, car SnapLogic ne propose pas de composant natif. Il faut donc construire manuellement les requêtes XML et parser les réponses, ce qui est fastidieux. Pour contourner ce problème, nous avons utilisé un Script Snap en Python, sans la bibliothèque xmlrpc.client qui n’est pas intégrée à toutes les versions SnapLogic. Ce script gère les appels, l’authentification et la réception des réponses.
Voici le code utilisé :
import requests
processed_data = []
def snaplogic_init():
return None
def snaplogic_process(input_doc):
global processed_data
processed_data.append(input_doc)
return None
def snaplogic_final():
ODOO_URL = "url_odoo"
DB_NAME = "db_name"
USERNAME = "adm"
PASSWORD = "mpd"
session = requests.Session()
auth_payload = {
"jsonrpc": "2.0",
"params": {
"db": DB_NAME,
"login": USERNAME,
"password": PASSWORD
}
}
auth_response = session.post(f"{ODOO_URL}/web/session/authenticate", json=auth_payload)
response_json = auth_response.json()
if auth_response.status_code == 200 and "result" in response_json:
session_cookie = session.cookies.get_dict()
response = session.post(f"{ODOO_URL}", json=processed_data)
return response.json()
Données en cache : un piège lors de la prévisualisation
Un piège fréquent lors du développement est le cache des prévisualisations. En effet, en mode « preview », SnapLogic garde souvent en mémoire les anciens résultats, surtout si on ne relance pas l’exécution complète. On peut alors voir des données obsolètes, ce qui complique le debug. Pour éviter cela, il faut vider le cache (un raccourci peu intuitif : Ctrl + bouton validation) ou lancer une exécution complète.
Déboguer dans SnapLogic : entre Snap rouge et montagnes de logs
Le débogage peut vite devenir complexe avec des pipelines nombreux et riches en traitements parallèles ou scripts. L’interface signale les Snaps en erreur, ce qui aide à localiser le problème, mais il faut souvent consulter les logs pour comprendre l’origine. Avec de gros volumes, isoler un cas précis est difficile et relancer tout le pipeline ralentit le processus. Pour être efficace, mieux vaut segmenter les pipelines en sous-parties simples et exploiter au maximum les outils de la plateforme.
L’intelligence artificielle, alliée précieuse… avec prudence
J’ai souvent fait appel à l’IA pour débloquer des situations ou obtenir des pistes sur SnapLogic. Elle est utile pour générer des exemples ou comprendre certains concepts. Toutefois, j’ai vite constaté ses limites, surtout dans un écosystème avec peu de communauté active. Les réponses restent parfois trop générales ou inexactes. Certains Snaps suggérés n’existent pas ou ne sont pas compatibles selon la version. J’ai donc appris à toujours recouper, tester, et adapter les propositions. L’IA reste un bon point de départ, mais rien ne remplace l’expérimentation et une connaissance fine de la plateforme.
Conclusion
SnapLogic facilite l’intégration entre systèmes grâce à une interface visuelle et des connecteurs prêts à l’emploi.
Accessible, oui — mais attention à ses subtilités.
Même sans composants parallèles, l’ordre d’exécution n’est pas toujours garanti. Par exemple, insérer des données puis les relire immédiatement peut provoquer des erreurs si l’insertion n’est pas encore terminée. Ce comportement surprend souvent, même dans un pipeline linéaire.
Les scripts (comme en Python) apportent souplesse et contrôle, mais demandent une vraie maîtrise. L’IA peut aider, mais ses suggestions doivent toujours être testées et validées.
Les bonnes pratiques classiques restent utiles, mais SnapLogic a ses propres règles. Le comprendre, c’est éviter les pièges et tirer le meilleur de sa flexibilité.
