How to Create Devices and Targets
WebSocket is a communication protocol that works over TCP and is 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
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.
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 text. Use the following snippet in the Prepare Script field to notify the system that it must parse the message with the Razor engine:
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 phrase that you wish to search for in the response message. Use the plain text to specify a 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 to 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 to a specified string.
- ValidateTextContains(string msg) – checks if a WebSocket response contains a 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, we will generate the validation error.
Dotcom-Monitor allows you to include as many operations as necessary in the Prepare script. However, if the task completion timeout is reached the script execution will be terminated.
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.
Time Validation Threshold (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 60 seconds.
The Basic Authentication scheme is 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.
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.
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 allows to set up the mapping of IP addresses to hostnames. IPv6 and IPv4 DNS resolution is supported.
To specify the mapping, enter the IP address and the hostname in the corresponding fields.
See also: DNS Mode Options.