# mulesoft Datagraph - Full Documentation # Anypoint DataGraph API 拡張機能リファレンス このガイドでは、DataGraph の API 拡張機能を定義します。 ## [](#オブジェクト種別拡張機能)オブジェクト種別拡張機能 この拡張機能により、オブジェクト種別に主キーがあり、リファレンスまたは拡張機能として使用できることがマークされます。 この拡張機能は、​`ObjectType`​ に適用されます。 ### [](#構造)構造
項目 型 説明

entity

Map (マップ)

オブジェクト種別をエンティティとしてマークします。

entity.key

String (文字列)

空にできない配列。各項目は、エンティティのキーである項目を参照する必要があります。

### [](#oas-の例)OAS の例 ```copy components: schemas: Customer: x-entity: key: [id] properties: name: type: string email: type: string id: type: string ... ``` ### [](#raml-の例)RAML の例 ```copy types: Customer: (dg.entity): key: [id] properties: name: type: string email: type: string id: type: string ... ``` ## [](#エンティティリファレンス)エンティティリファレンス この拡張機能により、1 つの種別から別の種別への DataGraph ​_リンク_​が生成されます。リンクは、同じ API 仕様で定義されない種別にできます。 この拡張機能は、​`ObjectType`​ に適用されます。 ### [](#構造-2)構造
項目 型 説明

entity-reference

オブジェクトの配列

すべてのリファレンスのリスト。

entity-reference.[n].name

String (文字列)

参照される種別の名前。API に含まれる場合も含まれない場合もあります。

entity-reference.[n].fieldName

String (文字列)

この種別について作成される新しい項目の名前。

entity-reference.[n].keyMapping

Map (マップ)

マップのキーはこの種別の項目を表しており、値は参照される種別のキーを表しています。

### [](#oas-の例-2)OAS の例 ```copy components: Schemas: Order: x-entity-reference: - name: Customer fieldName: customer keyMapping: customerId: id - name: Store fieldName: store keyMapping: storeId: id properties: orderItems: ... customerId: type: string storeId: type: string Customer: x-entity: key: [id] properties: name: type: string email: type: string id: type: string Store: x-entity: key: [id] properties: name: type: string id: type: string ... ``` ### [](#raml-の例-2)RAML の例 ```copy types: Order: (dg.entity-reference): - name: Customer fieldName: customer keyMapping: customerId: id - name: Store fieldName: store keyMapping: storeId: id properties: orderItems: ... customerId: type: string storeId: type: string Customer: (dg.entity): key: [id] properties: name: type: string email: type: string id: type: string ... Store: (dg.entity): key: [id] properties: name: type: string id: type: string ``` ## [](#エンティティプロバイダー)エンティティプロバイダー この拡張機能では、エンドポイントが ID によってエンティティのインスタンスを返すとマークします。 DataGraph では、これは​_デフォルトのクエリ方法_​です。 この拡張機能は、GET 操作に適用されます。 ### [](#構造-3)構造 対象は操作で暗黙的であるため、指定されません。
項目 型 説明

entity-provider

Map (マップ)

エンドポイントがエンティティインスタンスを返すとマークします。

entity-reference.keyMapping

Map (マップ)

マップのキーはこの操作のパラメーターを表しており、値は対象種別のキーを表しています。

### [](#oas-の例-3)OAS の例 ```copy Schemas: Customer: x-entity: key: [id] properties: name: type: string email: type: string 1: type: string ... paths: "/customers/{customerId}": get: x-entityProvider: keyMapping: customerId: id parameters: - in: query name: summaryView default: true schema: type: boolean ... responses: '200': content: application/json: schema: $ref: "#/components/schemas/Customer" ``` ### [](#raml-の例-3)RAML の例 ```copy types: Customer: (dg.entity): key: [id] properties: name: type: string email: type: string id: type: string … /customer/{customerId}: uriParameters: customerId: string get: (dg.entityProvider): keyMapping: customerId: id responses: 200: application/json: body: Customer ``` ## [](#http-メソッドの上書き)HTTP メソッドの上書き この拡張機能を使用して、POST メソッドを GET メソッドとして扱います。この拡張機能では、POST メソッドを変異ではなくクエリ操作に変換します。 この拡張機能は、操作に適用されます。 ### [](#構造-4)構造 対象は操作で暗黙的であるため、指定されません。
項目 型 説明

​http-method-override

Map (マップ)

上書きされる操作をマークします。

​http-method-override.method

String (文字列)

元の操作を上書きするために使用される HTTP メソッド。

### [](#oas-の例-4)OAS の例 ```copy paths: "/customers": post: x-http-method-override: method: get responses: '200': content: application/json: schema: type: array items: $ref: "#/components/schemas/Customer" ``` ### [](#raml-の例-4)RAML の例 ```copy /customers: post: (dg.http-method-override): method: get responses: 200: body: application/json: type: Customer[] ``` ## [](#datagraph-固有の拡張機能)DataGraph 固有の拡張機能 メインのアノテーション ​`datagraph`​ を異なるドメインで同じ名前にすることはできません。そのため、操作、種別、オブジェクトプロパティのアノテーションではポストフィックスを使用します。 - 操作: -method - 種別: -type - オブジェクトプロパティ: -field ### [](#非表示)非表示 この拡張機能を使用して、要素を非表示とマークします。非表示の要素は統合スキーマに表示されず、DataGraph ではどのクエリでも非表示の要素が返されません。 この拡張機能は、以下に適用されます。 - 操作 - 任意の種別 - オブジェクトプロパティ ### [](#構造-5)構造 対象は操作で暗黙的であるため、指定されません。
項目 型 説明

​datagraph

Map (マップ)

DataGraph 固有のアノテーションのコンテナ。

​datagraph.hide

Boolean (ブール)

true​ の場合、要素は統合スキーマで非表示になります。​false​ の場合、要素は非表示にならず、アノテーションを設定しなかった場合と同じ結果が得られます。

### [](#oas-の例-5)OAS の例 ```copy components: Schemas: Customer: x-datagraph: hide: true properties: name: type: string email: type: string x-datagraph: hide: true id: type: string ... paths: "/customers/{customerId}": get: x-datagraph: hide: true parameters: - in: query name: summaryView default: true schema: type: boolean ... responses: '200': content: application/json: schema: $ref: "#/components/schemas/Customer" ``` ### [](#raml-の例-5)RAML の例 ```copy types: Customer: (dg.datagraph): hide: true properties: name: type: string email: type: string (dg.datagraph): hide: true id: type: string … /customer/{customerId}: uriParameters: customerId: string get: (dg.datagraph): hide: true responses: 200: application/json: body: Customer ``` ## [](#名前)名前 この拡張機能を使用して、統合スキーマの要素に特定の名前を定義するなど、DataGraph で要素の目的の名前を設定します。この拡張機能を使用して、基礎となる API を変更することなく、さまざまな API の種別を統合できます。 この拡張機能は、以下に適用されます。 - 操作 - 任意の種別 - オブジェクトプロパティ ### [](#構造-6)構造 対象は操作で暗黙的であるため、指定されません。
項目 型 説明

​datagraph

Map (マップ)

DataGraph 固有のアノテーションのコンテナ。

​datagraph.name

String (文字列)

DataGraph の要素の目的の名前。可能であれば、有効な名前にパターンを使用してください。

### [](#oas-の例-6)OAS の例 ```copy components: Schemas: Customer: x-datagraph: name: SalesCustomer properties: name: type: string e-mail: type: string x-datagraph: name: email id: type: string ... paths: "/customers/{customerId}": get: x-datagraph: name: getCustomer parameters: - in: query name: summaryView default: true schema: type: boolean ... responses: '200': content: application/json: schema: $ref: "#/components/schemas/Customer" ``` ### [](#raml-の例-6)RAML の例 ```copy types: Customer: (dg.datagraph): name: SalesCustomer properties: name: type: string e-mail: type: string (dg.datagraph): name: email id: type: string … /customer/{customerId}: uriParameters: customerId: string get: (dg.datagraph): name: getCustomer responses: 200: application/json: body: Customer ``` ## [](#関連情報)関連情報 - [Anypoint Platform DataGraph CLI および API 拡張機能の使用](https://docs.mulesoft.com/jp/datagraph/overview-cli-extensions) - [Anypoint CLI DataGraph コマンドリファレンス](https://docs.mulesoft.com/jp/datagraph/datagraph-cli) # Anypoint DataGraph CLI リファレンス Anypoint Platform には、DataGraph 用のコマンドラインインターフェース (CLI) が用意されています。CLI は、対話型シェルと標準 CLI モードの両方をサポートしています。 DataGraph CLI を使用して、以下を管理します。 - [DataGraph API ソース](#datagraph-api-sources) - [DataGraph ロードバランサー](#datagraph-load-balancers) ## [](#始める前に)始める前に - CLI を使用して API ソースを DataGraph に追加する前に、​[「DataGraph CLI および API 拡張機能の使用」](https://docs.mulesoft.com/jp/datagraph/overview-cli-extensions)​を確認してください。 - [Anypoint CLI の前提条件、インストール、認証の手順](https://docs.mulesoft.com/jp/anypoint-cli/3.x/)​を確認してください。 ## [](#datagraph-api-sources)DataGraph API ソース
コマンド 説明

API ソースを追加する

API ソースを昇格する

API ソースを更新する

統合スキーマに対する API コールをスケーリングする

統合スキーマをダウンロードする

API ソースを削除する

API ソースを取得する

すべての API ソースをリストする

DataGraph に関する情報を返す

統合スキーマの API ソースを検証する

### [](#datagraph-sources-add)datagraph sources add \> datagraph sources add

DataGraph では、​stable​ 状態の API バージョンのみがサポートされています。

このコマンドは、​``​ で指定された API ソースを追加します。ここで、​`g`​ はグループ ID、​`a`​ はアセット ID、​`v`​ は API ソースのバージョン ID です。グループ ID は省略可能です。グループ ID を指定しない場合、このコマンドは現在の組織 ID を使用します。 このコマンドでは、デフォルトの ​`--help`​、​`-f/--fields`​、​`-o/--output`​、​`--verbose`​ オプション以外に次のオプションも使用できます。
オプション 説明

--auth-none

API が公開の場合に使用します。

--auth-basic

基本認証ヘッダー、またはユーザー名とパスワードを渡して、API に対する認証を行う場合に使用します。

必須:

  • --credentials <username>:<password>

--auth-oauth

OAuth 2.0 の ​client_id​、​client_secret​、認証サーバーの値を渡して API に対する認証を行う場合に使用します。

必須:

  • --credentials <client_id>:<client_secret>​

  • --server <authorization server URL>​ ​

    省略可能:

  • --scope <server>

--auth-pass-through

認証ヘッダーを渡して API に対する認証を行う場合に使用します。

必須:

  • ​--mapping: <comma-separated list of key-value pairs, for example, key1:value1,key2:value2>

--auth-headers

カスタムヘッダーパラメーターと値を渡して API に対する認証を行う場合に使用します。

ヘッダーで必須:

  • --custom-headers: <comma-separated list of header-value pairs, for example, header1:value1,header2:value2>​

    Or (または)

  • --custom-headers-file: <location of the file containing header-value pairs, one per line>

--auth-query-params

クエリパラメーターと値を渡して API に対する認証を行う場合に使用します。

クエリパラメーターで必須:

  • --credentials <client_id:client_secret>

--url <url>

バックエンド API の URL を設定します。

--discover-url

現在の環境で実行されているインスタンスに基づいて、バックエンド API の URL を自動的に検出します。複数の API が実行されている場合、DataGraph は最初の URL を使用します。

--ca

API のトラストストアに追加する認証機関 (CA) ファイルのカンマ区切りリストを指定します (​file.ca,file2.ca​ など)。

--cert

相互トランスポートレイヤーセキュリティ (mTLS) に使用するクライアント証明書のファイル名を指定します (​cert.ca​ など)。

--key

mTLS に使用する非公開キーのファイル名を指定します (​key.pem​ など)。

--key-password

暗号化された非公開キーを復号化するパスワードを指定します。

--ignore-invalid-edits

API 仕様の拡張機能で行われた有効な編集を適用し、無効な編集を無視するために使用します。

コマンドラインで定義されたすべてのヘッダーとクエリパラメーター、およびすべてのヘッダーとクエリパラメーターファイルが追加されます。反復キーがある場合、コマンドラインで指定された値が優先されます。
#### [](#コマンド例)コマンド例 ```copy datagraph sources add 18dc11ee-4a09-4aae-9c6c-4371a87eafa8/product-api/1.0.0/ --url http://test.com ``` #### [](#出力例)出力例 { "apiVersion": "v1", "assetId": "product-api", "createDate": "2022-05-20T18:05:41", "endpoint": "http://test.com", "environmentId": "", "groupId": "", "name": "Product API", "organizationId": "", "securityScheme": "NO\_AUTH", "sourceId": "deca7be1-c299-4441-bc7b-dba733e3a11f", "updateDate": "2022-05-20T18:05:41", "version": "1.0.0", "origin": "CLI" } ### [](#datagraph-sources-promote)datagraph sources promote \> datagraph sources promote このコマンドは、API ソース ​``​ を対象環境 ​``​ に昇格します。 このコマンドでは、デフォルトの ​`--help`​、​`-f/--fields`​、​`-o/--output`​、​`--verbose`​ オプション以外に次のオプションも使用できます。
オプション 説明

--auth-none

API が公開の場合に使用します。

--auth-basic

基本認証ヘッダー、またはユーザー名とパスワードを使用して、API に対する認証を行う場合に使用します。

必須:

  • --credentials <username>:<password>

--auth-oauth

OAuth 2.0 の ​client_id​、​client_secret​、認証サーバーの値を渡して API に対する認証を行う場合に使用します。

必須:

  • --client-credentials <client_id>:<client_secret>​

  • --server <authorization server URL>​ ​

    省略可能:

  • --scope <server>

--auth-pass-through

認証ヘッダーを渡して API に対する認証を行う場合に使用します。

必須:

  • ​--mapping: <comma-separated list of key-value pairs, for example, key1:value1,key2:value2>

--auth-headers

カスタムヘッダーパラメーターと値を渡して API に対する認証を行う場合に使用します。

ヘッダーで必須:

  • --custom-headers: <comma-separated list of header-value pairs, for example, header1:value1,header2:value2>​

    Or (または)

  • --custom-headers-file: <location of the file containing header header-value pairs, one per line>

--auth-query-params

クエリパラメーターと値を渡して API に対する認証を行う場合に使用します。

クエリパラメーターで必須:

  • --credentials <client_id:client_secret>

--url

バックエンド API の URL を設定します。

--discover-url

現在の環境で実行されているインスタンスに基づいて、バックエンド API の URL を自動的に検出します。複数の API が実行されている場合、DataGraph は最初の URL を使用します。

--ca

API のトラストストアに追加する CA ファイルのリストを指定します。

--cert

mTLS に使用するクライアント証明書を指定します。

--key

mTLS に使用する非公開キーを指定します。

--key-password

暗号化された非公開キーを復号化するパスワードを指定します。

--empty-ca

すべての CA 証明書を削除します。

--empty-mtls

クライアント証明書、非公開キー、非公開キーパスワード情報を削除します。

コマンドラインで定義されたすべてのヘッダーとクエリパラメーター、およびすべてのヘッダーとクエリパラメーターファイルが追加されます。反復キーがある場合、コマンドラインで指定された値が優先されます。
#### [](#コマンド例-2)コマンド例 この例では、​`promote`​ コマンドの実行後に ​`environmentId`​ が変更されます。 ```copy datagraph sources promote d1d27987-939a-4b41-b3ef-411568ee5bdd e7e8da65-9cf1-569e-c9d2-brd2r0rc7rd6 --auth-none ``` #### [](#出力例-2)出力例 { "apiVersion": "1.0", "assetId": "order-e2e", "createDate": "2022-05-27T18:56:03", "endpoint": "http://test.com", "environmentId": "e7e8da65-9cf1-569e-c9d2-brd2r0rc7rd6", "groupId": "", "name": "Order E2E", "organizationId": "", "securityScheme": "NO\_AUTH", "sourceId": "1ff021b3-9296-43fd-9d64-2f9027c25740", "updateDate": "2022-05-27T18:56:03", "version": "1.0.0", "origin": "CLI" } ### [](#datagraph-sources-update)datagraph sources update \> datagraph sources update

DataGraph では、​stable​ 状態の API バージョンのみがサポートされています。​update​ コマンドは、API ソースのパッチおよびマイナーバージョンのみを更新します。

このコマンドは、API ソース ​``​ のバージョンを更新します。 このコマンドでは、デフォルトの ​`--help`​、​`-f/--fields`​、​`-o/--output`​、​`--verbose`​ オプション以外に次のオプションも使用できます。
オプション 説明

--auth-none

API が公開の場合に使用します。

--auth-basic

基本認証ヘッダー、またはユーザー名とパスワードの両方を渡して、API に対する認証を行う場合に使用します。

必須:

  • --credentials <username>:<password>

--auth-oauth

OAuth 2.0 の ​client_id​、​client_secret​、認証サーバーの値を渡して API に対する認証を行う場合に使用します。

必須:

  • --credentials <client_id>:<client_secret>​

  • --server <authorization server URL>​ ​

    省略可能:

  • --scope <server>

--auth-pass-through

認証ヘッダーを渡して API に対する認証を行う場合に使用します。

必須:

  • ​--mapping: <comma-separated list of key-value pairs, for example, key1:value1,key2:value2>

--auth-headers

カスタムヘッダーパラメーターと値を渡して API に対する認証を行う場合に使用します。

ヘッダーで必須:

  • --custom-headers: <comma-separated list of header-value pairs, for example, header1:value1,header2:value2>​

    Or (または)

  • --custom-headers-file: <location of the file containing header-value pairs, one per line>

--auth-query-params

クエリパラメーターと値を渡して API に対する認証を行う場合に使用します。

クエリパラメーターで必須:

  • --credentials <client_id:client_secret>

--url

バックエンド API の URL を設定します。

--discover-url

現在の環境で実行されているインスタンスに基づいて、バックエンド API の URL を自動的に検出します。複数の API が実行されている場合、DataGraph は最初の URL を使用します。

--ca

API のトラストストアに追加する CA ファイルのリストを指定します。

--cert

mTLS に使用するクライアント証明書を指定します。

--key

mTLS に使用する非公開キーを指定します。

--key-password

暗号化された非公開キーを復号化するパスワードを指定します。

--empty-ca

すべての CA 証明書を削除します。

--empty-mtls

クライアント証明書、非公開キー、非公開キーパスワード情報を削除します。

--keep-edits

API ソースの現在のバージョンに存在する編集を、API 仕様から抽出する代わりに保持します。

--override-ui-edits

API ソースの取得元を CLI に変更します。API ソースの取得元が DataGraph UI である場合、このオプションを使用して、UI の編集を API 仕様の編集で上書きします。

--ignore-invalid-edits

API 仕様の拡張機能で行われた有効な編集を適用し、無効な編集を無視するために使用します。

コマンドラインで定義されたすべてのヘッダーとクエリパラメーター、およびすべてのヘッダーとクエリパラメーターファイルが追加されます。反復キーがある場合、コマンドラインで指定された値が優先されます。
#### [](#コマンド例-3)コマンド例 次のコマンドは、ソース API の URL を更新し、その認証を ​`auth-none`​ から ​`auth-basic`​ に変更して、クライアント ID とシークレットを追加します。 ```copy > datagraph sources update b6cb82a6-51dc-4968-861a-aa04447c3442 --url http://test2.com --version 1.0.0 --auth-basic --credentials client-test:client-secret ``` #### [](#出力例-3)出力例 { "apiVersion": "v1", "assetId": "product-api", "createDate": "2022-05-20T18:56:57Z", "endpoint": "http://test2.com", "environmentId": "", "groupId": "", "name": "Product API", "organizationId": "", "securityScheme": "BASIC", "sourceId": "b6cb82a6-51dc-4968-861a-aa04447c3442", "updateDate": "2022-05-27T18:31:39", "version": "1.0.0", "origin": "CLI" } ### [](#datagraph-scale)datagraph scale \> datagraph scale このコマンドでは、統合スキーマで許可される同時 API コール数を設定できます。API コール数を増減することで、必要に応じて処理するワークロードを増やし、コンシュームを最適化できます。 このコマンドはデフォルトのオプション ​`--help`​、​`-f/--fields`​、​`-o/--output`​、​`--verbose`​ を受け入れます。 #### [](#コマンド例-4)コマンド例 ```copy datagraph scale 300 ``` #### [](#出力例-4)出力例 { "message": "Api calls updated" } ### [](#datagraph-schema-download)datagraph schema-download \> datagraph schema-download このコマンドは、現在の環境の統合スキーマをダウンロードします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f/--fields`​、​`-o/--output`​、​`--verbose`​ を受け入れます。 #### [](#出力例-5)出力例 directive @key(fields: String) on OBJECT "An Item" type Item { itemId: Int! "A Product" product: OrderProduct! quantity: Int! } "An Order" type Order { items: \[Item!\]! orderId: String! customerId: String! } "A Product" type OrderProduct { productId: String! name: String! } type Query { orders(ordersCount: Int): \[Order!\] ordersByOrderId(orderId: String!): Order ordersProductsByOrderId(productsCounts: Int, orderId: String!): \[OrderProduct!\] } ### [](#datagraph-sources-delete)datagraph sources delete \> datagraph sources delete このコマンドは、指定された API ソースを削除します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f/--fields`​、​`-o/--output`​、​`--verbose`​ を受け入れます。 #### [](#コマンド例-5)コマンド例 ```copy datagraph sources delete d40df394-785d-4c91-8aeb-f07568dd57c ``` #### [](#出力例-6)出力例 { "message": "Source deleted successfully", "sourceId": "620afe93-b196-42eb-ae77-b68a0a937b6a" } ### [](#datagraph-sources-get)datagraph sources get \> datagraph sources get このコマンドは、指定された API ソースを取得します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f/--fields`​、​`-o/--output`​、​`--verbose`​ を受け入れます。 #### [](#コマンド例-6)コマンド例 ```copy datagraph sources get d1d27987-939a-4b41-b3ef-411568ee5bdd ``` #### [](#出力例-7)出力例 { "apiVersion": "1.0", "assetId": "order-e2e", "createDate": "2022-05-20T16:49:00Z", "hasKeystore": false, "endpoint": "http://test.com", "environmentId": "", "groupId": "", "name": "Order E2E", "organizationId": "", "hasTruststore": false, "securityScheme": "NO\_AUTH", "sourceId": "d1d27987-939a-4b41-b3ef-411568ee5bdd", "updateDate": "2022-05-20T16:49:00Z", "version": "1.0.0", "origin": "CLI" } ### [](#datagraph-sources-list)datagraph sources list ```copy > datagraph sources list ``` このコマンドは、現在の環境のすべての API ソースをリストします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f/--fields`​、​`-o/--output`​、​`--verbose`​ を受け入れます。 #### [](#出力例-8)出力例 { "apiVersion": "1.0", "assetId": "order-e2e", "createDate": "2022-05-20T16:49:00.000Z", "endpoint": "http://test.com", "environmentId": "", "groupId": "", "name": "Order E2E", "organizationId": "", "securityScheme": "NO\_AUTH", "sourceId": "d1d27987-939a-4b41-b3ef-411568ee5bdd", "updateDate": "2022-05-20T16:49:00.000Z", "version": "1.0.0", "origin": "CLI" }, { "apiVersion": "v1", "assetId": "product-api", "createDate": "2022-05-20T18:05:41.000Z", "endpoint": "http://test.com", "environmentId": "", "groupId": "", "name": "Product API", "organizationId": "", "securityScheme": "NO\_AUTH", "sourceId": "deca7be1-c299-4441-bc7b-dba733e3a11f", "updateDate": "2022-05-20T18:05:41.000Z", "version": "1.0.0", "origin": "CLI" } ### [](#datagraph-describe)datagraph describe ```copy > datagraph describe ``` このコマンドは、DataGraph に関する次の情報を返します。 - `endpoint`​: 要求を受け入れる GraphQL エンドポイントを表示します。 - `deploymentError`​: DataGraph のデプロイメントが失敗した場合、この項目にエラーの情報が表示されます。それ以外の場合は空です。 - `deploymentStatus`​: DataGraph はデプロイ中、実行中、またはエラーがあるかどうかを示します。 - `logLevels`​: 設定されたログレベルのリストを表示します。 - `envStatus`​: 現在の環境の状況を表示します。 - `dlbEndpoint`​: ロードバランサーエンドポイントを表示します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f/--fields`​、​`-o/--output`​、​`--verbose`​ を受け入れます。 #### [](#出力例-9)出力例 { "deploymentStatus": "STARTED", "dlbEndpoint": "datagraph-example.us-e1.prod.cloudhub.io", "endpoint": "datagraph-example.us-e1.prod.cloudhub.io", "envStatus": "STARTED" } ### [](#datagraph-validate)datagraph validate \> datagraph validate asset このコマンドは、API ソースを統合スキーマに追加できるかどうかを検証します。そのために、このコマンドは次の処理を行います。 - API ソースを GraphQL スキーマに変換する。 - API 仕様に適用されている API 拡張機能を検証する。 - 統合スキーマに対して競合チェックを実行する。 これらのステップのいずれかで競合またはエラーが発生した場合、コマンドは結果を返します。競合やエラーが見つからない場合は、成功メッセージを返します。 検証する API ソースは、​``​ で指定されます。ここで、​`g`​ はグループ ID、​`a`​ はアセット ID、​`v`​ は API ソースのバージョン ID です。グループ ID は省略可能です。グループ ID を指定しない場合、このコマンドは現在の組織 ID を使用します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f/--fields`​、​`-o/--output`​、​`--verbose`​ を受け入れます。 #### [](#コマンド例-7)コマンド例 ```copy datagraph validate asset 73b0d8f2-5a2f-4107-884d-fcd80f30bc51/sales-api/1.0.0 ``` #### [](#出力例-10)出力例 { "code": "success" } ## [](#datagraph-load-balancers)DataGraph ロードバランサー
コマンド 説明

専用ロードバランサー設定を Anypoint DataGraph に追加する

Anypoint DataGraph の専用ロードバランサー設定を表示する

専用ロードバランサー設定を Anypoint DataGraph から削除する

