Cirrus Shield CRM s’intègre avec Myddleware

Lorsqu’un de nos clients a souhaité intégrer son CRM Cirrus Shield avec les différentes applications qu’il utilisait, nous avions deux choix devant nous:

1. Soit on développait des intégrations point à point avec chacune des applications de notre client.
2. Soit on mettait en place un middleware.

Avec les expériences passées que nous avons vécues sur les déploiements d’outils de middleware, nous nous sommes d’abord dit qu’il vallait peut-être mieux développer des intégrations point à point avec chacune des applications de notre client.

L’avantage de cette approche (intégration point à point) est que nous contrôlerions cette intégration et que forcément lorsque le client aurait besoin d’une fonctionnalité il nous suffirait de l’implémenter plutôt que de devoir attendre que le fournisseur du middleware le fasse.

Mais nous avons souhaité nous donner une chance de mettre en place de bonnes pratiques d’intégration. A ce titre nous avons décidé de faire une analyse de survol de l’offre en middleware du marché.

Mais avant tout qu’est-ce qu’un middleware?

1- Qu’est-ce qu’un middleware?

Dans le contexte d’une architecture logicielle d’intégration, un middleware est un logiciel qui permet d’envoyer et de recevoir des messages informatiques entre différentes applications. En servant d’intermédiaire, le middleware permet aux développeurs de ne plus se soucier des différentes interfaces de communication de chacune des applications de leur système d’informations.

Les développeurs implémentent une seule intégration avec l’interface unique de leur middleware et celui-ci se charge de communiquer avec les autres applications.

2- Pourquoi avoir choisi le middleware ?

Pour notre client PME nous n’avons pas souhaité déployer de solution lourde et complexe et nous sommes donc orientés vers des solutions légères, agiles, et peu onéreuses. Exit donc les Dell Boomi et autres solutions telles que webMethods. Après une première recherche nous avions trouvé sur le marché les différentes solutions middleware suivantes qui pouvaient répondre à nos besoins:

En regardant les prix, notre choix s’est vite réduit à Zapier ou Myddleware. Compte-tenu du fait que nous ne souhaitions pas passer de temps à déployer un serveur et installer une solution, nous avons donc choisi de travailler avec Zapier.

Lorsque nous avons commencé à intégrer Zapier, nous nous sommes vites rendus compte que la quantité de connecteurs affichés par Zapier ne voulait en fait rien dire. En effet, nous avons appris par la pratique que la taille de l’écosystème d’un middleware n’est pas le seul critère et qu’il fallait prendre en considération, il fallait également étudier:

• Les actions offertes par chaque point d’intégration:
  • Quelles opérations sont permises parmi la Création, Lecture, Mise à jour, Supression sur les enregistrements.
  • Quels modules sont exposés par l’intégration.
• Les fonctionnalités propres au middleware telles que:
  • Limitiations sur le nombre d’appels / la quantité de données.
  • Quels outils de transformation des données.
  • Gestion des échecs de synchronisation avec la possibilité de relancer des items tombés en échec.
  • Gestion des files d’attente.
  • Synchronisation des données historiques.
  • Capacités de failover et de récupération après un plantage.

En creusant un peu, nous avons vite compris les limitations de Zapier. Non seulement les centaines de plugins étaient très pauvres en fonctionnalités (exemple type: possibilité de faire une lecture, mais pas de mise à jour, ou mises à jour limitées à certains modules et pas d’autres), mais en plus Zapier n’offrait pas la possibilité de faire d’import en masse de données historiques. L’import en masse des données historiques est pourtant la première étape lors du déploiement d’un projet.

Il ne restait donc plus dans la course que Myddleware. Nous avons donc décidé de contacter la société éditrice du logiciel et avons souscris à leur service de déploiement afin de ne pas avoir à installer le logiciel nous-même.

3- Retour d’expérience sur un projet intégrant 1 Million de données

Après quelques premiers tests, Myddleware s’est montré être une solution robuste et riche en fonctionnalités. Myddleware n’avait non seulement aucune des limitations de Zapier mais nous avons découvert que cette solution avait de nombreuses fonctionnalités qui en faisaient un outil idéal pour la migration et l’intégration de données entre les applications.

Ce sont pour ces raisons, et après mûre réflexion que nous avons choisi d’intégrer Cirrus Shield dans l’écosystème des applications intégrées à Myddleware.

Dorénavant quiconque souhaitera déployer une solution permettant d’intégrer Cirrus Shield au sein de son Système d’Information pourra utiliser Myddleware et son environnement visuel pour mettre en place des synchronisations entre les applications en quelques cliques.

De notre côté le projet pour lequel nous avons déployé Myddleware et Cirrus Shield CRM a été déployé en production avec réussite et sur des quantités de données avoisinant le million d’enregistrements.