記述子エンドポイント
作成対象:
- 開発者
スキーマは、データエンティティの静的表示を定義しますが、これらのスキーマ(データセットなど)に基づくデータが相互にどのように関連付けられるかに関する具体的な詳細は提供しません。Adobe Experience Platform では、記述子を使用して、これらの関係や、記述子に関するその他の解釈的なメタスキーマを記述できます。
スキーマ記述子はテナントレベルのメタデータです。つまり、スキーマ記述子は組織に固有で、すべての記述子の操作はテナントコンテナで行われます。
各スキーマには、1 つ以上のスキーマ記述子エンティティを適用できます。各スキーマ記述子エンティティは、記述子 @type
と、それが適用される sourceSchema
を含みます。適用されると、これらの記述子はスキーマを使用して作成されたすべてのデータセットに適用されます。
Schema Registry API の /descriptors
エンドポイントを使用すると、エクスペリエンスアプリケーション内の記述子をプログラムで管理できます。
はじめに
このガイドで使用するエンドポイントは、Schema Registry API の一部です。 先に進む前に、はじめる前にを参照し、関連ドキュメントへのリンク、このドキュメントのサンプル API 呼び出しを読み取るためのガイドおよび任意の Experience Platform API を正常に呼び出すために必要なヘッダーに関する重要な情報を確認してください。
記述子のリストの取得
/tenant/descriptors
に対してGET リクエストを行うことで、組織で定義されているすべての記述子をリストできます。
API 形式
GET /tenant/descriptors
リクエスト
curl -X GET \
https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-H 'Accept: application/vnd.adobe.xdm-link+json'
応答の形式は、リクエストで送信される Accept
ヘッダーによって異なります。 /descriptors
エンドポイントで使用される Accept
ヘッダーが、Schema Registry API の他のすべてのエンドポイントとは異なることに注意してください。
xed
を xdm
に置き換える一意の Accept
ヘッダーが必要で、記述子に固有の link
オプションも提供します。 以下の呼び出し例では適切な Accept
ヘッダーが含まれていますが、記述子を操作する際には正しいヘッダーが使用されるよう、細心の注意を払ってください。Accept
ヘッダーapplication/vnd.adobe.xdm-id+json
application/vnd.adobe.xdm-link+json
application/vnd.adobe.xdm+json
application/vnd.adobe.xdm-v2+json
Accept
ヘッダーを使用する必要があります。応答
応答には、定義された記述子を持つ各記述子タイプの配列が含まれます。つまり、ある種の @type
記述子が定義されていない場合、その記述子型の空の配列は返されません。
link
Accept
ヘッダーを使用する場合、各記述子は配列項目として /{CONTAINER}/descriptors/{DESCRIPTOR_ID}
の形式で表示されます
{
"xdm:alternateDisplayInfo": [
"/tenant/descriptors/85dc1bc8b91516ac41163365318e38a9f1e4f351",
"/tenant/descriptors/49bd5abb5a1310ee80ebc1848eb508d383a462cf",
"/tenant/descriptors/b3b3e548f1c653326bcf5459ceac4140fc0b9e08"
],
"xdm:descriptorIdentity": [
"/tenant/descriptors/f7a4bc25429496c4740f8f9a7a49ba96862c5379"
],
"xdm:descriptorOneToOne": [
"/tenant/descriptors/cb509fd6f8ab6304e346905441a34b58a0cd481a"
]
}
記述子の検索
特定の記述子の詳細を表示したい場合は、個々の記述子をその @id
を使って検索(GET)できます。
API 形式
GET /tenant/descriptors/{DESCRIPTOR_ID}
{DESCRIPTOR_ID}
@id
。リクエスト
次のリクエストは、@id
値で記述子を取得します。 記述子はバージョン管理されないので、参照リクエストでは Accept
ヘッダーは必要ありません。
curl -X GET \
https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors/f3a1dfa38a4871cf4442a33074c1f9406a593407 \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}'
応答
正常な応答は、記述子の詳細(@type
および sourceSchema
を含む)と、記述子の種類に応じて変化する追加情報を返します。返される @id
は、リクエストで指定された記述子 @id
と一致する必要があります。
{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/personalEmail/address",
"xdm:namespace": "Email",
"xdm:property": "xdm:code",
"xdm:isPrimary": false,
"createdUser": "{CREATED_USER}",
"imsOrg": "{ORG_ID}",
"createdClient": "{CREATED_CLIENT}",
"updatedUser": "{UPDATED_USER}",
"created": 1548899346989,
"updated": 1548899346989,
"meta:containerId": "tenant",
"@id": "f3a1dfa38a4871cf4442a33074c1f9406a593407"
}
記述子の作成
/tenant/descriptors
エンドポイントに POST リクエストを実行することで、新しい記述子を作成できます。
API 形式
POST /tenant/descriptors
リクエスト
次のリクエストでは、スキーマ例の「email address」フィールドに ID 記述子を定義します。この情報は、個人に関 Experience Platform る情報をつなぎ合わせるのに役立つ識別子として、メールアドレスを使用するようにユーザーに指示します。
curl -X POST \
https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-d '
{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/personalEmail/address",
"xdm:namespace": "Email",
"xdm:property": "xdm:code",
"xdm:isPrimary": false
}'
応答
正常な応答は、新しく作成された記述子の詳細(@id
を含む)と共に HTTP ステータス 201(作成済み)を返します。@id
は、Schema Registry によって割り当てられ、API で記述子を参照するために使用される読み取り専用フィールドです。
{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/personalEmail/address",
"xdm:namespace": "Email",
"xdm:property": "xdm:code",
"xdm:isPrimary": false,
"meta:containerId": "tenant",
"@id": "f3a1dfa38a4871cf4442a33074c1f9406a593407"
}
記述子の更新
PUT リクエストのパスに @id
を含めることで、記述子を更新できます。
API 形式
PUT /tenant/descriptors/{DESCRIPTOR_ID}
{DESCRIPTOR_ID}
@id
。リクエスト
このリクエストは、基本的に記述子を書き換えるので、リクエスト本文には、そのタイプの記述子を定義するために必要なすべてのフィールドを含める必要があります。 つまり、記述子を更新(PUT)するリクエストペイロードは、同じタイプの記述子を 作成(POST するペイロードと同じです。
次の例では、別の xdm:sourceProperty
(mobile phone
)を参照するように ID 記述子を更新し、xdm:namespace
を Phone
に変更します。
curl -X PUT \
https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors/f3a1dfa38a4871cf4442a33074c1f9406a593407 \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'Content-Type: application/json' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-d '{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/mobilePhone/number",
"xdm:namespace": "Phone",
"xdm:property": "xdm:code",
"xdm:isPrimary": false
}'
応答
正常な応答は、更新された記述子の @id
(リクエストで送信された @id
と一致する必要がある)と共に、HTTP ステータス 201(作成済み)を返します。
{
"@id": "f3a1dfa38a4871cf4442a33074c1f9406a593407"
}
記述子を表示するために 参照(GET)リクエストを実行すると、フィールドが更新され、PUT リクエストで送信された変更が反映されていることを示します。
記述子の削除
Schema Registry から定義した記述子を削除する必要が生じる場合があります。 これは、削除する記述子の @id
を参照するDELETE リクエストを実行することで行います。
API 形式
DELETE /tenant/descriptors/{DESCRIPTOR_ID}
{DESCRIPTOR_ID}
@id
。リクエスト
curl -X DELETE \
https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors/ca921946fb5281cbdb8ba5e07087486ce531a1f2 \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}'
応答
リクエストが成功した場合は、HTTP ステータス 204(コンテンツなし)が空白の本文とともに返されます。
記述子が削除されたことを確認するには、記述子 @id
に対して 参照リクエストを実行します。 記述子が Schema Registry から削除されたので、応答は HTTP ステータス 404 (見つかりません)を返します。
付録
次の節では、Schema Registry API での記述子の操作に関する追加情報を示します。
記述子の定義
以下の節では、使用可能な記述子の型の概要を示します。各型の記述子を定義するための必須フィールドも含まれます。
ID 記述子
ID 記述子は、[Adobe Experience Platform ID サービス ] で説明されているように、「sourceSchema」の「sourceProperty」が Identity フィールドであることを示します。
{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema":
"https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/personalEmail/address",
"xdm:namespace": "Email",
"xdm:property": "xdm:code",
"xdm:isPrimary": false
}
@type
xdm:descriptorIdentity
に設定する必要があります。xdm:sourceSchema
$id
URI。xdm:sourceVersion
xdm:sourceProperty
xdm:namespace
xdm:property
xdm:id
または xdm:code
(使用されている xdm:namespace
に応じる)。xdm:isPrimary
わかりやすい名前記述子
わかりやすい名前記述子を使用すると、ユーザーは、コアライブラリスキーマフィールドの title
、description
、meta:enum
の値を変更できます。 特に、「eVar」および組織に固有の情報を含むとしてラベル付けする他の「汎用」フィールドを扱う場合に役立ちます。UI は、これらを使用して、わかりやすい名前を表示したり、わかりやすい名前を持つフィールドのみを表示したりできます。
{
"@type": "xdm:alternateDisplayInfo",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/274f17bc5807ff307a046bab1489fb18",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/xdm:eventType",
"xdm:title": {
"en_us": "Event Type"
},
"xdm:description": {
"en_us": "The type of experience event detected by the system."
},
"meta:enum": {
"click": "Mouse Click",
"addCart": "Add to Cart",
"checkout": "Cart Checkout"
},
"xdm:excludeMetaEnum": {
"web.formFilledOut": "Web Form Filled Out",
"media.ping": "Media ping"
}
}
@type
xdm:alternateDisplayInfo
に設定する必要があります。xdm:sourceSchema
$id
URI。xdm:sourceVersion
xdm:sourceProperty
/
)で始める必要があり、1 で終わる必要はありません。 パスに properties
を含めないでください(例えば、/properties/personalEmail/properties/address
の代わりに /personalEmail/address
を使用します)。xdm:title
xdm:description
meta:enum
xdm:sourceProperty
で示されるフィールドが文字列フィールドの場合、セグメント化 UI でフィールドの推奨値を追加するために meta:enum
を使用できます。 XDM フィールドについては、定義済みリストを宣言 meta:enum
たり、データ検証を行ったりしないことに注意してください。これは、Adobeで定義されたコア XDM フィールドにのみ使用してください。 ソースプロパティが組織で定義されたカスタムフィールドの場合は、代わりに、PATCH リクエストを使用してフィールドの
meta:enum
プロパティをフィールドの親リソースに直接編集する必要があります。meta:excludeMetaEnum
xdm:sourceProperty
で示されるフィールドが、meta:enum
フィールドの下で提供された既存の推奨値を持つ文字列フィールドである場合、このオブジェクトをフレンドリ名記述子に含めて、これらの値の一部またはすべてをセグメント化から除外できます。 エントリを除外するには、各エントリのキーと値が、フィールドの元の meta:enum
に含まれる値と一致する必要があります。関係記述子
関係記述子は、sourceProperty
と destinationProperty
で説明されているプロパティに基づいて、2 つの異なるスキーマ間の関係を記述します。詳しくは、2 つのスキーマ間の関係の定義に関するチュートリアルを参照してください。
{
"@type": "xdm:descriptorOneToOne",
"xdm:sourceSchema":
"https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/parentField/subField",
"xdm:destinationSchema":
"https://ns.adobe.com/{TENANT_ID}/schemas/78bab6346b9c5102b60591e15e75d254",
"xdm:destinationVersion": 1,
"xdm:destinationProperty": "/parentField/subField"
}
@type
xdm:descriptorOneToOne
に設定される必要があります。 B2B editionでは、xdm:descriptorOneToOne
または xdm:descriptorRelationship
を使用できます。xdm:sourceSchema
$id
URI。xdm:sourceVersion
xdm:sourceProperty
xdm:destinationSchema
$id
URI。xdm:destinationVersion
xdm:destinationProperty
B2B 関係記述子
Real-Time CDP B2B editionでは、スキーマ間の関係を定義する別の方法が導入されており、多対 1 の関係が可能になります。 この新しい関係のタイプは @type: xdm:descriptorRelationship
である必要があり、ペイロードには @type: xdm:descriptorOneToOne
の関係よりも多くのフィールドを含める必要があります。 詳しくは、B2B editionのスキーマ関係の定義に関するチュートリアルを参照してください。
{
"@type": "xdm:descriptorRelationship",
"xdm:sourceSchema" : "https://ns.adobe.com/{TENANT_ID}/schemas/9f2b2f225ac642570a110d8fd70800ac0c0573d52974fa9a",
"xdm:sourceVersion" : 1,
"xdm:sourceProperty" : "/person-ref",
"xdm:destinationSchema" : "https://ns.adobe.com/{TENANT_ID/schemas/628427680e6b09f1f5a8f63ba302ee5ce12afba8de31acd7",
"xdm:destinationVersion" : 1,
"xdm:destinationProperty": "/personId",
"xdm:destinationNamespace" : "People",
"xdm:destinationToSourceTitle" : "Opportunity Roles",
"xdm:sourceToDestinationTitle" : "People",
"xdm:cardinality": "M:1"
}
@type
xdm:descriptorRelationship
に設定する必要があります。 その他のタイプについて詳しくは、 関係記述子の節を参照してください。xdm:sourceSchema
$id
URI。xdm:sourceVersion
xdm:sourceProperty
xdm:destinationSchema
$id
URI。xdm:destinationVersion
xdm:destinationProperty
xdm:destinationNamespace
xdm:destinationToSourceTitle
xdm:sourceToDestinationTitle
xdm:cardinality
M:1
に設定する必要があります。参照 ID 記述子
参照 ID 記述子は、スキーマフィールドのプライマリ ID への参照コンテキストを提供し、他のスキーマのフィールドから参照できるようにします。 この記述子を使用して他のスキーマが参照するには、参照スキーマにプライマリ ID フィールドが既に定義されている必要があります。
{
"@type": "xdm:descriptorReferenceIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/78bab6346b9c5102b60591e15e75d254",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/parentField/subField",
"xdm:identityNamespace": "Email"
}
@type
xdm:descriptorReferenceIdentity
に設定する必要があります。xdm:sourceSchema
$id
URI。xdm:sourceVersion
xdm:sourceProperty
/properties/personalEmail/properties/address
の代わりに /personalEmail/address
)。xdm:identityNamespace
非推奨のフィールド記述子
該当するフィールドに deprecated
に設定された meta:status
属性を追加することで 🔗 カスタム XDM リソース内のフィールドを非推奨(廃止予定 にすることができます。 ただし、スキーマ内の標準 XDM リソースで提供されるフィールドを非推奨(廃止予定)にする場合は、当該のスキーマに非推奨(廃止予定)のフィールド記述子を割り当てて、同じ効果を得ることができます。 correct Accept
ヘッダーを使用すると、API で検索する際に、スキーマで非推奨になっている標準フィールドを表示できます。
{
"@type": "xdm:descriptorDeprecated",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/c65ddf08cf2d4a2fe94bd06113bf4bc4c855e12a936410d5",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/faxPhone"
}
@type
xdm:descriptorDeprecated
に設定する必要があります。xdm:sourceSchema
$id
。xdm:sourceVersion
1
に設定してください。xdm:sourceProperty
["/firstName", "/lastName"]
)で指定します。