### [](#datagraph-load-balancer-config-add)datagraph load-balancer-config add ```copy > datagraph load-balancer-config add ``` このコマンドでは、​``​ で指定された専用ロードバランサー設定を Anypoint DataGraph に追加します。 `dlbUrl`​ は、DLB ドメインとマッピングルール ​`inputUri`​ を含む有効な URL です。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ### [](#datagraph-load-balancer-config-describe)datagraph load-balancer-config describe ```copy > datagraph load-balancer-config describe [options] ``` このコマンドでは、Anypoint DataGraph の専用ロードバランサーの URL を表示します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ### [](#datagraph-load-balancer-config-remove)datagraph load-balancer-config remove ```copy > datagraph load-balancer-config remove [options] ``` このコマンドでは、専用ロードバランサー設定を Anypoint DataGraph から削除します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#datagraph-cli-コマンドエラー)DataGraph CLI コマンドエラー コマンドの定義が正しくないと、DataGraph によって次のエラーが返されます。これらのエラーの原因として、オプションのパラメーターが正しくない、ID が見つからない、必須のオプションが欠落している、などが考えられます。 - [Options are Required (オプションが必須です)](#options-are-required) - [Not Found (見つかりません)](#not-found) - [Bad Request (不正な要求)](#bad-request) - [API Already Exists (API がすでに存在しています)](#api-already-exists) - [No API Instances Found (API インスタンスが見つかりません)](#no-api-instances-found) - [Must Define URL (URL を定義する必要があります)](#must-define-url) - [Invalid API Calls (API コールが無効です)](#invalid-api-calls) - [Unauthorized (承認されていません)](#unauthorized) - [API Not Found in Current Environment (現在の環境で API が見つかりません)](#api-not-found-in-current-environment) ### [](#options-are-required-オプションが必須です)Options are Required (オプションが必須です) ## [](#出力)出力: { "error": { "errorMessage": "Options are required" } } 原因: このエラーは、コマンドを実行するには 1 つ以上のオプションが必須であることを示しています。 \* \`datagraph sources add\`​: このコマンドでは ​\`--url\`​ オプションまたは ​\`--discover-url\`​ オプションが必須です。 \* \`datagraph sources update/promote\`​: 使用可能な任意のオプションが必須です。対象ソースで更新またはプロモートする要素を定義してください。 === Not Found (見つかりません) 出力: { "errorCode": "dg-xapi-proxy", "errorMessage": "Not Found" } 原因: このエラーは、DataGraph でアセットが見つからなかったことを示しています。 \* \`datagraph sources add\`​: グループ ID、アセット ID、バージョン ID が有効なアセットに対応していないか、アセットにアクセスできないため、アセットに到達できません。 \* \`datagraph sources update/promote\`​: 指定した UUID が現在の環境、またはアセットをプロモートする対象環境に存在しません。 === 不正な要求 出力: { "error": { "code": "400", "message": "Bad Request" } } 原因: このエラーは、コマンドの必須のパラメーターの一部で形式に誤りがあることを示しています。 \* \`datagraph sources update\`​: 指定されたソース ID が有効な UUID ではありません。 \* \`datagraph sources promote\`​: ソース ID または対象環境 ID が有効な UUID 形式ではありません。 === API Already Exists (API がすでに存在しています) 出力: { "errorCode": "dg-federation-source-exists", "errorMessage": "API already exists" } 原因: このエラーは、追加しようとしている API がすでに統合スキーマに存在していることを示しています。 \* \`datagraph sources add\`​: アセット ID と API ソースのメジャーバージョンがすでに統合スキーマに存在しています。ソースに変更を加えるには、​\`datagraph sources update\`​ コマンドを使用します。 === No API Instances Found (API インスタンスが見つかりません) 出力: { "errorCode": "dg-xapi-no-api-instances", "errorMessage": "No API instances found" } 原因: このエラーは、API インスタンスについて取得する URL が欠落していることを示しています。 \* \`datagraph sources add/update/promote\`​: このエラーは、​\`\`--discover-url\`​ オプションを使用しているときに表示されます。アセットに、モッキングサービスからのものではない URL を取得できる有効なインスタンスがない場合に発生します。このような場合は、代わりに ​\`--url\`​ オプションを使用します。 === Must Define URL (URL を定義する必要があります) 出力: { "error": { "errorMessage": "Must define url or set --discover-url" } } 原因: このエラーは、​\`--url\`​ または ​\`--discover-url\`​ を使用して URL を設定する必要があることを示しています。 \* \`datagraph sources add\`​: URL は ​\`add\`​ コマンドの必須項目であるため、​\`--url\`​ または ​\`--discover-url\`​ の 2 つのオプションのうちいずれかを設定する必要があります。 === Invalid API Calls (API コールが無効です) 出力: { "errorCode": "dg-xapi-invalid-api-calls", "errorMessage": "Invalid Api Calls: 1500" } 原因: このエラーは、無効な数の API コールを要求したことを示しています。 \* \`datagraph scale\`​: 同時コール数は 1 ~ 1200 の間である必要があります。 === Unauthorized (承認されていません) 出力: { "error": { "code": "401", "message": "Unauthorized" } } 原因: このエラーは、対話型モードで使用しているときに CLI でセッションを失ったことを示しています。CLI を終了して再起動し、もう一度ログインしてください。 === API Not Found in Current Environment (現在の環境で API が見つかりません) 出力: { "errorCode": "dg-federation-source-not-in-env", "errorMessage": "API not found in current environment" } 原因: このエラーは、編集、削除、または更新しようとしている API ソースが存在はしているが、作業環境にないことを示しています。 \* \`datagraph sources update/promote\`​: 送信された UUID が作業環境にありません。または、​\`--version\`​ オプションを使用している場合は、メジャーバージョンが現在のバージョンに対応していません。 == DataGraph CLI 検証エラー 統合スキーマに対して API ソースを追加または更新する前に ​\`datagraph validate asset\`​ コマンドを使用すると、DataGraph によって次のエラーが返されます。 \* xref:editing-errors\[編集エラー\] \* xref:conflict-errors\[競合エラー\] === 編集エラー 編集エラーが生成されるのは、特定の API ソースでの編集にセマンティックの問題が含まれる場合です。これらのエラーではコードプロパティ ​\`dg-federation-customization-conflict\`​ を使用しており、次のような構造になります。 { "code": "dg-federation-customization-conflict", "detail": \[ { "code": "element-not-found-in-spec", "editType": "set-primary-key", "reason": "field addId was not found in the specification", "element": "Address" } \], "message": "Customization conflict found adding Customer API" } \* \`message\`​ 項目には人間が読み取り可能な検証の応答が含まれており、エラーの概要が提供されます。 \* \`detail\`​ 項目には現在のアセットで見つかったすべての競合のリストが含まれています。 \*\* \`code\`​ 項目ではエラーの種類を特定します。 \*\* \`editType\`​ 項目では競合があるカスタマイズを特定します。 \*\* \`reason\`​ 項目には人間が読み取り可能な問題の説明が含まれています。 \*\* \`element\`​ 項目には問題が含まれています。 === 競合エラー 競合エラーが発生するのは、統合スキーマに API スキーマを追加しようとしたときです。これらのエラーではコードプロパティ ​\`dg-federation-udg-conflict\`​ を使用しており、次のような構造になります。 { "code": "dg-federation-udg-conflict", "detail": \[ { "element": "Customer", "violations": \[ { "code": "incompatible-primary-key-set", "keys": \[ "customerId" \], "expectedKeys": \[ "name" \], "message": "Primary key set have edges with different names" } \] } \], "message": "Merge conflict found adding CLI - Customer OAS API" } \* \`message\`​ 項目には人間が読み取り可能な検証の応答が含まれており、エラーの概要が提供されます。 \* \`detail\`​ 項目には、API スキーマを統合スキーマにマージしようとしたときに見つかったすべての競合のリストが含まれています。 \*\* \`element\`​ 項目には競合の場所が含まれています。 \*\* \`violations\`​ 項目では修正する必要がある競合がリストされます。 \*\*\* \`code\`​ 項目ではエラーの種類を特定します。 \*\*\* \`message\`​ 項目には人間が読み取り可能な問題の説明が含まれており、エラーの種類に応じて、詳細のための追加のプロパティが含まれる場合があります。 == 関連情報 \* xref:overview-cli-extensions.adoc\[DataGraph CLI および API 拡張機能の使用\] \* xref:api-extensions.adoc\[Anypoint DataGraph API 拡張機能リファレンス\] # Anypoint DataGraph Release Notes The following release notes are provided for Anypoint DataGraph: - [Anypoint DataGraph Release Notes](https://docs.mulesoft.com/jp/release-notes/datagraph/anypoint-datagraph-release-notes) - [Known Issues](https://help.salesforce.com/s/issues) # Anypoint DataGraph クイックスタートガイド このクイックスタートガイドを参考に、Anypoint DataGraph の使用を開始します。Anypoint DataGraph を使用すると、1 回の要求で複数の API を照会して、必要とする特定の情報を取得できます。 このクイックスタートガイドには次の手順が記載されています。 1. 2 つの API をダウンロードしてパブリッシュする 2. この 2 つの API を Anypoint DataGraph に追加する 3. 各種の API スキーマ編集ツール (リンク、マージなど) を使用して、統合スキーマをはじめとするスキーマを編集する 4. 統合スキーマにデータを送信するための変異を作成する 5. 統合スキーマを照会して、送信した特定のデータを取得する ## [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Anypoint Platform と Exchange に精通している (ビジネスグループで Exchange を使用して RAML 仕様や OAS 仕様をパブリッシュして表示する権限など)。 - Anypoint Platform アカウントがある。 - 「管理」または「寄稿」権限がある。 - Anypoint DataGraph を使用するビジネスグループまたは組織に、プランに指定されている適切な数の vCore が割り当てられている。API を追加しようとしている環境に適切な数の vCore が割り当てられていない場合、Anypoint DataGraph からエラーメッセージが表示されます。

Anypoint Virtual Private Cloud (Anypoint VPC) を使用している場合、DataGraph でクエリを実行するにはブラウザーで Anypoint VPC にアクセスする必要があります。アクセスできないと、​failed to fetch​ スキーマエラーを受信する場合もあります。これを防止するには、​専用ロードバランサー (DLB) をセットアップ​します。ネットワークとホスティングオプションについては、​「DataGraph のホスティングオプションとネットワーキング」​で説明しています。

## [](#order-api-と-product-api-をダウンロードしてパブリッシュする)Order API と Product API をダウンロードしてパブリッシュする このクイックスタートの例を実践してみる場合は、MuleSoft が提供する 2 つのサンプル API ( [Order Systems API v2.0](https://anypoint.mulesoft.com/exchange/68ef9520-24e9-4cf2-b2f5-620025690913/catalyst-retail-order-system-api/minor/2.0/console/summary/)​ と [Product API v2.0](https://anypoint.mulesoft.com/exchange/68ef9520-24e9-4cf2-b2f5-620025690913/catalyst-retail-product-api/minor/2.0/console/summary/)​) の RAML 定義をダウンロードしてください。 1. Anypoint Platform にログインします。 [Anypoint Platform に移動](https://anypoint.mulesoft.com/login) 2. Exchange で、​**\[Provided by MuleSoft (MuleSoft による提供)\]**​ をクリックします。 [Exchange に移動](https://www.mulesoft.com/exchange) 3. **「product api raml definition」**​(Product API RAML 定義) を検索して、結果リストから選択します。 4. **\[Product API\] | \[RAML Definition (RAML 定義)\]**​ で、アセットバージョン 2.0.2 の ​**\[Download (ダウンロード)\]**​ > ​**\[RAML\]**​ をクリックします。 5. 各自のビジネスグループ ID とアセット名を使用して、​[RAML 仕様を Exchange にパブリッシュします](https://docs.mulesoft.com/design-center/design-publish#procedure)​。 このクイックスタートの例では、​**Catalyst Product API**​ と ​**Catalyst Order API**​ という API プロジェクト名を使用します。 6. Order Systems API についても、アセットバージョン 2.0.3 の ​**\[Order Systems API\] | \[RAML Definition (RAML 定義)\]**​ で同じ手順を繰り返します。 ## [](#catalyst-product-api-を-anypoint-datagraph-に追加する)Catalyst Product API を Anypoint DataGraph に追加する サンプル API を Exchange にパブリッシュしたら、Catalyst Product API を Anypoint DataGraph に追加します。 1. \[Anypoint Platform\] > \[Anypoint DataGraph\] で ​**\[Unified Data Graph (統合データグラフ)\]**​ ドロップダウンリストから適切な環境を選択し、​**\[+Add API (+API を追加)\]**​ をクリックします。 2. **\[Add API (API の追加)\]**​ ページで、\[Catalyst Product API\] を選択します。 3. **\[Next: Configure URL (次へ: URL を設定)\]**​ をクリックします。 4. **\[Configure URL (URL の設定)\]**​ ページで、API バージョンとアセットバージョンを選択し、​**\[Confirm Selection (選択内容を確認)\]**​ をクリックします。 5. **\[Add a new URL (新しい URL を追加)\]**​ を選択します。 6. **\[Add URL (URI を追加)\]**​ 項目で、次の API URL を追加します。 ​`https://anypoint.mulesoft.com/mocking/api/v1/sources/exchange/assets/68ef9520-24e9-4cf2-b2f5-620025690913/catalyst-retail-product-api/2.0.2/m/` ![API バージョンとアセットバージョンを追加し、Catalyst Product API の URL を追加](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-configure-api.png) API を API Manager で管理している場合や、URL を Exchange に手動で追加した場合は、Anypoint DataGraph によって URL が取得されます。また、新しい URL が API 仕様に含まれている場合は手動で追加できます。 7. **\[Save (保存)\]**​ をクリックします。 8. **\[Next: Configure Security (次へ: セキュリティを設定)\]**​ をクリックします。 9. API の GET エンドポイントの認証を指定します (このクイックスタートの例では ​**\[No Auth (認証なし)\]**​)。 ![API 認証を 「No Auth (認証なし)」 に設定](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-api-authentication.png) Anypoint DataGraph ではこれらのログイン情報を使用して、この API に要求を実行します。 10. バージョンと認証の詳細を設定したら、​**\[Next: Preview Schema (次へ: スキーマのプレビュー)\]**​ をクリックします。 ![API スキーマのプレビューモードの Anypoint DataGraph](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-preview-schema.png) この時点で、追加している API の仕様が対応する API スキーマに自動的に変換されます。次のステップに進む前に、生成されたスキーマの詳細を確認しておくことをお勧めします。 たとえば、種別をクリックスルーしてスキーマ階層を理解したり、特定の要素 (この場合は ​`price`​) を検索したりすることが考えられます。 ![API スキーマのプレビューモードで price 要素を検索](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-preview-search.png) 11. スキーマのプレビューが完了したら、​**\[Next: Edit Schema (次へ: スキーマを編集)\]**​ をクリックします。 ## [](#catalyst-product-api-スキーマでのオブジェクト種別のコラボレーションの有効化)Catalyst Product API スキーマでのオブジェクト種別のコラボレーションの有効化

API スキーマを統合スキーマに追加する前に、編集機能 (コラボレーションの有効化、名前変更、非表示/再表示、オブジェクト種別のリンクやマージ) を実行する必要はありません。統合スキーマに追加した後でも API スキーマを変更できます。ただし、API スキーマを統合スキーマに追加する前に、Anypoint DataGraph で生じた競合をすべて解決しておく必要があります。

API を統合スキーマに追加するときに、オブジェクト種別、クエリメソッド、項目を設定して、有用なクエリ結果が生成されるようにします。具体的には、上記のエンティティを非表示/再表示したり、名前を変更したり、リンクやマージを行ったりします。 ここで、つながりのある統合スキーマにするための極めて重要なステップは、オブジェクト種別のコラボレーションを有効にすることです。 種別のコラボレーションを有効にすると、その種別の項目が統合スキーマまたはローカルの API スキーマの他の種別に生成されるため、種別間のリンクやマージを作成できるようになります。 ProductResponse オブジェクト種別のコラボレーションを有効にする手順は、次のとおりです。 1. Catalyst Product API スキーマのナビゲーションで、​**\[ProductResponse\]**​ オブジェクト種別をクリックします。 2. **\[Collaboration permissions (コラボレーション権限)\]**​ ペインで、​**\[Enable collaboration (コラボレーションを有効化)\]**​ をクリックします。 3. デフォルトのクエリメソッドを設定するには、​`productsByProductId (productId:String!): ProductResponse`​ を選択します。 ![デフォルトのクエリメソッドを products by product id に設定](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-default-query-method.png) オブジェクト種別のデフォルトのクエリメソッドとは、コラボレーションを有効にするオブジェクト種別の 1 つのレコードを常に返すメソッドです。 4. **\[Next (次へ)\]**​ をクリックします。 5. 主キーとして、ドロップダウンリストから ​`identifier (String!)`​ を選択します。 ![主キーを identifier string に設定](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-primary-key.png) 主キーはオブジェクト種別に含まれる項目で、そのオブジェクト種別の 1 つのレコードを一意に識別します。DataGraph では​_複合キー_​を使用するオブジェクト種別もサポートしていますが、この例では主キーを 1 つのみ使用します。 6. **\[Confirm (確認)\]**​ をクリックします。 7. **\[Edit type name and field settings (種別名と項目設定を編集)\]**​ ペインで、すべての項目が表示されるようにします。 API を追加したときに、ネストされている種別は統合スキーマですべて非表示になります。このため、各自のニーズに合わせてスキーマを柔軟に拡張し、統合スキーマに追加する種別だけを表示することができます。ネストされている種別を返すレベル 1 の種別の項目もすべて非表示になります。 8. **\[Next: Add to unified schema (次へ: 統合スキーマに追加)\]**​ をクリックします。 ![API スキーマを統合スキーマに追加中であることを示す状況インジケーター](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-add-api-status.png) Anypoint DataGraph で統合スキーマを更新中も、スキーマ内を移動して実施した変更を表示できます。 9. **\[Proceed to unified schema (統合スキーマに進む)\]**​ をクリックします。 ## [](#catalyst-order-api-の-anypoint-datagraph-への追加)Catalyst Order API の Anypoint DataGraph への追加 Product Order API を追加したときと同じ手順に従いますが、次の点が異なります。 - `https://anypoint.mulesoft.com/mocking/api/v1/sources/exchange/assets/68ef9520-24e9-4cf2-b2f5-620025690913/catalyst-retail-order-system-api/2.0.3/m/`​ という URL を使用します。 - また、先ほどコラボレーションを有効にしたオブジェクト種別の名前変更、リンク、マージを行ってスキーマを編集します。 ## [](#catalyst-order-api-スキーマでのオブジェクト種別の名前変更)Catalyst Order API スキーマでのオブジェクト種別の名前変更 API スキーマを統合スキーマに追加する前に、スキーマを編集して、統合スキーマを使用するユーザーが直感的に操作できるように項目、種別、クエリメソッドの名前を変更することができます。 たとえば、Catalyst Order API には ​`EnumType0`​ というネストされた種別があります。 ![Catalyst Order API の Enum type 0 を選択](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-rename-type.png) この列挙型の種別は追加時に名前がなかったため、Anypoint DataGraph で ​`EnumType0`​ という名前が生成されていました。この種別は有用な注文状況情報を示すため、​`OrderStatus`​ という適切な名前を付けます。 1. **\[EnumType0\]**​ をクリックします。 2. **\[Desired state (望ましい状態)\]**​ を ​**\[Visible (表示)\]**​ に切り替えます。 3. **\[Type settings (種別設定)\]**​ ペインで、​**\[Rename Type (種別の名前変更)\]**​ をクリックします。 4. 種別の名前を ​`OrderStatus`​ に変更して、​**\[Confirm (確認)\]**​ をクリックします。 種別リストに新しい種別が表示されます。 ## [](#catalyst-order-api-スキーマのオブジェクト種別のリンク)Catalyst Order API スキーマのオブジェクト種別のリンク また、統合スキーマを編集して、新たに追加された API のオブジェクト種別を既存の関連する種別にリンクして、項目を結合することができます。こうした結合によってクエリ結果が向上します。 たとえば、Catalyst Product API を追加したことにより、現在この統合スキーマには ​**ProductResponse**​ オブジェクト種別から取得した商品説明情報が存在します。Catalyst Order API スキーマには、​**OrderItemSummary**​ オブジェクト種別に含まれる商品情報もあります。この 2 つのオブジェクト種別をリンクすれば、1 回のクエリで両方の結果を返すことができます。 1. Catalyst Order API スキーマのナビゲーションで、​**\[OrderItemSummary\]**​ オブジェクト種別を選択します。 2. OrderItemSummary オブジェクト種別とその項目が非表示になっている場合、​**\[Hidden/Visible (非表示/表示)\]**​ 切り替えを使用して、​**\[Desired state (望ましい状態)\]**​ 値を ​**\[Visible (表示)\]**​ に切り替えます。 ![order item summary の表示の 「Desired state (望ましい状態)」 を 「Visible (表示)」 に設定](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-visible-object-type.png) 3. **\[Link to another type (別の種別にリンク)\]**​ ペインまでスクロールして、​**\[Select the type you want to link to (Target) (リンク先 (対象) の種別を選択)\]**​ で、​**\[ProductResponse\]**​ を選択します。 4. 外部キー項目で、​`productId (String!)`​ を設定します。 ![リンク設定の外部キー項目で product ID string に設定](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-link-configuration.png) 外部キー項目によって返される値と、そのキーで識別される ProductResponse のレコードは、対象の ProductResponse オブジェクト種別の主キーとまったく同じになります。 5. 外部キー項目の名前を ​**productresponse**​ から ​**product**​ に変更します。 新たに追加した項目 (product) がリンク先の種別を返すため、統合スキーマで外部キー項目を非表示にすることもできます。この例では、​**\[Visible (表示)\]**​ に変更することにします。 6. 新しいリンク設定を確認して、​**\[Save changes (変更を保存)\]**​ をクリックします。 これで OrderItemSummary 種別が ProductResponse! 種別にリンクされました。 ![リンク済みアイコンを示す OrderItemSummary 種別の product 項目](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-link-added.png) Catalyst Order API の追加を​_もう少し_​で完成させることができます。その前に、統合スキーマに追加する前に API スキーマを編集するもう 1 つの方法を確認しておきます。 ## [](#catalyst-order-api-スキーマのオブジェクト種別のマージ)Catalyst Order API スキーマのオブジェクト種別のマージ API スキーマのオブジェクト種別を、統合スキーマの別のオブジェクト種別、または同じ API スキーマの別のオブジェクト種別とマージすることができます。後者を​_ローカルマージ_​といいます。種別をマージすると、類似の種別を結合してその項目やデータセットを拡張し、クエリ結果を向上させることができます。 Anypoint DataGraph には、次の 3 種類のマージがあります。 - _拡張マージ_​: 種別のマージによってデータが結合されます。 - _参照マージ_​: 対象種別のみから項目を取得できます。 - _複合マージ_​: 種別のマージによって種別が 1 つの種別にまとめられ、統合スキーマが整理されますが、主キーなしで結合されます。 この例では、OrderSummary オブジェクト種別を OrderResponse オブジェクト種別にマージするというローカルの複合マージを実行します。 1. Catalyst Order API スキーマのナビゲーションで、​**\[OrderSummary\]**​ 種別を選択します。 2. **\[Merge with another type (別の種別とマージ)\]**​ ペインで、マージ先の種別 (この場合は ​**OrderResponseLocal**​) を選択します。 ![order summary 種別とマージする対象種別として order response を選択](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-merge-selection.png) 3. 差分ビューを使用してマージに 2 つの種別を横並びで比較し、必要に応じて、切り替えを使ってすべての項目を非表示にします。 4. **\[Preview merge result (マージ結果のプレビュー)\]**​ をクリックします。 ![order summary と order response のマージ結果のプレビュー](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-merge-preview-result.png) 結果に、OrderSummary オブジェクト種別と OrderResponse オブジェクト種別間でローカルマージが実行されたことが示されます。マージ後は、Catalyst Order API スキーマの OrderSummary オブジェクト種別の名前が OrderResponse に変更されているため、統合スキーマでは OrderResponse 種別を照会します。 5. **\[Confirm merge (マージを確認)\]**​ をクリックします。 6. **\[Apply Changes (変更を適用)\]**​ をクリックします。 Anypoint DataGraph で統合スキーマを更新中も、スキーマ内を移動して、加えた変更を表示できます。統合スキーマの状況が \[Up to date (最新)\] に変化したときに、クエリと変異を実行するためのアクセス権を要求します。 ## [](#クエリと変異を実行するためのアクセス権を要求する)クエリと変異を実行するためのアクセス権を要求する 2 つの API スキーマを統合スキーマに追加したら、操作を実行するためのアクセス権を要求できます。 1. **\[Run Operation (操作を実行)\]**​ をクリックします。 2. アクセス方法を選択します。この例では、​**\[Create a new application and use it immediately (新しいアプリケーションを作成してすぐに使用する)\]**​ を選択します。 ![操作を実行するためのアクセス権を要求するウィンドウで 「Create a new application (新しいアプリケーションの作成)」 を選択](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-request-query-access.png) 3. **\[Next (次へ)\]**​ をクリックします。 4. **\[Create a new application (新しいアプリケーションの作成)\]**​ ウィンドウで、項目に値を入力し、​**\[Next (次へ)\]**​ をクリックします。 ![アクセス権を要求するウィンドウの 「Create a new application (新しいアプリケーションの作成)」](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-create-query-application.png) 5. **\[Create & Request Access (アクセス権の作成と要求)\]**​ をクリックします。 ## [](#統合スキーマを探索する)統合スキーマを探索する 1. 変異を作成する前に、統合スキーマがどのようなものか把握しておきます。​**\[Explore Schema (スキーマを調査)\]**​ をクリックします。 ![クエリエディターに表示された schema explorer](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-explore-schema-docs.png) この画面で統合スキーマのドキュメントを確認できます。クエリの作成時のオートコンプリートでもこのドキュメントを参照できます。 ![インラインのオートコンプリートを使用してクエリを作成](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-query-autocompletion.png) ## [](#変異を作成する)変異を作成する 変異は、データオブジェクトを追加、更新、および削除するために使用する操作です。GraphQL では、変異操作は REST API 仕様で定義した POST、PATCH、PUT、DELETE、および HTTP メソッドを表します。 1. 次の変異の例を追加します。 ```copy mutation { createOrdersCustomerByCustomerId( customerId: "1964401a-a8b3-40c1-b86e-d8b9f75b5842", input: { customerId: "1964401a-a8b3-40c1-b86e-d8b9f75b5842", subtotal: "100.21", taxPrice: "15.22", shippingPrice: "10.00", total: "125.43", orderItems: { shipmentItems: [{ orderItemId: "fc3d4900-c5ac-4649-8bc8-cbbef4fe8fde" productId: "e1c515f9-102d-4830-b353-18fe48065732" productName: "Uniforms Modern Fit Short Sleeve Polo Shirt" location: { locationId: "1c9a20dc-c585-42fd-ac1a-1216085b76d2" deliveryMethod: SHIPMENT locationType: PARTNER } price: "50" quantity: 1 }] pickupItems: [{ orderItemId: "88668866-2c6d-4fa6-9e17-4b2c42e0f051", productId: "eb8c8ca7-3c42-4489-a820-3aa138430b75", productName: "Smart Slim Micro Stripe Shirt", location: { locationId: "1c9a20dc-c585-42fd-ac1a-1216085b76d2", deliveryMethod: PICKUP, locationType: STORE }, price: "50", quantity: 1 }], }, shippingAddress: { address: "Street 123", city: "San Francisco", postalCode: "94210", state: "CA", country: "US" }, }) { identifier message } } ``` 2. **\[Run (実行)\]**​ をクリックします。 DataGraph は、新しい注文を作成したことを示す結果を返します。 ![サンプル変異を実行すると新しい注文が作成されます](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-mutation-result.png) ## [](#クエリを作成する)クエリを作成する 次に、作成した注文に関する特定の情報を取得するためのクエリを作成できます。この場合、​`shipmentItems`​ に関する詳細を取得できます。 1. 準備ができたら、次のサンプルクエリを追加します。 ```copy { ordersByOrderId(orderId: "51c0ba3a-7e64-11e7-bb31-be2e44b06b34") { shippingAddress { state city postalCode } total status orderItems { shipmentItems { product { model description brand price { amount { name currencyValue } } } } } } } ``` この 1 つのクエリで、2 種類の API から結果を取得します。 ![1 つのクエリで 2 種類の API を照会](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-two-apis.png)
1 Catalyst Order API から ​shippingAddress​、​total​、​status​ の情報が返されます。
2 product​ の詳細は、​shipmentItems​ 情報の一部として Catalyst Product API から返されます。

