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.
L'API d'Adobe Campaign (REST depuis V7, SOAP historiquement) est le bon choix dans ces situations :
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.
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.
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é.
Les workflows techniques restent le pattern de référence pour tout ce qui est batch, planifié ou intensif en données :
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.
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.
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.
| Critère | API REST/SOAP | Workflow technique |
|---|---|---|
| Latence | Temps réel | Batch / planifié |
| Volume | Unitaire à moyen | Très grand volume |
| Contrôle orchestration | Côté appelant (ESB) | Natif Campaign |
| Monitoring / debug | Côté ESB/MDM | Journal Campaign natif |
| Gestion erreurs | Retry côté appelant | Reprise native Campaign |
| Complexité setup | Faible | Moyenne à élevée |
| Compatibilité V8 FFDA | Latence augmentée | Optimisé nativement |
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.
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.
One of the most recurring questions on ACC projects concerns the choice of integration pattern: should you use Adobe Campaign's REST or SOAP API, or build dedicated technical workflows? The answer isn't universal — it depends on context, volume, expected latency and existing architecture.
Here's what I've learned from connecting ACC with ESBs, MDM platforms and Snowflake on high-volume projects.
Adobe Campaign's API (REST since V7, historically SOAP) is the right choice in these situations:
If your ESB needs to trigger a transactional delivery in real time — order confirmation, alert, notification — the jssp/nms/interaction.jssp API or Message Center are the only coherent options. A technical workflow scheduled every N minutes introduces latency incompatible with this requirement.
When the MDM is the source of truth on customer data and updates must be reflected immediately in Campaign, a REST API push from the MDM is the cleanest pattern. It avoids polling loops and guarantees data consistency.
If your ESB (MuleSoft, IBM App Connect, WSO2…) is already the orchestrator of your integration flows, it makes sense to let it keep control. It calls ACC via API, handles retries, errors and traceability. Campaign doesn't need to know where the data comes from.
💡 Best practice: in V8, the REST API relies on the Snowflake engine in FFDA mode. Anticipate a few hundred ms of additional latency compared to V7 on unit calls. Prefer batching if volume is high.
Technical workflows remain the reference pattern for anything batch, scheduled or data-intensive:
The Database loading activity coupled with a Snowflake external account (FDA) allows importing large volumes in a controlled manner, with error handling, incident recovery and native Campaign execution logs. Far more robust than a looped API call.
When synchronisation doesn't need to be real-time — score recalculation, preference updates, consent consolidation — a nightly or morning scheduled workflow is more than sufficient and far more resource-efficient.
Business logic mixing segmentation, enrichment from external tables, pressure filters and target population building naturally belongs in Campaign workflows. Accessing it via API would be artificial and counterproductive.
| Criterion | REST/SOAP API | Technical workflow |
|---|---|---|
| Latency | Real-time | Batch / scheduled |
| Volume | Unit to medium | Very high volume |
| Orchestration control | Caller side (ESB) | Native Campaign |
| Monitoring / debug | ESB/MDM side | Native Campaign journal |
| Error handling | Retry on caller side | Native Campaign recovery |
| Setup complexity | Low | Medium to high |
| V8 FFDA compatibility | Increased latency | Natively optimised |
In practice, the architectures I encounter use both patterns in parallel. The ESB triggers real-time events via API, while batch synchronisations rely on scheduled technical workflows. Both coexist and complement each other.
The rule I apply: if latency is a constraint, use the API. If volume is a constraint, use the workflow.
⚠️ Watch out: in V8 with FFDA, workflows relying on local temporary tables (wkf_) must be revised. These tables are no longer local — they're in Snowflake. Behaviour can change significantly on intensive processing.
There is no universal answer to the choice between API and technical workflow. Both have their place in a mature ACC integration architecture. The key is to clearly define use cases, latency and volume constraints before choosing — and to document architectural decisions so the team that comes after you understands the rationale.
If you're designing or revising your Campaign integration architecture, I'm available to discuss it.
Je peux vous aider à choisir le bon pattern et à concevoir une architecture robuste. Réponse sous 24h.I can help you choose the right pattern and design a robust architecture. Reply within 24 hours.
Parlons de votre projet →Let's talk →