---
title: "Sitecore GraphQL APIのトラブルシューティング"
slug: "troubleshooting-the-sitecore-graphql-api"
abstract: "Sitecore GraphQL APIを使う際に注意すべきいくつかのシナリオを説明します。"
---
# Sitecore GraphQL APIのトラブルシューティング

このトピックでは、Sitecore GraphQL APIを使う際の潜在的な問題について説明し、それらの問題を回避する方法を提案します。

## Windows上で複数のWebSocket接続をテストする

WindowsデスクトップOS(Windows 10やWindows 8.1など)のIISには、アクティブな接続数が10回までという厳密な制限があります。WebSocket接続はこの制限にカウントされ、永続的です。もし多くの開いているタブレットで、デスクトップOSへのソケット接続がある場合、そのIISサーバーへのすべてのリクエストは、ソケット接続が閉じられるまで(通常はブラウザタブを閉じて)停止し、HTTP(またはソケット)接続用の利用可能な接続スロットを空けることがあります。この問題に対する回避策は、テスト中に過剰なソケットを開かないようにするためです。

## WebSocketトランスポート上でのクエリ実行

WebSocketトランスポート上で(サブスクリプションではなく)GraphQLクエリを実行することもできますが、この手法を使うとSitecoreコンテキストによっても問題が発生することがあります。WebSocketクエリやサブスクリプションはバックグラウンドスレッド上で実行され、Sitecore.Context.DatabaseやSitecore.Context.Siteへのアクセスはありません。つまり、以下の通りです:

-   コンテキスト認識型GraphQLエンドポイントはコンテキストデータベースを解析できません。
-   WebSocket接続で解決されたアイテムURLは、コンテキストサイトがないため形が歪んでいます。

HTTP接続上でクエリを実行し、サブスクリプションのみにWebSocketを使うことをお勧めします。これにより、ソケットをブロックするファイアウォールとの互換性が最大化され、デバッグも容易になります(ソケットデバッグツールはHTTPツールほど成熟していないためです)。