これが Anypoint DataGraph の基本的な用途です。つまり、1 回の要求で複数の API を照会し、必要とする情報のみを取得できます。

1. クエリをトレースせずに実行する場合は、​**\[Run (実行)\]**​ をクリックします。 ![クエリエディターに表示されたクエリ結果](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-query-result.png) 2. クエリを実行してトレースする場合は、アクションメニュー (​**…​**​) から ​**\[Trace Query (クエリをトレース)\]**​ を選択して、​**\[Run (実行)\]**​ をクリックします。 ![クエリのトレースビューとクエリ結果](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-query-traces.png) Anypoint DataGraph のトレース結果には、次の情報が示されます。 - Anypoint DataGraph でクエリの解析と検証に要した時間 - クエリ全体の合計応答時間 - クエリでの各ソース API への要求時間 3. クエリに関連するログを表示するには、アクションメニュー (​**…​**​) から ​**\[View Response Logs (応答ログを表示)\]**​ をクリックします。 ![クエリの応答ログページ](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-response-logs.png) Anypoint DataGraph のログレベルには、DEBUG、INFO、WARN、ERROR があります。 Titanium サブスクリプションに登録している場合は、Anypoint Monitoring でこれと同じログを表示することや、高度な検索を使用して特定の日付、時刻、優先度のログを見つけることができます。 4. **\[View History (履歴を表示)\]**​ をクリックすると、後からこの同じクエリ (または別のクエリ) にアクセスできます。 5. クエリと、自動的に生成されたエンドポイントをコピーするには、アクションメニュー (​**…​**​) から ​**\[Copy & Share Endpoint (エンドポイントのコピーと共有)\]**​ をクリックします。 \[クリップボードにコピー\] アイコンを使用して、クエリを cURL スニペットまたは GraphQL クエリとしてコピーします。また、クエリで使用する任意の認証値、リクエストヘッダー、変数などもコピーできます。 ## [](#関連情報)関連情報 - [Anypoint DataGraph の用語](https://docs.mulesoft.com/jp/datagraph/datagraph-terms) - [API スキーマの要素の理解](https://docs.mulesoft.com/jp/datagraph/schemas) - [DataGraph での GraphQL クエリおよび変異の作成](https://docs.mulesoft.com/jp/datagraph/write-queries-tutorial) # Anypoint DataGraph での API コールのスケーリング Anypoint DataGraph には、統合スキーマで許可される API コール数を設定するオプションがあります。API コール数を増減することで、必要に応じて処理するワークロードを増やし、コンシュームを最適化できます。 ## [](#datagraph-の-api-コールスケーリングのしくみ)DataGraph の API コールスケーリングのしくみ DataGraph では、デフォルトで環境ごとに統合スキーマあたり最大で年間 100 万回の API コールと 150 の同時または実行中のコールがサポートされます。最初の API を統合スキーマに追加した後、年間および同時の最大コール数を更新できます。 ただし、スケーリングの前に、プランでビジネスグループまたは組織について適切な数の vCore を割り当てる必要があります。環境に割り当てられた vCore 数の残り空き容量を超えてその環境内の API コールをスケーリングすることはできません。本番環境と Sandbox 環境にはそれぞれ独自の統合スキーマあたりのスケーリングオプションがあります。 **\[API Call Scaling (API コールスケーリング)\]**​ ページには選択可能なスケーリングオプションが表示されます。 ![api call scaling](/mulesoft/current/ja-jp/datagraph/_images/api-call-scaling.png) 各オプションには ​**\[Annual API Calls (年間 API コール数)\]**​ が含まれます。これは 1 年間に統合スキーマに対して実行できる API 要求の総数です。年間オプションを選択した場合、次の値も選択します。 - **Concurrent Calls (同時コール数)**​: 統合スキーマが並行して処理できるアクティブな API 要求の数 - **\# of Workers (ワーカー数)**​: 統合スキーマへの要求をアクティブに処理できる専用 Mule インスタンスの数 表示ラベル ​**\[Insufficient Capacity (容量不足)\]**​ は、そのオプションを選択するにはビジネスグループで割り当てている容量が不足であることを示します。ビジネスグループ管理者は、他の環境の使用量を減らしたり、ビジネスグループの追加容量を購入したりして容量を増やすことができます。 ## [](#選択可能なスケーリングオプション)選択可能なスケーリングオプション 次の表は、選択可能なスケーリングオプションの詳細です。
Annual API Calls (年間 API コール数) Concurrent Calls (同時コール数) # of Workers (ワーカー数)

100M

150

1

200M

300

2

300M

450

3

400M

600

4

500M

750

5

600M

900

6

700M

1050

7

800M

1200

8

## [](#api-コールスケーリングを設定する)API コールスケーリングを設定する API コールスケーリングを使用して現在の環境で統合スキーマに対して実行できる API コールの数を増減します。 調整するには、少なくとも 1 つの API が統合スキーマに追加されている必要があります。 DataGraph ​[管理者またはオペレーター権限](https://docs.mulesoft.com/jp/datagraph/permissions)​が必要です。 1. \[Anypoint Platform\] > \[Anypoint DataGraph\] で ​**\[Settings (設定)\]**​ をクリックします。 2. **\[API Call Scaling (API コールスケーリング)\]**​ タブで、選択可能なオプションを選択します。 3. **\[Save Changes (変更を保存)\]**​ をクリックします。 ## [](#関連リソース)関連リソース - [統合スキーマへの API の追加](https://docs.mulesoft.com/jp/datagraph/add-api-to-unified-schema) - [DataGraph の使用量メトリクスの表示](https://docs.mulesoft.com/jp/datagraph/usage-metrics) - [DataGraph の API のサポート](https://docs.mulesoft.com/jp/datagraph/#anypoint-datagraph-api-support) # Anypoint DataGraph でのオブジェクト種別コラボレーションの有効化 レベル-1 オブジェクト種別のコラボレーションを有効にすると、統合スキーマを接続し、強化することができます。 コラボレーションが有効化された種別は、API スキーマや他の API スキーマの類似の種別とコラボレーションして、それら独自の項目を追加できるようになります。その結果、より多くの項目やデータセットを使用でき、この種別のクエリ結果がさらに強化されます。 コラボレーションが有効化された種別では、項目が統合スキーマやローカル API スキーマの他の種別に提供されるため、次のことができます。 - 種別間のリンクを作成する 詳細は、​[「Anypoint DataGraph のオブジェクト種別間のリンクのしくみ」](https://docs.mulesoft.com/jp/datagraph/linking)​を参照してください。 - 種別を他の種別とマージする 詳細は​[「種別のマージ」](https://docs.mulesoft.com/jp/datagraph/merge-types)​を参照してください。 コラボレーションは、クエリメソッドから直接返されるレベル-1 オブジェクト種別でのみ有効化できます。詳細は、​[「レベル-1 種別とネストされた種別」](https://docs.mulesoft.com/jp/datagraph/schemas#level-1-and-nested-types)​を参照してください。 コラボレーションを有効にするための要件を正しく理解するには、API スキーマ内の種別を理解しておく必要があります。詳細は、[API スキーマの要素の理解](https://docs.mulesoft.com/jp/datagraph/schemas)を参照してください。 ## [](#デフォルトのクエリメソッドと主キー)デフォルトのクエリメソッドと主キー 種別のコラボレーションを有効にするには、その種別が項目にアクセスするためのデフォルトのクエリメソッドと 1 つまたは 2 つの主キーを設定する必要があります。 オブジェクト種別のデフォルトのクエリメソッドは、コラボレーションを有効にするそのオブジェクト種別のレコードを 1 件返すメソッドです。クエリメソッドをデフォルトとして選択できるのは次の場合のみです。 - 1 つまたは 2 つの必須入力引数がある。 - 入力引数がスカラーデータ型である (​`Int`​、​`Float`​、​`String`​、​`Boolean`​、​`ID`​ のいずれか)。 主キーはオブジェクト種別に含まれる項目で、そのオブジェクト種別の 1 つのレコードを一意に識別します。項目を主キーにするには、表示される Null 不可能 (末尾の ​`!`​ 記号で表される) な項目である必要があります。クエリメソッドで 2 つの主キーが使用されている場合、それは​_複合キー_​です。 たとえば、次の API スキーマの Order 種別のコラボレーションを有効にするとします。 ```none ordersById (id: ID!): Order -------------------- -------------------- Order -------------------- orderId: ID! date: String status: String ``` この例では、デフォルトのクエリメソッドは ​`ordersById`​、その主キーは ​`orderId`​ です。 ​`ordersById`​ が ​`Order`​ 種別を取得し、​`orderId`​ を使用して ​`ID`​ 項目に基づいて特定の情報を取得します。デフォルトのクエリメソッドの入力引数 ​`ID`​ のデータ型は主キーのデータ型と同じである必要があります。この例では、どちらのデータ型も ​`ID!`​ です。 ### [](#複合キーを使用するデフォルトのクエリメソッド)複合キーを使用するデフォルトのクエリメソッド 次の複合キーを使用する例では、デフォルトのクエリメソッドは ​`productDetail`​、その複合キーは ​`productId`​ と ​`productSku`​ です。どちらも ​`Product`​ 種別を取得し、​`productId`​ と ​`productSku`​ を使用して ​`string`​ 項目に基づいて特定の情報を取得します。デフォルトのクエリメソッドの入力引数のデータ型は各主キーのデータ型と同じである必要があります。この例では、どちらのデータ型も ​`string!`​ です。 ```none productDetail (id: String!, sku: String!): Product -------------------- -------------------- Product -------------------- productDetail: string!, string! productId: String productSku: String ``` ## [](#enable-collaboration-on-an-object-type)オブジェクト種別のコラボレーションを有効にする 1. API スキーマナビゲーションで、コラボレーションを有効にするレベル-1 オブジェクト種別を選択します。 2. **\[Collaboration permissions (コラボレーション権限)\]**​ ペインで、​**\[Enable collaboration (コラボレーションを有効化)\]**​ をクリックします。 3. デフォルトのクエリメソッドを設定します。 次の画像は、2 つの必須引数を使用するクエリメソッドを示します。 ![複合キーを使用するデフォルトのクエリメソッド](/mulesoft/current/ja-jp/datagraph/_images/composite-keys-default-query-method.png) 4. **\[Next (次へ)\]**​ をクリックします。 5. クエリメソッドに応じて、1 つまたは 2 つの主キーを選択します。 次の画像ではクエリメソッドが 2 つの必須引数を使用しており、複合キーを示します。 ![2 つの主キーが選択されている](/mulesoft/current/ja-jp/datagraph/_images/composite-keys.png) ## [](#オブジェクト種別のコラボレーションを無効化する)オブジェクト種別のコラボレーションを無効化する オブジェクト種別がその項目を他の種別に提供することを停止するには、その種別のコラボレーションを無効化します。ただし、統合スキーマ内の別のオブジェクト種別とマージされているオブジェクトのコラボレーションを無効化すると、マージが切断されて競合が発生するため、解決する必要があります。 コラボレーションを無効化する手順は、次のとおりです。 1. **\[List of APIs added (追加された API のリスト)\]**​ をクリックし、コラボレーションを無効化するオブジェクト種別が含まれる API を選択します。 2. API スキーマナビゲーションで、オブジェクト種別を選択します。 3. **\[Collaboration permissions (コラボレーション権限)\]**​ ペインで、​**\[Allow collaboration for this type (Extend this type) (この種別のコラボレーションを許可 (この種別を拡張))\]**​ を選択解除します。 4. 確認を促されたら、​**\[Undo merge and disable collaboration (マージを元に戻してコラボレーションを無効化)\]**​ をクリックしてオブジェクト種別のコラボレーションを無効化することを確認します。 5. 競合が発生したら、Anypoint DataGraph の画面の指示に従って解決します。 # Anypoint DataGraph でのオブジェクト種別のマージのしくみ API スキーマのオブジェクト種別を、統合スキーマの別のオブジェクト種別か、同じ API スキーマの別のオブジェクト種別のいずれかにマージできます。種別のマージにより、類似の種別を 1 つの種別に結合して項目やデータセットを拡張し、クエリ結果を向上させることができます。 オブジェクト種別は他のオブジェクト種別にのみマージできます。​_拡張マージ_​では種別のマージによってデータが結合され、​_複合マージ_​では種別のマージによって統合スキーマが整理されますが、この場合は主キーなしで結合されます。 Anypoint DataGraph では、マージを設定する種別を​_現在の種別_​、マージ先の種別を​_対象種別_​とします。 ## [](#コラボレーションが有効な-2-つの種別のマージ)コラボレーションが有効な 2 つの種別のマージ 現在の種別をコラボレーションが有効になっている対象種別にマージできます。両方の種別が主キーを指定している場合は、両方の主キーが同じオブジェクトを表し、そのオブジェクトの同じレコードを識別することを確認します。拡張マージと呼ばれるこの種のマージでは、両方のオブジェクト種別から同じデータセットが返されます。 たとえば、デフォルトの ​`customersById(id)`​ クエリメソッドと ​`id`​ 主キーを使用して ​`Customer`​ 種別を返す Customer API スキーマがあるとします。 ```none customersById(id): Customer -------------------- -------------------- Customer -------------------- id: string! email: firstName: lastName: telephone: ``` また、​`User`​ 種別がある ​`UserAccount`​ という API スキーマもあります。 ```none usersById(id): User -------------------- -------------------- User -------------------- id: email: address: Address accountId: type: organization: -------------------- -------------------- Address -------------------- addressLine1: addressLine2: city: postalCode: state: country: ``` Customer 種別と User 種別の両方が同じオブジェクト種別を参照し、その同じオブジェクトの同じ情報を返すとします。主キーの値を同じにするには、両方の種別が同じ Customer オブジェクトを識別する必要があります。さらに、両方の種別に共通する項目も、同じ値を返す必要があります。たとえば、​`Customer`​ 種別の ​`id = 1`​ と ​`User`​ 種別の ​`id = 1`​ の場合、メール項目の値がまったく同じでなければなりません。 この 2 つの種別をマージすると、同じ顧客に関するデータが結合され、1 回の要求で照合できます。 また、どちらの種別にも、同じオブジェクトを取得するデフォルトのクエリメソッドが設定されているため、この 2 つの種別をマージして、統合スキーマに結合されたクエリメソッドと種別が 1 つだけ存在するようにすることも可能です。 - Customer 種別 - デフォルトのクエリメソッド: `customersById(id): Customer` - 主キー: `id` - UserAccount 種別: - デフォルトのクエリメソッド: `usersById(id): User` - 主キー: `id` この結果、統合スキーマにマージされ、拡張された種別が 1 つ存在することになります。 ### [](#マージ後の種別の順序)マージ後の種別の順序 統合スキーマに最初に追加された種別が、マージ後の種別と対応するデフォルトのクエリメソッドの名前を優先的に定義します。 この例では、Customer API の種別が最初に追加されたため、統合スキーマに生成された種別は ​`Customer`​ という名前になり、Customer 種別と UserAccount 種別の両方のすべての項目が含まれます。生成されたクエリメソッドは ​`customersById`​ という名前で、マージされた ​`Customer`​ 種別を返します。 ```none customersById(id): Customer -------------------- -------------------- Customer -------------------- id: string! email: firstName: lastName: telephone: address: Address accountId: type: organization: -------------------- -------------------- Address -------------------- addressLine1: addressLine2: city: postalCode: state: country: ``` ## [](#一方のコラボレーションのみが有効になっている-2-つの種別のマージ)一方のコラボレーションのみが有効になっている 2 つの種別のマージ 2 つの種別の一方のコラボレーションのみが有効になっている場合でもマージできます。この種のマージでは、現在の種別 (マージを設定する種別) が対象種別 (マージ先の種別) への​_参照_​として機能します。マージを実行するためには、対象種別のコラボレーションが有効になっている必要があり、また、両方の種別が 1 つの主キーを定義するか、​[複合キー](#merging-types-that-use-composite-keys)​を使用する必要があります。 マージが完了すると、参照が宣言され、対象種別の項目のみを取得できます。現在の種別の主キー以外の項目は非表示になり、照会できません。 たとえば、​`Product`​ 種別を返す ​`Order`​ API スキーマがあるとします。 ```none ordersById(id: string!) : Order Order ---------- id: string! amount: float! date: string! product: Product ----------- ----------- Product ----------- id: string! name: string ------------ ``` `Product API Schema`​ も ​`Product`​ 種別を返します。 ```none productsById(id: string!) : Product Product ------------ id: string! name: string brand: string description: string unitPrice: float! quantityRemaining: int! ----------- ``` Order API スキーマの Product 種別を Product API スキーマの Product 種別にマージできます。この場合、Order API スキーマの Product 種別が Product API スキーマの Product 種別の参照になります。 マージ後の統合スキーマは次のようになります。 ```none ordersById(id: string!) : Order productsById(id: string!) : Product Order ---------- id: string! amount: float! date: string! product: Product ----------- ----------- Product ----------- id: string! name: string brand: string description: string unitPrice: float! quantityRemaining: int! ----------- ``` `Order`​ 種別によって関連する商品のより多くのデータが返されるようになり、別のクエリを作成する必要がありません。 この例では、どちらの種別も主キーが ​`id`​ で、どちらの API も、​`id`​ で同じ商品オブジェクトレコードを返します。 ## [](#複合キーを使用する種別のマージ)複合キーを使用する種別のマージ マージする種別に、​_複合キー_​を使用するクエリメソッドを設定することもできます。 たとえば、同じ ​`Order`​ API スキーマが ​`Product`​ 種別を返すとします。 ```none ordersById(id: string!) : Order Order ---------- id: string! amount: float! date: string! product: Product ----------- ----------- Product ----------- id: string! name: string sku: string ------------ ``` 他方、​`SalesOrder`​ API は ​`Product`​ 種別を返しますが、​`id`​ と ​`sku`​ の複合キーを使用します。 ```none SalesOrder(id: string!, sku: string!) : SalesOrder Product ------------ id: string! sku: string! name: string brand: string description: string unitPrice: float! quantityRemaining: int! ----------- ``` マージ後の統合スキーマは次のようになります。 ```none ordersById(id: string!, sku: string!) : Order SalesOrderByID(id: string!, sku: string!) : SalesOrder Order ---------- id: string! amount: float! date: string! product: Product ----------- ----------- Product ----------- id: string! sku: string! name: string brand: string description: string unitPrice: float! quantityRemaining: int! ----------- ``` ## [](#主キーが設定されていない-2-つの種別のマージ)主キーが設定されていない 2 つの種別のマージ マージする 2 つの種別のいずれにも主キーが定義されていない場合は、複合マージが行われます。このマージ方法では、デフォルトのクエリメソッドも主キーも指定する必要がありません。 どちらの種別にも主キーがないため、マージした場合、種別から返されるデータセットが結合されるのではなく、両方の種別が 1 つの種別に結合されます。このマージでは、同じオブジェクトを参照せず、項目を結合します。現在の種別と対象種別をマージすると、現在の種別のすべての項目が統合スキーマで null 可能になります。このマージによる種別のクエリ結果への影響はありませんが、重複する種別によって返されるデータセットが異なる場合に統合スキーマが整理されます。 たとえば、​`Amount`​ 種別を返す ​`Europe Sales API Schema`​ があるとします。 Europe Sales API スキーマ ```none Amount ---------- currency: String price: float ``` `North America API Schema`​ も ​`Amount`​ 種別を返します。 North America API スキーマ ```none Amount ---------- currency: String price: float ``` この 2 つをマージすると、統合スキーマには、クエリに応じて Europe Sales API と North America Sales API のいずれかから返される ​`Amount`​ 種別が 1 つのみ存在します。この 2 つの種別は似ていますが、データセットが結合されていません。 ## [](#入力種別のマージ)入力種別のマージ 入力種別は、変異を実行するときに統合スキーマの情報を変更するために使用する POST、PUT、および DELETE オブジェクトです。 すべての項目が一致する場合にのみ、2 つの入力種別をマージできます。両方の種別に同じ数の項目が必要であり、項目のサブセットを含めることはできません。 たとえば、次の同一の項目を含む ​`OrderInput`​ API と ​`PurchaseInput`​ API があるとします。 OrderInput ---------- orderId: String! customerEmail: String! customerId: String! OrderDate: String! product: Product Status: OrderStatus totalAmount: float 統合スキーマで ​`OrderInput`​ API を ​`PurchaseInput`​ API にマージして、これらの種別を統合できます。 入力種別をマージするために、コラボレーションを有効にする必要はなく、有効にすることもできません。 ## [](#同じ-api-スキーマのオブジェクト間のローカルマージ)同じ API スキーマのオブジェクト間のローカルマージ オブジェクト種別を同じ API スキーマの別のオブジェクト種別にマージする場合はローカルマージが行われます。生成されたこの種別を、ローカルの別のオブジェクト種別や統合スキーマの種別にマージすることもできます。 ローカルマージ後は、マージによって生成された種別のみを表示して編集できます。さらに、種別のコラボレーションを有効または無効にすることや、そのデフォルトのクエリメソッドや主キーを変更することはできません。オブジェクト種別や項目の名前変更、オブジェクト種別や項目の非表示、別のオブジェクト種別とのマージやリンクは実行できます。 ### [](#ローカルマージの項目の表示)ローカルマージの項目の表示 共通の項目がある 2 つのオブジェクト種別をローカルマージするときに、これらの項目の表示が異なる場合、ローカルでマージされた種別の項目の表示は次のようになります。
シナリオ 種別 A の項目 種別 B の項目 マージされた種別 (ローカル)

1

非表示

非表示

非表示

2

非表示

表示

表示

3

表示

非表示

表示

4

表示

表示

表示

## [](#関連情報)関連情報 - [オブジェクト種別のマージの作成および編集](https://docs.mulesoft.com/jp/datagraph/manage-merges) # Anypoint DataGraph でのスキーマ要素の表示 統合スキーマで表示する必要がない項目、種別、クエリメソッドを非表示にできます。非表示にした項目、種別、クエリメソッドは、照会できなくなります。 スキーマ要素の表示を管理することで、統合スキーマを管理しやすくクリーンに保つことができます。要素の表示は後で変更できます。 Anypoint DataGraph では、非表示にすることを選択した要素は _\[Hidden (非表示)\]_ になり、再表示することを選択した要素は _\[Visible (表示)\]_ になります。 デフォルトでは、すべてのネストされた種別は非表示です。ネストされた種別を統合スキーマに追加してそれを照会する場合は、最初に再表示する必要があります。 デフォルトのクエリメソッドとなるように設定したメソッド、または主キーとして設定した項目を非表示にすることはできません。 ## [](#スキーマ要素の表示を管理する)スキーマ要素の表示を管理する API スキーマの要素を非表示または再表示することで、統合スキーマで使用できる情報の粒度を制御できます。 API スキーマで、表示を管理するオブジェクト、項目、またはメソッドを選択し、​**\[Hidden/Visible (非表示/表示)\]**​ 切り替えをクリックします。 統合スキーマに要素を追加する _前_ に、要素を非表示または再表示する必要があります。 ![order item summary の表示の \[Desired state (望ましい状態)\] を \[Visible (表示)\] に設定](_images/visible-object-type.png) # Anypoint DataGraph でのセキュリティの設定 Anypoint DataGraph が統合スキーマに追加する API の GET エンドポイントにアクセスできるように、認証をセットアップする必要があります。認証により、クエリを実行するときに DataGraph はこれらの API に要求を送信できます。 必要に応じて、API と DataGraph 間の相互認証 (mTLS) もセットアップできます。 ## [](#サポートされる認証方法)サポートされる認証方法 統合スキーマに新しい API スキーマを追加する場合、または API スキーマを別の環境に昇格する場合、次の認証方法のいずれかを設定する必要があります。 - **No Auth (認証なし)**​ API が公開の場合に使用します。 - **Basic Auth (基本認証)**​ 基本認証ヘッダー、またはユーザー名とパスワードを使用して、API に対する認証を行う場合に使用します。 次に例を示します。 ```CURL curl "http://localhost/myResource" -u myUser:myPassword ``` または ```CURL curl GET 'http://localhost/myResource' \ --header 'Content-Type: application/json' \ --data-raw '{ "username": "myUser", "password": "myPassword" }' ``` - **Pass-through authentication (パススルー認証)**​ 認証ヘッダーを渡して API に対する認証を行う場合に使用します。 次の情報を指定する必要があります。 - **Query Header Name (クエリヘッダー名)**​: 最初のクエリで統合スキーマに送信される HTTP ヘッダーの名前。 - **API Header Name (API ヘッダー名)**​: 基盤となる API に渡されるヘッダー名。これは、基盤となる API に渡す前にクエリヘッダーの名前を変更する場合に役立ちます。 - **Client ID enforcement via headers (ヘッダー経由のクライアント ID 適用)**​ `client_id`​ および ​`client_secret`​ ヘッダーを渡して API に対する認証を行う場合に使用します。 次に例を示します。 ```CURL curl "http://localhost/myResource" -H "client_id:1234" -H "client_secret:abcd" ``` - **Client ID enforcement via query parameters (クエリパラメーター経由のクライアント ID 適用)**​ `client_id`​ および ​`client_secret`​ クエリパラメーターを渡して API に対する認証を行う場合に使用します。 次に例を示します。 ```CURL curl "http://localhost/myResource?client_id=1234&client_secret=abcd" ``` - **OAuth 2.0 Client Credentials (OAuth 2.0 クライアントログイン情報)**​ OAuth 2.0 の ​`client_id`​、​`client_secret`​、認証サーバーの値を渡して API に対する認証を行う場合に使用します。 次に例を示します。 ```CURL curl --request POST \ --url 'https://YOUR_DOMAIN​/oauth/token' \ --header 'content-type: application/x-www-form-urlencoded' \ --data 'grant_type=authorization_code&client_id=​YOUR_CLIENT_ID​&code_verifier=​CODE_VERIFIER​&code=​AUTHORIZATION_CODE​&redirect_uri=https://YOUR_APP​/callback' ``` - **Custom (カスタム)**​ カスタムヘッダーパラメーターと値を使用して API に対する認証を行う場合に使用します。 追加した API にアクセスするためのそれ以外の認証方法 (有効期間の短いトークン方式など) はサポートされていません。 ## [](#datagraph-での相互認証の設定)DataGraph での相互認証の設定 相互認証 (mTLS) により、Datagraph および統合スキーマ内の基盤となる API で安全かつ検証済みの接続が作成されます。 API に mTLS が必要な場合は、API を統合スキーマに追加するとき、または API を別の環境に昇格するときに mTLS を設定します。これを行うには、次の情報を指定します。 - 含まれるキーストア: - 組織のルート認証機関 (CA) によって署名された公開証明書 - 証明書署名要求 (CSR) の生成に使用される非公開キー - 非公開キーのパスワード 必要に応じて、統合スキーマが API に到達できるようにするために、トラストストアを追加し、ルート CA を含む証明書バンドルを提供できます。 Anypoint Platform は、​[シークレットマネージャー](https://docs.mulesoft.com/jp/anypoint-security/index-secrets-manager)​の PEM ファイルにキーストアとトラストストアを保存します。

