Decisioning-Migrations-API decisioning-migration-api

Mit der Decisioning Migration Service-API können Sie Entscheidungs-Management-Objekte von einer Sandbox in eine andere migrieren. Der Migrationsprozess wird als asynchrone Workflows ausgeführt, die Funktionen zur Abhängigkeitsanalyse, Ausführung und optionales Rollback enthalten.

Mit dieser API können Sie Ihre Entscheidungs-Inhalte nahtlos zwischen Umgebungen (z. B. von der Entwicklung zum Staging oder von der Staging- zur Produktionsumgebung) wechseln, während die Datenintegrität und -beziehungen erhalten bleiben.

Weitere Informationen zu den Vorteilen und Funktionen von Decisioning im Vergleich zum Entscheidungs-Management finden Sie dieser Seite.

Funktionen capabilities

Die Decisioning Migration Service-API bietet die folgenden Funktionen:

Voraussetzungen prerequisites

Erforderliche Berechtigungen permissions

Um die Migrations-API verwenden zu können, benötigen Sie entsprechende Berechtigungen in der Quell- und Ziel-Sandbox:

Source Sandbox - Lesezugriff auf Entscheidungs-Management-Objekte

Target-Sandbox - Zugriff auf Decisioning-Objekte erstellen und bearbeiten

Zu den typischen Berechtigungen gehören:

Vorbereiten der Ziel-Sandbox target-sandbox-preparation

Bevor Sie eine Migration ausführen, stellen Sie sicher, dass Ihre Ziel-Sandbox ordnungsgemäß konfiguriert ist:

Weitere Informationen zur Sandbox-Verwaltung finden Sie unter ​ und Zuweisen von Sandboxes.

API-Grundlagen api-basics

Basis-URLs base-urls

Verwenden Sie je nach Umgebung die folgenden Basis-URLs:

Authentifizierung authentication

Alle API-Anfragen erfordern die folgenden Kopfzeilen:

Detaillierte Anweisungen zum Einrichten der Authentifizierung finden Sie im Authentifizierungshandbuch für Journey Optimizer.

Workflow-Modell workflow-model

Jeder API-Aufruf erstellt oder ruft eine Workflow-Ressource ab. Workflows sind asynchrone Vorgänge, die den Fortschritt und die Ergebnisse von Migrationsaufgaben verfolgen.

Ein Workflow verfügt über die folgenden Eigenschaften:

Migrations-Workflow migration-workflow

Der Migrationsprozess besteht aus zwei Hauptschritten: Analysieren von Abhängigkeiten und Ausführen der Migration. Führen Sie diese Schritte aus, um eine erfolgreiche Migration sicherzustellen.

Schritt 1: Abhängigkeiten analysieren analyze-dependencies

Verwenden Sie vor der Migration den Abhängigkeits-Workflow, um zu ermitteln, was in Ihrer Ziel-Sandbox vom Entscheidungs-Management zum Entscheidungs-Management zugeordnet werden muss. Diese Analyse hilft Ihnen, die Beziehungen zwischen Objekten zu verstehen und die erforderlichen Zuordnungen vorzubereiten.

Erstellen eines Abhängigkeits-Workflows create-dependency-workflow

Verwenden Sie den folgenden API-Aufruf, um einen Workflow zur Abhängigkeitsanalyse zu erstellen.

API-Format

POST /migration/service/dependency

Abhängigkeit auf Sandbox-Ebene (zuerst empfohlen)

Beginnen Sie mit einer Analyse auf Sandbox-Ebene, um einen vollständigen Überblick über alle Abhängigkeiten zu erhalten:

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"
  }'

Abhängigkeit auf Angebotsebene

Um die Abhängigkeiten nur für bestimmte Angebote zu analysieren, legen Sie requestLevel: "offer" fest und stellen Sie ein offersList-Array mit den Angebots-IDs bereit, die Sie analysieren möchten.

Abhängigkeit auf Entscheidungsebene

Um die Abhängigkeiten nur für bestimmte Entscheidungen zu analysieren, legen Sie requestLevel: "decision" fest und stellen Sie ein decisionsList-Array mit den Entscheidungs-IDs bereit, die Sie analysieren möchten.

Überprüfen des Workflow-Status der Abhängigkeit poll-dependency-status

