Spécifications de modèle pour les destinations créées avec Destination SDK
Utilisez la partie de spécification du modèle de la configuration du serveur de destination pour configurer la manière de formater les requêtes HTTP envoyées à la destination.
Dans une spécification de modèle, vous pouvez définir comment transformer les champs d’attribut de profil entre le schéma XDM et le format pris en charge par votre plateforme.
Les spécifications de modèle font partie de la configuration du serveur de destination pour les destinations en temps réel (streaming).
Pour comprendre la place de ce composant dans une intégration créée avec Destination SDK, consultez le diagramme de la documentation options de configuration ou consultez le guide sur la utilisation de Destination SDK pour configurer une destination de diffusion en streaming.
Vous pouvez configurer les spécifications du modèle pour la destination via le point d’entrée /authoring/destination-servers. Pour obtenir des exemples d’appels API détaillés dans lesquels vous pouvez configurer les composants affichés sur cette page, consultez les pages de référence de l’API suivantes.
Types d’intégration pris en charge supported-integration-types
Pour en savoir plus sur les types d’intégration qui prennent en charge les fonctionnalités décrites sur cette page, consultez le tableau ci-dessous.
Configuration d’une spécification de modèle configure-template-spec
Adobe utilise un langage de modèle similaire à Jinja pour transformer les champs du schéma XDM en un format pris en charge par la destination.
Pour plus d’informations sur la transformation, consultez les liens ci-dessous :
Consultez ci-dessous un modèle type de requête HTTP, ainsi que des descriptions de chaque paramètre individuel.
{
"httpTemplate":{
"httpMethod":"POST",
"requestBody":{
"templatingStrategy":"PEBBLE_V1",
"value":"{ \"attributes\": [ {% for ns in [\"external_id\", \"yourdestination_id\"] %} {% if input.profile.identityMap[ns] is not empty and first_namespace_encountered %} , {% endif %} {% set first_namespace_encountered = true %} {% for identity in input.profile.identityMap[ns]%} { \"{{ ns }}\": \"{{ identity.id }}\" {% if hasSegments(input.profile.segmentMembership) %} , \"AEPSegments\": { \"add\": [ {% for namespace in input.profile.segmentMembership %} {% for segment in input.profile.segmentMembership[namespace.key] %} {% if (segment.value.status == \"realized\" or segment.value.status == \"existing\") and destination.namespaceSegmentAliases[namespace.key][segment.key] is defined %} {% if added_segment_found %} , {% endif %} {% set added_segment_found = true %} \"{{ destination.namespaceSegmentAliases[namespace.key][segment.key] }}\" {% endif %} {% endfor %} {% endfor %} ], \"remove\": [ {% for namespace in input.profile.segmentMembership %} {% for segment in input.profile.segmentMembership[namespace.key] %} {% if segment.value.status == \"exited\" and destination.namespaceSegmentAliases[namespace.key][segment.key] is defined %} {% if removed_segment_found %} , {% endif %} {% set removed_segment_found = true %} \"{{ destination.namespaceSegmentAliases[namespace.key][segment.key] }}\" {% endif %} {% endfor %} {% endfor %} ] } {% set removed_segment_found = false %} {% set added_segment_found = false %} {% endif %} {% if input.profile.attributes is not empty %} , {% endif %} {% for attribute in input.profile.attributes %} \"{{ attribute.key }}\": {% if attribute.value is empty %} null {% else %} \"{{ attribute.value.value }}\" {% endif %} {% if not loop.last%} , {% endif %} {% endfor %} } {% if not loop.last %} , {% endif %} {% endfor %} {% endfor %} ] }"
},
"contentType":"application/json"
}
}
httpMethodGET, PUT, POST, DELETE, PATCH.templatingStrategyPEBBLE_V1.valuePour plus d’informations sur l’écriture du modèle, lisez la section sur l’utilisation de modèles.
Pour plus d’informations sur les caractères d’échappement, consultez la section Norme RFC JSON, section 7.
Pour obtenir un exemple de transformation simple, reportez-vous à la transformation attributs de profil.
contentTypeapplication/json.Conversion d’un modèle pour prendre en charge les audiences externes template-converter-tool
Les anciens modèles lisent uniquement l’appartenance à l’audience à partir de l’espace de noms ups. Mettez à jour ces modèles pour effectuer une itération sur chaque espace de noms dans segmentMembership, de sorte qu’ils lisent également l’appartenance à des audiences externes.
Pour plus d’informations sur la configuration de la destination pour prendre en charge les audiences externes, voir Configuration de la prise en charge des audiences externes.
Utilisez l’outil Convertisseur de modèles pour convertir automatiquement votre modèle existant. L’outil réécrit un modèle qui lit uniquement l’espace de noms ups dans un modèle qui effectue une itération sur tous les espaces de noms d’segmentMembership, y compris les audiences externes.
Téléchargement de l’outil de conversion de modèles
L’outil nécessite Java Runtime Environment (JRE) 11 ou une version ultérieure. Il prend en charge deux modes :
-
Mode d’interface de ligne de commande (CLI) : exécutez l’outil à partir d’un terminal et transmettez votre modèle existant en tant que paramètre.
code language-shell java -jar templates-converter-cli.jar "your-existing-template-string"L’outil imprime le modèle converti sur la borne.
-
Mode de l’interface utilisateur (IU) : exécutez l’outil avec une interface graphique. Ce mode nécessite le SDK JavaFX, qui est inclus dans l’archive téléchargée.
code language-shell java --module-path="./javafx-sdk-17.0.7/lib" --add-modules=javafx.controls,javafx.fxml -jar templates-converter-ui.jar
Après avoir converti votre modèle, testez-le par rapport à plusieurs exemples de profils à l’aide de l’API render template pour confirmer qu’il s’affiche toujours correctement avant de l’ajouter à la configuration de votre serveur de destination.
Configurer les en-têtes de requête headers
Outre le corps de la requête, vous pouvez ajouter des en-têtes HTTP personnalisés aux appels effectués par Experience Platform vers la destination. Chaque entrée d’en-tête utilise les mêmes champs templatingStrategy et value que les autres champs modélisés du serveur de destination.
"httpTemplate": {
"httpMethod": "POST",
"headers": [
{
"header": "Authorization",
"value": {
"templatingStrategy": "PEBBLE_V1",
"value": "Basic {{ (authData.username + ':' + authData.password) | base64encode }}"
}
},
{
"header": "x-integration",
"value": {
"templatingStrategy": "PEBBLE_V1",
"value": "{{customerData.integrationId}}"
}
},
{
"header": "Amazon-Advertising-API-ClientId",
"value": {
"templatingStrategy": "PEBBLE_V1",
"value": "{{authData.clientId}}"
}
},
{
"header": "Accept",
"value": {
"templatingStrategy": "NONE",
"value": "application/json"
}
}
]
}
headerAuthorization, Content-Type ou en-tête personnalisé.value.templatingStrategyPEBBLE_V1 lorsque la valeur de l’en-tête est dynamique ou utilise des expressions Pebble. Utilisez NONE pour les valeurs statiques.value.value{{customerData.integrationId}}, {{authData.clientId}} ou {{ (authData.username + ':' + authData.password) | base64encode }}.Certaines API de partenaire nécessitent un en-tête personnalisé renseigné avec une valeur des informations d’authentification fournies par la clientèle, plutôt que l’en-tête Authorization standard. L’en-tête Amazon-Advertising-API-ClientId illustré ci-dessus est un exemple de ce modèle, où la valeur de l’en-tête provient directement d’un champ authData.
value est une chaîne plate au lieu d’un objet avec des champs templatingStrategy et value. Pour obtenir un exemple, consultez la section Gestion des métadonnées d’audience.Pour les destinations qui utilisent l’authentification de base et qui nécessitent un en-tête codé en Base64 personnalisé, consultez Personnaliser l’en-tête d’authentification de base.
Étapes suivantes next-steps
Vous êtes arrivé au bout de cet article. À présent, vous devriez mieux comprendre ce qu’est une spécification de modèle et comment la configurer.
Pour en savoir plus sur les autres composants de serveur de destination, consultez les articles suivants :