自己署名証明書を使用して API に対して mTLS を有効にすると、DataGraph はその API との TLS 接続を確立できなくなります。

## [](#統合スキーマに追加した-api-の-mtls-を編集する)統合スキーマに追加した API の mTLS を編集する 統合スキーマに追加した API の mTLS を設定する必要がある場合、​**\[API details (API の詳細)\]**​ ページでキーストアを追加して設定できます。 トラストストアを追加して統合スキーマから API へのアクセスを許可することもできます。
API にすでにキーストアまたはトラストストアがある場合、​[API details (API の詳細)]​ ページで削除してから新規追加できます。そのためには、​[Remove and add a new one (削除して新規追加)]​ をクリックします。
1. **\[List of APIs added (追加された API のリスト)\]**​ をクリックし、URL を編集する API を選択します。 2. **\[API details (API の詳細)\]**​ をクリックします。 3. **\[Configure Keystore (キーストアを設定)\]**​ を選択して次の情報を指定します。 - 組織の「ルート」認証機関 (CA) によって署名された公開証明書 - 証明書署名要求 (CSR) の生成に使用される非公開キー - 非公開キーのパスワード 4. 必要に応じて、​**\[Configure Truststore (トラストストアを設定)\]**​ を選択し、ルート CA が含まれる証明書バンドルへのリンクを指定します。 5. **\[Save (保存)\]**​ をクリックします。 ## [](#関連リソース)関連リソース - [統合スキーマへの API ソースの追加](https://docs.mulesoft.com/jp/datagraph/add-api-to-unified-schema) - [API スキーマの昇格](https://docs.mulesoft.com/jp/datagraph/promote-api) - [統合スキーマに追加された API の認証方法を変更する](https://docs.mulesoft.com/jp/datagraph/add-api-to-unified-schema#change-the-authentication-method-for-an-api-added-to-the-unified-schema) # Anypoint DataGraph での状況更新の表示 API や統合スキーマを操作中、状況更新で、統合スキーマにいつクエリを実行できるのか、統合スキーマへの変更がいつ有効になるのか、どの API スキーマが追加、削除、更新されているのかを知ることができます。 ## [](#状況-更新中)状況: 更新中 統合スキーマにはいつでも追加や更新を実行できます。変更を適用すると、状況が ​**\[Updating (更新中)\]**​ になり、進行状況とキューに登録済みの更新が示されます。この状況更新は、その環境の権限を有するビジネスグループの全員が表示できます。 ![API スキーマを統合スキーマに追加中であることを示す状況インジケーター](/mulesoft/current/ja-jp/datagraph/_images/datagraph-status-update-in-process.png) 統合スキーマの更新時、スキーマの新しい変更を表示し、追加の変更を加え、新しい変更を適用できます。ただし、更新が完了するまで、こうした変更にクエリを実行することができません。 キューに登録済みの更新が終了すると、状況が ​**\[finished (完了)\]**​ に変わります。 ![更新が完了したことを示す状況インジケーター](/mulesoft/current/ja-jp/datagraph/_images/datagraph-status-update-finished.png) すべての更新が完了すると、状況が ​**\[Up to date (最新状態)\]**​ に変わります。 ![統合スキーマが最新状態であることを示す状況インジケーター](/mulesoft/current/ja-jp/datagraph/_images/status_uptodate.png) ## [](#状況-保留中)状況: 保留中 Anypoint DataGraph を利用できない場合は、状況が ​**\[On hold (保留中)\]**​ に変化します。 変更を実行していた場合は、Anypoint DataGraph が利用可能になった時点でその変更が自動的に適用され、状況が ​**\[Updating (更新中)\]**​ になり、追加、削除、更新されている API の詳細が示されます。 状況が ​**\[On hold (保留中)\]**​ の場合も引き続き統合スキーマやソースリストを参照できますが、編集することはできません。また、以前にデプロイした統合スキーマにクエリを実行することもできます。 ## [](#更新の競合の解決)更新の競合の解決 既存の API スキーマを変更したり、統合スキーマに追加したりすると、Anypoint DataGraph で統合スキーマのメタデータが自動的に更新されます。この更新は瞬時に行われ、更新されたメタデータがほぼリアルタイムで保存されます。 ただし、ごく稀にメタデータにエラーが生じることがあります。たとえば、他のコントリビューターが同時に競合する変更を適用した場合などです。こうした状況では、統合スキーマの最新バージョンを処理していることを確認してから、変更を再度実行する必要があります。 # Anypoint DataGraph での自動永続クエリとコンテンツ配信ネットワークの使用 パフォーマンスを向上させ、ネットワークトラフィックの潜在的なボトルネックを減らすために、DataGraph では自動永続クエリがサポートされています。また、永続クエリをコンテンツ配信ネットワーク (CDN) と組み合わせて使用すると、DataGraph サーバーへの往復処理よりもはるかに速くキャッシュされた結果を配信できます。 ## [](#datagraph-での自動永続クエリのしくみ)DataGraph での自動永続クエリのしくみ 永続クエリを作成するには、次の情報を含む POST 要求を送信します。 - GraphQL クエリとクエリ変数。 - 理想的には SHA-256 などのハッシュアルゴリズムを使用して作成された、一意の ID を含む ​`persistedQuery`​ 拡張パラメーター。ハッシュを使用すると、競合の可能性が制限され、複数のクライアントが同じ ID を使用してクエリにアクセスできます。 永続クエリを作成したら、persistedQuery 拡張パラメーターとしてハッシュ ID を渡すことで、GET 要求を DataGraph に送信できます。 ## [](#自動永続クエリを-datagraph-に登録する)自動永続クエリを DataGraph に登録する 永続クエリを送信するには、次の要件を満たしている必要があります。 - DataGraph コンシューム権限 - 有効なクライアント ID とシークレットを使用した DataGraph への認証済み接続 - 永続クエリの ID 永続クエリを登録するには、次の情報を含む POST 要求を送信します。 - DataGraph インスタンスのエンドポイント - `persistedQuery`​ パラメーターを含む拡張機能 - `persistedQuery`​ パラメーター内の ID - GraphQL クエリと変数 次の例は、curl を使用して永続クエリを登録する方法を示しています。 ```copy curl --location --request POST 'https:///graphql' \ --header 'Content-Type: application/json' \ --data-raw '{ "extensions": { "persistedQuery": { "version": 1, "sha256Hash": "bcd3868f0cb4f723cdb5bdbc433d6ab73156f0b9d0e9d5bd17e200cdab6fba4" } }, "query": "{\n customers(customersCount: 30) {\n customerId\n name\n }\n}", "variables": {} } ``` ## [](#datagraph-から永続クエリを要求する)DataGraph から永続クエリを要求する DataGraph から永続クエリを要求するには、次の要件を満たしている必要があります。 - DataGraph コンシューム権限 - 有効なクライアント ID とシークレットを使用した DataGraph への認証済み接続 永続クエリを要求するには、次の情報を含む GET 要求を作成します。 - DataGraph インスタンスのエンドポイント - `persistedQuery`​ パラメーターを含む拡張機能 - `persistedQuery`​ パラメーター内の ID 次の例は、curl を使用して永続クエリを要求する方法を示しています。 ```copy curl --location --request GET 'https:///graphql?extensions=%7B%0A%20%20%22persistedQuery%22%3A%20%7B%0A%20%20%20%20%22version%22%3A%201%2C%0A%20%20%20%20%22sha256Hash%22%3A%20%22acf31818e50ac3e818ca4bdbc433d6ab73176f0b9d5f9d5ad17e200cdab6fba4%22%0A%20%20%7D%0A%7D' ``` ## [](#クエリが見つからないエラーのトラブルシューティング)クエリが見つからないエラーのトラブルシューティング 要求で ID を送信してクエリが見つからない場合、DataGraph はクエリは永続クエリでないというエラーを返します。 { "errors": \[ { "message": "PersistedQueryNotFound", "locations": \[\], "extensions": { "persistedQueryId": "bcd3868f0cb4f723cdb5bdbc433d6ab73156f0b9d0e9d5bd17e200cdab6fba4", "classification": "PersistedQueryNotFound" } } \] } この時点で、クエリと ID を含む新しい POST 要求を送信してクエリを登録した後に、クエリを要求できます。 ## [](#cdn-での自動永続クエリの使用)CDN での自動永続クエリの使用 コンテンツ配信ネットワーク (CDN) では、GET 操作への完全な応答をキャッシュして、API のパフォーマンスを高速化できます。 多くの CDN のキャッシュ機能は GET 要求のみをサポートしているため、DataGraph の永続クエリを CDN に同期して高速に取得できます。
CDN を設定して操作する機能が必要です。
### [](#cdn-が-datagraph-の自動永続クエリと連携する方法)CDN が DataGraph の自動永続クエリと連携する方法 DataGraph の永続クエリを CDN と同期するプロセスは次のとおりです。 1. 永続クエリを DataGraph に登録します。 2. 永続クエリの ID を渡すことで、CDN に GET 要求を行います。 3. CDN によって要求が DataGraph に転送されます。 4. DataGraph は、API に追加した cache-control ディレクティブを含むヘッダーを使用して応答を返します。 5. 応答が CDN に保存され、返送されます。 6. 後続の GET 要求を CDN に発行し、応答を取得できます。 ### [](#サポートされる-cache-control-ディレクティブ)サポートされる cache-control ディレクティブ cache-control ディレクティブは、CDN で応答をキャッシュする方法を定義します。DataGraph では、次の cache-control ディレクティブがサポートされています。 - `private`​: 応答を非公開キャッシュ (ブラウザーのローカルキャッシュなど) にのみ保存できることを示します。 - `public`​: 応答を共有キャッシュに保存できることを示します。 - `max-age`​: 応答が生成されてから ​_n_​ 秒後まで応答が最新なままであることを示します。 - `no-cache`​: 応答をキャッシュに保存できるものの、各再利用前に発信元サーバーで検証する必要があることを示します。 - `no-store`​: 非公開キャッシュでも公開キャッシュでも応答を保存しないことを示します。 次の例の cache-control ヘッダーは、応答を共有キャッシュに 10 分間保存できることを示しています。 `“Cache-Control:public, max-age=600”`​ ### [](#datagraph-の動的-cache-control)DataGraph の動的 cache-control DataGraph は、永続化クエリの項目を解決するために使用される API から、cache-control ヘッダーの最も制限の厳しい値を自動的に選択します。 たとえば、それぞれに異なる ​`max-age`​ 値が含まれる 2 つの API の項目を含むクエリについて考えてみます。API-1 の ​`max-age`​ は 300 秒、API-2 の ​`max-age`​ は 500 秒です。クエリ応答の ​`max-age`​ ヘッダー値は、2 つの API の ​`max-age`​ として 300 秒を自動的に選択します。 ### [](#cdn-から永続クエリを要求する)CDN から永続クエリを要求する CDN から永続クエリを要求するには、次の要件を満たしている必要があります。 - DataGraph コンシューム権限。 - 有効なクライアント ID とシークレットを使用した DataGraph への認証済みパススルー接続。DataGraph に要求を渡すときにこれらの資格情報を追加するように CDN を設定するか、DataGraph へのルートの許可リストに資格情報ヘッダーを追加できます。 - CDN からコンテンツを要求したり CDN に対して認証したりするための権限。 - クエリの要求元の CDN へのエンドポイント。
extensions​、​variables​、​operationName​、​query​ クエリパラメーターを渡すように CDN を設定する必要があります。
CDN の永続クエリを要求するには、次の情報を含む GET 要求を作成します。 - CDN へのエンドポイント - `persistedQuery`​ パラメーターを含む拡張機能 - persistedQuery パラメーターのハッシュ ID 次の例は、curl を使用して CDN の永続クエリを要求する方法を示しています。 ```copy curl --location --request GET 'https:///graphql?extensions=%7B%0A%20%20%22persistedQuery%22%3A%20%7B%0A%20%20%20%20%22version%22%3A%201%2C%0A%20%20%20%20%22sha256Hash%22%3A%20%22acf31818e50ac3e818ca4bdbc433d6ab73176f0b9d5f9d5ad17e200cdab6fba4%22%0A%20%20%7D%0A%7D' ``` ## [](#関連情報)関連情報 - [サポートされる認証方法](https://docs.mulesoft.com/jp/datagraph/security#supported-authentication-methods) - [Anypoint DataGraph の権限の使用](https://docs.mulesoft.com/jp/datagraph/permissions) # Anypoint DataGraph のオブジェクト種別間のリンクのしくみ 現在のオブジェクト種別を別の対象オブジェクト種別にリンクして、クエリ結果を向上させることができます。リンクにより、異なるオブジェクトを説明する 2 つの関連する種別の項目を結合して、この 2 つの種別をつなぎ合わせることができます。 現在の種別のコラボレーションが有効になっていなくても、現在のオブジェクト種別を対象オブジェクト種別にリンクできますが、対象のコラボレーションが有効になっている必要があります。コラボレーションのしくみについての詳細は、「[Anypoint DataGraph でのオブジェクト種別コラボレーションの有効化](https://docs.mulesoft.com/jp/datagraph/collaboration)」を参照してください。 ## [](#オブジェクト種別間のリンクの作成)オブジェクト種別間のリンクの作成 2 つの API スキーマがあり、1 つに ​`Order`​ オブジェクト種別、もう 1 つに ​`Customer`​ オブジェクト種別があるとします。
注文スキーマ 顧客スキーマ
ordersByOrderId (orderId:String!):Order
--------------------
--------------------
Order
--------------------
orderId: String!
Items: Item[]
customerId: String!
customersByCustomerId (customerId:String!): Customer
--------------------
--------------------
Customer
--------------------
customerId: String!
name: String!
現在、統合スキーマは次のようになっています。 ```none ordersByOrderId (orderId:String!):Order customersByCustomerId (customerId:String!): Customer -------------------- -------------------- Order -------------------- orderId: String! Items: Item[] customerId: String! -------------------- -------------------- Customer -------------------- customerId: String! name: String! ``` 現在のこの設定で、注文データセットと顧客データセットを同時に照会するには、両方の種別を別々に照会する必要があります。 ```none ordersByOrderId (orderId: “123”) { orderId customerId } customersByCustomerId (customerId: “CC83”) { customerId name } ``` また、注文の顧客データを照会するには、その注文に関連付けられている顧客 ID が必要です。 ただし、​`Order`​ オブジェクト種別には ​`customerId`​ を返す項目があります。​`customerId: String!`​ を​_外部キー_​として、​`Order`​ オブジェクト種別を ​`Customer`​ オブジェクト種別に​_リンク_​すれば、​`Customer`​ を対象種別として参照できます。このリンクによって選択した外部キーが ​`Customer`​ 種別の主キー ​`customerId:String!`​ にマッピングされます。 その結果、次のようになります。 - `Order`​ オブジェクト種別に ​`Customer`​ という新しい項目が作成され、リンクされた ​`Customer`​ オブジェクト種別を返します。 - API スキーマで生成された新しいオブジェクト種別が ​`Customer`​ API スキーマの種別への参照として機能するため、​`Customer`​ API スキーマに行った変更が ​`Order`​ API スキーマに影響することがありません。 ```none ordersByOrderId (orderId:String!):Order -------------------- -------------------- Order -------------------- orderId: String! Items: Item[] customer: Customer -------------------- -------------------- Customer -------------------- -------------------- customerId: String! ``` 更新された統合スキーマで、​`Order`​ 種別が ​`Customer`​ 種別にリンクされていることがわかります。 ```none ordersByOrderId (orderId:String!):Order -------------------- -------------------- Order -------------------- orderId: String! Items: Item[] customer: Customer -------------------- -------------------- Customer -------------------- -------------------- customerId: String name: String ``` リンク後は、統合スキーマの消費者が、関連付けられている ​`customerId`​ を知らなくても、​`Order`​ データセットと関連する ​`Customer`​ データセットを同時に照会できます。 ```none ordersByOrderId (orderId: “123”) { orderId customer { name } } ``` ## [](#複合キーを使用するオブジェクト種別間のリンクの作成)複合キーを使用するオブジェクト種別間のリンクの作成 種別のデフォルトのクエリメソッドに​_複合キー_​を使用することもできます。 デフォルトのクエリメソッドに ​`customerId`​ と ​`customerStatus`​ の複合キーを使用する ​`Customer`​ 対象種別について考えてみます。 ```none customerDetail (id: string!, status: string!): Customer -------------------- -------------------- Customer -------------------- customerDetail: string!, string! customerId: String! customerStatus: String! ``` `Order`​ スキーマは上記と同じであるものとします。 ```none ordersByOrderId (orderId:String!):Order -------------------- -------------------- Order -------------------- orderId: String! Items: Item[] customerId: String! ``` `Customer`​ 種別を ​`Order`​ 種別の対象としてリンクすると、統合スキーマにリンクが次のように示されます。 ```none ordersByOrderId (orderId:String!):Order -------------------- -------------------- Order -------------------- orderId: String! Items: Item[] customerId: Customer customerStatus: Customer -------------------- -------------------- Customer -------------------- -------------------- customerDetail: String!, String! customerId: String! customerStatus: String! ``` ## [](#関連リソース)関連リソース - [オブジェクト種別間のリンクの作成および編集](https://docs.mulesoft.com/jp/datagraph/manage-links) # Anypoint DataGraph のトラブルシューティング 次のトピックでは、DataGraph でのトラブルシューティングに役立つ情報を提供します。 - [ランタイムエラーのトラブルシューティング](#troubleshooting-runtime-errors) - [スキーマエラーのトラブルシューティング](#troubleshooting-schema-errors) - [mTLS エラーのトラブルシューティング](#troubleshooting-mtls-errors) - [アクセスエラーのトラブルシューティング](#troubleshooting-access-errors) - [サーバーエラーのトラブルシューティング](#troubleshooting-server-errors) ## [](#ランタイムエラーのトラブルシューティング)ランタイムエラーのトラブルシューティング Anypoint DataGraph のクエリエディターを使おうとしたときにランタイムエラーが発生した場合は、次の方法でトラブルシューティングします。 ### [](#failed-to-fetch-schema-スキーマを取得できませんでしたエラー)「Failed to Fetch Schema (スキーマを取得できませんでした)」エラー 「Failed to Fetch Schema (スキーマを取得できませんでした)」エラーは、Anypoint DataGraph のクエリエディターに移動時に発生し、次のように表示されます。 { "message": "Failed to fetch", "stack": "TypeError: Failed to fetch" } Anypoint DataGraph でこのエラーが生成されるのは、統合スキーマを読み込めない場合で、次の 3 つのいずれかが原因です。 1. 共有ロードバランサーのポート 8082 を使用できない。 解決法: 専用ロードバランサー (DLB) を作成し、​[Anypoint DataGraph が要求を DLB 経由で転送するように URL を設定します](https://docs.mulesoft.com/jp/datagraph/set-dlb)​。 2. 無効な証明書を使用して DLB を設定している。 解決法: DLB に有効な CA 署名証明書があることを確認します。ない場合は、ブラウザーが Anypoint DataGraph に接続されません。 3. インターネットブラウザーが Anypoint Virtual Private Cloud (VPC) にアクセスできない。 解決法: インターネットブラウザーから Anypoint VPC に接続できることを確認します。Anypoint DataGraph のネットワーキングの概要については、​[「Anypoint DataGraph Architecture and Networking (Anypoint DataGraph アーキテクチャとネットワーキング)」](https://docs.mulesoft.com/jp/datagraph/hosting-options#anypoint-datagraph-architecture-and-networking)​を参照してください。 ### [](#exception-while-fetching-data-データの取得中の例外エラー)「Exception While Fetching Data (データの取得中の例外)」エラー クエリを実行後、Anypoint DataGraph に次のようなエラーが表示されます。 { { "errors": \[ { "message": "Exception while fetching data (/ordersById) : Error 429 executing request.", "locations": \[ { "line": 2, "column": 3 } \], "path": \[ "ordersById" \], "extensions": { "httpResponse": { "statusCode": 429, "xHeaders": { "x-ratelimit-limit": 10 "x-ratelimit-remaining": 0 "x-ratelimit-reset": 41827 "x-xss-protection": "1; mode=block" }, "contentType": "application/json", "body": { "error": "Quota has been exceeded" } }, "classification": "DataFetchingException" 「Exception while fetching data (データの取得中の例外)」エラーが生じるのは、統合スキーマがその基盤となる API に接続できない場合です。 このエラーをトラブルシューティングするには、次の点を確認します。 1. 基盤となる API が実行されている。 2. 各 API に正しい URL が指定されている。​**\[List of API added (追加された API のリスト)\]**​ > \[Select an API (API を選択)\] > ​**\[API Details (API の詳細)\]**​ に移動して、URL を確認します。 3. Anypoint VPC に接続されていないスタンドアロンインスタンスで実行される API の​[接続を要求する必要があります](https://docs.mulesoft.com/cloudhub/to-request-vpc-connectivity)​。 4. エラーメッセージの ​`extensions`​ セクションに、このエラーのトラブルシューティングに役立つと思われる情報がないか確認する。 ### [](#その他のランタイムエラー)その他のランタイムエラー - 無効なクエリを整形できない 無効なクエリを整形しようとすると、DataGraph で構文エラーが生成されます。この問題を解決するには、構文を修正してからクエリを整形します。 - 無効なアクションエラー DataGraph エディターで無効なスキーマを作成するアクションを実行すると、DataGraph によってエラーが生成されます。アクションが有効であると思われる場合は、MuleSoft サポートにお問い合わせください。 ## [](#スキーマエラーのトラブルシューティング)スキーマエラーのトラブルシューティング API スキーマを生成しようとしたときにランタイムエラーが発生した場合は、次の方法でトラブルシューティングします。 ### [](#api-スキーマ生成時に発生する可能性があるエラー)API スキーマ生成時に発生する可能性があるエラー 統合スキーマに新しい API を追加すると、Anypoint DataGraph は API スキーマを生成します。ただし、API 仕様のすべての機能が API スキーマに正常に生成されるわけではありません。 Anypoint DataGraph は、API 仕様の次の部分を API スキーマに変換しません。 - `Media type`​ 値が ​`application/json`​ 以外の要求 - `Media type`​ 値が ​`application/json`​ 以外の応答 - サポートされていない種別 ​`Schema`​、​`File`​、​`Tuple`​、​`Matrix`​、​`Nil`​、またはいずれかの種別の配列を含む応答ペイロード - 種別がスカラーまたはスカラー配列以外の ​`query params`​ および ​`headers`​ - サポートされていない種別の必須 ​`params`​ のエンドポイント - メンバーが ​`objects`​ および ​`nils`​ 以外の ​`union`​ 種別 - JSON スキーマキーワード ​`if`​、​`then`​、​`else` サポートされていない部分のみで API 仕様が構成されている場合、Anypoint DataGraph は API スキーマを生成せず、​`「Validation failed (入力規則エラー)」`​エラーをスローします。 ## [](#api-の追加更新またはプロモート時のエラーのトラブルシューティング)API の追加、更新、またはプロモート時のエラーのトラブルシューティング API を追加、更新、またはプロモートするときにエラーが発生した場合は、次の方法でトラブルシューティングします。 - 2 人のユーザーが同時に環境を更新したときのエラー 2 人のユーザーが同時に環境を更新しようとすると、DataGraph によって一方のユーザーでエラーが生成されます。このエラーが発生した場合は、更新が完了するまで待ってからもう一度更新してみてください。 - API の編集中に実行されたアクションに問題があるときのエラー このエラーが発生した場合は、編集を行わずに API を追加してみて、編集アクションで問題が発生するかどうかを確認してください。 - デプロイに十分な容量がないときのエラー 統合スキーマを作成するのに十分な容量が環境にない場合、DataGraph によってこのエラーが生成されます。このエラーが発生した場合は、管理者に容量の追加を要求するか、オペレーターに組織内の容量を再配分するよう依頼してください。 ## [](#mtls-エラーのトラブルシューティング)mTLS エラーのトラブルシューティング mTLS エラーが発生した場合は、次の方法でトラブルシューティングします。 - 読み取ることができないファイルをアップロードしたときのエラー このエラーは、​`.pem`​ 形式でない証明書ファイルをアップロードしたことを示しています。ファイルが有効な ​`.pem`​ ファイルであることを確認して、もう一度アップロードしてください。 - 無効なキーストアを検証しようとしているときのエラー 非公開キーまたはパスワードが証明書に一致しない場合、DataGraph によってこのエラーが生成されます。非公開キーと証明書が一致することを確認するか、パスワードを確認してください。 - TLS に問題があるときのエラー このエラーは、統合スキーマに追加した API の mTLS を設定しようとしているときに発生します。この問題をトラブルシューティングするには、mTLS を設定せずに API を追加し、TLS ファイルに問題があるかどうかを判断します。 ## [](#アクセスエラーのトラブルシューティング)アクセスエラーのトラブルシューティング DataGraph にアクセスしようとしているときにエラーが発生した場合は、次の方法でトラブルシューティングします。 - アクセス要求がまだ承認されていないときのエラー このエラーが発生した場合は、管理者にアクセス権を要求してください。 - 未承認のときのエラー このエラーが発生した場合は、管理者に認証を要求してください。 - 要求が多すぎるときのエラー 試みた要求が多すぎると DataGraph によってこのエラーが生成されます。この場合、しばらく待ってからもう一度要求をお試しください。 ## [](#サーバーエラーのトラブルシューティング)サーバーエラーのトラブルシューティング サーバーエラーが発生した場合は、次の方法でトラブルシューティングします。 - ポリシー、コントラクト、層、許可種別を作成するときのサーバーエラー ポリシー、コントラクト、層、または許可種別を作成するときにサーバーエラーが発生した場合は、しばらく待ってからもう一度お試しいただくか、API Manager の状況を確認してください。 - アセットを選択するときのサーバーエラー ポリシーを作成するためにアセットを選択するときにサーバーエラーが発生した場合は、しばらく待ってからもう一度お試しいただくか、Exchange の状況を確認してください。 ## [](#関連情報)関連情報 - [応答ログを使用したクエリのトラブルシューティング](https://docs.mulesoft.com/jp/datagraph/troubleshoot-query-logs) - [クエリトレースを使用したクエリのパフォーマンスのトラブルシューティング](https://docs.mulesoft.com/jp/datagraph/troubleshoot-query-traces) - [競合やマージの不整合の解決](https://docs.mulesoft.com/jp/datagraph/resolve-conflicts) # Anypoint DataGraph のホスティングオプションとネットワーキング Anypoint DataGraph では、次の Anypoint Platform ホスティングオプションとネットワーク設定がサポートされています。 ## [](#anypoint-platform-コントロールプレーンホスティングオプション)Anypoint Platform コントロールプレーンホスティングオプション Anypoint DataGraph は、米国および EU のクラウドコントロールプレーンホスティングで使用できます。 ## [](#anypoint-platform-ランタイムプレーンホスティングオプション)Anypoint Platform ランタイムプレーンホスティングオプション Anypoint DataGraph は、API を統合スキーマに追加するときに指定した宛先 URL に接続する必要があります。次のシナリオのいずれかを満たす場合は、ランタイムプレーンで追加の設定を行う必要はありません。 - API 実装が CloudHub で実行されている。 - API 実装がスタンドアロンインスタンスで実行され、Anypoint Virtual Private Cloud (Anypoint VPC) に接続されている。 - API 実装がランタイムプレーンホスティングオプションで実行され、公開されている。 API インスタンスがスタンドアロンインスタンスで実行され、公開されておらず、Anypoint VPC に接続されていない場合は、最初にスタンドアロンランタイムを Anypoint VPC とペアリングする必要があります。詳細は、​[「ネットワークとの Anypoint VPC 接続の申請」](https://docs.mulesoft.com/cloudhub/to-request-vpc-connectivity)​を参照してください。 ## [](#anypoint-datagraph-アーキテクチャとネットワーキング)Anypoint DataGraph アーキテクチャとネットワーキング Anypoint DataGraph は、ビジネスグループのデフォルトリージョン内の Anypoint Platform で実行される完全に管理されたサービスです。次の図は、DataGraph の一般的なネットワークアーキテクチャを示しています。 ![Anypoint DataGraph および Anypoint Platform の一般的なネットワークアーキテクチャ](/mulesoft/current/ja-jp/datagraph/_images/datagraph-network-architecture.png) 公開インターネットからのコンシューマーの要求は、CloudHub または Anypoint Virtual Private Cloud (Anypoint VPC) の設定に応じて、共有または専用のロードバランサーを介して Anypoint DataGraph に転送されます。DataGraph は、統合スキーマを構成する基盤となる API に要求を送信します。同様に、Anypoint DataGraph UI で変更を行うと、それらの変更により、ランタイムプレーンの Anypoint DataGraph の更新がトリガーされます。 ロードバランサーのポート 8082 を使用できない場合は、​[CloudHub 専用ロードバランサー (DLB) を使用するための新しい URL を Anypoint DataGraph に設定](https://docs.mulesoft.com/jp/datagraph/set-dlb)​する必要があります。 ## [](#関連リソース)関連リソース - [Anypoint Platform ホスティングオプション](https://docs.mulesoft.com/hosting-home/) # Anypoint DataGraph の使用量メトリクスの表示 Anypoint Datagraph では API 要求メトリクスが提供され、Anypoint Monitoring では DataGraph の追加の使用量メトリクスを表示できます。 ## [](#api-要求メトリクスを表示する)API 要求メトリクスを表示する DataGraph ではメトリクスを追跡できるため、ビジネスグループに指定された制限に関連する使用量を常に把握できます。これらのメトリクスを使用して、各環境の統合スキーマに対して行われたコールの総数を追跡します。 使用量メトリクスは、ビジネスグループごとに本番環境と Sandbox 環境によって分けられます。より具体的には、特定の環境のメトリクスには次の情報が表示されます。 - その環境で受信した GraphQL API 要求 - その種別の他の環境で受信した GraphQL API 要求 - その種別のすべての環境で受信した GraphQL API 要求 API 要求の使用量メトリクスは、Anypoint DataGraph の \[Overview (概要)\] セクションに表示されます。 使用量メトリクスを表示するには、​[「Admin (管理)」権限](https://docs.mulesoft.com/jp/datagraph/permissions)​が必要です。 1. \[Overview (概要)\] をクリックします。 2. \[Details (詳細)\] をクリックして、正しい環境にいることを確認します。 3. \[Usage Metrics (使用量メトリクス)\] をクリックします。 ![\[Overview (概要)\] セクションに表示されている DataGraph の使用量メトリクス](_images/datagraph-usage-metrics.png) 4. 特定の期間のメトリクスを表示するには、カレンダーパラメーターを設定します。メトリクスクエリは自動的に実行され、データが更新されます。 5. 現在の期間のメトリクスを更新するには、更新アイコンをクリックします。 ## [](#anypoint-monitoring-を使用した使用量メトリクスの表示)Anypoint Monitoring を使用した使用量メトリクスの表示 Anypoint Monitoring では、組み込みダッシュボードやカスタムダッシュボードを介して使用量メトリクスを表示できます。これらのメトリクスは、統合スキーマで統合された API に対して行われたコールではなく、DataGraph アプリケーションに対して行われたコールを参照します。 ### [](#組み込みダッシュボード)組み込みダッシュボード Anypoint Monitoring では、DataGraph は「管理 API」とみなされます。​[組み込みダッシュボードを表示](https://docs.mulesoft.com/jp/monitoring/app-dashboards#view-a-built-in-dashboard)​するときに、環境と DataGraph アプリケーションの名前を選択します。 組み込みダッシュボードでは、設定は必要なく、さまざまなページにさまざまな種類のチャートが表示されます。たとえば、概要ページには以下に関連するデータが表示されます。 - Request volume (要求量) - Failed requests (失敗した要求) - Total 4xx errors (4xx エラー合計) - Total 5xx errors (5xx エラー合計) - Average response time (平均応答時間) ### [](#カスタムダッシュボード)カスタムダッシュボード カスタムダッシュボードでは、組み込みダッシュボードと同じメトリクスが収集されます。カスタムダッシュボードでは、追加の設定が必要で、次の場合に役立ちます。 - 多様なメトリクスを相関付ける - 比較分析を実行する - 通常のトレンドと異常を区別する - 問題をすばやく切り分ける 次の例は、client\_id ごとの要求量を追跡するためのカスタムダッシュボードのセットアップ方法を示しています。 1. Anypoint Monitoring から ​**\[Custom dashboards (カスタムダッシュボード)\]**​ を選択します。 2. **\[New Dashboard ( 新規ダッシュボード)\]**​ をクリックし、グラフオプションを選択します。 3. 新しいグラフで、設定メニュー (縦の省略記号) をクリックし、​**\[Configure (設定)\]**​ をクリックします。 4. **\[Advanced Mode (高度なモード)\]**​ を切り替えて高度なモードをアクティブ化します。 5. クエリを次のように編集します。 1. **\[Panel Type (パネル種別)\]**​ ドロップダウンリストで、​**\[API Panel (API パネル)\]**​ を選択します。(Datagraph は API アプリケーション種別)。 2. **\[Where (場所)\]**​ の横にある ​**\[+\]**​ をクリックします。 3. ドロップダウンリストから、​`[api_id]`​ と ​`[api_version_id]`​ を選択し、情報の収集元の Datagraph アプリケーションにそれぞれの値を設定します。 4. **\[Select (選択)\]**​ ドロップダウンリストから ​`[field(request_size.count)]`​ を選択します。 5. **\[Group by (グループ化基準)\]**​ ドロップダウンリストから ​`[tag(client_id)]`​ を選択します。 6. **\[Alias by (別名基準)\]**​ 項目で、​`[$tag_client_id]`​ を追加します。 6. **\[Apply changes (変更を適用)\]**​ をクリックします。 7. 時間ピッカーを開き、期間を選択し、​**\[Confirm (確認)\]**​ をクリックします。 次の例では、前の時間のクエリを追跡するグラフが表示されています。 ![client\_id ごとの要求量が表示されている Monitoring のカスタムグラフ](/mulesoft/current/ja-jp/datagraph/_images/datagraph-custom-graph.png) ## [](#関連リソース)関連リソース - [https://docs.mulesoft.com/monitoring/dashboard-custom-config](https://docs.mulesoft.com/monitoring/dashboard-custom-config) - [https://docs.mulesoft.com/monitoring/create-custom-dashboard](https://docs.mulesoft.com/monitoring/create-custom-dashboard) - [https://docs.mulesoft.com/monitoring/app-dashboards](https://docs.mulesoft.com/monitoring/app-dashboards) # Anypoint Datagraph の専用ロードバランサーの URL の設定 CloudHub 共有ロードバランサーのポート 8082 を使用できない場合は、専用ロードバランサー (DLB) を使用するための URL を Anypoint DataGraph に設定する必要があります。 URL を設定するには、Anypoint DataGraph 設定に DLB のマッピングルールを追加します。 ## [](#dlb-url-のマッピングルールの例)DLB URL のマッピングルールの例 DLB のマッピングルールをどのように機能させるかに基づいて、​**入力パス**​ (入力 URI) と​**出力パス**​ (アプリケーション URI) を設定し、最終的な DLB URL が Anypoint DataGraph アプリケーションのエンドポイント (​`/graphql`​) にアクセスできるようにする必要があります。 たとえば、​**入力パス**​の値と Datagraph アプリケーション名 (​`datagraph-xz082edx-1585-901xe374-d0x0`​) に基づく ​`examplelb.lb.anypointdns.net`​ のマッピングルールについて検討します。
インデックス 入力 URI (入力パス) アプリケーション名 アプリケーション URI (出力パス) プロトコル

