How to Сreate Devices and Targets

WebSocket is a communication protocol that works over TCP and designed to exchange messages between a browser and a web server in real-time. The browser (client) and server use a protocol similar to HTTP to establish a WebSocket connection.

For more information about the WebSocket protocol and WebSocket-based application monitoring, please visit the Dotcom-Monitor blog.

A WebSocket device created in the Dotcom-Monitor platform checks a single WebSocket URL for availability, performance, proper content, and errors. The monitoring device can also be configured to validate security certificates and response content.

Configuring a Request

URL

To open a WebSocket connection, you are required to enter the WebSocket URL of the endpoint or IP address of the WebSocket URL you wish to check (the ws:// and encrypted wss:// protocols are supported). For example, wss://echo.websocket.org/

To turn on a more visually-friendly input mode, click the Detailed switch on the top of the section.

You can convert the URL to a dynamic value or context parameter here. For example, you can dynamically change the target URL while monitoring.

Send Data

Once the connection has been opened, Dotcom-Monitor listens to the events in the socket. If you need to transfer data to the target endpoint, in the Send Data field, specify a message in a string or binary format. Dotcom-Monitor will send the message to the target endpoint using the WebSocket protocol and wait for the response.

Dotcom-Monitor supports Razor expressions in the WebSocket messages. To send a string that contains a Razor expression, enter it in the Send Data field and use the Prepare Script to set the message type to Razor expression. Otherwise, the message will be parsed and sent as a text. Use the following snippet in the Prepare Script field to notify the system that the message must be parsed with the Razor engine:

ProcessPostDataByRazor(currentTask);

In addition to the Razor engine, Dotcom-Monitor enables dynamically changing request body data by using data masks. To learn how to use the Razor syntax and data masks in sent data, and configure dynamically changing payload, see How to Dynamically Change Payload in HTTP Request.

Response Validation (Content Validation)

To validate a message string received from the WebSocket, you can assert keywords in the call execution scenario. The system will wait for the response from the target endpoint, and check the received message for the presence of the specified keyword in the string until the monitoring task completion timeout is reached. If the keyword was not detected in the responses from the socket, an error will be generated.

In the Keyword fields, you can specify one word or a phrase that you wish to search for in the response message.

Note that a keyword is case-sensitive.

A valid keyword expression must include the start and end brackets as follows:

{["keyword"]}

Prepare Script and Post Script

The fields can contain C# code, which can be used for specific requests and URL data or for validating or publishing custom headers. Please see the Using Prepare Script and Post Script article or contact technical support for more details on usage.

The dynamic scenario of the WebSocket call execution can be specified in the Prepare Script field. The dynamic scenario can include a number of operations with binary or string data.

Binary formatted operations (msg as Base64 encoded):

  • ValidateBinary(string msg) – checks if a WebSocket response is equal specified binary data.
  • ValidateBinaryContains(string msg) – checks if a WebSocket response contains specified binary data.
  • SendBinary(string msg) – sends a binary message to a WebSocket.
Text formatted operations:
  • SendText(string msg) – sends a text string to a WebSocket.
  • ValidateText(string msg) – checks if a response from a WebSocket is equal specified string.
  • ValidateTextContains(string msg) – checks if a WebSocket response contains specified string.

In cases where any assertion was specified in the Prepare Script field, the system will wait for the specified assertion in the response and proceed with the script execution once the validation is successful. If a message with the specified assertion is not received, and the task completion timeout is reached, the validation error will be generated.

Dotcom-Monitor allows you to include as many operations as necessary to the prepare script. However, if the task completion timeout is reached the script execution will be terminated.

Note that the Send Data and Content Validation fields are ignored if the Prepare Script field contains corresponding steps in the dynamic scenario. For example, if the following steps are included in the script the Send Data and Content Validation field will be ignored:

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

Where the currentTask parameter does not depend on a task name and has the type of the task that is currently processed.

SSL/Certificate Check

Secure Socket Layer SSL Certificate Monitoring is a standard aspect of web monitoring.

The following options are available:

  • Authority: verifies whether a certificate chain contains a root certificate that is trusted, or not trusted.
  • Common Name (CN): validates that an address you navigate to matches the address certificate the address was signed to.
  • Date: verifies the certificate expiration date.
  • Revocation: validates that the certificate’s chain of trust doesn’t contain a revoked certificate.
  • Usage: verifies a certificate chain for the improper use of an intermediate certificate.
  • Expiration Reminder in Days: a reminder that notifies (as an error) about certificate expiration.
  • Client Certificate: client certificate name.

Completion Timeout (in seconds)

Enter the number of seconds the task should wait for a response from the web page before ending the task and returning an error. If this is left blank the default timeout for a task is 120 seconds.

Basic Authentication

The Basic Authentication scheme s used to allow users to access content on some websites. Once provided login credentials will be passed along with the request header to the web server.

  • Username: contains a username for HTTP/S basic or digest access authentication.
  • User Password: contains a password for HTTP/S basic or digest access authentication.

Do not confuse Basic Authentication with other authentication schemes such as Bearer Authentication that involves bearer tokens and OAuth 2.0 that uses access tokens.

Read the articles on Basic Authentication Username and Password and Monitoring OAuth 2.0-based APIs for more information.

Headers

The option enables adding any additional custom headers if it is necessary.

  • Header Name: specify the name of the parameter as it will appear in the request.
  • Value: enter the value associated with the name of the parameter.

DNS Options

The DNS Options feature allows users to choose how domain name server (DNS) requests are conducted during a monitoring task.

To specify the mode of resolving hostnames, in the DNS Resolve Mode section, select one of the available modes. For more details on the feature configuration, see DNS Mode Options.

The Custom DNS Hosts section contains the mappings of IP addresses to hostnames.

To specify the mapping, enter the IP address and the host name in the corresponding fields.

Examples:

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

See also: DNS Mode Options.