# Adobe Campaign

## Adobe Campaign (Classic)

Les workflows Adobe Campaign peuvent déclencher des appels à l’API The Wallet Crew. Cela permet des mises à jour automatisées des cartes pendant une campagne. Les mises à jour typiques incluent l’ajout d’une offre, la mise à jour des données de fidélité ou l’écriture d’un message de campagne dans `additionalData`.

<details>

<summary>Exemples concrets</summary>

* Une marque de distribution ajoute un message personnalisé à une carte du segment VIP, juste après l’envoi.
* Un organisateur de spectacle met à jour un billet Wallet avec un changement de porte de dernière minute.
* Un fournisseur de billetterie écrit un `campaignId` dans `additionalData` pour mesurer les conversions Wallet.

</details>

### Prérequis

L’accès à une clé API disposant de l’autorisation de mettre à jour les cartes est requis. Un identifiant stable doit également exister dans Adobe Campaign et correspondre à l’identifiant utilisé pour rechercher des cartes dans The Wallet Crew (par exemple, un ID client).

{% hint style="info" %}
L’hôte et le chemin de l’API dépendent de l’environnement (QA vs production) et de la configuration du projet The Wallet Crew. Les valeurs d’URL d’exemple doivent être remplacées par celles fournies par The Wallet Crew.
{% endhint %}

### Vue d’ensemble de la requête API

L’API de mise à jour des cartes de The Wallet Crew est appelée avec `PATCH`. L’exemple ci-dessous filtre les cartes à l’aide d’un identifiant spécifique au projet (`id.y2.customerId`) et met à jour `additionalData`.

{% code title="Exemple de requête PATCH" %}

```bash
curl -X 'PATCH' \\
  'https://app-qa.neostore.cloud/api/xxxxx/passes?id.y2.customerId=00100000207298' \\
  -H 'accept: */*' \\
  -H 'X-API-KEY: xyz' \\
  -H 'Content-Type: application/json' \\
  -d '{
        "additionalData": {
          "adobe_message": "Offre exclusive : venez nous rendre visite."
        }
      }'
```

{% endcode %}

### Conception du workflow Adobe Campaign

La configuration la plus sûre sépare la sélection de l’exécution. La sélection définit *qui* doit être mise à jour. L’exécution définit *ce qui* doit être écrit dans la carte.

{% stepper %}
{% step %}

#### Sélectionner l’audience

Une activité de requête sélectionne la population cible. La transition sortante doit contenir l’identifiant qui correspond à la clé de recherche de carte The Wallet Crew (exemple : `customerId`).
{% endstep %}

{% step %}

#### Itérer sur les enregistrements

Un modèle de workflow peut traiter un enregistrement à la fois ou de petits lots, selon le volume attendu. Cela réduit le rayon d’impact en cas d’erreurs API.
{% endstep %}

{% step %}

#### Appeler l’API The Wallet Crew

La `PATCH /cartes` est appelé pour chaque identifiant. La charge utile doit rester minimale et n’écrire que les champs qui doivent changer (exemple : `additionalData.adobe_message`).
{% endstep %}

{% step %}

#### Journaliser et gérer les erreurs

Les journaux du workflow doivent stocker le code d’état HTTP et le corps de la réponse. Un chemin d’erreur explicite pour les réponses hors 2xx est recommandé (nouvelle tentative, mise en quarantaine ou revue manuelle), selon la criticité de la campagne.
{% endstep %}

{% step %}

#### Valider les résultats

La validation commence généralement par un petit segment de test. Les champs attendus peuvent ensuite être confirmés sur un échantillon de cartes dans The Wallet Crew.
{% endstep %}
{% endstepper %}

### Exemple d’implémentation (activité JavaScript)

Cette section fournit un exemple pour une Adobe Campaign Classic **activité JavaScript** qui met à jour les cartes dans The Wallet Crew pour une population sélectionnée.

