DocumentationJourney OptimizerGuide de Journey Optimizer

Transmettre des collections dans des paramètres d’action personnalisée passing-collection

Dernière mise à jour : 16 septembre 2026
  • S'applique à :
  • Journey Orchestration

Créé pour :

  • Experienced
  • Développeur

Sur cette page : découvrez comment transmettre des collections d’objets simples et dans des paramètres d’action personnalisés afin qu’elles soient renseignées dynamiquement au moment de l’exécution.

style
shade-box

Vous pouvez transmettre une collection dans des paramètres d’actions personnalisées qui seront renseignés dynamiquement au moment de l’exécution.

Deux types de collections sont pris en charge :

  • Collections simples

    Vous pouvez utiliser des collections simples pour les listes de valeurs de base, telles que des chaînes, des nombres ou des booléens. Elles s’avèrent utiles lorsque vous n’avez besoin de transmettre qu’une liste d’éléments sans propriétés supplémentaires.

    Par exemple, une liste de types d’appareils :

    code language-json 
    {
 "deviceTypes": [
     "android",
     "ios"
 ]
}

  • Collections d’objets

    Vous pouvez utiliser des collections d’objets lorsque chaque élément comprend plusieurs champs ou propriétés. Elles servent habituellement à transmettre des données structurées, telles que des détails de produit, des enregistrements d’événement ou des attributs d’élément.

    Par exemple :

    code language-json 
    {
"products":[
   {
      "id":"productA",
      "name":"A",
      "price":20.1
   },
   {
      "id":"productB",
      "name":"B",
      "price":10.0
   },
   {
      "id":"productC",
      "name":"C",
      "price":5.99
   }
 ]
}
NOTE
Les tableaux imbriqués dans les collections ne sont que partiellement pris en charge dans les payloads de requête d’action personnalisée. Pour plus d’informations, consultez la section Limites.

Procédure générale general-procedure

Dans cette section, nous utiliserons l’exemple de payload JSON ci-après. Il s’agit d’un tableau d’objets avec un champ qui est une collection simple.

{
  "ctxt": {
    "products": [
      {
        "id": "productA",
        "name": "A",
        "price": 20.1,
        "color":"blue",
        "locations": [
          "Paris",
          "London"
        ]
      },
      {
        "id": "productB",
        "name": "B",
        "price": 10.99
      }
    ]
  }
}

Vous pouvez voir que products est un tableau de deux objets. Vous devez avoir au moins un objet.

  1. Créez votre action personnalisée. En savoir plus sur cette page.

  2. Dans la section Paramètres d’action, collez l’exemple JSON. La structure affichée est statique : lorsque vous collez la payload, tous les champs sont définis comme des constantes.

    Éditeur d’expression présentant les fonctions et opérations de collection

  3. Si nécessaire, ajustez les types de champs. Les types de champs suivants sont pris en charge pour les collections : listString, listInteger, listDecimal, listBoolean, listDateTime, listDateTimeOnly, listDateOnly, listObject

    note
    NOTE
    Le type de champ est automatiquement déduit en fonction de l’exemple de payload.

  4. Si vous souhaitez transmettre des objets de façon dynamique, vous devez les définir en tant que variables. Dans cet exemple, nous définissons products comme variable. Tous les champs d’objet inclus dans l’objet sont automatiquement définis sur des variables.

    note
    NOTE
    Le premier objet de l’exemple de payload est utilisé pour définir les champs.

  5. Pour chaque champ, définissez le libellé qui sera affiché dans la zone de travail du parcours.

    Fonction de collections de filtres avec l’interface du créateur de conditions {width="70%"}

  6. Créez votre parcours et ajoutez l’action personnalisée que vous avez créée. En savoir plus sur cette page.

  7. Dans la section Paramètres d’action, définissez le paramètre de tableau (products dans notre exemple) à l’aide de l’éditeur d’expression avancé.

    Expression de filtrage des collections avec sélection de champ

  8. Pour chacun des champs d’objet suivants, saisissez le nom de champ correspondant à partir du schéma XDM source. Si les noms sont identiques, cela n’est pas nécessaire. Dans notre exemple, il nous suffit de définir product id et « color ».

    Fonction de tri des collections avec configuration de tri {width="50%"}

Pour le champ de tableau, vous pouvez également utiliser l’éditeur d’expression avancé pour effectuer une manipulation de données. Dans l’exemple suivant, nous utilisons les fonctions filter et intersect :

Compléter l’expression de collection avec les opérations de filtre, de tri et de limite

Limites limitations

