ウェブソケット要求の設定

URL

WebSocket 接続を開くには、エンドポイントの WebSocket URL または確認する WebSocket URL の IP アドレスを入力する必要があります (ws:// および暗号化された wss:// プロトコルがサポートされています)。 たとえば、wss://echo.websocket.org/

より視覚的にわかりやすい入力モードをオンにするには、セクションの上部にある 詳細 スイッチをクリックします。

ここで、URL を動的な値またはコンテキスト パラメーターに変換できます。 たとえば、ターゲット URL を動的に変更します。

データの送信

ターゲット エンドポイントにデータを転送する必要がある場合は、[ データの送信 ] フィールドで、文字列形式またはバイナリ形式でメッセージを指定します。 ドットコムモニターは、WebSocket プロトコルを使用してターゲット エンドポイントにメッセージを送信し、応答を待機します。

ドットコムモニターは、WebSocket メッセージで Razor 式をサポートしています。 Razor 式を含む文字列を送信するには、[ データの送信 ] フィールドに文字列を入力し、 準備スクリプト を使用してメッセージの種類を Razor 式に設定します。 それ以外の場合、メッセージは解析され、テキストとして送信されます。 [ スクリプトの準備 ] フィールドで次のスニペットを使用して、メッセージを Razor エンジンで解析する必要があることをシステムに通知します。

ProcessPostDataByRazor(currentTask);

Razor エンジンに加えて、ドットコムモニターを使用すると、データ マスクを使用して要求本文データを動的に変更できます。 送信データで Razor 構文とデータ マスクを使用する方法、および動的に変化するペイロードを構成する方法については、「 HTTP 要求でペイロードを動的に変更する方法」を参照してください。

応答の検証 (コンテンツの検証)

WebSocket から受信したメッセージ文字列を検証するには、呼び出し実行シナリオでキーワードをアサートします。 システムはターゲット エンドポイントからの応答を待機し、受信したメッセージで文字列内に指定されたキーワードが存在するかどうかを確認します。 ソケットからの応答でキーワードが検出されなかった場合は、エラーが生成されます。

[キーワード] フィールドには、応答メッセージで検索する単語または語句を 1 つ指定できます。 プレーンテキストを使用してキーワードを指定します。

キーワードでは大文字と小文字が区別されることに注意してください。

スクリプトとポスト スクリプトの準備

フィールドには、特定の要求や URL データ、またはカスタム ヘッダーの検証や公開に使用できる C# コードを含めることができます。 使用方法の詳細については、「スクリプト の準備とポスト スクリプトの使用 」の記事を参照するか、テクニカル サポートにお問い合わせください。

WebSocket 呼び出し実行の動的シナリオは、[ スクリプトの準備 ] フィールドで指定できます。 動的シナリオには、バイナリ データまたは文字列データを使用した多数の操作を含めることができます。

バイナリ形式の操作 (Base64 エンコードとしてのメッセージ):

  • ValidateBinary(文字列メッセージ) – WebSocket 応答が指定されたバイナリ データと等しいかどうかを確認します。
  • ValidateBinaryContains(文字列メッセージ) – WebSocket 応答に指定されたバイナリ データが含まれているかどうかを確認します。
  • SendBinary(文字列メッセージ) – バイナリメッセージをWebSocketに送信します。

テキスト形式の操作:

  • SendText(文字列メッセージ) – テキスト文字列をウェブソケットに送信します。
  • ValidateText(文字列メッセージ) – WebSocket からの応答が指定された文字列と等しいかどうかを確認します。
  • ValidateTextContains (文字列 msg) – WebSocket 応答に指定された文字列が含まれているかどうかを確認します。
[ スクリプトの準備 ] フィールドにアサーションが指定されている場合、システムは応答で指定されたアサーションを待機し、検証が成功するとスクリプトの実行を続行します。 指定されたアサーションを持つメッセージが受信されず、タスク完了タイムアウトに達した場合、検証エラーが生成されます。

ドットコムモニターを使用すると、準備スクリプトに必要な数の操作を含めることができます。 ただし、テスト タスクの完了タイムアウトに達すると、スクリプトの実行は終了します。

[ データの送信 ] フィールドと [コンテンツの検証 ] フィールドは、[ スクリプトの準備 ] フィールドに動的シナリオの対応するステップが含まれている場合は無視されます。 たとえば、次の手順がスクリプトに含まれている場合、[送信データとコンテンツの検証] フィールドは無視されます。

(currentTask).SendText("This is a test");
(currentTask).ValidateText("This is a test");

currentTask パラメーターはタスク名に関連付けられておらず、現在処理されているタスクを反映しています。

SSL/証明書チェック

セキュアソケットレイヤーSSL証明書チェックには、次の検証オプションが含まれています。

  • [証明機関]: 証明書チェーンに、信頼されているルート証明書が含まれているか、信頼されていないかを確認します。
  • 共通名 (CN): 移動先のアドレスが、そのアドレスが署名されたアドレス証明書と一致していることを検証します。
  • [日付]: 証明書の有効期限を確認します。
  • 失効: 証明書の信頼チェーンに失効した証明書が含まれていないことを検証します。
  • 使用法: 中間証明書の不適切な使用について証明書チェーンを検証します。
  • 有効期限アラーム日数: 証明書の有効期限を通知する通知 (エラー)。
  • クライアント証明書: クライアント証明書名。

時間検証のしきい値 (秒)

サービスが Web ページからの応答を待機してから、要求の実行を終了してエラーを返す秒数を入力します。 これを空白のままにすると、要求の既定のタイムアウトは 60 秒になります。

基本認証

基本認証スキームは、ユーザーが一部の Web サイトのコンテンツにアクセスできるようにするために使用されます。 指定されたログイン資格情報が、要求ヘッダーとともに Web サーバーに渡されます。

  • ユーザー名: HTTP/S の基本認証またはダイジェスト アクセス認証のユーザー名が含まれています。
  • ユーザーパスワード: HTTP/S基本認証またはダイジェストアクセス認証のパスワードが含まれています。

基本認証は、ベアラー トークンを含むベアラー認証やアクセス トークンを使用する OAuth 2.0 などの他の認証スキームと混同しないでください。

詳細については、基本認証ユーザー名とパスワードおよびモニタリング OAuth 2.0 ベースの API に関する記事を参照してください。

ヘッダー

このオプションを使用すると、必要に応じてカスタムヘッダーを追加できます。

  • ヘッダー名: 要求に表示されるパラメーターの名前を指定します。
  • : パラメータの名前に関連付けられた値を入力します。

DNS オプション

DNS オプション機能を使用すると、監視タスク中にドメイン ネーム サーバー (DNS) 要求を実行する方法をユーザーが選択できます。

ホスト名の解決モードを指定するには 、[DNS 解決モード] セクションで、使用可能なモードのいずれかを選択します。 機能の構成の詳細については 、「DNS モード オプション」を参照してください。

[カスタム DNS ホスト]セクションには、IP アドレスとホスト名のマッピングが含まれています。

マッピングを指定するには、対応するフィールドに IP アドレスとホスト名を入力します。

例:

192.168.107.246 example.com user.example.com userauth.example.com tools.example.com
192.168.107.246 example.com
192.168.107.246 user.example.com
192.168.107.246 userauth.example.com

参照 : DNS モード オプション

エラーフィルタ

特定のエラーの種類とコードを無視するようにフィルターを設定できます。 [エラー フィルター ] セクションでは、ユーザーが構成できる特定のエラーを除外できます。 たとえば、DNS サーバーの操作の責任者に基づいて DNS エラーを除外できます。 特定のデバイスの目標に関連しない、発生する可能性がある特定のエラーを無視するフィルターを作成できます。

さらに、ダッシュを使用してエラー コードの範囲を無視するようにシステムを設定したり、セミコロンを区切り文字として使用する複数のエラー コードを無視することもできます。

たとえば、特定のデバイスで 404 個のエラーを気にしていない場合は、検出されたアラートを受信しないようにフィルター処理できます。

エラーがフィルター条件に一致する場合、エラーはレポートに反映されず、追跡できないことに注意してください。