Démo : Mise en place d'un socle ESB
Comment mettre en place un (rapide) socle ESB pour synchroniser des applis Cloud d'un SI ?
On a interviewé Damien Albagnac, un architecte Data indépendant.
Dans cet article on va revoir ensemble la démo qui a été présentée.
Contexte client
Pour un client, SIBLU, on a besoin de faire synchroniser automatiquement leurs applications utilisées en interne.
Sachant que les 2 applis sont en SAAS, avec 2 éditeurs différents.
Au trimestre 1, on veut faire dialoguer mon CRM et mon ERP : Si un devis est validé dans le CRM par un commercial, on veut que l'information soit synchronisé dans l'ERP.
Ensuite au trimestre 3, on veut en plus faire la maj du call center.
Si un devis est validé dans le CRM par un commercial, on veut que l'information soit synchronisé dans l'ERP. Si non, au call center, pour relance du prospect.
Et bien sûr, on veut éviter de faire ce que fait la majorité des équipes... qui doivent faire vite car demande urgente etc.
De développer un job indépendant du job du 1er trimestre, qui va à nouveau partir du CRM.
Se faisant on sur-sollicite le CRM, et on l'a vu, les appels API coûtent chers à la longue.
Architecture cible
Pour éviter de développer des jobs qui vont du CRM vers l'ERP, on va créer des demi-pivots (vu ici).
Et ainsi alimenter notre bus de données, le broker de messages (vu ici).
On aura ainsi 3 demi-pivots :
- l'alimentation du broker par le CRM
- l'alimentation de l'ERP depuis le broker
- l'alimentation du call center depuis le broker
Et si on veut ajouter d'autres cibles, on pourra en créer autant qu'on le souhaite. Sans toutefois solliciter davantage le CRM.
Alimentation du broker de messages
On va créer un object Contact dans le broker de messages (ActiveMQ dans ce cas présent), qui sera alimenté pour appels API du CRM
Besoin asynchrone
Si du temps réel n'est pas nécessaire (on a vu ici la pertinence du temps réel), on peut développer un job.
Qu'on pourra exécuter à des intervalles souhaites (en minutes, en heures etc).
Dans la démo on a choisi cette solution pour l'alimentation de l'ERP depuis notre broker de message.
Besoin temps réel
Pour du temps réel, on a créé une route (ou médiation).
Attention : une route et un job n'ont rien à voir, savoir faire de l'ETL ne veut absolument pas dire qu'on sait faire des routes sous Talend.
Comme c'est du temps réel, le job ne s'arrête pas. C'est donc coûteux.
Il est donc important de tout optimiser : mémoire, durée de traitement, le traitement en lui même.
À PROPOS
Le collectif de freelances experts en intégration de données.
Créé avec © systeme.io
