記述子エンドポイント
スキーマはデータエンティティの構造を定義しますが、これらのスキーマから作成されたデータセットの相関関係は指定しません。 Adobe Experience Platformでは、記述子を使用してこれらの関係を記述し、スキーマに解釈可能なメタデータを追加できます。
記述子は、Adobe Experience Platformのスキーマに適用されるテナントレベルのメタデータオブジェクトです。 ダウンストリームでのデータの検証、結合、解釈の方法に影響を与える構造の関係、キー、行動フィールド(タイムスタンプやバージョン管理など)を定義します。
スキーマには、1 つ以上の記述子を含めることができます。 各記述子は、@type
と、それが適用される sourceSchema
を定義します。 記述子は、そのスキーマから作成されたすべてのデータセットに自動的に適用されます。
Adobe Experience Platformでは、記述子は、スキーマに動作規則や構造的意味を追加するメタデータです。
記述子には次のようないくつかのタイプがあります。
/descriptors
API の Schema Registry エンドポイントを使用すると、エクスペリエンスアプリケーション内の記述子をプログラムで管理できます。
はじめに
このガイドで使用するエンドポイントは、Schema Registry API の一部です。 先に進む前に、はじめる前にを参照し、関連ドキュメントへのリンク、このドキュメントのサンプル API 呼び出しを読み取るためのガイドおよび任意の Experience Platform API を正常に呼び出すために必要なヘッダーに関する重要な情報を確認してください。
Schema Registry は、標準の記述子に加えて、プライマリキー、バージョン、タイムスタンプ など、モデルベースのスキーマの記述子タイプをサポートしています。 これらは、一意性の強制、バージョン管理の制御、スキーマレベルでの時系列フィールドの定義を行います。 モデルベースのスキーマに慣れていない場合は、先に進む前に Data Mirrorの概要および モデルベースのスキーマのテクニカルリファレンスを確認してください。
記述子のリストの取得 list
/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 の他のすべてのエンドポイントとは異なることに注意してください。
Accept
を xed
に置き換える一意の xdm
ヘッダーが必要で、記述子に固有の 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"
]
}
記述子の検索 lookup
特定の記述子の詳細を表示するには、@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"
}
記述子の作成 create
/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
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 リクエストで送信された変更が反映されていることを示します。
記述子の削除 delete
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 (見つかりません)を返します。
付録 appendix
次の節では、Schema Registry API での記述子の操作に関する追加情報を示します。
記述子の定義 defining-descriptors
以下の節では、使用可能な記述子の型の概要を示します。各型の記述子を定義するための必須フィールドも含まれます。
ID 記述子 identity-descriptor
ID 記述子は、Experience Platform ID サービス で説明されているように、「sourceSchema」の「IdentitysourceProperty」がフィールドであることを示します。
{
"@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
わかりやすい名前記述子 friendly-name
わかりやすい名前記述子を使用すると、ユーザーは、コアライブラリスキーマフィールドの 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
を含めないでください(例えば、/personalEmail/address
の代わりに /properties/personalEmail/properties/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
に含まれる値と一致する必要があります。関係記述子 relationship-descriptor
関係記述子は、xdm:sourceProperty
と xdm:destinationProperty
で説明されているプロパティに基づいて、2 つの異なるスキーマ間の関係を記述します。詳しくは、2 つのスキーマ間の関係の定義に関するチュートリアルを参照してください。
これらのプロパティを使用して、ソースフィールド(外部キー)と宛先フィールド( プライマリキーまたは候補キー)の関係を宣言します。
xdm:sourceProperty
で定義)です。 候補キー とは、レコードを一意に識別する、宛先スキーマ内の任意のフィールド(またはフィールドのセット)であり、プライマリキーの代わりに使用できます。この API は、次の 2 つのパターンをサポートしています。
xdm:descriptorOneToOne
:標準 1:1 関係。xdm:descriptorRelationship
:新しい作業およびモデルベースのスキーマの一般的なパターン(カーディナリティ、命名および非プライマリキーのターゲットをサポート)。
1 対 1 の関係(標準スキーマ)
既に xdm:descriptorOneToOne
に依存している既存の標準スキーマ統合を維持する場合は、これを使用します。
{
"@type": "xdm:descriptorOneToOne",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SOURCE_SCHEMA_ID}",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/parentField/subField",
"xdm:destinationSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{DEST_SCHEMA_ID}",
"xdm:destinationVersion": 1,
"xdm:destinationProperty": "/parentField/subField"
}
次の表に、1 対 1 関係記述子を定義するために必要なフィールドを示します。
@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
一般的な関係(モデルベースのスキーマで、新規プロジェクトに推奨)
この記述子は、すべての新規実装と、モデルベースのスキーマに使用します。 関係のカーディナリティ(1 対 1 または多対 1 など)を定義し、関係名を指定して、プライマリキー(非プライマリキー)以外の宛先フィールドにリンクできます。
次の例は、一般的な関係記述子の定義方法を示しています。
最小限の例:
この最小限の例には、2 つのスキーマ間の多対 1 の関係を定義するための必須フィールドのみが含まれています。
{
"@type": "xdm:descriptorRelationship",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SOURCE_SCHEMA_ID}",
"xdm:sourceProperty": "/customer_ref",
"xdm:sourceVersion": 1,
"xdm:destinationSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{DEST_SCHEMA_ID}",
"xdm:cardinality": "M:1"
}
すべてのオプションフィールドを使用した例:
この例には、リレーションシップ名、表示タイトル、明示的な非プライマリ キーのリンク先フィールドなど、すべてのオプション フィールドが含まれています。
{
"@type": "xdm:descriptorRelationship",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SOURCE_SCHEMA_ID}",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/customer_ref",
"xdm:destinationSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{DEST_SCHEMA_ID}",
"xdm:destinationProperty": "/customer_id",
"xdm:sourceToDestinationName": "CampaignToCustomer",
"xdm:destinationToSourceName": "CustomerToCampaign",
"xdm:sourceToDestinationTitle": "Customer campaigns",
"xdm:destinationToSourceTitle": "Campaign customers",
"xdm:cardinality": "M:1"
}
関係記述子の選択
次のガイドラインを使用して、適用する関係記述子を決定します。
xdm:descriptorRelationship
xdm:descriptorOneToOne
でのみサポートされる機能が必要な場合を除き、xdm:descriptorRelationship
を使用し続けます。1:1
、1:0
、M:1
、M:0
)が必要xdm:descriptorRelationship
xdm:descriptorRelationship
xdm:descriptorRelationship
xdm:descriptorOneToOne
記述子の場合、非プライマリ ID 宛先ターゲット、カスタムネーミング、拡張カーディナリティなどの機能が必要な場合以外は、それらを引き続き使用してください。機能の比較
次の表では、2 つの記述子タイプの機能を比較しています。
xdm:descriptorOneToOne
xdm:descriptorRelationship
xdm:destinationProperty
を使用した非プライマリキーxdm:sourceToDestinationName
、xdm:destinationToSourceName
およびタイトル制約と検証
一般的な関係記述子を定義する際は、次の要件と推奨事項に従います。
- モデルベースのスキーマの場合は、ルートレベルのソースフィールド(外部キー)を配置します。 これは、取得に関する現在の技術的な制限で、ベストプラクティスの推奨事項だけではありません。
- ソースおよび宛先フィールドのデータタイプに互換性があることを確認します(数値、日付、ブール値、文字列)。
- カーディナリティは情報目的であることに注意してください。ストレージでは適用されません。 カーディナリティを
<source>:<destination>
形式で指定します。 指定できる値は、1:1
、1:0
、M:1
、M:0
です。
プライマリキー記述子 primary-key-descriptor
プライマリキー記述子(xdm:descriptorPrimaryKey
)は、スキーマの 1 つ以上のフィールドに対して一意性と null 以外の制約を適用します。
{
"@type": "xdm:descriptorPrimaryKey",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SCHEMA_ID}",
"xdm:sourceProperty": ["/orderId", "/orderLineId"]
}
@type
xdm:descriptorPrimaryKey
である必要があります。xdm:sourceSchema
$id
マの URI。xdm:sourceProperty
バージョン記述子 version-descriptor
バージョン記述子(xdm:descriptorVersion
)は、順不同の変更イベントによる競合を検出して防ぐフィールドを指定します。
{
"@type": "xdm:descriptorVersion",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SCHEMA_ID}",
"xdm:sourceProperty": "/versionNumber"
}
@type
xdm:descriptorVersion
である必要があります。xdm:sourceSchema
$id
マの URI。xdm:sourceProperty
required
とマークする必要があります。タイムスタンプ記述子 timestamp-descriptor
タイムスタンプ記述子(xdm:descriptorTimestamp
)は、"meta:behaviorType": "time-series"
を含むスキーマのタイムスタンプとして日時フィールドを指定します。
{
"@type": "xdm:descriptorTimestamp",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/{SCHEMA_ID}",
"xdm:sourceProperty": "/eventTime"
}
@type
xdm:descriptorTimestamp
である必要があります。xdm:sourceSchema
$id
マの URI。xdm:sourceProperty
required
とマークされ、date-time
タイプである必要があります。B2B 関係記述子 B2B-relationship-descriptor
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:sourceProperty
と互換性のあるデータタイプを持つ別のフィールドに解決される必要があります。 省略すると、関係が期待どおりに機能しない可能性があります。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
/personalEmail/address
の代わりに /properties/personalEmail/properties/address
)。xdm:identityNamespace
非推奨のフィールド記述子
該当するフィールドに に設定された属性を追加することで meta:status
カスタム XDM リソース内のフィールドを非推奨(廃止予定 deprecated
にすることができます。 ただし、スキーマ内の標準 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"]
)で指定します。