Sitecore GraphQL APIのトラブルシューティング
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
このトピックでは、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ツールほど成熟していないためです)。