[Alpha]{class="badge informative"}

インスタンスとリクエスト

ブラウザーでは、ページの読み込みごとに、1人の訪問者に対して提供されるWeb SDKの新しいコピーが開始されます。 サーバーが違う。 1つの長時間実行プロセスで、多くの訪問者からのリクエストを処理します。多くの場合、同時に処理します。 Server SDKは、プロセスごとに1回実行される作業と、各訪問者のリクエストに対して実行される作業を分離します。

サーバーの起動時に1回設定 configure-once

1つのインスタンスを作成し、サーバーがリクエストの受け入れを開始する前に設定します。 設定が完了する前に呼び出すとforRequestがエラーをスローするため、configureが解決されるのを待ちます。

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

const alloy = createInstance();

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(",")
  }
});

例えば、オプションが無効であるためにconfigureが拒否した場合、インスタンスは未設定のままになり、forRequestはconfigureへの呼び出しが成功するまでスローを続けます。

各リクエストのforRequestの呼び出し for-request

各受信リクエストについて、forRequestを呼び出して、受信リクエストオブジェクトを渡します。 返されるハンドルには、configureとforRequestを除き、インスタンスと同じメソッドがあります。

次の例では、Node.js組み込みのnode:http モジュールを使用しています。 同じパターンは、ExpressやFastifyなどの受信リクエストオブジェクトを与える任意のフレームワークで機能します。

import { createServer } from "node:http";

createServer(async (req, res) => {
  const visitor = alloy.forRequest({ request: req });

  try {
    await visitor.sendEvent({
      xdm: {
        eventType: "web.webpagedetails.pageViews",
        identityMap: {
          Email: [{ id: "visitor@example.com", primary: true }]
        }
      }
    });
  } catch (error) {
    console.error("Failed to send event to Adobe", error);
  }

  res.end("OK");
}).listen(3000);

ランタイムまたはフレームワークがFetch API Requestをハンドラーに渡し、その代わりにResponseを期待する場合は、同じパターンを使用します。 ランタイムまたはフレームワークが必要とする方法でハンドラーを登録します。

async function handleRequest(request) {
  const visitor = alloy.forRequest({ request });

  try {
    await visitor.sendEvent({
      xdm: {
        eventType: "web.webpagedetails.pageViews",
        identityMap: {
          Email: [{ id: "visitor@example.com", primary: true }]
        }
      }
    });
  } catch (error) {
    console.error("Failed to send event to Adobe", error);
  }

  return new Response("OK");
}

各ハンドルは、configureに渡したのと同じオプションで設定された独自のSDK インスタンスによってバックアップされます。 ハンドルは訪問者の状態を互いに共有しないため、ある訪問者のIDまたは同意が別の訪問者のリクエストに漏れることはありません。

requestを渡すと、SDKは訪問者のヘッダー（User-Agent、Accept-Language、X-Forwarded-Forなど）をEdge Networkに転送できます。 ​ コンテキストと転送ヘッダーを参照してください。

何が共有され、何がリクエストごとにあるか scope

リクエストをまたいだIDと同意 identity

SDKは、Web SDKと同じように、訪問者のExperience Cloud ID （ECID）と同意設定をCookieに保存します。 サーバー上で、SDKはこれらのCookieを​ cookie サービス ​を通じて読み取り、書き込みます。このサービスはforRequestにcookie プロパティとして渡されます。

SDKには、HTTP CookieおよびSet-Cookie ヘッダーの読み取りと書き込みを行うCookie サービスは含まれていません。 複数のリクエストをまたいで訪問者のIDと同意を維持するには、Cookie サービスインターフェイスを独自に実装します。 Platform サービス ​を参照してください。

訪問者トラフィックのトップレベルインスタンスを避ける top-level

sendEventなどのメソッドは、createInstanceが返すインスタンスで直接呼び出すことができます。 これは、設定をテストしたり、特定の訪問者に属していないイベントを送信したりするのに便利です。 ただし、トップレベルインスタンスは、プロセスの有効期間に対して1つのメモリ内Cookie ストアを保持します。 呼び出しのたびに、呼び出しをトリガーした訪問者に関係なく、同じIDが共有されます。 代わりに、各訪問者のリクエストにforRequest ハンドルを使用してください。