Bien que les collections dans les actions personnalisées offrent la flexibilité nécessaire pour transmettre des données dynamiques, certaines contraintes structurelles doivent être prises en compte :

  • Prise en charge des tableaux imbriqués dans les actions personnalisées

    Adobe Journey Optimizer prend en charge les tableaux d’objets imbriqués dans les actions personnalisées payloads de réponse, mais cette prise en charge est limitée dans les payloads de requête.

    Dans les payloads de requête, les tableaux imbriqués ne sont pris en charge que s’ils contiennent un nombre fixe d’éléments, comme défini dans la configuration de l’action personnalisée. Par exemple, si un tableau imbriqué comprend toujours exactement trois éléments, il peut être configuré comme une constante. Lorsque le nombre d’éléments doit être dynamique, seuls les tableaux non imbriqués (tableaux au niveau inférieur) peuvent être définis comme variables.

    Exemple :

    1. L’exemple suivant illustre un cas d’utilisation non pris en charge.

      Dans cet exemple, le tableau « products » comprend un tableau imbriqué (locations) avec un nombre dynamique d’éléments, qui n’est pas pris en charge dans les payloads de requête.

      code language-json 
      {
"products": [
   {
      "id": "productA",
      "name": "A",
      "price": 20,
      "locations": [
      { "name": "Paris" },
      { "name": "London" }
      ]
   }
]
}

    2. Exemple pris en charge, avec des éléments fixes définis comme des constantes.

      Dans ce cas, les emplacements imbriqués sont remplacés par des champs fixes (location1, location2), ce qui permet à la payload de rester valide dans la configuration prise en charge.

      code language-json 
      {
"products": [
   {
      "id": "productA",
      "name": "A",
      "price": 20,
      "location1": { "name": "Paris" },
      "location2": { "name": "London" }
   }
]
}

  • Test des collections : pour tester des collections à l’aide du mode test, vous devez utiliser le mode d’affichage du code. Notez que le mode d’affichage du code n’est pas pris en charge pour les événements métier. Dans ce cas, vous ne pouvez donc envoyer qu’une collection contenant un seul élément.

Cas particuliers examples

Pour les types et les tableaux de tableaux hétérogènes, le tableau est défini avec le type listAny. Vous pouvez uniquement mapper des éléments individuels, mais ne pouvez pas modifier le tableau en variable.

Collection hétérogène avec types de données mixtes et sélection de champs {width="70%"}

Exemple de type hétérogène :

{
    "data_mixed-types": [
        "test",
        "test2",
        null,
        0
    ]
}

Exemple de tableau de tableaux :

{
    "data_multiple-arrays": [
        [
            "test",
            "test1",
            "test2"
        ]
    ]
}

Ressources supplémentaires

Parcourez les sections suivantes pour en savoir plus sur la configuration des actions personnalisées, l’utilisation de celles-ci et la résolution des problèmes liés à celles-ci :

AI Knowledge Reference

This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.

For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.

  • TL;DR: This page explains how to pass simple and object collections dynamically into custom action parameters in Journey Optimizer, including supported field types, the configuration procedure, and known limitations around nested arrays.

Intents:

  • Configure a custom action to accept a collection (simple or object) as a dynamic parameter
  • Define array parameters as variables in the advanced expression editor when building a journey
  • Apply filter and intersect functions to manipulate array data in the expression editor
  • Understand and work within the nested array limitations for custom action request payloads
  • Test collection parameters using code view mode in journey test mode

Glossary:

  • Simple collection: A list of basic scalar values (strings, numbers, booleans) passed as a custom action parameter (product-specific)
  • Object collection: A list of structured objects, each with multiple fields, passed as a custom action parameter (product-specific)
  • listObject: The field type used in custom action configuration to represent an array of objects (product-specific)
  • listAny: The field type used for heterogeneous arrays or arrays of arrays where items have mixed types (product-specific)
  • Variable (vs. Constant): In action parameter configuration, a field set to “variable” is populated dynamically at runtime from the journey context, while a “constant” is a fixed value set at configuration time (product-specific)

Guardrails:

  • Nested arrays in request payloads are only supported when they contain a fixed number of items (defined as constants); dynamic nested arrays are not supported
  • Code view mode is required to test collections in test mode; code view is not supported for business events, so only single-element collections can be sent in that case
  • At least one object must be present in the payload example used to define collection fields
  • The first object of the payload example defines the fields for the entire collection

Terminology:

  • Canonical name: Collection — Acronym: none — variants: array, list, dynamic collection
  • Synonyms: “simple collection” = “list of scalar values” ; “object collection” = “array of objects”
  • Do not confuse: “listAny” ≠ “listObject” (listAny handles heterogeneous or nested arrays; listObject handles uniform arrays of structured objects)

FAQ:

  • Q: What is the difference between a simple collection and an object collection? — A simple collection contains basic scalar values (strings, numbers, booleans), while an object collection contains structured objects each with multiple named fields.
  • Q: How do I make a collection parameter dynamic at runtime? — In the custom action’s Action parameters section, set the array field to “variable”; all object fields within it are then automatically set to variables.
  • Q: Are nested arrays supported in custom action request payloads? — Only partially. Nested arrays with a fixed, known number of items can be defined as constants. Nested arrays with a dynamic number of items are not supported in request payloads.
  • Q: How do I test a collection in journey test mode? — Use code view mode in the test interface. Note that business events do not support code view, so only single-element collections can be tested in that context.
  • Q: What field types are supported for collections? — listString, listInteger, listDecimal, listBoolean, listDateTime, listDateTimeOnly, listDateOnly, and listObject are all supported.
recommendation-more-help
journey-optimizer-help