{% hint style="warning" %}
À confirmer : les API exactes disponibles dans les activités JavaScript varient selon la version d’Adobe Campaign et le modèle d’hébergement. L’extrait ci-dessous est un exemple d’implémentation et peut nécessiter des adaptations pour l’instance (méthode de requête, client HTTP, stockage des identifiants).
{% endhint %}

{% code title="Exemple d’activité JavaScript (illustratif)" %}

```javascript
// Configuration de l’API The Wallet Crew
var apiUrl = "https://app-qa.neostore.cloud/api/xxxxx/passes";
var apiKey = "xyz"; // Les clés API doivent être stockées comme des secrets, pas codées en dur.

// Récupérer la liste des clients depuis le contexte du workflow (adapter au modèle de données de l’instance)
var query = xtk.queryDef.create();
query.select("customerId")        // Champ identifiant utilisé pour trouver les cartes
     .from("customerTable");      // Table source
var customers = query.executeQuery();

for (var i = 0; i < customers.length; i++) {
  var customerId = customers[i].customerId;

  // Construire l’URL du point de terminaison API
  var url = apiUrl + "?id.y2.customerId=" + encodeURIComponent(customerId);

  // Définir la charge utile pour la requête API
  var payload = {
    additionalData: {
      adobe_message: "Offre exclusive : venez nous rendre visite."
    }
  };

  try {
    // Exécuter l’appel API (adapter le client HTTP aux capacités de l’instance)
    var response = http.request({
      method: "PATCH",
      url: url,
      headers: {
        "X-API-KEY": apiKey,
        "Content-Type": "application/json",
        "accept": "*/*"
      },
      body: JSON.stringify(payload)
    });

    logInfo("ID client " + customerId + " : mise à jour OK. Statut : " + response.statusCode);
  } catch (error) {
    logError("ID client " + customerId + " : mise à jour échouée. Erreur : " + error.message);
  }
}
```

{% endcode %}

### Bonnes pratiques

Les tests dans un environnement de non-production réduisent le risque. La gestion des erreurs doit être explicite, car les échecs d’API peuvent être transitoires. Si une limitation de débit est activée sur le projet, le throttling ou le traitement par lots aide à éviter les réponses 429. Les clés API doivent être considérées comme des secrets et stockées à l’aide des options sécurisées d’Adobe Campaign, lorsqu’elles sont disponibles.

### FAQ

<details>

<summary>Quel identifiant doit être utilisé dans le filtre de l’API ?</summary>

L’identifiant doit correspondre à ce qui a été configuré dans le projet The Wallet Crew pour la recherche de cartes. Les identifiants courants incluent un ID client, un ID de fidélité ou un ID utilisateur externe. Le nom du paramètre de requête (exemple : `id.y2.customerId`) dépend du modèle de données du projet.

</details>

<details>

<summary>Comment confirmer que les cartes ont été mises à jour avec succès ?</summary>

La confirmation nécessite généralement à la fois les journaux du workflow et des vérifications ponctuelles dans The Wallet Crew. Les journaux du workflow doivent conserver l’identifiant de requête et la réponse HTTP. Les vérifications ponctuelles doivent vérifier les champs attendus (exemple : `additionalData`) sur un petit échantillon de cartes.

</details>

<details>

<summary>Comment éviter les limites de débit lors de la mise à jour de grandes audiences ?</summary>

Le traitement par lots et le bridage réduisent le risque d’atteindre les limites de l’API. Une approche courante consiste à traiter les enregistrements par petits groupes, à ajouter des pauses entre les lots et à réessayer avec un backoff sur les réponses 429/5xx.

</details>

<details>

<summary>Où la clé API doit-elle être stockée dans Adobe Campaign ?</summary>

Les clés API doivent être traitées comme des secrets. Privilégiez les mécanismes d’Adobe Campaign prévus pour le stockage des identifiants, plutôt que de coder en dur les valeurs dans les activités ou les scripts. L’accès doit être limité au strict minimum d’opérateurs et de workflows.

</details>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.thewalletcrew.io/connectors/fr/marketing-automation/adobe-campaign.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.