Recommandations et limitations limitations
Autorisations et sécurité permissions
Mappage des profils de produit
Dans Campaign Standard, vous avez obtenu un accès élevé au rôle d’administrateur aux API, quel que soit le profil de produit qui vous a été attribué. Campaign v8 introduit un ensemble différent de profils de produit, ce qui nécessite de mapper les profils de produits Campaign Standard aux profils de produits Campaign v8.
Avec la migration, deux profils de produit sont ajoutés à vos comptes techniques existants ou précréés : Administrateur et Message Center (pour l’accès aux API transactionnelles). Vérifiez le mappage des profils de produit et attribuez le profil de produit nécessaire si vous ne souhaitez pas que le profil de produit Administrateur soit mappé à votre compte technique.
Identifiant du tenant
Après la migration, pour les intégrations futures, il est recommandé d’utiliser votre identifiant client Campaign v8 dans les URL REST, en remplaçant votre identifiant client Campaign Standard précédent.
Utilisation des clés
La gestion des valeurs PKey diffère entre Campaign Standard et Campaign v8. Si vous stockiez des clés PKey avec Campaign Standard, assurez-vous que votre implémentation crée dynamiquement les appels API suivants à l’aide des clés PKey ou href obtenus à partir d’appels API précédents.
API disponibles deprecated
Pour l’instant, les API REST répertoriées ci-dessous peuvent être utilisées :
- Profils
- Services et abonnements
- Ressources personnalisées
- Workflows
- Messages transactionnels
- Historique marketing
- Entités organisationnelles
- Gestion de la confidentialité
Filtrage
-
Pour utiliser vos filtres dans les payloads de l’API REST, vous devez les modifier dans Campaign v8 et fournir un nom à utiliser dans vos payloads. Pour ce faire, accédez aux paramètres supplémentaires du filtre à partir de l’onglet Paramètres et indiquez le nom souhaité dans le champ Nom du filtre dans l’API REST.
-
Le préfixe « par » requis pour utiliser les filtres personnalisés n’est plus nécessaire. Le nom du filtre doit être utilisé tel quel dans vos requêtes.
Exemple :
GET https://mc.adobe.io/<ORGANIZATION>/campaign/profileAndServicesExt/<resourceName>/<customFilterName>?<customFilterparam>=<customFilterValue>
Champs de base de données supprimés
Certains champs de la base de données sont supprimés lors de la migration. Lors de l’utilisation d’un champ déposé, les API REST renverront des valeurs vides. À l’avenir, tous les champs déposés seront abandonnés et supprimés.
POST avec ressources liées
Lors de l’utilisation du format de corps de requête suivant, avec « VehicleOwner » représentant le lien vers « nms:recipient » :
{
"vehicleNumber": "20009",
"vehicleName": "Model E",
"vehicleOwner":{
"firstName":"tester 11",
"lastName":"Smith 11"
}
}
Les informations sur le lien sont ignorées. Par conséquent, un nouvel enregistrement est généré sous « cusVehicle » contenant uniquement les valeurs « VehicleNumber » et « VehicleName ». Cependant, le lien reste nul, ce qui entraîne la définition de « VehicleOwner » sur null.
Dans Campaign v8, lorsque la même structure de corps de requête est utilisée et que le « véhicule » est lié à un profil, une erreur se produit. Cette erreur se produit car la propriété « firstName » n'est pas reconnue comme valide pour « cusVehicle ». Cependant, un corps de requête comprenant uniquement les attributs sans lien fonctionne sans aucun problème.
Opérations de PATCH
- Campaign v8 ne prend pas en charge PATCH avec un corps de requête vide : il renvoie un statut 204 Aucun contenu .
- Bien que Campaign Standard prenne en charge PATCH sur les éléments/attributs d’un schéma, notez que les opérations PATCH à l’emplacement ne sont pas prises en charge dans Campaign v8. Toute tentative de PATCH sur place entraînera une erreur de serveur interne 500 avec un message d’erreur indiquant que la propriété « zipCode » n’est pas valide pour la ressource « profile ».
Réponses REST
La section ci-dessous répertorie les différences mineures entre les réponses REST de Campaign Standard et de v8.
- Pour les enregistrements GET uniques, la réponse inclut le href dans la réponse.
- Lorsqu’elle est interrogée avec l’attribut , Campaign v8 fournit Count et Pagination dans la réponse.
- Après les opérations POST, les valeurs des ressources liées sont renvoyées dans la réponse.
Codes d’erreur et messages
La section ci-dessous répertorie les différences entre les codes d’erreur et les messages de Campaign Standard et de Campaign v8.
Profil - Fuseau horaire
Avec Campaign Standard, le fuseau horaire s’affiche dans le cadre de la réponse JSON des appels de l’API REST profileAndServices/profile.
Avec Campaign v8, le fuseau horaire n’est affiché que dans le cadre des appels API REST profileAndServicesExt/profile. Il ne fait pas partie des appels de l’API REST profileAndServices/profile, car il est ajouté dans un schéma étendu.
Workflows - Déclenchement de signal externe
L’API Campaign Standard Workflow GET renvoie des noms de paramètre tels que les variables d’instance de workflow et leurs types de données (booléen, chaîne, etc.). Il est utilisé pour créer un corps de requête JSON correctement formaté lors du déclenchement du signal via un appel de l’API POST.
Campaign v8 ne prend pas en charge les variables d’instance de workflow publicitaire, mais s’attend à ce que les développeurs et développeuses les connaissent. Ainsi, après la migration, les informations sur les paramètres dans le corps de la requête POST devront être construites sans que les informations sur les paramètres ne soient disponibles dans la réponse de l’API GET.