07

Intégration Drupal à votre SI

Sources externes de données ou applications transactionnelles

Les projets digitaux sont aujourd'hui de plus en plus intégrés au coeur de votre entreprise et donc de votre système d'information. Nous avons une longue expérience d'intégration d'applications Drupal avec le reste de votre SI. Intégration Drupal avec votre ERP (SAP, MS Dynamics, AX, AS-400, etc...) ou bien avec votre PIM, CRM ou DAM. Mais aussi des intégrations sur-mesure avec des architectures SOA / micro-services, intégration de vos ESB/ETL (Talend, BizTalk, Apigee, MuleSoft) ou applications métiers réalisés sur mesure. L'intégration peut aussi vouloir dire, des imports ou exports massifs de contenus (> 5.000.000 items), des transactions critiques et hautement disponibles.

Quelles sont les différentes typologies d'intégration Drupal ?

Globalement nous constatons 3 principaux types d'intégrations : l'import, l'export et les intégrations transactionnelles. L'import concerne principalement la synchronisation d'objets métier de type client, catalogue produit (fiches produits, référentiels, prix, stocks), documents (contrats, factures, bons de livraisons, commandes, etc...). L'import des données dans Drupal s'appuie sur le module Migrate API, se fait de manière généralement asynchrone par échange de fichiers (XML, CSV, JSON). L'export de données est souvent lié à l'alimentation d'ERP ou d'outil de business intelligence avec les données collectées ou générées par Drupal. On peut alors utiliser une palette de procédés : créer un module sur mesure, s'appuyer sur le module Views Data Export ou le module Services. Enfin, l'intégration transactionnelle la plus complexe, puisque nécessite d'écrire des modules sur mesure intégrés avec le coeur de Drupal, les modules communautaires et vos données structurées. Ce type d'intégration repose sur le développement de modules sur mesure, nécessite la mise en place de tests unitaires complets et d'un contrat d'interface clairement établi avec l'outil à intégrer. Ce type d'intégrations transactionnelles concerne souvent les site e-commerce (verification de stocks, création de commandes, paiement) ou les applications métiers.

Les principaux points d'attention lors de vos intégrations

 

Choisir le bon type d'intégration

Exemple : si vous choisissez de synchroniser les commandes e-commerce passées sur votre site de manière asynchrone et par des fichiers, vous courrez le risque d'accepter une commande alors que votre ERP la refusera (indisponibilité du produit, erreur dans le fichier de commande, adresse de livraison non vérifiée et pas au bon format, etc..). Vous aurez alors beaucoup d'appel au service client, des consommateurs insatisfaits et des couts cachés nombreux. Pour choisir la bonne manière d'intégrer il faut considérer de nombreux paramètres : volumétrie des données, la fréquence de la synchronisation, l'importance du temps-réel, le cout des erreurs, le niveau de service attendu en termes de qualité et de performance.

Volumétrie

Quand la volumétrie est faible (< 100 objets métier ou lignes) l'intégration via des API de type JSON / GraphQL ou SOAP reste la plus intéressante : simple à analyser, facile à décrire et avec un format standard auto-explicite, il faudra la préférer aux échanges de fichiers. Au-delà, l'échange par fichiers reste l'approche la plus efficace en termes de performances et de reprise sur erreur. Il est possible de transférer le fichier en local, le découper en plusieurs morceaux et organiser le traitement par batchs. Enfin, si la volumétrie des données dépasse plusieurs millions de lignes avec une fréquence élevée (< 24h) il faut analyser la nécessité même de la synchronisation. Il serait alors probablement préférable de faire évoluer l'outil source pour qu'il puisse servir directement la donnée via une API plutôt que d'envisager une synchronisation avec Drupal.

Fréquence

Plus la fréquence de vos intégration est élevée plus on tend vers une intégration par des web-services transactionnels, plutôt qu'une intégration asynchrone par fichiers. De manière empirique nous considérons que tout échange arrivant plusieurs fois en 24h devrait, en priorité, être intégré sous forme de web-services transactionnels sans synchronisation de données. 

Cohérence des données

Est-ce qu'il est acceptable de montrer à vos visiteurs des données qui ont quelques heures ou jours de fraicheur ? Prenons un exemple. Lorsque votre visiteur se balade sur votre site e-commerce et qu'il choisit d'ajouter un produit au panier, il serait totalement inacceptable qu'au moment de payer la commande le prix changeait. Il serait très frustrant que le produit qu'il croyait en stock ne le soit pas en réalité et qu'il le découvre au moment de passer commande, pis après avoir passé commande. Enfin ce n'est pas dramatique si le descriptif du produit en question ait quelques faute d'orthographes, corrigés dans la dernière version sur votre PIM, corrections qui ne seraient pas encore arrivées au moment de l'achat. Plus vos données doivent être fraîches, plus fréquente doit être votre synchronisation jusqu'à passer en mode web-service à la source pour certaines typologies de données (stocks, prix, commandes). 

 

 

Nos services

Intégration Hybris / Demandware / Magento

Intégration CRM - Salesforce, Microsoft Dynamics, SugarCRM

Intégration DAM (digital asset management)

Intégration ERP

Mise en place plan de taggage & analytics

Intégration GED - Alfresco, Office365

Mise en place SOLR, Elastic Search, Algolia

Intégration Social Media

Intégration et mise en place ESB