API de migration Decisioning decisioning-migration-api

L’API Decisioning Migration Service vous permet de migrer des objets Decision Management d’un sandbox à un autre. Le processus de migration s’exécute sous la forme de workflows asynchrones qui incluent l’analyse des dépendances, l’exécution et des fonctionnalités de restauration facultatives.

Cette API vous permet de transférer facilement votre contenu de prise de décision entre les environnements (par exemple, du développement à l’évaluation ou de l’évaluation à la production) tout en préservant l’intégrité et les relations des données.

Pour en savoir plus sur les avantages et les fonctionnalités de la prise de décision par rapport à la gestion des décisions, consultez cette page.

Fonctionnalités capabilities

L’API du service de migration Decisioning offre les fonctionnalités suivantes :

Conditions préalables prerequisites

Autorisations nécessaires permissions

Pour utiliser l’API de migration, vous avez besoin des autorisations appropriées dans les sandbox source et cible :

Sandbox Source - Accès en lecture aux objets de gestion des décisions

Sandbox cible - Création et modification de l’accès aux objets Decisioning

Les autorisations standard incluent :

Préparation de votre sandbox cible target-sandbox-preparation

Avant d’exécuter une migration, vérifiez que votre sandbox cible est correctement configuré :

Pour plus d’informations sur la gestion des sandbox, voir ​ Utilisation et affectation de sandbox.

Bases d’API api-basics

URL de base base-urls

Utilisez les URL de base suivantes en fonction de votre environnement :

Authentification authentication

Toutes les requêtes API nécessitent les en-têtes suivants :

Pour obtenir des instructions détaillées sur la configuration de l’authentification, consultez le guide d’authentification de Journey Optimizer.

Modèle de workflow workflow-model

Chaque appel API crée ou récupère une ressource de workflow. Les workflows sont des opérations asynchrones qui effectuent le suivi de la progression et des résultats des tâches de migration.

Un workflow possède les propriétés suivantes :

Workflow de migration migration-workflow

Le processus de migration se compose de deux étapes principales : l'analyse des dépendances et l'exécution de la migration. Pour garantir une migration réussie, procédez comme suit.

Étape 1 : analyser les dépendances analyze-dependencies

Avant la migration, utilisez le workflow de dépendance pour identifier ce qui doit être mappé de la gestion des décisions à la prise de décision dans votre sandbox cible. Cette analyse vous aide à comprendre les relations entre les objets et à préparer les mappages nécessaires.

Création d’un workflow de dépendance create-dependency-workflow

Utilisez l’appel API suivant pour créer un workflow d’analyse des dépendances.

Format d’API

POST /migration/service/dependency

Dépendance au niveau du sandbox (recommandée en premier)

Commencez par une analyse au niveau du sandbox pour obtenir une vue complète de toutes les dépendances :

curl --request POST \
  --url "https://platform.adobe.io/migration/service/dependency" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>" \
  --header "Content-Type: application/json" \
  --data '{
    "imsOrgId": "<IMS_ORG_ID>",
    "sourceSandboxDetails": { "sandboxName": "<SOURCE_SANDBOX_NAME>" },
    "targetSandboxDetails": { "sandboxName": "<TARGET_SANDBOX_NAME>" },
    "requestLevel": "sandbox"
  }'

Dépendance de niveau offre

Pour analyser les dépendances uniquement pour des offres spécifiques, définissez requestLevel: "offer" et fournissez un tableau offersList avec les identifiants des offres à analyser.

Dépendance de niveau décision

Pour analyser les dépendances uniquement pour des décisions spécifiques, définissez requestLevel: "decision" et fournissez un tableau decisionsList avec les ID de décision à analyser.

Vérification du statut du workflow de dépendance poll-dependency-status

Interrogez le workflow de dépendance pour vérifier la fin de l’analyse.

Format d’API

GET /migration/service/dependency/{id}

Requête

curl --request GET \
  --url "https://platform.adobe.io/migration/service/dependency/<WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>"

Lorsque le champ de status affiche Completed, l’analyse des dépendances est prête. Utilisez la sortie du workflow pour créer vos mappages de dépendance de migration :

Étape 2 : exécuter la migration execute-migration

Une fois que vous avez analysé les dépendances et préparé vos mappages, vous pouvez exécuter la migration.

Création d’un workflow de migration create-migration-workflow

Utilisez les mappages de dépendance de l’étape 1 pour configurer et exécuter votre migration.

Format d’API

POST /migration/service/migrations

Migration au niveau des sandbox

