SSJS dans Automation Studio : automatiser Salesforce Marketing Cloud

AMPscript fait des merveilles dans un e-mail, mais il montre vite ses limites dès qu’il faut orchestrer un traitement par lots, dialoguer avec une API externe ou enchaîner plusieurs Data Extensions dans une Automation. C’est là qu’intervient le Server-Side JavaScript (SSJS) dans Automation Studio. Bien utilisé, il transforme Salesforce Marketing Cloud en véritable moteur d’intégration : lecture et écriture massives, appels REST sortants, journalisation propre et logique conditionnelle complexe. Dans ce guide pratique, vous verrez comment structurer un Script Activity robuste, manipuler vos données avec la Core library, appeler une API tierce et sécuriser le tout — avec des exemples de code prêts à adapter.

Pourquoi choisir SSJS plutôt qu’AMPscript ?

AMPscript reste imbattable pour la personnalisation inline d’un message. Mais SSJS apporte trois choses qu’AMPscript ne sait pas faire élégamment : les structures de données (objets, tableaux, JSON natif), la gestion des erreurs via try/catch, et l’accès à des librairies serveur comme Platform, Core et WSProxy. Concrètement, dès qu’une tâche relève du back-office — synchroniser un référentiel produit, appeler un service de scoring, dédupliquer une liste de plusieurs milliers de lignes — SSJS est le bon outil.

La règle de décision est simple : si le traitement s’exécute au moment de l’envoi et concerne un abonné à la fois, restez sur AMPscript. S’il s’exécute en amont dans une Automation et concerne un volume, passez à SSJS.

Mettre en place un Script Activity

Dans Automation Studio, un Script Activity attend un bloc encadré par les balises script avec l’attribut runat="server". La première instruction charge toujours le framework Platform. Voici le squelette minimal que nous réutilisons sur tous nos projets :

<script runat="server">
  Platform.Load("Core", "1.1.1");
  try {
    var deName = "Produits_Staging";
    Write("Démarrage du script\n");
    // ... logique métier ...
  } catch (e) {
    Write("Erreur : " + Stringify(e));
  }
</script>

La fonction Write() envoie sa sortie dans le journal d’exécution de l’activité — indispensable pour déboguer. Pensez à toujours envelopper votre logique dans un try/catch : sans cela, une Automation peut échouer en silence et bloquer toute la chaîne.

Lire et écrire dans les Data Extensions

La Core library expose l’objet DataExtension, qui couvre la majorité des besoins CRUD. Pour récupérer des lignes selon un filtre :

var de = DataExtension.Init("Produits_Staging");
var rows = de.Rows.Lookup(["Statut"], ["A_traiter"]);

for (var i = 0; i < rows.length; i++) {
  var sku = rows[i].SKU;
  Write("Traitement du SKU : " + sku + "\n");
}

Pour insérer ou mettre à jour, Rows.Add et Rows.Update prennent un objet clé-valeur. La mise à jour s’appuie sur les champs de clé primaire de la Data Extension :

de.Rows.Add({ SKU: "REF-1042", Statut: "Importe", MajLe: Now() });

de.Rows.Update(
  { Statut: "Traite" },   // valeurs à écrire
  ["SKU"], ["REF-1042"]   // critère de ciblage
);

Passer à l’échelle avec WSProxy

La Core library est confortable, mais elle envoie une requête par opération. Pour des volumes importants, WSProxy permet des opérations en lot et une pagination maîtrisée :

var api = new Script.Util.WSProxy();
var data = api.retrieve("DataExtensionObject[Produits_Staging]",
  ["SKU", "Statut"],
  { Property: "Statut", SimpleOperator: "equals", Value: "A_traiter" }
);
Write("Lignes récupérées : " + data.Results.length);

Le vrai gain de SSJS n’est pas la syntaxe : c’est la capacité à traiter un volume de données en amont de l’envoi, là où AMPscript vous obligerait à des contorsions ligne par ligne. Réservez SSJS aux automatisations, gardez AMPscript pour le message.

Appeler une API REST externe

L’un des usages les plus puissants de SSJS : enrichir vos données depuis un service tiers — scoring, géocodage, vérification d’adresse. L’objet HTTP gère les requêtes sortantes. Exemple d’un appel POST authentifié :

var url = "https://api.exemple.com/v1/score";
var headers = ["Authorization: Bearer " + token,
               "Content-Type: application/json"];
var payload = Stringify({ email: "client@exemple.com" });

var resp = HTTP.Post(url, "application/json", payload, headers);

if (resp.StatusCode == 200) {
  var result = Platform.Function.ParseJSON(resp.Response[0]);
  Write("Score reçu : " + result.score);
} else {
  Write("Échec API, code : " + resp.StatusCode);
}

Ne stockez jamais un jeton d’API en clair dans le script. Conservez-le dans une Data Extension à accès restreint, ou mieux, récupérez-le dynamiquement via un endpoint d’authentification appelé en début de script.

Journaliser proprement les erreurs

En production, un script qui échoue sans trace est un script ingérable. La bonne pratique : écrire chaque erreur dans une Data Extension de log dédiée, avec horodatage et contexte. Vous obtenez ainsi un historique consultable sans ouvrir chaque journal d’Automation :

function logError(etape, message) {
  var logDE = DataExtension.Init("Journal_SSJS");
  logDE.Rows.Add({
    Date: Now(),
    Etape: etape,
    Message: String(message).substring(0, 4000)
  });
}

try {
  // ... logique ...
} catch (e) {
  logError("Enrichissement", Stringify(e));
}

Performance et sécurité : nos garde-fous

SSJS s’exécute dans un environnement contraint. Quelques règles que nous appliquons systématiquement : limitez les boucles imbriquées qui multiplient les appels Lookup ; préférez une seule requête WSProxy à mille requêtes Core ; bornez toujours vos volumes avec une clause de filtre côté serveur plutôt que de filtrer en JavaScript après coup. Côté sécurité, validez et tronquez toute donnée externe avant de l’écrire en base, et n’exposez jamais d’identifiants dans le code source de l’activité.

Enfin, testez vos scripts sur un sous-ensemble réduit avant de les lâcher sur l’intégralité d’une Data Extension. Un Script Activity mal calibré peut consommer votre fenêtre d’exécution et retarder l’ensemble de l’Automation.

À retenir

1. Le bon outil au bon moment. AMPscript pour la personnalisation à l’envoi, SSJS pour les traitements par lots en amont dans Automation Studio.

2. Toujours encadrer par try/catch. Une erreur non capturée fait échouer l’Automation en silence ; journalisez dans une Data Extension dédiée.

3. WSProxy pour le volume. Préférez les opérations en lot à des centaines d’appels Core unitaires pour préserver votre fenêtre d’exécution.

4. Sécurisez les appels externes. Jamais de jeton en clair, validez et tronquez les données tierces avant écriture.

5. Testez petit avant de déployer grand. Validez sur un échantillon avant d’exécuter sur l’ensemble de vos données.

Vous souhaitez industrialiser vos automatisations Salesforce Marketing Cloud ou faire auditer vos scripts existants ? Contactez l’équipe CGC-Agency pour en discuter.