0

/graphql

datagraph-xz082edx-1585-901xe374-d0x0

/graphql

HTTPS

1

/datagraph/

datagraph-xz082edx-1585-901xe374-d0x0

/graphql

HTTPS

2

/datagraph/

datagraph-xz082edx-1585-901xe374-d0x0

/

HTTPS

3

/{app}/

{app}

/

HTTPS

各インデックスの適切な DLB URL は次のとおりです。 - インデックス 0: `examplelb.lb.anypointdns.net/graphql` - インデックス 1: `examplelb.lb.anypointdns.net/datagraph/` - インデックス 2: `examplelb.lb.anypointdns.net/datagraph/graphql` - インデックス 3: `examplelb.lb.anypointdns.net/datagraph-xz082edx-1585-901xe374-d0x0/graphql` ## [](#前提条件)前提条件 - DLB URL を指定する環境の​[「管理者」または「オペレーター」権限](https://docs.mulesoft.com/jp/datagraph/permissions)​が必要です。 - Anypoint CLI のコマンドを​[認証](https://docs.mulesoft.com/jp/anypoint-cli/latest/#authentication)​して実行できる必要があります。 - [DLB マッピングルールの作成](https://docs.mulesoft.com/cloudhub/lb-mapping-rules)​に精通している必要があります。 - [DLB を作成して設定](https://docs.mulesoft.com/cloudhub/cloudhub-dedicated-load-balancer#create-and-configure-a-dedicated-load-balancer)​する必要があります。 このタスクを実行する手順は、次のとおりです。 1. Anypoint CLI を使用して、DLB と Anypoint DataGraph に関する詳細を収集します。 2. Anypoint Runtime Manager を使用して DLB のマッピングルールを作成します。 3. Anypoint CLI を使用して DLB 設定を Anypoint DataGraph に追加します。 ## [](#dlb-と-anypoint-datagraph-に関する詳細を収集する)DLB と Anypoint DataGraph に関する詳細を収集する DLB の名前と Anypoint DataGraph のアプリケーション名を収集します。 1. Anypoint Platform のユーザー名とパスワードを使用して、Anypoint CLI に接続します。 2. 環境をまだ設定していない場合は、次のコマンドを使用して設定します。 - Anypoint CLI v3.x の使用: `use environment ` - Anypoint CLI v4.x の使用: `conf environment ` 3. DLB の名前を取得します。 - Anypoint CLI v3.x の使用: `cloudhub load-balancer describe ` - Anypoint CLI v4.x の使用: `cloudhub:load-balancer:describe ` 出力は次のようになります。 `Name | examplelb` 4. Anypoint DataGraph アプリケーション名の CloudHub ドメインを取得します。 - Anypoint CLI v3.x の使用: `datagraph load-balancer-config describe` - Anypoint CLI v4.x の使用: `datagraph:load-balancer-config:describe` 値は次のようになります。 `Domain | datagraph-xz082edx-1585-901xe374-d0x0` DataGraph アプリケーション名には、各自の組織 ID と環境 ID の要素が含まれます。 5. 手順 3 ~ 4 の値を書き留めます。 ## [](#dlb-のマッピングルールを作成する)DLB のマッピングルールを作成する Runtime Manager でマッピングルールをセットアップします。 1. Anypoint Platform の ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューから、​**\[Load Balancers (ロードバランサー)\]**​ を選択します。 3. ロードバランサー名をクリックして、証明書名をクリックします。 ロードバランサーに有効な CA 署名証明書があることを確認します。ない場合は、ブラウザーが Anypoint DataGraph に接続されません。 4. **\[URL Mapping Rules (URL マッピングルール)\]**​ セクションで ​**\[Add New Rule (新規ルールを追加)\]**​ をクリックします。 5. 項目に次の値を入力します。 - **Input Path (入力パス)**​ (​`inputUri`​): クライアントが要求する URI (例: `/{app}/`​) - **Target App (対象アプリケーション)**​ (​`appName`​): ステップ 4 の詳細の収集タスクで確認した Anypoint DataGraph アプリケーションのドメインです。 - **Output Path (出力パス)**​ (​`appURI`​): Anypoint DataGraph に渡す URI 文字列 (例: `/`​、​`/graphql`​) - **Protocol (プロトコル)**​ (​`upstreamProtocol`​): https Anypoint DataGraph では HTTPS のみをサポートしています。 ## [](#dlb-設定を-anypoint-datagraph-に追加する)DLB 設定を Anypoint DataGraph に追加する マッピングルールを追加したら、Anypoint Datagraph で使用する DLB を設定します。 1. Anypoint DataGraph の DLB URL を確認します。 - Anypoint CLI v3.x の使用: ```copy datagraph load-balancer-config describe ``` - Anypoint CLI v4.x の使用: ```copy datagraph:load-balancer-config:describe ``` デフォルトで、この Anypoint DataGraph 環境に DLB を設定したことがない場合は、​`dlbUrl`​ の値が返されません。 2. 新しい DLB URL を追加します。 - Anypoint CLI v3.x の使用: ```copy datagraph load-balancer-config add ``` - Anypoint CLI v4.x の使用: ```copy datagraph:load-balancer-config:add ``` ``​ を、DLB 名と DataGraph アプリケーション名 (手順 3 ~ 4 の詳細の収集タスクで確認) とマッピングルールの​**入力パス**​を含む有効な URL に置換します。次に例を示します。 - Anypoint CLI v3.x の使用: ```copy datagraph load-balancer-config add examplelb.lb.anypointdns.net/datagraph/graphql ``` - Anypoint CLI v4.x の使用: ```copy datagraph:load-balancer-config:add examplelb.lb.anypointdns.net/datagraph/graphql ``` 必要に応じて、​[「DLB URL のマッピングルールの例」](#example-mapping-rules-for-a-dlb-url)​を参照してください。 3. 更新された値を検証します。 - Anypoint CLI v3.x の使用: ```copy datagraph load-balancer-config describe ``` - Anypoint CLI v4.x の使用: ```copy datagraph:load-balancer-config:describe ``` CLI で、Anypoint DataGraph ロードバランサーのアプリケーション名と DLB の完全ドメイン名を含む詳細が返されます。 この変更を追加すると、Anypoint DataGraph が再デプロイされるため、Anypoint DataGraph が最新の状態であることが状況インジケーターに示されるまで待機します。 ## [](#anypoint-datagraph-から-dlb-設定を削除する)Anypoint DataGraph から DLB 設定を削除する 次のコマンドを使用して、Anypoint DataGraph から DLB 設定を削除できます。 - Anypoint CLI v3.x の使用: ```copy datagraph load-balancer-config remove ``` - Anypoint CLI v4.x の使用: ```copy datagraph:load-balancer-config:remove ``` 設定を削除すると、Anypoint DataGraph が再デプロイされます。 ## [](#関連リソース)関連リソース - [Anypoint DataGraph のホスティングオプションとネットワーキング](https://docs.mulesoft.com/jp/datagraph/hosting-options) - [統合スキーマへの API スキーマの追加](https://docs.mulesoft.com/jp/datagraph/add-api-to-unified-schema) - [DataGraph CLI](https://docs.mulesoft.com/jp/datagraph/datagraph-cli) # Anypoint DataGraph の概要 Anypoint DataGraph では、アプリケーションネットワーク内のすべてのデータを統合スキーマに統合できます。Anypoint DataGraph を使用して、次の操作を実行できます。 - 統合スキーマのデータを動的に照会する - 1 つの UI でアプリケーションネットワークをナビゲートする - 新しいコードを記述せずに、アプリケーションネットワークの情報を検出、再利用、活用する ![](https://play.vidyard.com/jh14R8RyB59WPa3QHguJ26.jpg) ## [](#anypoint-datagraph-のしくみ)Anypoint DataGraph のしくみ 新しい API をアプリケーションネットワークに追加するたびに、Anypoint Platform がその API をメタデータのグラフとして保存します。Anypoint DataGraph を使用すると、こうしたグラフを 1 つの​_統合スキーマ_​に接続できます。このスキーマは 1 つの SaaS GraphQL エンドポイントとして実行され、すべての API 内で定義されたすべての項目が含まれ、リンクされています。したがって、基盤となる API 全体にクエリを実行できるため、API 内に存在するリレーションや特定の機能をすべて理解している必要がありません。 ### [](#統合スキーマ)統合スキーマ 統合スキーマは、ユーザーが Anypoint DataGraph に多様な API スキーマを追加してコンシューマーがその項目を照会できるようにした、種別の一元的なコレクションで、最新の状態で維持されます。統合スキーマのクエリタイプには、ユーザーが DataGraph に追加した多様な API スキーマにあるすべてのクエリメソッドが含まれます。コンシューマーが統合スキーマにアクセスすれば、各人がどのデータを参照可能かを 1 か所で確認し、1 回のクエリでそのデータの特定のサブセットを要求できます。 つながりのある、整然とした統合スキーマを作成できるように、Anypoint DataGraph に搭載されている 3 つの機能で次の操作を実行できます。 1. オブジェクト種別間のコラボレーションを有効にする 2. オブジェクト種別をリンクして、種別をつなぎ合わせる 3. オブジェクト種別をマージして、類似の種別を 1 つの種別に結合して項目やデータセットを拡張し、クエリ結果を向上させる ### [](#ユースケースの例)ユースケースの例 組織で次の API を使用しているとします。 - 特定の発注書に関する情報を示す Order API - 各発注書の出荷情報を示す Shipment API - 商品情報と仕様を示す Product API この組織では、顧客の特定の注文状況の詳細を表示するモバイルアプリケーションを作成したいと考えています。 このモバイルアプリケーションを配布するためには、API 開発者が、顧客のすべての注文を識別し、その注文の商品を検索して、それぞれの出荷レコードを識別し、配送日と追跡番号を検索する新しい API を構築する必要があります。エンタープライズアーキテクトは、まず必要な各 API へのアクセス権を開発者に付与し、開発者が構築して納品した後にこの API を管理してセキュリティ保護する必要があります。 この組織はその後、倉庫の在庫管理担当者のために、各商品の既存の全注文を管理する Web アプリケーションを構築したいと考えます。また、Web アプリケーションでは、在庫管理担当者が注文を返品または削除できるようにする必要もあります。これらの機能を提供するために、チームは同じような開発プロセスを行うことになります。 組織が Anypoint DataGraph を使用すれば、新しいビジネス要件ごとに新しい API を作成する必要がなくなります。エンタープライズアーキテクトが既存の Order API、Shipment API、Product API を見つけ、それぞれの API スキーマを Anypoint DataGraph に追加できるためです。続いて、開発者が統合スキーマへのアクセス権を要求し、必要なデータにクエリを実行したり、単一エンドポイントから更新したりできます。 ## [](#anypoint-datagraph-api-のサポート)Anypoint DataGraph API のサポート Anypoint DataGraph でサポートの対象となるのは次のとおりです。 - RAML 仕様および OAS 仕様を使用する REST API - 統合スキーマごとに最大 250 の API - 統合スキーマごとに最大 16,000 の項目 - 100 ネストレベルのクエリ深度 - クエリあたり 30 秒のタイムアウト ## [](#api-manager-での-anypoint-datagraph-の管理)API Manager での Anypoint DataGraph の管理 API Manager で Anypoint DataGraph を管理します。一般的な管理タスクは次のとおりです。 - [DataGraph 管理設定](https://docs.mulesoft.com/jp/api-manager/latest/datagraph-settings)​を使用して、統合スキーマの GraphQL エンドポイントの表示と編集、ポリシーの設定、クライアントプロバイダーの設定を行う。 - [コントラクト](https://docs.mulesoft.com/jp/api-manager/latest/datagraph-managing-contracts)​を管理して、認証されたクライアントアプリケーションのみが統合スキーマをコンシュームできるようにする。 - 各 Anypoint DataGraph インスタンスの ​[SLA 層](https://docs.mulesoft.com/jp/api-manager/latest/datagraph-adding-sla-tiers)​を管理する。 - [API Manager の \[Client Applications (クライアントアプリケーション)](https://docs.mulesoft.com/jp/api-manager/latest/datagraph-viewing-application-contracts)\]​ ページを使用して、クライアントアプリケーションコントラクトを表示して管理する。 ## [](#anypoint-platform-の要件とライセンス)Anypoint Platform の要件とライセンス Anypoint DataGraph を使用するには、以下の要件を満たしていることを確認します。 - 次のそれぞれのライセンスが必要です。 - Anypoint Platform - API Manager and Analytics - Anypoint DataGraph

Anypoint DataGraph ライセンスに関連付けられている API コールは、Anypoint DataGraph からダウンストリームの REST API へのコールを参照します。

