En esta página: Aprenda a pasar colecciones simples y de objetos a parámetros de acción personalizados para que se rellenen dinámicamente durante la ejecución.
Puede pasar una colección en parámetros de acción personalizados que se rellenan dinámicamente durante la ejecución.
Se admiten dos tipos de colecciones:
-
Colecciones simples
Utilice colecciones simples para listas de valores básicos, como cadenas, números o valores booleanos. Son útiles cuando solo necesita pasar una lista de elementos sin propiedades adicionales.
Por ejemplo, una lista de tipos de dispositivos:
code language-json { "deviceTypes": [ "android", "ios" ] } -
Colecciones de objetos
Utilice colecciones de objetos cuando cada elemento incluya varios campos o propiedades. Normalmente se utilizan para pasar datos estructurados, como detalles de productos, registros de eventos o atributos de elementos.
Por ejemplo:
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 } ] }
Procedimiento general general-procedure
En esta sección, utilizamos el siguiente ejemplo de carga útil JSON. Es una matriz de objetos con un campo que es una colección simple.
{
"ctxt": {
"products": [
{
"id": "productA",
"name": "A",
"price": 20.1,
"color":"blue",
"locations": [
"Paris",
"London"
]
},
{
"id": "productB",
"name": "B",
"price": 10.99
}
]
}
}
Puede ver que products es una matriz de dos objetos. Debe tener al menos un objeto.
-
Cree su acción personalizada. Obtenga más información en esta página.
-
En la sección Parámetros de acción, pegue el ejemplo JSON. La estructura mostrada es estática: al pegar la carga útil, todos los campos se definen como constantes.
-
Si es necesario, ajuste los tipos de campo. Se admiten los siguientes tipos de campos para colecciones: listString, listInteger, listDecimal, listBoolean, listDateTime, listDateTimeOnly, listDateOnly, listObject
note NOTE El tipo de campo se infiere automáticamente según el ejemplo de carga útil. -
Si desea pasar objetos de forma dinámica, debe establecerlos como variables. En este ejemplo establecemos
productscomo variable. Todos los campos de objeto incluidos en el objeto se establecen en variables automáticamente.note NOTE El primer objeto del ejemplo de carga útil se utiliza para definir los campos. -
Para cada campo, defina la etiqueta que se mostrará en el lienzo de recorrido.
-
Cree el recorrido y añada la acción personalizada que ha creado. Obtenga más información en esta página.
-
En la sección Parámetros de acción, defina el parámetro de matriz (
productsen nuestro ejemplo) utilizando el editor de expresiones avanzadas.
-
Para cada uno de los siguientes campos de objeto, escriba el nombre del campo correspondiente del esquema XDM de origen. Si los nombres son idénticos, no es necesario. En nuestro ejemplo, solo necesitamos definir
product idy “color”.
Para el campo de matriz, también puede utilizar el editor de expresiones avanzadas para realizar la manipulación de datos. En el ejemplo siguiente, utilizamos las funciones filter y intersect:
Limitaciones limitations
Aunque las colecciones en acciones personalizadas proporcionan flexibilidad para pasar datos dinámicos, hay que tener en cuenta ciertas restricciones estructurales:
-
Compatibilidad con matrices anidadas en acciones personalizadas
Adobe Journey Optimizer admite matrices anidadas de objetos en cargas de respuesta de acción personalizada, pero esta compatibilidad está limitada en cargas de solicitud.
En las cargas útiles de solicitud, las matrices anidadas solo se admiten cuando contienen un número fijo de elementos, como se define en la configuración de acción personalizada. Por ejemplo, si una matriz anidada siempre incluye exactamente tres elementos, se puede configurar como una constante. Cuando el número de elementos debe ser dinámico, solo las matrices no anidadas (matrices en el nivel inferior) pueden definirse como variables.
Por ejemplo:
-
El siguiente ejemplo ilustra un caso de uso no admitido.
En este ejemplo, la matriz de productos incluye una matriz anidada (
locations) con un número dinámico de elementos, que no se admite en las cargas útiles de solicitud.code language-json { "products": [ { "id": "productA", "name": "A", "price": 20, "locations": [ { "name": "Paris" }, { "name": "London" } ] } ] } -
Ejemplo compatible, con elementos fijos definidos como constantes.
En este caso, las ubicaciones anidadas se reemplazan por campos fijos (
location1,location2), lo que permite que la carga útil siga siendo válida dentro de la configuración admitida.code language-json { "products": [ { "id": "productA", "name": "A", "price": 20, "location1": { "name": "Paris" }, "location2": { "name": "London" } } ] }
-
-
Colecciones de prueba: para probar las colecciones con el modo de prueba, debe usar el modo de vista de código. Tenga en cuenta que el modo de vista de código no es compatible con eventos empresariales, por lo que en ese caso, solo puede enviar una colección que contenga un solo elemento.
Casos particulares examples
Para los tipos y matrices heterogéneos de matrices, la matriz se define con el tipo listAny. Solo puede asignar elementos individuales, pero no puede cambiar la matriz a variable.
Ejemplo de tipo heterogéneo:
{
"data_mixed-types": [
"test",
"test2",
null,
0
]
}
Ejemplo de matriz de matrices:
{
"data_multiple-arrays": [
[
"test",
"test1",
"test2"
]
]
}
Recursos adicionales
Examine las secciones siguientes para obtener más información sobre la configuración, el uso y la resolución de problemas de sus acciones personalizadas:
- Empiece a usar las acciones personalizadas: descubra qué es una acción personalizada y cómo le ayudan a conectarse a sistemas de terceros
- Configurar las acciones personalizadas: aprenda a crear y configurar una acción personalizada
- Usar acciones personalizadas: aprenda a usar acciones personalizadas en sus recorridos
- Solución de problemas con acciones personalizadas - Aprenda a solucionar problemas de una acción personalizada
- Iterar en datos contextuales: aprenda a trabajar con matrices en expresiones de Recorrido e iterar en respuestas de acciones personalizadas, datos de eventos y búsquedas de conjuntos de datos en la personalización de mensajes
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.