[Alpha]{class="badge informative"}

Platform-Services

Der Server-SDK teilt seine Kernlogik mit dem Web-SDK. Alles, was von der Umgebung abhängt, z. B. das Senden von Netzwerkanfragen, das Lesen von Cookies oder das Speichern von Daten, durchläuft einen Satz von Platform-Services. Die SDK umfasst Standarddienste, die nur Web-Standard-APIs verwenden, sodass sie in jeder Laufzeit funktionieren, die die Anforderungen erfüllt. Sie können alle durch Ihre eigene Implementierung ersetzen.

Die meisten Implementierungen müssen keine Services ersetzen. Der häufigste Grund für die Ersetzung ist die Bereitstellung eines cookie-Service, damit ein Besucher über Anfragen hinweg dieselbe Identität und dasselbe Einverständnis behält.

Übergeben von Diensten where

Sie können Dienste an zwei Stellen übergeben:

import { createInstance } from "@adobe/alloy-node";

// Applies to the top-level instance. Handles reuse network, runtime, legacy, and globals.
const alloy = createInstance({
  platformServices: {
    runtime: myRuntimeService
  }
});

await alloy.configure({
  datastreamId: "ebebf826-a01f-4458-8cec-ef61de241c93",
  orgId: "ADB3LETTERSANDNUMBERS@AdobeOrg",
  edgeCredentials: {
    clientId: process.env.ADOBE_CLIENT_ID,
    clientSecret: process.env.ADOBE_CLIENT_SECRET,
    scopes: process.env.ADOBE_SCOPES.split(",")
  }
});

// Applies only to this handle
const visitor = alloy.forRequest({
  request: req,
  cookie: myCookieServiceForThisVisitor,
  storage: myStorageServiceForThisVisitor
});

Die Schnittstellen für jeden Service werden in packages/core/src/services/types.ts im adobe/alloy-Repository auf GitHub definiert. Wenn Sie einen Service ersetzen, muss Ihre Implementierung alle Methoden in der Schnittstelle bereitstellen.

Verfügbare Services services

Cookie-Dienst cookie

Die SDK speichert die Identität (ECID) und Einverständnisvoreinstellungen jedes Besuchers in Cookies. Auf einem Server liest und schreibt es diese Cookies über den cookie-Service. Der Cookie-Dienst muss die folgenden Methoden bereitstellen:

Der standardmäßige Cookie-Dienst speichert Cookies nur im Speicher:

Der SDK umfasst keinen Cookie-Service, der die Cookie-Header des Besuchers liest und Set-Cookie Antwort-Header schreibt. Um die Identität und das Einverständnis eines Besuchers über Anfragen hinweg zu bewahren, müssen Sie für jede Anfrage eine eigene Implementierung bereitstellen und eine neue übergeben, die forRequest werden soll.

Speicherdienst storage

Der SDK verwendet den storage-Service, um sich einige Werte zu merken, z. B. ob das Debugging mit setDebug aktiviert ist, welche Einverständnisvoreinstellungen bereits gesendet setConsent und die Client-ID, die Adobe Experience Platform Assurance zum Überprüfen von Anfragen verwendet. Der standardmäßige Speicher-Service speichert Daten im Arbeitsspeicher.

Jedes forRequest erhält einen neuen, leeren Speicherdienst, es sei denn, Sie übergeben einen. Wenn Sie Assurance verwenden und möchten, dass die Assurance-Client-ID eines Besuchers bei allen Anfragen gleich bleibt, übergeben Sie einen storage-Service für diesen Besucher an forRequest.

Netzwerkdienst network

Der standardmäßige Netzwerk-Service sendet -Anfragen mit der globalen fetch. Wenn Sie eine request an forRequest übergeben, werden auch die Header der Besucher zu jeder Anfrage hinzugefügt. Siehe Kontext und weitergeleitete Kopfzeilen.

Um den Netzwerkdienst zu ersetzen, übergeben Sie eine function, die die Protokollierung der SDK empfängt und einen Netzwerkdienst zurückgibt, anstatt das Dienstobjekt selbst zu übergeben:

const alloy = createInstance({
  platformServices: {
    network: (logger) => myNetworkService
  }
});