- 各自のプランで、Anypoint DataGraph を使用するビジネスグループまたは組織に適切な数の vCore を割り当てる必要があります。API を追加しようとしている環境に適切な数の vCore が割り当てられていない場合、Anypoint DataGraph からエラーメッセージが表示されます。適切な数の vCore を割り当てた後で同じ変更を再適用します。 API のホスティング要件についての詳細は、​[「Anypoint Platform Runtime Plane Hosting Options (Anypoint Platform ランタイムプレーンをホストするためのオプション)」](https://docs.mulesoft.com/jp/datagraph/hosting-options#anypoint-platform-runtime-plane-hosting-options)​を参照してください。 ## [](#使用を開始するためのリソース)使用を開始するためのリソース - [Anypoint DataGraph クイックスタートガイド](https://docs.mulesoft.com/jp/datagraph/datagraph-qsg) - [Anypoint DataGraph の用語](https://docs.mulesoft.com/jp/datagraph/datagraph-terms) - [API スキーマの要素の理解](https://docs.mulesoft.com/jp/datagraph/schemas) - [DataGraph での GraphQL クエリおよび変異の作成](https://docs.mulesoft.com/jp/datagraph/write-queries-tutorial) # Anypoint DataGraph の権限の使用 Anypoint DataGraph ではアクセス管理権限が提供されるため、組織のセキュリティ要件を満たし、同時にチーム間のコラボレーションを促進できます。 Anypoint DataGraph の権限は、他の Anypoint Platform 製品の権限とは無関係です。 統合スキーマに参加するには、API を追加するビジネスグループに対する​**「Exchange Viewers (Exchange 閲覧者)」**​権限が必要です。詳細は、​[「ユーザーアクセス権限の設定」](https://docs.mulesoft.com/jp/exchange/to-set-permissions)​を参照してください。 次の権限は、環境ごとにビジネスグループ単位で使用できます。
権限 説明

Admin (管理)

権限の対象:

  • 統合スキーマへの参加、コンシューム、操作

  • 使用量メトリクスの表示

Contribute (参加)

権限の対象:

  • 統合スキーマへのソース API の追加

  • 統合スキーマに追加されたソース API スキーマの編集

  • クエリを実行するためのアクセス権の要求

  • 環境への API スキーマの昇格

  • UI からクエリを実行中にクエリトレースをリアルタイムで表示する

  • クエリエディターから統合スキーマのコピーをダウンロードする

Consume (コンシューム)

権限の対象:

  • 統合スキーマを表示および探索する

  • クエリを実行し、UI からデータ要求を行うためのアクセス権を要求する

  • クエリエディターから統合スキーマのコピーをダウンロードする

Operate (操作)

権限の対象:

  • 顧客向けのログを表示する

  • Anypoint Datagraph の専用ロードバランサーの URL を設定する

## [](#関連リソース)関連リソース - Anypoint DataGraph SLA 層の設定とコントラクトの管理についての詳細は、API Manager ドキュメントの​[「Anypoint DataGraph 管理」](https://docs.mulesoft.com/jp/api-manager/latest/datagraph-landing-page)​を参照してください。 - Anypoint DataGraph のユーザー権限とロールを設定する手順については、​[「ユーザーへの権限とロールの付与」](https://docs.mulesoft.com/jp/access-management/users#granting-permissions-and-roles-to-users)​を参照してください。 # Anypoint DataGraph の用語 次の用語は、一部は GraphQL 辞書からのものであり、Anypoint DataGraph のしくみを理解するのに役立ちます。
用語 使用方法

API スキーマ

RAML または OAS の API 仕様から Anypoint DataGraph によって生成された API スキーマには、API 仕様で定義した GET リソースとエンティティのコレクション、およびそれらのリレーションが含まれています。

統合スキーマ

統合スキーマは、ユーザーが Anypoint DataGraph に多様な API スキーマを追加して消費者がその項目を照会できるようにした、種別の一元的なコレクションで、最新の状態で維持されます。

オブジェクト種別

スキーマで最も一般的な種別であるオブジェクト種別は、GET 応答の一部として返される API 仕様のエンティティを表します。

列挙種別

列挙種別は、API 仕様で定義した特定の値のセットのみを返します。

結合種別

結合種別は、他のオブジェクト種別を使用してデータのインスタンスを説明します。結合種別は 1 つ以上の特定のオブジェクト種別で構成されます。

クエリ種別

クエリ種別は、要求を行うときの API スキーマへのエントリポイントです。この種別には、API 仕様で定義したクエリメソッドが含まれます。

クエリメソッド

API 仕様で定義された各一意の GET エンドポイントは、クエリを開始するために使用するクエリメソッドによって表されます。

項目

項目は、API 仕様でオブジェクト種別に対して定義するプロパティです。

レベル-1 種別

API スキーマでは、レベル-1 種別はクエリメソッドによって直接返すことができるオブジェクト種別です。

ネストされた種別

API スキーマでは、レベル-1 種別のクエリメソッドを介してのみネストされた種別にアクセスできます。ネストされた種別は、クエリメソッドによって直接返されません。

コラボレーション

レベル-1 オブジェクト種別でのコラボレーションを有効にすることで、他の種別とその種別をリンクおよびマージできるようにします。コラボレーションにより、つながりの増した統合スキーマを作成できるため、コンシューマーのクエリエクスペリエンスがより効率的になります。

コラボレーションは、レベル-1 オブジェクト種別でのみ可能です。

リンク

リンクにより、異なるオブジェクトを説明する 2 つの関連する種別の項目を結合し、それらをつなぎ合わせることができます。

マージ

種別のマージにより、類似の種別を 1 つの種別に結合して項目やデータセットを拡張し、クエリ結果を向上させることができます。

## [](#関連リソース)関連リソース - [API スキーマの要素の理解](https://docs.mulesoft.com/jp/datagraph/schemas) - [クエリおよび変異の実行](https://docs.mulesoft.com/jp/datagraph/query-unified-schema) # Anypoint DataGraph ベストプラクティスルールセット DataGraph ベストプラクティスルールセットは、Anypoint DataGraph で使用する API プロジェクトに連動関係として追加できるガバナンスルールのコレクションです。このルールセットは、API プロジェクトが DataGraph のベストプラクティスに従うためのメッセージのコレクションです。このルールセットは Exchange で公開されており、Design Center API Designer で API 仕様に連動関係として追加します。API Governance CLI を使用してルールセットに対して API を検証することもできます。 ## [](#使用例)使用例 次の ​`example-api.raml`​ を考えてみます。 #%RAML 1.0 title: DOCS - Order API types: Order: description: An Order properties: orderId: description: The ID of the order type: string additionalProperties: false /orders/{orderId}: get: responses: 200: body: application/xml: type: Order DataGraph ベストプラクティスルールセットを適用すると、次の警告メッセージが表示されます。 example-api.raml (16:3) ⚠️Warning: \[Datagraph Best Practices\] Only JSON payloads are supported at the moment in DataGraph. This is the preferred media type format. このメッセージは、GET コマンドの ​`application/xml`​ が ​`application/json`​ である必要があることを示しています。 API Designer でのルールセットの追加と使用についての詳細は、​[「API 定義内の API 準拠の問題を検出」](https://docs.mulesoft.com/api-governance/find-conformance-issues)​を参照してください。 # Anypoint DataGraph 入門 次のドキュメントを使用して、Anypoint DataGraph の主要な概念について学び、使用を開始してください。 - [Anypoint DataGraph クイックスタートガイド](https://docs.mulesoft.com/jp/datagraph/datagraph-qsg) このクイックスタートガイドを参考に、Anypoint DataGraph の使用を開始します。 - [Anypoint DataGraph の用語](https://docs.mulesoft.com/jp/datagraph/datagraph-terms) Anypoint DataGraph のしくみを理解するのに役立つ重要な用語を学びます。 - [API スキーマの要素の理解](https://docs.mulesoft.com/jp/datagraph/schemas) API 仕様に応じて、API スキーマに存在する可能性があるさまざまな種別を理解します。 - [DataGraph での GraphQL クエリおよび変異の作成](https://docs.mulesoft.com/jp/datagraph/write-queries-tutorial) この簡単なチュートリアルでは、Anypoint DataGraph で GraphQL クエリを作成するための重要な概念を紹介します。 # Anypoint Platform DataGraph CLI および API 拡張機能の使用 Anypoint CLI DataGraph コマンドを使用して、DataGraph で API ソースを追加および編集できます。そのためには、最初の適切な DataGraph API 拡張機能を API ソースに追加する必要があります。 ## [](#プロジェクトへの拡張機能の追加)プロジェクトへの拡張機能の追加 拡張機能を連動関係として API 仕様プロジェクトに追加し、続いてプロジェクトを Exchange にパブリッシュする必要があります。API 仕様プロジェクトをパブリッシュした後で、CLI を使用して API を DataGraph に追加できます。 API Designer を使用して拡張機能をプロジェクトに追加します。​[「API 仕様プロジェクトに連動関係を追加する」](https://docs.mulesoft.com/design-center/design-add-api-dependency#add-dependencies-to-an-api-specification-project)​の手順に従い、連動関係種別として ​**\[Fragments (フラグメント)\]**​ を選択します。 API Designer により、必須の連動関係が ​`exchange.json`​ に追加され、プロジェクトを Exchange にパブリッシュする前に追加したアノテーションの構文が検証されます。 ## [](#raml-の互換性の維持)RAML の互換性の維持 RAML 仕様で API 拡張機能がサポートされないツールとの互換性を維持するために、これらの拡張機能には RAML アノテーション定義のシンプルなバージョンが提供される「RAML companion」が含まれています。RAML で DataGraph API 拡張機能を使用するには、次のコードを API プロジェクト仕様のメインファイルに追加します。 uses: dg: exchange\_modules////datagraph-api-extensions.raml プレフィックス ​`dg`​ は必要に応じて変更できますが、拡張機能で使用されているプレフィックスに一致している必要があります。 ``​、​``​、​``​ は Exchange でパブリッシュされている API 拡張機能を参照します。 ## [](#datagraph-cli-と-datagraph-ui-の使用の比較)DataGraph CLI と DataGraph UI の使用の比較 CLI を使用して API ソースを追加する場合は、UI で直接編集したりそのバージョンを更新したりすることはできません。これらの変更は CLI を使用して行う必要があります。 ## [](#関連情報)関連情報 - [Anypoint DataGraph API 拡張機能リファレンス](https://docs.mulesoft.com/jp/datagraph/api-extensions) - [Anypoint DataGraph CLI リファレンス](https://docs.mulesoft.com/jp/datagraph/datagraph-cli) # API スキーマの昇格 API スキーマを開発して設定するときに、本番に向けた次の環境に API スキーマを昇格して、その環境の統合スキーマに追加することができます。この場合、スキーマ設定のみが昇格され、基盤となる実際のソース REST API は昇格されません。 昇格により、ある環境で API スキーマを設定した後、後続の環境で同じ設定を繰り返す必要がなくなります。昇格を使用して、スキーマ設定を開発からステージング、ステージングから本番に移動します。 本番までのサイクルで API を昇格するために実行する手順は、各自のニーズによって異なります。たとえば、開発環境で開発して設定した Orders API をステージングに昇格するとします。この場合、次のような昇格シナリオが考えられます。
開発の Orders API のバージョン ステージングの Orders API のバージョン 昇格アクション 昇格後のバージョン

v3.1.0

なし

Anypoint DataGraph で API スキーマとその設定が昇格される。

ユーザーが URL と認証方法を設定する。

v3.1.0

v3.1.1

v3.1.0

Anypoint DataGraph で既存の API スキーマのアセットバージョンが自動的に更新される。

ユーザーが URL と認証方法を設定する。

v3.1.1

v3.1.0

v3.1.0

Anypoint DataGraph でアセットバージョンのカスタマイズが更新される。

v3.1.0

v4.0.0

v3.1.0

Anypoint DataGraph で両方の API バージョンが対象環境に追加されて共存する。

ユーザーが v4.0.0 の URL と認証方法を設定する。

v3.1.0、v4.0.0

## [](#api-を別の環境に昇格する)API を別の環境に昇格する アクセス権のある任意の環境に API スキーマを昇格できます。 API は Exchange でパブリッシュする必要がありますが、API が Mule アプリケーションでなくても、あるいは Mule Runtime Engine や CloudHub で実行されていなくても、統合スキーマに追加できます。 昇格するスキーマが、対象環境の統合スキーマと競合しないようにします。競合が存在する場合は、API を手動で追加して、API を追加する場合と同じ方法で競合を解決する必要があります。 [「寄稿」または「管理」権限が](https://docs.mulesoft.com/jp/datagraph/permissions)​必要です。

Anypoint DataGraph から API にアクセスするためにサポートされている認証方法は次の手順に記載されています。それ以外の認証方法 (有効期間の短いトークン方式など) はサポートされていません。詳細は、​「サポートされる認証方法」​を参照してください。

API を昇格する手順は、次のとおりです。 1. **\[List of API added (追加された API のリスト)\]**​ をクリックし、昇格する API を選択します。 2. **\[Promote API schema (API スキーマを昇格)\]**​ をクリックします。 3. **\[Target environment (対象環境)\]**​ リストから、昇格の対象環境を選択します。 4. **\[Next: Configure URL (次へ: URL を設定)\]**​ をクリックします。 5. 昇格シナリオに応じて、次の設定オプションのいずれかを選択できます。 - API が API Manager で管理されているか、Exchange の API のインスタンスを追加した場合は、​**\[Get an existing URL from Anypoint Platform (Anypoint Platform から既存の URL を取得)\]**​ を選択します。 - 独自の実装 URL を指定する場合は、​**\[Add a new URL (新しい URL を追加)\]**​ を選択するか、​**\[Use the URL in API specification (API 仕様の URL を使用)\]**​ をクリックします。 6. **\[Next: Provide Authentication (次へ: 認証を指定)\]**​ をクリックします。 7. **\[Provide authentication (認証の指定)\]**​ ページで、API の GET エンドポイントに追加する認証の種類を選択し、照会時に Anypoint DataGraph が API に要求を実行できるようにします。 - **No Auth (認証なし)**​: API が公開の場合に使用します。 - **Basic Auth (基本認証)**​: ユーザー名とパスワードを使用して API に対する認証を行う場合に使用します。 - **Pass-through (パススルー)**​: 認証ヘッダーを渡して API に対する認証を行う場合に使用します。 - **Client ID enforcement via headers (ヘッダー経由のクライアント ID 適用)**​: `client_id`​ および ​`client_secret`​ ヘッダーを渡して API に対する認証を行う場合に使用します。 - **Client ID enforcement via query parameters (クエリパラメーター経由のクライアント ID 適用)**​: `client_id`​ および ​`client_secret`​ クエリパラメーターを渡して API に対する認証を行う場合に使用します。 - **OAuth 2.0 Client Credentials (OAuth 2.0 クライアントログイン情報)**​: OAuth 2.0 の ​`client_id`​、​`client_secret`​、認証サーバーの値を渡して API に対する認証を行う場合に使用します。 - **Custom (カスタム)**​: カスタムヘッダーパラメーターと値を使用して API に対する認証を行う場合に使用します。 8. 必要に応じて、キーストアを追加し、API と DataGraph 間の相互認証 (mTLS) を設定します。

対象環境に既存の API を昇格する場合は、対象環境の API に既存のキーストアまたはトラストストアがあるかどうかがチェックされます。対象環境にキーストアまたはトラストストアが存在する場合は、既存のものを維持する、既存のものを削除する、既存のものを削除して新しいものを追加するのいずれかを選択できます。ソース環境のキーストアやトラストストアを対象環境に自動的に送信することはできません。ソース環境のキーストアやトラストストアを対象環境で使用するには、昇格プロセス中に削除して追加し直す必要があります。

**\[Configure Keystore (キーストアを設定)\]**​ を選択して次の情報を指定します。 - 組織の「ルート」認証機関 (CA) によって署名された公開証明書 - 証明書署名要求 (CSR) の生成に使用される非公開キー - 非公開キーのパスワード 9. 必要に応じて、トラストストアを追加して統合スキーマから API へのアクセスを許可します。 **\[Configure Truststore (トラストストアを設定)\]**​ を選択して、ルート CA が含まれる証明書バンドルを指定します。 10. **\[Next: Add to unified schema (次へ: 統合スキーマに追加)\]**​ をクリックします。 ## [](#更新された-api-を昇格する)更新された API を昇格する API バージョンを更新したら、更新されたバージョンを別の環境に昇格できます。 昇格する API の新しいバージョンを選択すると、対象環境で新しいバージョンに自動的に適用できない現在のバージョンへの編集が DataGraph にリストされます。 DataGraph で自動的に適用できない編集には、プロモーションを完了する前にそれらの編集を手動で適用するオプションがあります。 更新された API スキーマを昇格する前に、​[API バージョンを更新](https://docs.mulesoft.com/jp/datagraph/add-api-to-unified-schema#update-an-api-version)​する必要があります。 1. **\[List of APIs added (追加された API のリスト)\]**​ をクリックし、該当する API を選択します。 2. **\[API details (API の詳細)\]**​ をクリックします。 3. **\[Promote API schema (API スキーマを昇格)\]**​ をクリックします。 4. **\[Target environment (対象環境)\]**​ リストから、昇格の対象環境を選択します。 5. **\[Next (次へ)\]**​ をクリックします。 6. DataGraph で適用できない変更が検出された場合、​**\[Changes Not Applied (適用されない変更)\]**​ のリストを確認し、手動で適用します。 1. 変更を選択し、​**\[Next (次へ)\]**​ をクリックします。 2. 必要に応じて API スキーマを編集し、​**\[Apply Changes and Promote (変更を適用して昇格)\]**​ をクリックします。 変更を適用したら、追加の変更に対してステップ 5 を繰り返します。 7. **\[Next (次へ)\]**​ をクリックして、残りの昇格手順を完了します。 ## [](#関連リソース)関連リソース - [Anypoint DataGraph の権限](https://docs.mulesoft.com/jp/datagraph/permissions) - [競合やマージの不整合の解決](https://docs.mulesoft.com/jp/datagraph/resolve-conflicts) - [troubleshoot-schemas-queries.adoc#potential-errors-when-generating-an-api-schema](https://docs.mulesoft.com/jp/datagraph/troubleshoot-schemas-queries#potential-errors-when-generating-an-api-schema) # API スキーマの編集 新しい API を統合スキーマに追加するときは、スキーマを編集して、現在のスキーマの種別に、統合スキーマに既存の種別と競合するものがないようにする必要があります。統合スキーマのどの種別も一意でなければなりません。 API スキーマを統合スキーマに追加する前に、編集機能を実行する必要はありません。統合スキーマに追加した後でも API スキーマを変更できます。ただし、Anypoint DataGraph で競合エラーが発生した場合は、統合スキーマに追加する​_前_​にスキーマを編集して、競合を解決する必要があります。

CLI を使用して API ソースを追加する場合は、UI で直接編集したりそのバージョンを更新したりすることはできません。これらの変更は CLI を使用して行う必要があります。

API スキーマを編集するときは、次の点に対処します (該当する場合)。 - オブジェクト種別間の競合をすべて解決する 統合スキーマと競合する種別がある場合は、必ずすべて解決します。詳細は、「[競合やマージの不整合の解決](https://docs.mulesoft.com/jp/datagraph/resolve-conflicts)」を参照してください。 - オブジェクト種別のコラボレーションを有効にする 該当する種別のコラボレーションを有効にして、必須の設定を指定します。このステップは省略可能ですが、種別のコラボレーションを有効にすると、統合スキーマのつながりが増えて強化されます。詳細は、「[Anypoint DataGraph でのオブジェクト種別コラボレーションの有効化](https://docs.mulesoft.com/jp/datagraph/collaboration)」を参照してください。 - スキーマ要素の表示を管理する 統合スキーマで表示する必要がない項目、種別、クエリメソッドを非表示にできます。詳細は、「[Anypoint DataGraph でのスキーマ要素の表示](https://docs.mulesoft.com/jp/datagraph/manage-elements-visibility)」を参照してください。 - スキーマ要素の名前を確認して編集する 統合スキーマに追加するすべての項目、種別、クエリメソッドの名前を確認または変更できます。詳細は、「[スキーマ要素の名前の編集](https://docs.mulesoft.com/jp/datagraph/edit-elements-names)」を参照してください。 - 類似のオブジェクト種別をマージする 種別をマージすると、類似の種別を結合して項目やデータセットを拡張し、クエリ結果を向上させることができます。詳細は、「[Anypoint DataGraph でのオブジェクト種別のマージのしくみ](https://docs.mulesoft.com/jp/datagraph/merge-types)」を参照してください。 - オブジェクト種別間の関連する項目をリンクする リンクによって 2 つの種別の関連する項目が結合され、クエリ結果を向上させることができます。 詳細は、「[Anypoint DataGraph のオブジェクト種別間のリンクのしくみ](https://docs.mulesoft.com/jp/datagraph/linking)」を参照してください。 - API の URL を編集する 統合スキーマに追加した API の URL を編集する必要がある場合、​**\[API details (API の詳細)\]**​ ページで編集できます。​[「統合スキーマに追加した API の URL を編集する」](https://docs.mulesoft.com/jp/datagraph/add-api-to-unified-schema#edit-the-url-for-an-api-added-to-the-unified-schema)​を参照してください。 - API の認証方法を変更する 統合スキーマに追加した API の認証方法を編集する必要がある場合、​**\[API details (API の詳細)\]**​ ページで編集できます。​[「統合スキーマに追加された API の認証方法を変更する」](https://docs.mulesoft.com/jp/datagraph/add-api-to-unified-schema#change-the-authentication-method-for-an-api-added-to-the-unified-schema)​を参照してください。 - API の相互認証 (mTLS) を設定する 統合スキーマに追加した API に mTLS を設定する必要がある場合は、​**\[API Details (API の詳細)\]**​ ページで実行できます。​[「統合スキーマに追加した API の mTLS を編集する」](https://docs.mulesoft.com/jp/datagraph/add-api-to-unified-schema#configure-mtls-for-an-api-added-to-the-unified-schema)​を参照してください。 - API バージョンを更新する API スキーマを DataGraph に追加したら、いつでも API ソースのバージョンを更新できます。 [「API バージョンを更新する」](https://docs.mulesoft.com/jp/datagraph/add-api-to-unified-schema#update-an-api-version)​を参照してください。 # API スキーマの要素の理解 Anypoint DataGraph は、クライアントが使用できるようにするために選択したすべてのデータを統合スキーマに整理します。統合スキーマは、追加するすべての API のすべてのスキーマの単一コレクションで、常に最新です。 統合スキーマに新しい API を追加すると、Anypoint DataGraph は API の RAML または OAS 仕様から API スキーマを生成します。各 API スキーマは、その API が追加されたときに作成されるため、統合スキーマは常に最新です。また、すべての API スキーマは組織内に個別に保存されるため、他のスキーマの整合性に影響を与えることなく、個別に編集できます。 Anypoint DataGraph が生成する API スキーマには、API 仕様で定義した GET リソースとエンティティのコレクション、およびそれらの間のリレーションが含まれます。統合スキーマに新しい API スキーマを追加するときはいつでも、統合スキーマに含まれる種別と項目を設定できます。 種別に適用できるさまざまな設定について学習する前に、次のトピックを参照し、API 仕様に応じて API スキーマに存在する可能性があるさまざまな種別を理解してください。 ## [](#オブジェクト種別と項目)オブジェクト種別と項目 スキーマで最も一般的な種別であるオブジェクト種別は、GET 応答の一部として返される API 仕様のエンティティを表します。オブジェクト種別にはわかりやすい名前が付けられ、オブジェクトのプロパティを示す項目が含まれています。 たとえば、RAML 仕様では、仕様の各種別要素はオブジェクト種別、列挙種別、結合種別のいずれかになります。また、各種別要素のプロパティは、API スキーマ内のそれらのオブジェクト種別の項目です。
RAML API 仕様 API スキーマ
#%RAML 1.0
title: Order API

types:
  Order:
    type: object
    properties:
      orderId:
      date:
      status:


  Product:
    type: object
    properties:
      productId:
      name:
      brand:

/orders/​{id}​:
  get:
    displayName: Get Order by ID
ordersById(id): Order
--------------------
--------------------
Order
--------------------
orderId: ID!
date: String
status: String
--------------------
--------------------
Product
--------------------
productId: ID!
name: String
brand: String
`Order`​ と ​`Product`​ は両方とも異なるオブジェクト種別であり、それぞれに異なる項目があり、次のように表すことができます。 ```none type Order { orderId: ID! date: String! status: String! } ``` ```none type Product { productId: ID! name:String! brand: String! } ``` ### [](#項目のデータ型)項目のデータ型 各項目は、クエリの応答で返される型のデータセットを表します。デフォルトでは、5 個のスカラー型があります。 - `Int`​: 符号付き 32 ビット整数。 - `Float`​: 符号付き倍精度浮動小数点値。 - `String`​: UTF-8 文字シーケンス。 - `Boolean`​: `true`​ または ​`false`​。 - `ID`​: ID スカラー型は一意の識別子を表し、オブジェクトの再取得やクエリメソッドのキーとしてよく使用されます。ID 型は、文字列と同じ方法でシリアル化されます。ただし、ID としての定義は人間が読める形式ではないことを意味します。 ### [](#null-不可能な項目)null 不可能な項目 `!`​ 記号で表された値を含む項目は null 不可能です。つまり、項目は null 値で応答できません。たとえば、​`Product`​ 種別では、ID を null にすることはできません。 ```none type Product { productId: ID! name:String brand: String } ``` また、​`Order`​ 種別では、どの値も null にすることはできません。 ```none type Order { orderId: ID! name: String! price: String! brand: Int! } ``` ## [](#クエリ種別とクエリメソッド)クエリ種別とクエリメソッド クエリ種別は、要求を行うときの API スキーマへのエントリポイントです。クエリ種別には、API 仕様で定義した GET エンドポイントを表すクエリメソッドが含まれます。 たとえば、​`/orders/{id}`​ で GET エンドポイントを定義する RAML 仕様では、スキーマのクエリメソッドは ​`ordersById(id)`​ です。
RAML API 仕様 API スキーマ
#%RAML 1.0
title: Order API

/orders/​{id}​:
  get:
    displayName: Get Order by ID
ordersById(id): Order
## [](#level-1-and-nested-types)レベル-1 種別とネストされた種別 スキーマ内の種別は、種別とクエリメソッド間のリレーションに依存するカテゴリに属しています。 - レベル-1 種別 これらの種別にはクエリメソッドが関連付けられているため、直接アクセスできます。 たとえば、前の API 仕様では、​`order/{id}`​ エンドポイントに GET が関連付けられているため、​`Order`​ はレベル-1 オブジェクト種別です。 このオブジェクト種別には、クエリメソッドを直接使用してアクセスできます。 ```none ordersById (orderId: “123”) { orderId date } ``` - ネストされた種別 これらの種別にはクエリメソッドが関連付けられていないため、レベル-1 種別のクエリメソッドを介してのみアクセスできます。 たとえば、前の API 仕様では、​`Product`​ はクエリメソッドが関連付けられていないオブジェクト種別です。​`Product`​ 種別の項目を照会するには、そのレベル-1 種別 ​`Order`​ に関連付けられているメソッドを照会する必要があります。 ```none ordersById(id: "123") { orderId product { name price } } ``` この構造に従うと、クエリメソッドはレベル 0 種別とみなされます。 ## [](#列挙種別)列挙種別 列挙種別は、特定の値のセットのみを返すことができる種別です。API 仕様で列挙種別を宣言して、項目が常に有限の値のセットを返すようにすることができます。 たとえば、オブジェクト種別 ​`Processing`​、​`Completed`​、​`Canceled`​ のいずれかを返す必要がある ​`OrderStatus`​ 種別を定義する RAML 仕様があるとします。
RAML API 仕様 API スキーマ
#%RAML 1.0
title: Order API

types:
  OrderStatus:
    type: string
    description: Current status of the order
    enum: [Processing, Completed, Canceled]
enum OrderStatus {
  Processing
  Completed
  Canceled
}
## [](#結合種別)結合種別 結合種別は、他のオブジェクト種別を使用してデータのインスタンスを説明します。結合種別は 1 つ以上の特定のオブジェクト種別で構成されます。 たとえば、RAML 仕様では、​`Notebook`​ や ​`Phone`​ などの他の種別を使用して ​`Product`​ 種別を定義できます。
RAML API 仕様 API スキーマ
#%RAML 1.0
title: Order API

types:

  Product:
    type: Phone | Notebook

  Notebook:
    type: object
    properties:
      manufacturer:
        type: string
      numberOfUSBPorts:
        type: number
      kind: string

  Phone:
    type: object
    properties:
      manufacturer:
        type: string
      numberOfSIMCards:
        type: number
      kind: string
Product
--------------------
Notebook
Phone
--------------------
--------------------
Notebook
--------------------
manufacturer: String
numberOfUSBPorts: int
--------------------
--------------------
Phone
--------------------
manufacturer: String
numberOfSIMCards: int
## [](#変異および入力種別)変異および入力種別 _変異_​は、データオブジェクトを追加、更新、および削除するために使用する操作です。GraphQL では、変異操作は REST API 仕様で定義した POST、PATCH、PUT、DELETE、および HTTP メソッドを表します。 たとえば、この RAML 仕様は ​`/createOrder/{OrderInput}`​ で POST エンドポイントを定義し、スキーマの変異メソッドは ​`createOrder(input:OrderInput)`​ です。
RAML API 仕様 API スキーマ
#%RAML 1.0
title: Order API

/createOrder/​{OrderInput}​:
  post:
    displayName: Create Order by OrderInput
createOrder(input:OrderInput): Order
入力種別は、変異操作によって作成されたオブジェクトの属性を表します。入力種別は、変異を実行するときに統合スキーマの情報を変更するために使用する POST、PUT、および DELETE 要求オブジェクトです。 たとえば、​`/createOrder/{OrderInput}:`​ 変異を使用して ​`OrderInput`​ 入力種別に送信できます。 createOrder (input: “123”) { orderId customerEmail cutomerID orderDate product status totalAmount } ## [](#関連リソース)関連リソース - [DataGraph での GraphQL クエリおよび変異の作成](https://docs.mulesoft.com/jp/datagraph/write-queries-tutorial) - [Anypoint DataGraph クイックスタートガイド](https://docs.mulesoft.com/jp/datagraph/datagraph-qsg) # DataGraph での GraphQL クエリおよび変異の作成 この簡単なチュートリアルでは、Anypoint DataGraph で GraphQL クエリを作成するための重要な概念を紹介します。 Anypoint DataGraph クエリエディターを使用して、次の操作を実行する方法を説明します。 1. クエリ操作を検出して追加する 2. クエリに入力パラメーターを追加する 3. クエリに使用できる項目を検出する 4. ネストされた種別を追加する 5. クエリの別名を追加する 6. 変異を作成し、クエリ種別を理解する ## [](#クエリ操作を検出して追加する)クエリ操作を検出して追加する GraphQL では、クエリメソッドは必要なデータを取得するためのエントリポイントとして機能します。Anypoint DataGraph クエリエディターのスキーマエクスプローラーを使用して、API スキーマで使用できるクエリメソッドを検出することから始めます。 たとえば、​[「DataGraph クイックスタートガイド」](https://docs.mulesoft.com/jp/datagraph/datagraph-qsg)​で使用されている Catalyst Order API スキーマには、​`ordersCustomerByCustomerId`​ と ​`ordersByOrderId`​ の 2 つのクエリメソッドが関連付けられています。 ![スキーマエクスプローラーにリストされている 2 つのクエリメソッド](/mulesoft/current/ja-jp/datagraph/_images/schema-explorer-query-method.png) `ordersByOrderId`​ の場合: このクエリメソッドは、オブジェクト種別 ​`OrderResponse`​ に関するデータを返し、​`orderID`​ の引数を文字列形式で必要とします。 `ordersByOrderId (orderId:String!):OrderResponse`​ GraphQL で、クエリメソッドを追加してクエリを開始します。 ```copy { ordersByOrderId(orderId:String!) } ``` ## [](#入力パラメーターを追加する)入力パラメーターを追加する 感嘆符 (​`!`​) で示されているように、クエリメソッド ​`orderID`​ の入力パラメーターは null 不可能な項目です。この項目には、null 値ではない文字列データ型が必要です。 この場合、クエリに注文 ID を追加する必要があります。 ```copy { ordersByOrderId(orderId: "51c0ba3a-7e64-11e7-bb31-be2e44b06b3") } ``` ## [](#項目を追加する)項目を追加する 項目は、クエリ応答で返される種別のデータセットを表し、クエリを作成するときに必要な項目を選択できます。たとえば、前述のように ​`ordersByOrderID`​ クエリメソッドは ​`OrderResponse`​ オブジェクト種別を返し、次の項目を返します。 ![スキーマエクスプローラーにリストされている使用可能な項目](/mulesoft/current/ja-jp/datagraph/_images/schema-explorer-fields.png) クエリを作成するときに、これらの項目のいずれかを追加または削除できます。次のクエリは、使用可能な項目の一部を使用しています。 ```copy { ordersByOrderId(orderId: "51c0ba3a-7e64-11e7-bb31-be2e44b06b3") { customerId status subtotal taxPrice total trackingNumber } } ``` `OrderResponse`​ はレベル-1 種別です。つまり、前の例のようにクエリメソッドを使用して直接アクセスできます。 ## [](#ネストされた種別の項目を追加する)ネストされた種別の項目を追加する `billingAddress`​ などの OrderResponse オブジェクト種別によって返される項目の多くは、それ自体が、クエリ結果の価値を高めることができる追加データが含まれるオブジェクト種別です。これらの追加種別は、ネストされた種別と呼ばれます。 `billingAddress`​ オブジェクト種別は ​`PostalAddress`​ オブジェクト種別を返し、それ自体がいくつかの追加項目を返します。​`billingAddress`​ を照会するには、​`PostalAddress`​ から返す項目を指定する必要があります。次に例を示します。 ```copy { ordersByOrderId(orderId: "51c0ba3a-7e64-11e7-bb31-be2e44b06b3") { billingAddress { state city postalCode } } } ``` 結果として、最終的なクエリは次のようになります。 ```none { ordersByOrderId(orderId: "51c0ba3a-7e64-11e7-bb31-be2e44b06b3") { customerId status subtotal taxPrice total trackingNumber billingAddress { state city postalCode } } } ``` このクエリの場合、Anypoint DataGraph は次を返します。 ```none { "data": { "ordersByOrderId": { "customerId": "1964401a-a8b3-40c1-b86e-d8b9f75b5842", "status": "Draft", "subtotal": "100.21", "taxPrice": "15.22", "total": "125.43", "trackingNumber": "", "billingAddress": { "state": "CA", "city": "San Francisco", "postalCode": "94210" } } } } ``` ## [](#クエリの別名を追加する)クエリの別名を追加する 別名を使用して、クエリ応答の個々のキーの名前を変更できます。 たとえば、クエリ応答のみで、合計項目の名前を ​`totalPrice`​、状況項目の名前を ​`orderStatus`​ に変更できます。 ```copy { ordersByOrderId(orderId: "51c0ba3a-7e64-11e7-bb31-be2e44b06b3") { billingAddress { state city postalCode } totalPrice : total orderStatus : status } } ``` 異なる入力パラメーターを使用して 2 つ以上のクエリ操作で同じ項目を取得する場合は、クエリ操作に別名を指定できます。 ```copy { Order1: ordersByOrderId(orderId: "51c0ba3a-7e64-11e7-bb31-be2e44b06b3") { billingAddress { state city postalCode } totalPrice : total orderStatus : status } Order2: ordersByOrderId(orderId: "87c0ba4a-de28-12o7-pd11-eew12094b0w4) { billingAddress { state city postalCode } totalPrice : total orderStatus : status } } ``` これは、同じ項目が異なる値を取得する場合のエラーを回避するのに役立ちます。 ## [](#変異を作成する)変異を作成する _変異_​は、データオブジェクトを追加、更新、および削除するために使用する操作です。GraphQL では、変異操作は REST API 仕様で定義した POST、PUT、PATCH、DELETE HTTP メソッドを表します。 スキーマを簡略化するため、変異への入力は、変異操作によって作成されたオブジェクトの属性を表す​_入力種別_​によって処理されます。入力種別は、変異を実行するときに統合スキーマの情報を変更するために使用する POST、PUT、および DELETE 要求オブジェクトです。 たとえば、次の例に示すスキーマでは、6 個の変異操作が関連付けられています。 ![スキーマエクスプローラーにリストされている 6 個の変異操作](/mulesoft/current/ja-jp/datagraph/_images/schema-explorer-mutation-method.png) `createCustomer`​ の場合: この変異は ​`CustomerInput`​ オブジェクトを入力として取り、​`Customer`​ 種別の新しいオブジェクトを作成します。 そのためこの場合、入力種別 ​`CustomerInput`​ には次の項目があります。 ![スキーマエクスプローラーにリストされている CustomerInput の項目](/mulesoft/current/ja-jp/datagraph/_images/schema-explorer-mutation-fields.png) 住所項目には、​`AddressInput`​ 入力種別からのデータがあります。 ![スキーマエクスプローラーにリストされている AddressInput の項目](/mulesoft/current/ja-jp/datagraph/_images/schema-explorer-mutation-fields2.png) 変異操作を実行するときに、入力種別の各項目に値を指定します。 ```copy mutation { createCustomer(input: { firstName: "Lydia", lastName: "Millet", address: { city: "Tucson", state: "Arizona", street: "Speedway", postalCode: "1234" } }) { id } } ``` この変異は新しい顧客を作成するため、DataGraph は次を返します。 { "data": { "createCustomer": { "id": 42 } } } `CustomerInput`​ 入力種別には ​`id`​ 項目がないため、変異ではその項目が変異への入力に含まれません。ただし、​`Customer`​ 種別には ​`id`​ 項目が含まれ、その値は入力で指定された値に基づいて生成されます。 ## [](#関連リソース)関連リソース - [GraphQL クエリのドキュメント](https://graphql.org/learn/queries/) - [Anypoint DataGraph の用語](https://docs.mulesoft.com/jp/datagraph/datagraph-terms) - [API スキーマの要素の理解](https://docs.mulesoft.com/jp/datagraph/schemas) - [クエリおよび変異の実行](https://docs.mulesoft.com/jp/datagraph/query-unified-schema) # オブジェクト種別のマージの作成および編集 次のタスクでは、統合スキーマ内およびローカルスキーマ内でマージを作成する方法と元に戻す方法を説明します。 ## [](#オブジェクト種別のマージ)オブジェクト種別のマージ オブジェクト種別をマージすると、類似の 2 つのオブジェクト種別の項目を結合して、1 つのクエリで有益な結果を得ることができます。 オブジェクト種別を同じ API スキーマ内でローカルにマージすることも、オブジェクト種別を統合スキーマの種別とマージすることもできます。 マージするオブジェクト種別が​[表示されるように設定](https://docs.mulesoft.com/jp/datagraph/manage-elements-visibility)​されていることを確認します。 オブジェクト種別をマージする手順は、次のとおりです。 1. API スキーマのナビゲーションで、マージするオブジェクト種別を選択します。 2. **\[Merge (マージ)\]**​ ペインで、マージ先の対象種別を選択します。 次の例では、​**OrderSummary**​ という現在の種別を ​**OrderResponse**​ という対象オブジェクト種別にマージします。 ![order summary 種別とマージする対象種別として order response を選択](/mulesoft/current/ja-jp/datagraph/_images/merge-selection.png) 対象種別が同じ名前である必要はありません。 3. 現在の種別でコラボレーションが可能ながら、まだ有効になっていない場合や、選択した対象種別に主キーが定義されている場合は、次のいずれかを選択します。 - (推奨) 2 つの種別の項目を結合して、この種別のクエリ結果を向上させます。 この方法を選択すると、​**\[Enable collaboration (コラボレーションを有効化)\]**​ ペインが表示され、このペインでデフォルトのクエリメソッドと主キーを設定するか、クエリメソッドに複合キーを使用する場合は主キーを 2 つ設定します。(オブジェクト種別のコラボレーションについての詳細は、​[「種別のコラボレーションの有効化」](https://docs.mulesoft.com/jp/datagraph/collaboration)​を参照してください。) - 現在の種別を参照と宣言し、マージ先の種別の項目とデータセットのみが返されるようにします。 4. **\[Merge with another type (別の種別とマージ)\]**​ ペインで、​**\[Preview merge result (マージ結果のプレビュー)\]**​ をクリックします。 次の例では、プレビューに統合スキーマの ​**OrderResponse**​ 対象オブジェクト種別が表示され、​**OrderSummary**​ オブジェクト種別が ​**OrderResponse**​ にマージされた後に追加された新しい項目も示されています。 ![order summary と order response のマージ結果のプレビュー](/mulesoft/current/ja-jp/datagraph/_images/merge-preview.png) 5. 終了する場合は、​**\[Confirm merge (マージを確認)\]**​ をクリックします。 変更を適用すると、次のとおり、統合スキーマのマージ後のオブジェクト種別にマージ済みであることが示されます。 ![プレビューのマージ結果のインジケーター](/mulesoft/current/ja-jp/datagraph/_images/merged-type-results.png) ## [](#オブジェクト種別間のマージを元に戻す)オブジェクト種別間のマージを元に戻す 必要に応じて、オブジェクト種別間のマージを元に戻すことができます。たとえば、オブジェクト種別 A をオブジェクト種別 C にマージしたいと考えているが、種別 A がすでに統合スキーマまたはローカルの API スキーマの種別 B にマージされている場合は、まず種別 A と B 間の既存のマージを元に戻してから、種別 C との新しいマージを作成する必要があります。 次の点に注意してください。 - マージを元に戻すと、マージした種別に既存のクエリが中断されます。 - オブジェクト種別 A と統合スキーマの種別 B 間のマージを元に戻す場合は、オブジェクト種別 A (とマージされているクエリメソッド) の名前を変更する必要があります。オブジェクト種別 A (とそのクエリメソッド) の名前が変更されるか、種別 B と再度マージされるまで、Anypoint DataGraph に競合が表示されます。 - マージを元に戻すと、null 可能な項目が元の状態に戻ります。たとえば、オブジェクト種別の項目に null を指定できなかったが、マージの結果 null 可能になった場合、マージを元に戻すと、この項目に null を指定できなくなります。 マージを元に戻す手順は、次のとおりです。 1. 統合スキーマで、​**\[List of API added (追加された API のリスト)\]**​ をクリックし、マージされたオブジェクト種別を含む API を選択します。 2. API スキーマのナビゲーションで、オブジェクト種別を選択し、​**\[Merge (マージ)\]**​ ペインまでスクロールします。 3. **\[Undo merge (マージを元に戻す)\]**​ をクリックします。 4. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ## [](#ローカルマージを分割する)ローカルマージを分割する ローカルマージを分割して、競合の解決、要素の表示の管理、項目の名前変更、ローカルの API スキーマでのその他の編集を行います。 ローカルでマージされ、さらに統合スキーマの種別とマージされたオブジェクト種別がある場合は、まず統合スキーマとのマージを元に戻す必要があります。 マージを分割する手順は、次のとおりです。 1. **\[List of API added (追加された API のリスト)\]**​ をクリックし、マージ解除するオブジェクト種別を含む API スキーマを選択します。 2. API スキーマのナビゲーションで、オブジェクト種別を選択し、\[Merge (マージ)\] ペインまでスクロールします。 3. **\[Split Local Merge (ローカルマージを分割)\]**​ > ​**\[Apply Changes (変更を適用)\]**​ の順にクリックします。 分割後、種別は元の状態に戻りますが、項目の表示の変更や新しい名前などのカスタマイズは維持されます。 ## [](#関連リソース)関連リソース - [競合やマージの不整合の解決](https://docs.mulesoft.com/jp/datagraph/resolve-conflicts) - [Anypoint DataGraph でのオブジェクト種別のマージのしくみ](https://docs.mulesoft.com/jp/datagraph/merge-types) # オブジェクト種別間のリンクの作成および編集 以下のタスクでは、オブジェクト種別間のリンクを作成する方法と元に戻す方法について説明します。 ## [](#関連するオブジェクト種別をリンクする)関連するオブジェクト種別をリンクする リンクにより、2 つの関連するオブジェクト種別の項目を結合して、統合スキーマから有用なクエリ結果を得ることができます。 - オブジェクト種別をリンクする前に、​[項目が表示されるように設定](https://docs.mulesoft.com/jp/datagraph/manage-elements-visibility)​されていることを確認します。 - リンクできるのは、リンク先のオブジェクト種別に ​[\[Enable collaboration (コラボレーションを有効化)](https://docs.mulesoft.com/jp/datagraph/collaboration#enable-collaboration-on-an-object-type)\]​ がある場合のみです。 オブジェクト種別をリンクする手順は、次のとおりです。 1. API スキーマのナビゲーションで、リンク元 (ソース) のオブジェクト種別を選択します。 2. **\[Link to another type (別の種別にリンク)\]**​ ペインまでスクロールして、​**\[Select the type you want to link to (Target) (リンク先 (対象) の種別を選択)\]**​ メニューで、対象オブジェクトを選択します。 Anypoint DataGraph で、対象種別の主キーまたは複合キーが検出されて表示されます。 3. ドロップダウンメニューを使用して、ソースの外部キーとなる項目を選択します。 外部キーが対象種別の主キーにマッピングされ、まったく同じデータ型になります。 対象種別で複合キーを使用する場合は、項目を 2 つ選択する必要があります。 4. **\[New field configurations (新規項目設定)\]**​ で、リンクされた項目の名前を確認し、必要に応じて編集します。 Anypoint DataGraph で現在の種別にこの項目が作成され、対象種別にリンクされます。 5. (省略可能) 統合スキーマで外部キー項目を非表示にします。 新しい項目がリンク先の種別を返すため、未解決のクエリがある場合を除き、外部キーを非表示にしても問題ありません。 ![リンクされた対象種別の結果の詳細を示す \[Link configurations (リンク設定)\]](_images/link-object-type.png) 6. **\[Save changes (変更を保存)\]**​ をクリックします。 項目ペインまでスクロールアップすると、項目がリンクされたことを示すアイコンが示されます。 ![リンクアイコンによってリンク済みであることがわかるオブジェクト](/mulesoft/current/ja-jp/datagraph/_images/linked-type-icon.png) ## [](#オブジェクト種別間のリンクを削除する)オブジェクト種別間のリンクを削除する 項目は一度に他の 1 つのオブジェクト種別にのみリンクできます。そのため、リンクが不要になった場合や、項目を別のオブジェクト種別にリンクする場合は、元のリンクを削除できます。 オブジェクト種別間のリンクを削除する手順は、次のとおりです。 1. 統合スキーマで、​**\[List of API added (追加された API のリスト)\]**​ をクリックし、項目がリンクされているオブジェクト種別を含む API を選択します。 2. API スキーマのナビゲーションで、項目がリンクされているオブジェクト種別を選択し、​**\[Link to another type (別の種別にリンク)\]**​ ペインまでスクロールします。 3. 削除するリンクを見つけ、​**\[>\]**​ をクリックしてリンクの詳細を開きます。 4. **\[Remove Link (リンクを削除)\]**​ をクリックします。 5. **\[Save (保存)\]**​ をクリックして、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 ## [](#関連リソース)関連リソース - [Anypoint DataGraph のオブジェクト種別間のリンクのしくみ](https://docs.mulesoft.com/jp/datagraph/linking) # クエリおよび変異の実行 統合スキーマは 1 つの GraphQL エンドポイントに解決されます。統合スキーマに対するクエリまたは変異を実行するには、まずアクセス権を要求し (該当する場合)、クエリエディターで GraphQL クエリを作成して実行します。 ## [](#始める前に)始める前に - [「Consume (コンシューム)」、「Contribute (参加)」、「Admin (管理)」のいずれかの権限](https://docs.mulesoft.com/jp/datagraph/permissions)​が必要です。 - [「Anypoint DataGraph の API のサポート」](https://docs.mulesoft.com/jp/datagraph/#anypoint-datagraph-api-support)​を確認してください。 ## [](#クエリを実行するためのアクセス権を要求する)クエリを実行するためのアクセス権を要求する クエリまたは変異を実行するためには、アクセス権を要求する必要があります。 外部クライアントプロバイダーを使用している場合は、​[「外部クライアントプロバイダーを使用する環境へのアクセス権の要求」](#request-access-to-environments-using-an-external-client-provider)​を参照してください。 1. **\[Run Operation (操作を実行)\]**​ をクリックします。 2. **\[Request access to run queries (クエリを実行するためのアクセス権の要求)\]**​ ダイアログで、クエリを実行するためのアクセス方法を選択します。 既存のクライアントアプリケーション、またはクライアントの ID とシークレットのペアを使用する場合は、Exchange で確認できます。新しいタブで Exchange を開き、​**\[My applications (マイアプリケーション)\]**​ に移動し、リストからアプリケーションを選択して関連情報を確認します。 次のいずれかのオプションを選択します。 - **Use one of my existing applications (既存のアプリケーションの 1 つを使用する)**​: リストから既存のクライアントアプリケーションを選択して、\[Request Access (アクセス権を要求)\] をクリックします。 - **Create a new application and use it immediately (新しいアプリケーションを作成してすぐに使用する)**​: **\[Next (次へ)\]**​ をクリックし、アプリケーション名と、説明やアプリケーション URL (省略可能) を指定して、​**\[Create and Request Access (作成してアクセス権を要求)\]**​ をクリックします。 - **I already have credentials…​ (ログイン情報を取得済み…​)**​: **\[Next (次へ)\]**​ をクリックし、クライアント ID とシークレットのペアを指定してから、​**\[Authenticate & Request Access (認証してアクセス権を要求)\]**​ をクリックします。 3. クエリエディターでアクセス方法を変更するには、アクションメニュー (​**…​**​) から ​**\[Switch Current Credentials (現在のログイン情報を切り替え)\]**​ を選択します。 ## [](#クエリを実行する)クエリを実行する クエリエディターは、クエリの作成、実行、トラブルシューティングに使用できます。 1. 統合スキーマの API にパススルー認証が必要なものがある場合は、​**\[Add HTTP Headers (HTTP ヘッダーを追加)\]**​ をクリックして、次の手順を実行します。 1. ヘッダー名を選択します。 2. ヘッダー値を入力します。 3. 他の API のヘッダー名と値のペアも指定する場合は、​**\[+Add Header (+ヘッダーを追加)\]**​ をクリックします。 4. **\[Save (保存)\]**​ をクリックします。 5. HTTP ヘッダーを編集する場合は、​**\[Edit HTTP Headers (HTTP ヘッダーを編集)\]**​ をクリックします。 2. クエリエディターで、インラインのオートコンプリート機能を使用してクエリを入力するか、​**Option/Alt + Shift + Space**​ キーでオートコンプリートメニューを開いて入力します。 ![インラインのオートコンプリートを使用してクエリを作成](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-query-autocompletion.png) 3. 必要に応じて、​**\[Query Variables (クエリ変数)\]**​ ペインで、使用するクエリ変数を追加します。 ![クエリエディターにクエリ変数を挿入](/mulesoft/current/ja-jp/datagraph/_images/datagraph-query-variable.png) 4. **\[Run (実行)\]**​ をクリックします。 ![クエリエディターに表示されたクエリ結果](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-query-result.png) 5. クエリトレースを使用して結果を表示する場合は、アクションメニュー (​**…​**​) から ​**\[Trace Query (クエリをトレース)\]**​ を選択して、​**\[Run (実行)\]**​ をクリックします。 ![クエリのトレースビューとクエリ結果](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-query-traces.png) DataGraph のクエリトレースの結果には、次の情報が示されます。 - DataGraph でクエリの解析と検証に要した時間 - クエリ全体の合計応答時間 - クエリでの各ソース API への要求時間 6. クエリに関連するログを表示するには、アクションメニュー (​**…​**​) から ​**\[View Response Logs (応答ログを表示)\]**​ を選択します。 ![クエリの応答ログページ](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-response-logs.png) DataGraph のログレベルには、DEBUG、INFO、WARN、ERROR があります。 7. **\[View History (履歴を表示)\]**​ をクリックすると、後からこの同じクエリ (または別のクエリ) にアクセスできます。 8. このクエリをアプリケーションで使用するには、​**\[Copy endpoint (エンドポイントをコピー)\]**​ をクリックして、クエリと自動的に生成された GraphQL エンドポイントをコピーします。クエリを curl スニペットとしてコピーすることもできます。 ## [](#変異を実行する)変異を実行する クエリエディターを使用して、変異を作成して実行します。必要に応じて、クエリエディターで変異のトラブルシューティングを行うこともできます 1. 統合スキーマの API にパススルー認証が必要なものがある場合は、​**\[Add HTTP Headers (HTTP ヘッダーを追加)\]**​ をクリックして、次の手順を実行します。 1. ヘッダー名を選択します。 2. ヘッダー値を入力します。 3. 他の API のヘッダー名と値のペアも指定する場合は、​**\[+Add Header (+ヘッダーを追加)\]**​ をクリックします。 4. **\[Save (保存)\]**​ をクリックします。 5. HTTP ヘッダーを編集する場合は、​**\[Edit HTTP Headers (HTTP ヘッダーを編集)\]**​ をクリックします。 2. クエリエディターで、インラインのオートコンプリート機能を使用して変異を入力するか、​**Option/Alt + Shift + Space**​ キーでオートコンプリートメニューを開いて入力します。 ![インラインのオートコンプリートを使用して変異を作成](/mulesoft/current/ja-jp/datagraph/_images/datagraph-mutation-autocomplete.png) 3. 必要に応じて、​**\[Query Variables (クエリ変数)\]**​ ペインで、使用する変数を追加します。 4. **\[Run (実行)\]**​ をクリックします。 ![クエリエディターに表示された変異結果](/mulesoft/current/ja-jp/datagraph/_images/datagraph-mutation-result.png) 5. クエリトレースを使用して結果を表示する場合は、アクションメニュー (​**…​**​) から ​**\[Trace Query (クエリをトレース)\]**​ を選択して、​**\[Run (実行)\]**​ をクリックします。 6. クエリに関連するログを表示するには、アクションメニュー (​**…​**​) から ​**\[View Response Logs (応答ログを表示)\]**​ を選択します。 7. **\[View History (履歴を表示)\]**​ をクリックすると、後からこの同じ変異 (または別の変異) にアクセスできます。 8. この変異をアプリケーションで使用するには、​**\[Copy endpoint (エンドポイントをコピー)\]**​ をクリックして、クエリと自動的に生成された GraphQL エンドポイントをコピーします。クエリを curl スニペットとしてコピーすることもできます。 ## [](#クエリエディターのショートカット)クエリエディターのショートカット 次の表は、クエリエディターで使用可能なショートカットを示しています。
関数 ショートカット

クエリの整形

Shift ​Ctrl​ p

操作を実行

Ctrl + Enter

オートコンプリート

Ctrl + space

行のコメントアウト

Cmd + /

現在のスコープの終点または始点にジャンプ

Cmd + m

現在の単語の強調表示

Cmd + d

正規表現検索

Cmd + f

検索と置換

Cmd + h

次の行を現在の行に移動

Cmd + j

行のカーソルより後の部分を削除

Cmd + kk

現在の行の強調表示

Cmd + l

現在の行のアウトデント

Cmd + [

現在の行のインデント

Cmd + ]

## [](#外部クライアントプロバイダーを使用する環境へのアクセス権の要求)外部クライアントプロバイダーを使用する環境へのアクセス権の要求 API Manager を使用すると、環境ごとに異なるクライアントプロバイダーを設定できます。データグラフが実行される環境によっては、クライアントアプリケーションで、デフォルトの Anypoint Platform ネイティブクライアントプロバイダーまたはサポートされている外部クライアントプロバイダーのいずれかを使用して認証する必要のある場合があります。詳細は、​[「クライアント管理について」](https://docs.mulesoft.com/jp/access-management/managing-api-clients)​を参照してください。 環境に特定のクライアントプロバイダーを設定しない場合は、Anypoint Platform のデフォルトのネイティブクライアントプロバイダーが使用されます。 各自の環境で外部クライアントプロバイダーを使用している場合は、​**\[Request Access (アクセス権の要求)\]**​ ポップアップに、外部クライアントプロバイダーの実装で定義された必須項目と省略可能な項目が表示されます。 たとえば、​`/api-federation/xapi/organizations/{organizationID}/environments/{environmentID}/type/federation/api/clientProvider/`​ エンドポイントに照会すると、その環境で設定されている許可種別が返されます。 ```JSON { "id": "aaaaaaaa-1a1a-1a1a-1a1a-aaaa1111aaa1", "name": "OpenAM", "typeName": "openam", "grantTypes": [ { "name": "password", "label": "Resource Owner Grant", "depends": [], "exclude": [], "required": true (1) }, { "name": "implicit", "label": "Implicit Grant", "depends": [], "exclude": [], "required": true (1) }, { "name": "client_credentials", "label": "Client Credentials Grant", "depends": [], "exclude": [ "authorization_code" (2) ], "required": false }, { "name": "authorization_code", "label": "Authorization Code Grant", "depends": [], "exclude": [ "client_credentials" (2) ], "required": false } ] } ``` これらの許可種別のプロパティは、クライアントのアクセス権を設定するときの UI に反映されます。 ![外部クライアントプロバイダーを使用する場合のアクセス権の要求](/mulesoft/current/ja-jp/datagraph/_images/confirm-credentials.png)
1UI で ​[Resource Owner Grant (リソースオーナー許可)]​ と ​[Implicit Grant (暗黙的許可)]​ の両方が必須とマークされています。
2UI の ​[Client Credentials Grant (クライアントログイン情報許可)]​ と ​[Authorization Code Grant (認証コード許可)]​ は相互に排他的です。
## [](#関連リソース)関連リソース - [DataGraph での GraphQL クエリおよび変異の作成](https://docs.mulesoft.com/jp/datagraph/write-queries-tutorial) - [Anypoint DataGraph のトラブルシューティング](https://docs.mulesoft.com/jp/datagraph/troubleshoot-schemas-queries) - [Configure Multiple Client Providers for Client Management in API Manager (API Manager でのクライアント管理用の複数のクライアントプロバイダーの設定)](https://docs.mulesoft.com/jp/api-manager/latest/configure-multiple-credential-providers) # クエリトレースを使用したクエリのパフォーマンスのトラブルシューティング Anypoint DataGraph でクエリトレースを使用すると、特定のクエリで統合スキーマのソース API に対して実行された各コールをトレースするという方法で、クエリのパフォーマンスを分析できます。 トレースの結果には次の情報が示されます。 ![クエリトレースの詳細ビュー](/mulesoft/current/ja-jp/datagraph/_images/query-trace-details.png)
1Anypoint DataGraph でクエリの解析と検証に要した時間
2クエリ全体の合計応答時間
3クエリの実行中に検出されたエラー
4トレース情報の不足 (ぼやけた線で示されます)
5クエリでの各ソース API への要求時間
## [](#前提条件)前提条件 クエリトレースを使用するには、​[「寄稿」または「管理」権限](https://docs.mulesoft.com/jp/datagraph/permissions)​が必要です。 ## [](#クエリトレースを実行する)クエリトレースを実行する 操作を実行するとすぐにクエリトレースの結果が表示されます。 1. アクションメニュー (​**…​**​) から、​**\[Trace Query (クエリをトレース)\]**​ を選択します。 2. クエリを作成します。 3. **\[Run (実行)\]**​ をクリックします。 クエリのトレースパネルが開き、結果が表示されます。 ![クエリで有効になっているクエリトレース](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-query-traces.png) クエリのトレースパネルは必要に応じて折りたたんだり展開したりすることができます。 ## [](#関連リソース)関連リソース - [応答ログを使用したクエリのトラブルシューティング](https://docs.mulesoft.com/jp/datagraph/troubleshoot-query-logs) - [クエリおよび変異の実行](https://docs.mulesoft.com/jp/datagraph/query-unified-schema) # スキーマ要素の名前の編集 統合スキーマに API を追加すると、項目、種別、およびクエリメソッドの名前を変更できるため、統合スキーマのコンシューマーにとってより便利になり、要素間の競合を解決できます。 統合スキーマの種別とマージされている API の種別の名前を変更すると、マージは元に戻されます。同様に、主キーとして設定した項目の名前を変更すると、その主キーに関連付けられたリンクまたはマージが解除されます。項目またはクエリメソッドの名前を変更するときは、それらの要素の既存のコラボレーションが解除されないことを確認します。 要素の名前を編集する前に、必ず​[その要素を表示](https://docs.mulesoft.com/jp/datagraph/manage-elements-visibility)​してください。 スキーマ要素の名前を編集する手順は、次のとおりです。 1. オブジェクト種別、項目、またはメソッドに移動し、​**\[Rename (名前を変更)\]**​ をクリックします。 2. **\[Change to: (変更後:)\]**​ 項目に新しい名前を追加し、​**\[Confirm (確認)\]**​ をクリックします。 3. 要素をデフォルトにリセットする場合は、もう一度 ​**\[Rename (名前を変更)\]**​ をクリックしてから、​**\[Reset name to default (名前をデフォルトにリセット)\]**​ をクリックします。 # 応答ログを使用したクエリのトラブルシューティング Anypoint DataGraph には、クエリのトラブルシューティングに役立つ情報が記載された応答ログがあります。 応答ログには Anypoint DataGraph のクエリに関する情報のみが示されます。Anypoint DataGraph ではログデータが、最大 100 MB と最長 30 日間の制限のいずれか早いほうに到達するまで保存されます。

Titanium サブスクリプションに登録している場合は、​Titanium のログ制限が適用​されます。

## [](#anypoint-datagraph-の応答ログのログレベル)Anypoint DataGraph の応答ログのログレベル Anypoint DataGraph のログレベルには、DEBUG、INFO、WARN、ERROR があります。ログレベルは段階的で、各レベルに次の情報が示されます。
ログレベル 説明 含まれるレベル

DEBUG

リクエストヘッダーと要求クエリに関する情報をログします。

すべてのレベル

INFO

要求クエリ、応答時間、クエリで要求された各項目の基盤となる API URL に関する情報をログします。

INFO、WARN、ERROR

WARN

警告メッセージをリストします。

INFO、WARN

ERROR

無効なクエリ、タイムアウト、認証エラー、ペイロードエラーに関するエラーメッセージをリストします。

ERROR

デフォルトで、各環境のログレベルは INFO に設定されています。この設定はいつでも変更できます。ログレベルを変更すると、ユーザーに関係なく、​_Anypoint DataGraph インスタンスに対する今後のすべてのクエリ_​に一貫して適用されます。 ## [](#操作の応答ログを表示する)操作の応答ログを表示する 応答ログを表示または検索するには、​[「操作」または「管理」権限](https://docs.mulesoft.com/jp/datagraph/permissions)​が必要です。 Titanium のサブスクライバーの場合は、​[Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/logs)​ でも応答ログを表示できます。 Anypoint DataGraph で応答ログを表示する手順は、次のとおりです。 1. 操作を作成して実行します。 2. アクションメニュー (​**…​**​) から、​**\[View Response Logs (応答ログを表示)\]**​ を選択します。 このクエリの応答ログは次のように表示されます。 ![クエリの応答ログページ](/mulesoft/current/ja-jp/datagraph/_images/datagraph-qsg-response-logs.png) ## [](#応答ログを検索する)応答ログを検索する 特定の値を含むログを検索したり、日付や優先度でログを検索したりします。 **\[Date & Time (日時)\]**​ 検索条件を使用すると、次の値で日付範囲を指定してログを検索できます。 - Last hour (過去 1 時間) - Last 24 hours (過去 24 時間) - Last week (先週) - Last month (先月) また、優先度で検索結果を絞り込むこともできます。 - All priorities (すべての優先度) - INFO - DEBUG - WARN - ERROR 既存のログを検索する手順は、次のとおりです。 1. 検索ボックスに値を入力するか、\[Advanced (詳細)\] をクリックして、指定した時刻、日付、日付範囲、メッセージ優先度のログを検索します。 ![クエリの応答ログの項目を検索](/mulesoft/current/ja-jp/datagraph/_images/search-logs.png) 2. **\[Apply (適用)\]**​ をクリックします。 ## [](#関連リソース)関連リソース - [クエリトレースを使用したクエリのパフォーマンスのトラブルシューティング](https://docs.mulesoft.com/jp/datagraph/troubleshoot-query-traces) - [クエリおよび変異の実行](https://docs.mulesoft.com/jp/datagraph/query-unified-schema) # 競合やマージの不整合の解決 統合スキーマにオブジェクト種別を追加するときに、マージの競合またはマージの不整合を解決する必要があります。 ## [](#オブジェクト種別間の競合を解決する)オブジェクト種別間の競合を解決する 統合スキーマに種別を追加するときに、追加する種別のすべてが統合スキーマの既存の種別と競合しないようにする必要があります。 統合スキーマ内にすでに存在する種別名を持つ API スキーマを追加すると、Anypoint DataGraph でエラーが発生します。続行する前に、このエラーを解決する必要があります。 この特定の種別を統合スキーマに追加する必要がない場合は、項目を非表示にすることを選択できます。 この競合する種別を統合スキーマに追加する場合は、次のいずれかを行う必要があります。 - 種別またはクエリメソッドを非表示にする 詳細は、「[Anypoint DataGraph でのスキーマ要素の表示](https://docs.mulesoft.com/jp/datagraph/manage-elements-visibility)」を参照してください。 - 種別の名前を変更して名前の競合を回避する 詳細は、「[スキーマ要素の名前の編集](https://docs.mulesoft.com/jp/datagraph/edit-elements-names)」を参照してください。 - 新しい種別を同じ名前の既存の種別とマージする 詳細は、「[Anypoint DataGraph でのオブジェクト種別のマージのしくみ](https://docs.mulesoft.com/jp/datagraph/merge-types)」を参照してください。 ## [](#マージの不整合を解決する)マージの不整合を解決する マージする前に、オブジェクト種別および項目間の不整合やその他の問題を解決します。問題の例を示すリストを次に示します。 - 両方の種別で表示設定が同じでない場合、マージ後に共通項目の表示設定は変更できない。 共通項目を含む 2 つのオブジェクト種別をマージし、共通項目が ObjectType1 で非表示になっており、ObjectType2 で表示されている場合、マージ後に共通項目の表示設定を変更することはできません。代わりに、オブジェクト種別を分割し、項目設定を変更して、それらを再度マージする必要があります。 - 対象種別が最新でない場合、オブジェクト種別はマージできない。 別のユーザーが統合スキーマを更新しているときに、オブジェクト種別を統合スキーマ内のオブジェクト種別とマージしようとすると、マージは失敗し、DataGraph で変更が適用されません。マージをキャンセルし、統合スキーマのローカルバージョンを更新して、マージをやり直す必要があります。 - マージ後、種別の残りの項目のみの表示設定は変更できない。 それぞれが 2 つの一意の表示項目を持つ 2 つのオブジェクト種別 (ObjectType1 には FieldA と FieldB が含まれ、ObjectType2 には FieldC と FieldD が含まれる) をマージする場合、FieldA を非表示にしてからオブジェクト種別をマージすると、FieldB は ObjectType1 で唯一の表示項目になるため、マージされたままだと FieldB の表示設定は変更できません。代わりに、マージを分割または元に戻し、項目設定を変更して、再度マージする必要があります。 - 重複する名前があるオブジェクト種別を非表示にすると、競合が発生する。 統合スキーマまたは同じスキーマ内の別のオブジェクト種別と同じ名前の非表示のオブジェクト種別がローカル API スキーマにある場合、そのオブジェクト種別を非表示にすると、競合が発生します。オブジェクト種別の名前を変更するか、再表示してから同じ名前のオブジェクト種別とマージする必要があります。 - マージした種別を非表示にすると、マージが取り消される。 統合スキーマのオブジェクト種別をマージしてから、参加している種別のいずれかを非表示にすると、オブジェクト種別はマージされなくなります。非表示のオブジェクト種別を表示して、再度マージする必要があります。 ## [](#関連リソース)関連リソース - [API スキーマ生成時に発生する可能性があるエラー](https://docs.mulesoft.com/jp/datagraph/troubleshoot-schemas-queries) - [統合スキーマに追加するために API スキーマを編集](https://docs.mulesoft.com/jp/datagraph/edit-schema) # 統合スキーマおよび診断データの取得 統合スキーマのコピーを取得する場合は、クエリエディターからダウンロードするか、サードパーティの API クライアントを使用します。診断データは、DataGraph の ​**\[List of API added (追加された API のリスト)\]**​ ページからダウンロードできます。 このスキーマは ​`.graphql`​ ファイルとしてダウンロードされます。診断データは JSON ファイルとしてダウンロードされます。 ## [](#クエリエディターから統合スキーマをダウンロードする)クエリエディターから統合スキーマをダウンロードする クエリエディターからスキーマをダウンロードするには、​[「コンシューマー」、「コントリビューター」、「管理者」のいずれかの権限](https://docs.mulesoft.com/jp/datagraph/permissions)​が必要です。 1. クエリエディターに移動します。 2. アクションメニュー (​**…​**​) から、​**\[Download Schema (スキーマをダウンロード)\]**​ を選択します。 ## [](#api-クライアントを使用した統合スキーマの取得)API クライアントを使用した統合スキーマの取得 統合スキーマのコピーを取得するには、次のものが必要です。 - 統合スキーマのグラフエンドポイント。Anypoint DataGraph のホームページで取得できます。 - 統合スキーマの照会に使用する ​`client_id`​ と ​`client_secret`​ の値。API Manager の ​[\[Client Applications (クライアントアプリケーション)](https://docs.mulesoft.com/jp/api-manager/latest/datagraph-viewing-application-contracts)\]​ ページで取得できます。 任意の API クライアントで、次の情報を指定した GET 要求を実行します。 - `/schema`​ が付加されている統合スキーマのグラフエンドポイント - 各自の ​`client_id`​ ヘッダーと ​`client_secret`​ ヘッダー 完全なコマンドは次のようになります。 ```copy curl https:///schema \ -H 'client_id: ' \ -H 'client_secret: ' ``` ## [](#診断データをダウンロードする)診断データをダウンロードする 診断データをダウンロードするときに、DataGraph ではその環境に追加した API ソースの診断データがダウンロードされます。 ソース API をダウンロードするには、​[コントリビューターまたは管理者権限](https://docs.mulesoft.com/jp/datagraph/permissions)​が必要です。 1. **\[List of APIs added (追加された API のリスト)\]**​ ページに移動します。 2. API リストの右隅で、​**\[…​\]**​ > ​**\[Download Diagnostic Data (診断データをダウンロード)\]**​ をクリックします。 # 統合スキーマからの API の削除 必要に応じて、統合スキーマから API を削除できます。たとえば、API を削除して新しいバージョンを追加したり、基盤となる REST API が存在しなくなった場合に API を削除したりします。 ただし、統合スキーマから API を削除する場合、次の機能が停止する点に注意してください。 - 削除した API スキーマの種別とのマージおよびリンク - 削除した API スキーマの種別と項目を照会する既存のクエリ API を削除する手順は、次のとおりです。 1. **\[List of API added (追加された API のリスト)\]**​ をクリックし、削除する API を選択します。 2. **\[Remove API (API を削除)\]**​ をクリックして、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 ## [](#関連リソース)関連リソース - [DataGraph 状況の概要](https://docs.mulesoft.com/jp/datagraph/status-updates) - [統合スキーマに追加するために API スキーマを編集](https://docs.mulesoft.com/jp/datagraph/edit-schema) # 統合スキーマへの API ソースの追加 API を追加すると、Anypoint DataGraph によってその API の仕様から API スキーマが生成されます。そのスキーマを統合スキーマに追加する前に編集できます。 API 仕様の要素には API スキーマに追加されないものがあります (GET 以外の操作など)。詳細は、​[「API スキーマ生成時に発生する可能性があるエラー」](https://docs.mulesoft.com/jp/datagraph/troubleshoot-schemas-queries)​を参照してください。 API を統合スキーマに追加するには、次の 3 つのタスクを実行します。 1. [API を Anypoint DataGraph に追加する](#add-the-api-to-anypoint-datagraph)​ 2. [生成された API スキーマをプレビューする](#preview-the-generated-api-schema)​ 3. [API スキーマを編集し、競合があれば解決する](#edit-the-api-schema-and-add-it-to-the-unified-schema)​ 生成された API スキーマを統合スキーマに追加する前に、オブジェクト種別間の競合を解決する必要があります。詳細は、​[「競合の解決と不整合のマージ」](https://docs.mulesoft.com/jp/datagraph/resolve-conflicts)​を参照してください。 API を追加すると、次のことができるようになります。 - [認証方法を変更する](#change-the-authentication-method-for-an-api-added-to-the-unified-schema) - [API の mTLS を設定する](#configure-mtls-for-an-api-added-to-the-unified-schema) - [そのバージョンを更新する](#update-an-api-version)

Anypoint CLI​ を使用して DataGraph で API ソースを追加および編集することもできます。ただし、CLI を使用して API ソースを追加する場合は、UI で直接編集したりそのバージョンを更新したりすることはできません。これらの変更は CLI を使用して行う必要があります。

## [](#始める前に)始める前に API を統合スキーマに追加するには、次のことを確認します。 - RAML または OAS のいずれかの仕様を使用する REST API を作成した。 - 統合スキーマと同じ組織の Exchange に API をパブリッシュした。DataGraph でサポートされるのは、​`安定`​状態の API バージョンのみです。 - アクセス可能な URL を使用して API のインスタンスを開始した。 API は Mule アプリケーションでなくても、Mule Runtime Engine または CloudHub 上で実行されていなくてもかまいません。 さらに、次のことを確認する必要があります。 - API を追加するための​[適切な権限](https://docs.mulesoft.com/jp/datagraph/permissions)​がある。 - Anypoint DataGraph を使用するビジネスグループまたは組織に、プランの指定どおりに適切な数の vCore が割り当てられている。API を追加しようとしている環境に適切な数の vCore が割り当てられていない場合、Anypoint DataGraph からエラーメッセージが表示されます。 ## [](#api-を-anypoint-datagraph-に追加する)API を Anypoint DataGraph に追加する API を統合スキーマに追加するための最初のタスクでは、アセットバージョン、URL、認証方法を設定して API を Anypoint DataGraph に追加します。
  • Anypoint DataGraph から API にアクセスするためにサポートされている認証方法は次の手順に記載されています。それ以外の認証方法 (有効期間の短いトークン方式など) はサポートされていません。詳細は、​「サポートされる認証方法」​を参照してください。

1. \[Anypoint Platform\] > \[Anypoint DataGraph\] で ​**\[Unified Data Graph (統合データグラフ)\]**​ ドロップダウンリストから適切な環境を選択し、​**\[+Add API (+API を追加)\]**​ をクリックします。 2. **\[Select API (API を選択)\]**​ ページで、追加する API を選択します。 3. **\[Next: Configure URL (次へ: URL を設定)\]**​ をクリックします。 4. **\[Configure URL (URL を設定)\]**​ ページで、追加する API の API バージョンとアセットバージョンを選択し、​**\[Confirm Selection (選択を確認)\]**​ を選択します。 5. 引き続き ​**\[Configure URL (URL を設定)\]**​ ページで、API の URL を次のように追加または編集します。 - API が API Manager で管理されているか、Exchange の API のインスタンスを追加した場合は、​**\[Get an existing URL from Anypoint Platform (Anypoint Platform から既存の URL を取得)\]**​ を選択します。 - 独自の実装 URL を手動で指定する場合は、​**\[Add a new URL (新しい URL を追加)\]**​ を選択します。 6. **\[Next: Provide authentication (次へ: 認証を指定)\]**​ をクリックします。 7. **\[Configure Security (セキュリティを設定)\]**​ ページで、追加する API の GET エンドポイントの認証種別を選択します。 - **No Auth (認証なし)**​: API が公開の場合に使用します。 - **Basic Auth (基本認証)**​: ユーザー名とパスワードを使用して API に対する認証を行う場合に使用します。 - **Pass-through (パススルー)**​: 認証ヘッダーを渡して API に対する認証を行う場合に使用します。 - **Client ID enforcement via headers (ヘッダー経由のクライアント ID 適用)**​: `client_id`​ および ​`client_secret`​ ヘッダーを渡して API に対する認証を行う場合に使用します。 - **Client ID enforcement via query parameters (クエリパラメーター経由のクライアント ID 適用)**​: `client_id`​ および ​`client_secret`​ クエリパラメーターを渡して API に対する認証を行う場合に使用します。 - **OAuth 2.0 Client Credentials (OAuth 2.0 クライアントログイン情報)**​: OAuth 2.0 の ​`client_id`​、​`client_secret`​、認証サーバーの値を渡して API に対する認証を行う場合に使用します。 - **Custom (カスタム)**​: カスタムヘッダーパラメーターと値を使用して API に対する認証を行う場合に使用します。 8. 引き続き ​**\[Configure Security (セキュリティを設定)\]**​ ページで、必要に応じてキーストアを追加して API と DataGraph 間の相互認証 (mTLS) を設定します。 **\[Configure Keystore (キーストアを設定)\]**​ を選択して次の情報を指定します。 - 組織の「ルート」認証機関 (CA) によって署名された公開証明書 - 証明書署名要求 (CSR) の生成に使用される非公開キー - 非公開キーのパスワード 9. 必要に応じて、トラストストアを追加して統合スキーマから API へのアクセスを許可します。 **\[Configure Truststore (トラストストアを設定)\]**​ を選択して、ルート CA が含まれる証明書バンドルを指定します。 10. **\[Next: Preview Schema (次へ: スキーマをプレビュー)\]**​ をクリックします。 ## [](#生成された-api-スキーマをプレビューする)生成された API スキーマをプレビューする API の追加後、Anypoint DataGraph によって自動的に API の仕様が対応する API スキーマに変換されます。そのスキーマをプレビューしてから、編集し、競合があれば解決します。 1. **\[Preview Schema (スキーマをプレビュー)\]**​ ページで、API スキーマの種別と項目を確認します。 2. スキーマのプレビューが完了したら、​**\[Next: Edit Schema (次へ: スキーマを編集)\]**​ をクリックします。 ## [](#スキーマを編集して統合スキーマに追加する)スキーマを編集して統合スキーマに追加する API 追加の最期のタスクでは、​[スキーマを編集](https://docs.mulesoft.com/jp/datagraph/edit-schema)​して競合があれば解決し、スキーマを強化します。 1. Anypoint DataGraph でエラーが表示され、競合の解決を促されたら、​**\[Edit Schema (スキーマを編集)\]**​ ページで解決します。 Anypoint DataGraph で表示された競合のプロンプトには推奨解決策が含まれます。 2. 統合スキーマをより強固にするには、API スキーマを (この時点で、または統合スキーマに追加した後に) 編集して次の操作を実行します。 - オブジェクト種別のコラボレーションを有効にする。 該当する種別の​[コラボレーションを有効に](https://docs.mulesoft.com/jp/datagraph/collaboration)​して、必須の設定を指定します。これは省略可能ですが、種別のコラボレーションを有効にすると、作成する統合スキーマの接続や強化が促進されます。 - スキーマ要素の表示を管理する。 統合スキーマに表示したくない​[項目、種別、クエリメソッドを非表示にする](https://docs.mulesoft.com/jp/datagraph/manage-elements-visibility)​ことができます。 - スキーマ要素の名前を確認して編集する。 統合スキーマに追加する​[すべての項目、種別、クエリメソッドの名前を編集](https://docs.mulesoft.com/jp/datagraph/edit-elements-names)​してクエリへの関連性を高めることができます。 - 類似のオブジェクト種別をマージする。 [種別をマージ](https://docs.mulesoft.com/jp/datagraph/manage-merges)​すると、類似の種別を統合して項目とデータセットを拡張し、クエリ結果をより強化できます。 - オブジェクト種別間で関連項目をリンクする。 [リンク](https://docs.mulesoft.com/jp/datagraph/manage-links)​すると、2 つの項目の関連項目を結合し、リンクした種別を照会するときにより広範囲の結果を返すことができます。 3. **\[Next: Add to unified schema (次へ: 統合スキーマに追加)\]**​ をクリックします。 Anypoint DataGraph によって​[統合スキーマが更新](https://docs.mulesoft.com/jp/datagraph/status-updates)​されます。統合スキーマの更新時、スキーマの新しい変更を表示し、追加の変更を加え、新しい変更を適用できます。ただし、これらの変更は更新が完了するまで照会できません。更新には数分かかる場合があります。 ## [](#edit-the-url-for-an-api-added-to-the-unified-schema)スキーマに追加した API の URL を編集する 統合スキーマに追加した API の URL を編集する必要がある場合、​**\[API details (API の詳細)\]**​ ページで編集できます。 1. **\[List of APIs added (追加された API のリスト)\]**​ をクリックし、URL を編集する API を選択します。 2. **\[API details (API の詳細)\]**​ をクリックします。 3. **\[API url (API の URL)\]**​ 項目の横にある ​**\[Edit URL (URL を編集)\]**​ をクリックします。 4. 新しい URL を入力します。 5. **\[Save (保存)\]**​ をクリックします。 ## [](#change-the-authentication-method-for-an-api-added-to-the-unified-schema)統合スキーマに追加された API の認証方法を変更する 統合スキーマに追加した API の認証方法を編集する必要がある場合、​**\[API details (API の詳細)\]**​ ページで編集できます。現在の認証方法を削除して新しい認証方法を追加する必要があります。 認証方法を編集する手順は、次のとおりです。 1. **\[List of APIs added (追加された API のリスト)\]**​ をクリックし、該当する API を選択します。 2. **\[API details (API の詳細)\]**​ をクリックします。 3. **\[Authentication (認証)\]**​ パネルで ​**\[remove and add a new one (削除して新規追加)\]**​ をクリックします。 4. 認証ポリシーを選択し、必須項目に入力します。 5. **\[Save (保存)\]**​ をクリックします。 ## [](#configure-mtls-for-an-api-added-to-the-unified-schema)統合スキーマに追加した API の mTLS を編集する 統合スキーマに追加した API の mTLS を設定する必要がある場合、​**\[API details (API の詳細)\]**​ ページでキーストアを追加して設定できます。 トラストストアを追加して統合スキーマから API へのアクセスを許可することもできます。
API にすでにキーストアまたはトラストストアがある場合、​[API details (API の詳細)]​ ページで削除してから新規追加できます。そのためには、​[Remove and add a new one (削除して新規追加)]​ をクリックします。
1. **\[List of APIs added (追加された API のリスト)\]**​ をクリックし、URL を編集する API を選択します。 2. **\[API details (API の詳細)\]**​ をクリックします。 3. **\[Configure Keystore (キーストアを設定)\]**​ を選択して次の情報を指定します。 - 組織の「ルート」認証機関 (CA) によって署名された公開証明書 - 証明書署名要求 (CSR) の生成に使用される非公開キー - 非公開キーのパスワード 4. 必要に応じて、​**\[Configure Truststore (トラストストアを設定)\]**​ を選択し、ルート CA が含まれる証明書バンドルへのリンクを指定します。 5. **\[Save (保存)\]**​ をクリックします。 ## [](#update-an-api-version)API バージョンを更新する API スキーマを DataGraph に追加したら、いつでも API ソースのバージョンを更新できます。DataGraph でサポートされるのは、​`安定`​状態の API バージョンのみです。更新機能によって更新されるのは、API ソースのパッチおよびマイナーバージョンのみです。

CLI を使用して API ソースを追加する場合は、UI で直接そのバージョンを更新することはできません。これらの変更は CLI を使用して行う必要があります。

API の新しいバージョンを選択すると、新しいバージョンに自動的に適用できない現在のバージョンへの編集が DataGraph にリストされます。 DataGraph で自動的に適用できない編集には、更新を完了する前にそれらの編集を手動で適用するオプションがあります。 1. **\[List of APIs added (追加された API のリスト)\]**​ をクリックし、該当する API を選択します。 2. **\[API details (API の詳細)\]**​ をクリックします。 3. **\[Updated Version (更新バージョン)\]**​ リストから、新しい API バージョンを選択します。 4. **\[Next (次へ)\]**​ をクリックします。 5. DataGraph で適用できない変更が検出された場合、​**\[Existing Edits Not Applied in Updated Schema (更新スキーマに適用されない既存の編集)\]**​ のリストを確認し、手動で適用します。 1. カスタマイズを選択し、​**\[Next (次へ)\]**​ をクリックします。 2. 必要に応じて API スキーマを編集し、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 変更を適用したら、追加の変更に対してステップ 5 を繰り返します。 6. **\[Next (次へ)\]**​ をクリックして、新しいバージョンのスキーマを編集します。 ## [](#関連リソース)関連リソース - [API スキーマの編集](https://docs.mulesoft.com/jp/datagraph/edit-schema) - [Anypoint DataGraph の API コールスケーリング](https://docs.mulesoft.com/jp/datagraph/api-call-scaling) - [Anypoint DataGraph の権限](https://docs.mulesoft.com/jp/datagraph/permissions) - [Anypoint DataGraph でのセキュリティの設定](https://docs.mulesoft.com/jp/datagraph/security) - [troubleshoot-schemas-queries.adoc#potential-errors-when-generating-an-api-schema](https://docs.mulesoft.com/jp/datagraph/troubleshoot-schemas-queries#potential-errors-when-generating-an-api-schema)