API de migration vers la prise de décision decisioning-migration-api

Sur cette page : utilisez l’API Decisioning Migration Service pour déplacer les objets de gestion des décisions entre les sandbox avec une analyse des dépendances automatisée et la prise en charge de la restauration, afin que vous puissiez transférer le contenu de prise de décision entre les environnements tout en préservant l’intégrité des données.

L’API Decisioning Migration Service vous permet de migrer des objets de gestion des décisions 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 en toute transparence votre contenu de prise de décision entre les environnements tout en préservant l’intégrité des données et les relations.

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 Decisioning Migration Service offre les fonctionnalités suivantes :

Conditions préalables prerequisites

Autorisations nécessaires permissions

Pour utiliser l’API 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 : accès permettant de créer et modifier les objets de prise de décision

Parmi les autorisations standard figurent :

Préparer 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 Utiliser et attribuer des sandbox.

Bases d’API api-basics

URL de base base-url

Utilisez l’URL de base suivante :

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 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éer 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 /workflows/generate-dependencies

Dépendance au niveau du sandbox (à privilégier)

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

curl --request POST \
  --url "https://decisioning-migration.adobe.io/workflows/generate-dependencies?request-level=sandbox" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "Content-Type: application/json" \
  --data '{
    "imsOrgId": "<IMS_ORG_ID>",
    "sourceSandboxDetails": { "sandboxName": "<SOURCE_SANDBOX_NAME>" },
    "targetSandboxDetails": { "sandboxName": "<TARGET_SANDBOX_NAME>" }
  }'

Dépendance au niveau de l’offre

Pour analyser les dépendances uniquement pour des offres spécifiques, appelez le même point d’entrée avec request-level=offer dans la chaîne de requête et fournissez un tableau offersList dans le corps avec les identifiants d’offre que vous souhaitez analyser.

Dépendance au niveau de la décision

Pour analyser les dépendances uniquement pour des décisions spécifiques, utilisez request-level=decision dans la chaîne de requête et fournissez un tableau decisionsList dans le corps avec les identifiants de décision à analyser.

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

Interrogez le workflow de dépendance pour vérifier quand l’analyse est terminée.

Format d’API

GET /workflows/generate-dependencies/{id}

Requête

curl --request GET \
  --url "https://decisioning-migration.adobe.io/workflows/generate-dependencies/<WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>"

Lorsque le champ status affiche Completed, l’analyse des dépendances est prête. Utilisez le résultat 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éer 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 /workflows/migration

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://decisioning-migration.adobe.io/workflows/migration?request-level=sandbox' \
  --header 'Authorization: Bearer <IMS_ACCESS_TOKEN>' \
  --header 'Content-Type: application/json' \
  --header 'x-gw-ims-org-id: <IMS_ORG_ID>' \
  --data '{
    "imsOrgId": "<IMS_ORG_ID>",
    "sourceSandboxDetails": { "sandboxName": "<SOURCE_SANDBOX_NAME>" },
    "targetSandboxDetails": { "sandboxName": "<TARGET_SANDBOX_NAME>" },
    "createDataStream": true,
    "dependency": {
      "profileAttributes": {
        "sourceAttr1": "targetAttr1"
      },
      "segments": {
        "sourceSegmentKey1": {
          "namespace": "<TARGET_SEGMENT_NAMESPACE>",
          "id": "<TARGET_SEGMENT_ID>"
        }
      },
      "contextAttributes": {
        "sourceCtx1": "targetCtx1"
      },
      "datasetName": "<TARGET_DATASET_NAME>"
    }
  }'

Migration au niveau des offres

Pour migrer des offres spécifiques uniquement, utilisez request-level=offer dans la chaîne de requête et ajoutez un tableau offersList au corps :

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

Migration au niveau des décisions

Pour migrer des décisions spécifiques uniquement, utilisez request-level=decision dans la chaîne de requête et ajoutez un tableau decisionsList au corps :

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

Surveiller le statut de la migration poll-migration-status

Interrogez le workflow de migration pour suivre sa progression.

Format d’API

GET /workflows/migration/{id}

Requête

curl --request GET \
  --url "https://decisioning-migration.adobe.io/workflows/migration/<WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>"

Résultats de la migration

Lorsque le champ status affiche Completed, la migration a réussi. Le workflow result comprend :

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

Valider 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 train 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éer 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 /workflows/rollback

Requête

curl --request POST \
  --url "https://decisioning-migration.adobe.io/workflows/rollback" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "Content-Type: application/json" \
  --data '{ "rollbackWorkflowId": "<MIGRATION_WORKFLOW_ID>" }'

Remplacez <MIGRATION_WORKFLOW_ID> par l’identifiant du workflow de migration que vous souhaitez restaurer.

Surveiller le statut de la restauration poll-rollback-status

Interrogez le workflow de restauration pour suivre sa progression.

Format d’API

GET /workflows/rollback/{rollbackWorkflowId}

Requête

curl --request GET \
  --url "https://decisioning-migration.adobe.io/workflows/rollback/<ROLLBACK_WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>"

Gérer des workflows simultanés handle-concurrency

L’API Migration n’autorise l’exécution que d’un seul workflow à 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 de 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 mappage 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 de workflows cleanup

La suppression de workflows n’est pas disponible publiquement. Si vous devez supprimer une ressource de workflow, contactez votre administrateur ou administratrice système.

Rubriques connexes related-topics