Retour aux Insights

ACC + ESB/MDM/Snowflake : API REST/SOAP ou workflows techniques ?

Pierre Frin Mai 2026 10 min de lecture
Adobe Campaign Classic (ACC) API REST/SOAP Workflow technique ESB MDM Snowflake Data Warehouse FDA / FFDA ADOBE CAMPAIGN CLASSIC SYSTÈMES TIERS DATA PLATFORM

L'une des questions les plus récurrentes sur les projets ACC est celle du choix du pattern d'intégration : faut-il passer par l'API REST ou SOAP d'Adobe Campaign, ou construire des workflows techniques dédiés ? La réponse n'est pas universelle, elle dépend du contexte, du volume, de la latence attendue et de l'architecture existante.

Voici ce que j'ai appris en interconnectant ACC avec des ESB, des plateformes MDM et Snowflake sur des projets à fort volume.

Les deux patterns en bref

API REST / SOAP

  • Appels synchrones depuis un système tiers
  • Idéal pour les échanges unitaires temps réel
  • Contrôle côté appelant
  • Pas de dépendance au scheduler ACC
  • Traçabilité côté ESB/MDM

Workflow technique ACC

  • Orchestration native dans Campaign
  • Idéal pour les traitements batch planifiés
  • Accès direct aux tables internes
  • Logique métier centralisée dans ACC
  • Monitoring via le journal Campaign

Quand utiliser l'API REST/SOAP

L'API d'Adobe Campaign (REST depuis V7, SOAP historiquement) est le bon choix dans ces situations :

1. Déclenchement d'événements transactionnels

Si votre ESB doit déclencher une diffusion transactionnelle en temps réel, confirmation de commande, alerte, notification, l'API jssp/nms/interaction.jssp ou le Message Center sont les seules options cohérentes. Un workflow technique planifié toutes les N minutes introduit une latence incompatible avec ce besoin.

2. Alimentation de profils en temps réel depuis un MDM

Quand le MDM est la source de vérité sur les données client et que les mises à jour doivent être répercutées immédiatement dans Campaign, l'API REST en push depuis le MDM est le pattern le plus propre. Il évite la polling loop et garantit la cohérence des données.

3. Intégration pilotée par l'ESB

Si votre ESB (MuleSoft, IBM App Connect, WSO2…) est déjà le chef d'orchestre de vos flux d'intégration, il est logique de lui laisser la main. Il appelle ACC via API, gère les retry, les erreurs et la traçabilité. Campaign n'a pas besoin de savoir d'où vient la donnée.

💡 Bonne pratique : en V8, l'API REST s'appuie sur le moteur Snowflake en FFDA. Anticipez une latence de quelques centaines de ms supplémentaires par rapport à V7 sur des appels unitaires. Préférez le batching si le volume est élevé.

Quand utiliser les workflows techniques

Les workflows techniques restent le pattern de référence pour tout ce qui est batch, planifié ou intensif en données :

1. Chargements de données massifs depuis Snowflake

L'activité Chargement (SGBD) couplée à un compte externe Snowflake (FDA) permet d'importer des volumes importants de façon contrôlée, avec gestion des erreurs, reprise sur incident et log d'exécution natif Campaign. C'est bien plus robuste qu'un appel API en boucle.

2. Synchronisation MDM en batch

Quand la synchronisation n'a pas besoin d'être temps réel, recalcul de scores, mise à jour des préférences, consolidation des consentements, un workflow planifié nuit ou matin est largement suffisant et bien plus économe en ressources.

3. Orchestration de campagnes complexes

La logique métier qui mélange segmentation, enrichissement depuis des tables externes, filtres de pression et construction de populations cibles appartient naturellement au workflow Campaign. Y accéder par API serait artificiel et contre-productif.

Comparatif synthétique

CritèreAPI REST/SOAPWorkflow technique
LatenceTemps réelBatch / planifié
VolumeUnitaire à moyenTrès grand volume
Contrôle orchestrationCôté appelant (ESB)Natif Campaign
Monitoring / debugCôté ESB/MDMJournal Campaign natif
Gestion erreursRetry côté appelantReprise native Campaign
Complexité setupFaibleMoyenne à élevée
Compatibilité V8 FFDALatence augmentéeOptimisé nativement

Le pattern hybride : la réalité du terrain

Dans la pratique, les architectures que je rencontre utilisent les deux patterns en parallèle. L'ESB déclenche les événements temps réel via API, tandis que les synchronisations batch s'appuient sur des workflows techniques planifiés. Les deux coexistent et se complètent.

La règle que j'applique : si la latence est un critère, c'est l'API. Si le volume est un critère, c'est le workflow.

⚠️ Point de vigilance : en V8 avec FFDA, les workflows qui s'appuyaient sur des tables temporaires locales (wkf_) doivent être revus. Ces tables ne sont plus locales, elles sont dans Snowflake. Le comportement peut changer significativement sur des traitements intensifs.

Conclusion

Il n'existe pas de réponse universelle au choix entre API et workflow technique. Les deux ont leur place dans une architecture d'intégration ACC mature. L'essentiel est de définir clairement les cas d'usage, les contraintes de latence et de volume avant de choisir, et de documenter les choix d'architecture pour que l'équipe qui viendra après vous comprenne pourquoi.

Si vous êtes en train de concevoir ou de revoir votre architecture d'intégration Campaign, je suis disponible pour en discuter.

Pierre Frin
Fondateur Grokium · Expert Adobe Campaign Classic · 10 ans d'expérience
Formation en ligne

Aller plus loin avec Adobe Campaign Classic V8

8 modules, 24 leçons pour écrire du code fiable en production : queryDef, workflows JavaScript, JSSP, webApps, API et déploiement. Accès permanent, code complet commenté.

Découvrir la formation →

Un projet d'intégration Campaign à concevoir ?

Je peux vous aider à choisir le bon pattern et à concevoir une architecture robuste. Réponse sous 24h.

Parlons de votre projet →
Aller plus loin
Outils gratuits pour Adobe Campaign Formation Adobe Campaign Classic V8 Mes prestations CRM