Fragen Sie den Abhängigkeits-Workflow ab, um zu überprüfen, wann die Analyse abgeschlossen ist.

API-Format

GET /migration/service/dependency/{id}

Anfrage

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>"

Wenn das status Feld Completed anzeigt, ist die Abhängigkeitsanalyse bereit. Verwenden Sie die Workflow-Ausgabe, um Ihre Zuordnungen von Migrationsabhängigkeiten zu erstellen:

Schritt 2: Migration ausführen execute-migration

Nachdem Sie die Abhängigkeiten analysiert und die Zuordnungen vorbereitet haben, können Sie die Migration ausführen.

Migrationsprozess erstellen create-migration-workflow

Verwenden Sie die Abhängigkeitszuordnungen aus Schritt 1, um Ihre Migration zu konfigurieren und auszuführen.

API-Format

POST /migration/service/migrations

Migration auf Sandbox-Ebene

So migrieren Sie alle Decisioning-Objekte von einer Sandbox in eine andere:

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 auf Angebotsebene

Um nur bestimmte Angebote zu migrieren, verwenden Sie requestLevel: "offer" und fügen Sie ein offersList-Array hinzu:

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

Migration auf Entscheidungsebene

Um nur bestimmte Entscheidungen zu migrieren, verwenden Sie requestLevel: "decision" und fügen Sie ein decisionsList-Array hinzu:

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

Überwachen des Migrationsstatus poll-migration-status

Abfrage des Migrations-Workflows zur Verfolgung des Fortschritts.

API-Format

GET /migration/service/migrations/{id}

Anfrage

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>"

Migrationsergebnisse

Wenn im Feld status Completed angezeigt wird, war die Migration erfolgreich. Die Workflow-result umfasst:

Wenn das status Feld Failed anzeigt, überprüfen Sie das errors[] Array und result.error Feld für Details zu den Problemen.

Validieren der Migration validate-migration

Überprüfen Sie nach erfolgreichem Abschluss der Migration, ob alle Objekte korrekt migriert wurden.

Validierungs-Checkliste validation-checklist

Beispiel test-runtime-delivery

Wenn bei der Migration ein Datenstrom erstellt wurde, können Sie die Angebotsbereitstellung anhand des folgenden Beispiels testen:

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": [ ... ] }'

Rollback für eine Migration rollback

Wenn Sie während der Validierung Probleme feststellen, können Sie eine abgeschlossene Migration zurücksetzen, um den vorherigen Status der Ziel-Sandbox wiederherzustellen.

Erstellen eines Rollback-Workflows create-rollback-workflow

Starten Sie ein Rollback, indem Sie einen Rollback-Workflow erstellen, der auf die Migration verweist, die Sie zurücksetzen möchten.

API-Format

POST /migration/service/rollbacks/{migrationWorkflowId}

Ersetzen Sie {migrationWorkflowId} durch die ID des Migrations-Workflows, den Sie zurücksetzen möchten.

Anfrage

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>"

Überwachen des Rollback-Status poll-rollback-status

Abruf des Rollback-Workflows zur Verfolgung des Fortschritts.

API-Format

GET /migration/service/rollbacks/{rollbackWorkflowId}

Anfrage

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>"

Gleichzeitige Workflows handhaben handle-concurrency

Mit der Migrations-API kann jeweils nur ein Workflow pro Organisation ausgeführt werden. Wenn Sie versuchen, einen neuen Workflow zu erstellen, während ein anderer ausgeführt wird, erhalten Sie eine 409 Conflict-Fehlerantwort („Ein Workflow ist bereits in Bearbeitung…„).

Warten Sie in diesem Fall, bis der laufende Workflow abgeschlossen ist, oder rufen Sie die Workflow-ID ab und fragen Sie ihren Status ab. Sobald der aktuelle Workflow abgeschlossen ist, können Sie einen neuen erstellen.

Entitätszuordnungsreferenz entity-mapping

Bei der Migration vom Entscheidungs-Management zum Entscheidungs-Management werden Entitäten wie folgt zugeordnet:

Workflow-Bereinigung cleanup

Workflow-Ressourcen können nur von Service-Benutzern gelöscht werden. Löschvorgänge erfordern eine If-Match mit dem _etag des Workflows.

Verfügbare Löschvorgänge:

Verwandte Themen related-topics