Sitecore GraphQL APIのトラブルシューティング
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
このトピックでは、Sitecore GraphQL APIの使用時に発生する可能性のある問題について説明し、これらの問題を回避する方法を提案します。
Windowsでの複数のWebSocket接続のテスト
Windowsデスクトップ オペレーティング システム (Windows 10やWindows 8.1など) 上のIISには、アクティブな接続が10個というハード制限があります。WebSocket接続はこれにカウントされ、永続的です。デスクトップ オペレーティング システムへのソケット接続を持つタブが多数開いている場合、そのIISサーバーへのすべての要求は、ソケット接続が閉じられ (通常はブラウザー タブを閉じることによって)、HTTP (またはソケット) 接続が使用するための使用可能な接続スロットが解放されるまでハングする可能性があります。これに対する回避策は、テスト中に過剰な数のソケットを開かないようにする以外にありません。
WebSocketトランスポート経由でのクエリの実行
WebSocketトランスポート経由で (サブスクリプションではなく) GraphQLクエリを実行できますが、この手法を使用すると、Sitecoreのコンテキストによっては問題が発生する可能性があります。WebSocketクエリとサブスクリプションはバックグラウンド スレッドで実行され、Sitecore.Context.DatabaseまたはSitecore.Context.Siteにはアクセスできません。これは、次のことを意味します。
-
コンテキスト対応のGraphQLエンドポイントは、コンテキストデータベースを解決できません。
-
WebSocket接続で解決されたアイテムURLは、コンテキスト サイトがないため、形式が正しくありません。
HTTP接続経由でクエリを実行し、WebSocketはサブスクリプションにのみ使用することをお勧めします。これにより、最高の互換性が確保され (ソケットをブロックするファイアウォールなどに対して)、デバッグが容易になります (ソケット デバッグ ツールはHTTPツールよりもはるかに成熟していないため)。