Pour migrer tous les objets de prise de décision d’un sandbox à un autre :

curl --request POST \
  --url "https://platform.adobe.io/migration/service/migrations" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>" \
  --header "Content-Type: application/json" \
  --data '{
    "imsOrgId": "<IMS_ORG_ID>",
    "sourceSandboxDetails": { "sandboxName": "<SOURCE_SANDBOX_NAME>" },
    "targetSandboxDetails": { "sandboxName": "<TARGET_SANDBOX_NAME>" },
    "createDataStream": true,
    "dependency": {
      "profileAttributeDependency": {
        "sourceAttr1": "targetAttr1"
      },
      "segmentsDependency": {
        "sourceSegmentKey1": {
          "segmentNamespace": "<TARGET_SEGMENT_NAMESPACE>",
          "segmentId": "<TARGET_SEGMENT_ID>"
        }
      },
      "contextAttributeDependency": {
        "sourceCtx1": "targetCtx1"
      },
      "datasetName": "<TARGET_DATASET_NAME>"
    },
    "requestLevel": "sandbox"
  }'

Migration au niveau des offres

Pour migrer des offres spécifiques uniquement, utilisez requestLevel: "offer" et ajoutez un tableau offersList :

"offersList": ["offer-id-1", "offer-id-2"]

Migration au niveau de la décision

Pour migrer des décisions spécifiques uniquement, utilisez requestLevel: "decision" et ajoutez un tableau decisionsList :

"decisionsList": ["decision-id-1", "decision-id-2"]

Surveillance du statut de migration poll-migration-status

Interrogez le workflow de migration pour suivre sa progression.

Format d’API

GET /migration/service/migrations/{id}

Requête

curl --request GET \
  --url "https://platform.adobe.io/migration/service/migrations/<WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>"

Résultats de la migration

Lorsque le champ status affiche Completed, la migration a réussi. Le result de workflow comprend les éléments suivants :

Lorsque le champ status s’affiche, Failed le tableau de errors[] et result.error champ pour en savoir plus sur le problème.

Validation de la migration validate-migration

Une fois la migration terminée, vérifiez que tous les objets ont été migrés correctement.

Liste de contrôle de validation validation-checklist

Exemple test-runtime-delivery

Si votre migration a créé un flux de données, vous pouvez tester la diffusion de l’offre à l’aide de l’exemple suivant :

curl --request POST \
  --url "https://edge.adobedc.net/ee/or2/v1/interact?configId=<DATASTREAM_ID>" \
  --header "Content-Type: application/json" \
  --header "x-request-id: <uuid>" \
  --data '{ "events": [ ... ] }'

Restaurer une migration rollback

Si vous rencontrez des problèmes lors de la validation, vous pouvez annuler une migration terminée afin de restaurer le sandbox cible à son état précédent.

Création d’un workflow de restauration create-rollback-workflow

Lancez une restauration en créant un workflow de restauration qui fait référence à la migration que vous souhaitez annuler.

Format d’API

POST /migration/service/rollbacks/{migrationWorkflowId}

Remplacez {migrationWorkflowId} par l’identifiant du workflow de migration que vous souhaitez restaurer.

Requête

curl --request POST \
  --url "https://platform.adobe.io/migration/service/rollbacks/<MIGRATION_WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>"

Surveillance du statut de restauration poll-rollback-status

Recherchez le workflow de restauration pour suivre sa progression.

Format d’API

GET /migration/service/rollbacks/{rollbackWorkflowId}

Requête

curl --request GET \
  --url "https://platform.adobe.io/migration/service/rollbacks/<ROLLBACK_WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>"

Gestion des workflows simultanés handle-concurrency

L’API de migration permet à un seul workflow de s’exécuter à la fois par organisation. Si vous tentez de créer un workflow alors qu’un autre est en cours, vous recevrez une réponse d’erreur 409 Conflit (« Un workflow est déjà en cours… »).

Dans ce cas, attendez que le workflow en cours soit terminé ou récupérez l’ID du workflow et interrogez son statut. Une fois le workflow en cours terminé, vous pouvez en créer un nouveau.

Référence de mapping d’entités entity-mapping

Lors de la migration de la gestion des décisions vers la prise de décision, les entités sont mappées comme suit :

Nettoyage du workflow cleanup

Les ressources de workflow ne peuvent être supprimées que par les utilisateurs et utilisatrices du service. Les opérations de suppression nécessitent un en-tête If-Match avec la valeur de _etag du workflow.

Opérations de suppression disponibles :

Rubriques connexes related-topics