gRPC requests#

gRPC is an open source framework for remote procedure calls. gRPC includes:

  • Protocol Buffers (Protobuf) data serialization standard

  • HTTP/2 data transfer protocol

  • Interface Definition Language

Before adding a gRPC request to the test, import a PROTO file that contains a description of methods for remote procedure calls.

Import PROTO file#

  1. In the Import data pane, click grpc_button. The dialog opens:

    ../_images/um_protobuffer.en.png
  2. Click to upload file.

  3. Select the PROTO file. The file size shouldn’t exceed 100 MB.

  4. Click Close.

Add gRPC request#

  1. Go to the group or click edit_button. The editor opens:

    ../_images/um_editor.en.png
  2. Use Drag & Drop to move the gRPC request element into the transaction.

  3. Expand the transaction:

    ../_images/um_transaction_grpc.png
  4. Go to the gRPC request or click edit_button. The dialog opens:

    ../_images/um_grpc_parametres.en.png
  5. Enter the request URL.

  6. Click SSL_TLS_button to disable SSL/TLS certificate verification if needed.

  7. Select a method from the PROTO file.

  8. Enter the name of the request manually or using the buttons:

    • copy_url_button copies the request URL to the Name field.

    • copy_path_button copies the request path to the Name field.

    • copy_url_without_params_button copies the request URL without parameters to the Name field.

  9. Go to the required tab and edit the data:

  10. Click Save.

Metadata#

../_images/um_grpc_parametres.en.png

To add a metadata, follow these steps:

  1. Enter the name of the parameter in the Key field. To enter the name of the parameter in the format ${expression}, click P and select the parameter. Don’t use spaces in the parameter name.

  2. Enter the value of the parameter in the Value field. To enter the name of the parameter in the format ${expression}, click P and select the parameter.

    ../_images/um_select_parameter.png

    You can select the parameters with the P button, if you have added these parameters in the test. For more information, see Add and use parameters.

To delete a parameter, click delete_button.

Body#

../_images/um_grpc_body.en.png

Add the request body.

Click the Beautify Mode toggle for convenient viewing and further editing of the request body in JSON format:

../_images/um_request_body_beatify.en.png

Extract from response#

../_images/um_grpc_extract_from_response.en.png

PFLB Platform lets you extract values from the response, for example, to get the session token. If the response contains values corresponding to the specified expression or boundaries, then the values are written to the variable. You can use the value of the variable as a parameter in the following test requests.

To extract values from the response, select the value from the drop-down list:

  • Regex. Regular expression.
    1. Fill in the fields:

      • Variable name. The variable into which the parsing results are saved.

      • Regular expression. For more information, see Regular expression syntax cheatsheet and Examples of using regular expressions.

      • Group’s number. The group to be extracted from the regular expression. For example, 1 value extracts the first group value. The default is 0 value, used to extract the whole regexp.

    2. Select the field from which you need to extract the values:

      • Body. The response body without headers.

      • Request headers.

      • Response code. For example, 200.

      • Response message.

      • Url. Request URL.

    3. Select the value from the drop-down list:

      • Random match. To select any of the values.

      • Specific match. To select a particular value.

      • All matches. To select all values. As a result, an array of values is formed: Param_1, Param_2, Param_n, where Param is the name of the variable, and n is the size of the array.

        Note

        When using the extracted parameter, manually specify the sequence number of the occurrence: ${param_n}, where n is the sequence number of the occurrence. If you use such a parameter or header without specifying the occurrence number, an empty value is sent.

  • jSONPath. Request to JSON file elements.
    1. Fill in the fields:

    2. Select the value from the drop-down list:

      • Random match. To select any of the values.

      • Specific match. To select a particular value.

      • All matches. To select all values. As a result, an array of values is formed: Param_1, Param_2, Param_n, where Param is the name of the variable, and n is the size of the array.

        Note

        When using the extracted parameter, manually specify the sequence number of the occurrence: ${param_n}, where n is the sequence number of the occurrence. If you use such a parameter or header without specifying the occurrence number, an empty value is sent.

  • XPath. Request to XML document elements.
    1. Fill in the fields:

    2. Select the value from the drop-down list:

      • Random match. To select any of the values.

      • Specific match. To select a particular value.

      • All matches. To select all values. As a result, an array of values is formed: Param_1, Param_2, Param_n, where Param is the name of the variable, and n is the size of the array.

        Note

        When using the extracted parameter, manually specify the sequence number of the occurrence: ${param_n}, where n is the sequence number of the occurrence. If you use such a parameter or header without specifying the occurrence number, an empty value is sent.

  • Boundary. JMeter Boundary Extractor allows you to extract values from a server response using left and right boundaries. For more information, see JMeter Documentation and Example of using boundaries.
    1. Fill in the fields:

      • Variable name. The variable into which the parsing results are saved.

      • Left border. Left boundary of value to find. This is an optional field.

      • Right border. Right boundary of value to find. This is an optional field.

    2. Select the field from which you need to extract the values:

      • Body. The response body without headers.

      • Request headers.

      • Response code. For example, 200.

      • Response message.

      • Url. Request URL.

    3. Select the value from the drop-down list:

      • Random match. To select any of the values.

      • Specific match. Enter a particular value. The occurrence numbers start with 1.

      • All matches. To select all values. As a result, an array of values is formed: Param_1, Param_2, Param_n, where Param is the name of the variable, and n is the size of the array.

        Note

        When using the extracted parameter, manually specify the sequence number of the occurrence: ${param_n}, where n is the sequence number of the occurrence. If you use such a parameter or header without specifying the occurrence number, an empty value is sent.

To delete a setting, click delete_button.

Assertions#

../_images/um_grpc_assertions.en.png

Assertions are used to check a request, response, or URL for compliance with specified conditions, for example, the presence of the string in the response.

If at least one of the Assertions conditions isn’t met, the request is considered erroneous.

You can check the Assertions results in Grafana dashboard.

To configure Assertions, select the scope:

  • Request body.
    1. Select the type of condition:

      • Equals. The assertion is successful if the entire body of the request matches the specified string completely. Case-sensitive.

      • Not equals. The assertion is successful if the request body doesn’t match the specified string. Case-sensitive.

      • Not substring. The assertion is successful if the request body doesn’t contain the specified string. Case-sensitive.

      • Regexp contains. The assertion is successful if the request body contains a string that matches the regular expression pattern.

      • Regexp matches. The assertion is successful if the entire request body fully matches the regular expression pattern.

      • Regexp not contains. The assertion is successful if the request body doesn’t contain a string that matches the regular expression pattern.

      • Regexp not matches. The assertion is successful if the entire request body doesn’t match the regular expression pattern.

      • Substring. The assertion is successful if the request body contains the specified string. Case-sensitive.

    2. Specify a string or regular expression.

    For example, let’s check that the request body contains the name parameter:

    ../_images/um_request_body_example.png
  • Request metadata.
    1. Select the type of condition:

      • Equals. The assertion is successful if all the request metadata matches the specified string completely. Case-sensitive.

      • Not equals. The assertion is successful if the request metadata doesn’t match the specified string. Case-sensitive.

      • Not substring. The assertion is successful if the request metadata doesn’t contain the specified string. Case-sensitive.

      • Regexp contains. The assertion is successful if the request metadata contains a string that matches the regular expression pattern.

      • Regexp matches. The assertion is successful if all the request metadata fully matches the regular expression pattern.

      • Regexp not contains. The assertion is successful if the request metadata doesn’t contain a string that matches the regular expression pattern.

      • Regexp not matches. The assertion is successful if all the request metadata doesn’t match the regular expression pattern.

      • Substring. The assertion is successful if the request metadata contains the specified string. Case-sensitive.

    2. Specify a string or regular expression.

    For example, let’s check the value of the request ID:

    ../_images/um_request_metadata_example.png
  • Response body.

    Select the value from the drop-down list:

    • No filter. JSONPath and Xpath filters are not used:

      1. Select the type of condition:

        • Equals. The assertion is successful if the entire response body matches the specified string completely. Case-sensitive.

        • Not equals. The assertion is successful if the response body doesn’t match the specified string. Case-sensitive.

        • Not substring. The assertion is successful if the request body doesn’t contain the specified string. Case-sensitive.

        • Regexp contains. The assertion is successful if the response body contains a string that matches the regular expression pattern.

        • Regexp matches. The assertion is successful if the entire response body fully matches the regular expression pattern.

        • Regexp not contains. The assertion is successful if the response body doesn’t contain a string that matches the regular expression pattern.

        • Regexp not matches. The assertion is successful if the entire response body doesn’t match the regular expression pattern.

        • Substring. The assertion is successful if the response body contains the specified string. Case-sensitive.

      2. Specify a string or regular expression.

      For example, let’s check that the response body contains the name parameter:

      ../_images/um_response_body_nofilter_example.png
    • JSONPath. JSONPath is a query language for JSON. For more information, see JSON path syntax in detail:

      1. Specify the JSONPath expression.

      2. Select the type of condition:

        • Equals. The assertion is successful if the entire response body matches the specified string completely. Case-sensitive.

        • Exists. The assertion is successful if the JSONpath exists.

        • Is not null. The assertion is successful if the value isn’t equal to null.

        • Is null. The assertion is successful if the value is equal to null.

        • Not equals. The assertion is successful if the response body doesn’t match the specified string. Case-sensitive.

        • Not exists. The assertion is successful if the JSONpath doesn’t exist.

        • Regexp matches. The assertion is successful if the entire response body fully matches the regular expression pattern.

        • Regexp not matches. The assertion is successful if the entire response body doesn’t match the regular expression pattern.

      3. Specify a string or regular expression.

      For example, let’s check that the price of the first phone in the response body is not null:

      ../_images/um_response_body_json_example.png
    • XPath. XPath is a query language for XML. For more information, see XPath Syntax:

      1. Select the type of condition:

        • Matches. The assertion is successful if the response body matches the XPath expression.

        • Not matches. The assertion is successful if the response body doesn’t match the XPath expression.

      2. Specify the XPath expression.

      For example, let’s check the phone name in the response body with id=1:

      ../_images/um_response_body_xpath_example.png
  • Response body size.
    1. Select the type of condition.

    2. Specify the expected size of the response body in bytes. For example:

      ../_images/um_response_body_size_example.png
  • Response code.
    1. Select the type of condition:

      • Equals. The assertion is successful if the entire response code matches the specified string completely. Case-sensitive.

      • Not equals. The assertion is successful if the response code doesn’t match the specified string. Case-sensitive.

      • Not substring. The assertion is successful if the response code doesn’t contain the specified string. Case-sensitive.

      • Regexp contains. The assertion is successful if the response code contains a string that matches the regular expression pattern.

      • Regexp matches. The assertion is successful if the entire response code fully matches the regular expression pattern.

      • Regexp not contains. The assertion is successful if the response code doesn’t contain a string that matches the regular expression pattern.

      • Regexp not matches. The assertion is successful if the entire response code doesn’t match the regular expression pattern.

      • Substring. The assertion is successful if the response code contains the specified string. Case-sensitive.

    2. Specify a string or regular expression. For example:

      ../_images/um_response_code_example.png
  • Response code size.
    1. Select the type of condition.

    2. Specify the expected size of the response code in bytes. For example:

      ../_images/um_response_code_size_example.png
  • Response document. The text of the document returned by the web server. For a list of supported document formats, see Apache Tika Supported Document Formats.
    1. Select the type of condition:

      • Equals. The assertion is successful if the entire document text matches the specified string completely. Case-sensitive.

      • Not equals. The assertion is successful if the document text doesn’t match the specified string. Case-sensitive.

      • Not substring. The assertion is successful if the document text doesn’t contain the specified string. Case-sensitive.

      • Regexp contains. The assertion is successful if the document text contains a string that matches the regular expression pattern.

      • Regexp matches. The assertion is successful if the entire document text fully matches the regular expression pattern.

      • Regexp not contains. The assertion is successful if the document text doesn’t contain a string that matches the regular expression pattern.

      • Regexp not matches. The assertion is successful if the entire document text doesn’t match the regular expression pattern.

      • Substring. The assertion is successful if the document text contains the specified string. Case-sensitive.

    2. Specify a string or regular expression.

    For example, let’s check that the document contains the string <html>:

    ../_images/um_response_document_example.png
  • Response duration.
    1. Select the type of condition.

    2. Specify the expected response time to the request in milliseconds.

    For example, let’s check that the response time does not exceed 5 seconds:

    ../_images/um_response_duration_example.png
  • Response full size.
    1. Select the type of condition.

    2. Specify the expected size of the metadata and the response body in bytes. For example:

      ../_images/um_response_full_size_example.png
  • Response message.
    1. Select the type of condition:

      • Equals. The assertion is successful if the entire response message matches the specified string completely. Case-sensitive.

      • Not equals. The assertion is successful if the response message doesn’t match the specified string. Case-sensitive.

      • Not substring. The assertion is successful if the response message doesn’t contain the specified string. Case-sensitive.

      • Regexp contains. The assertion is successful if the response message contains a string that matches the regular expression pattern.

      • Regexp matches. The assertion is successful if the entire response message fully matches the regular expression pattern.

      • Regexp not contains. The assertion is successful if the response message doesn’t contain a string that matches the regular expression pattern.

      • Regexp not matches. The assertion is successful if the entire response message doesn’t match the regular expression pattern.

      • Substring. The assertion is successful if the response message contains the specified string. Case-sensitive.

    2. Specify a string or regular expression.

    For example, let’s check that the response message contains the Not found text:

    ../_images/um_response_message_example.png
  • Response message size.
    1. Select the type of condition.

    2. Specify the expected size of the response message in bytes. For example:

      ../_images/um_response_message_size_example.png
  • Response metadata.
    1. Select the type of condition:

      • Equals. The assertion is successful if all the response metadata matches the specified string completely. Case-sensitive.

      • Not equals. The assertion is successful if the response metadata doesn’t match the specified string. Case-sensitive.

      • Not substring. The assertion is successful if the response metadata doesn’t contain the specified string. Case-sensitive.

      • Regexp contains. The assertion is successful if the response metadata contains a string that matches the regular expression pattern.

      • Regexp matches. The assertion is successful if all the response metadata fully matches the regular expression pattern.

      • Regexp not contains. The assertion is successful if the response metadata doesn’t contain a string that matches the regular expression pattern.

      • Regexp not matches. The assertion is successful if all the response metadata doesn’t match the regular expression pattern.

      • Substring. The assertion is successful if the response metadata contains the specified string. Case-sensitive.

    2. Specify a string or regular expression.

    For example, let’s check the value of the request ID:

    ../_images/um_response_metadata_example.png
  • Response metadata size.
    1. Select the type of condition.

    2. Specify the expected size of the response metadata in bytes. For example:

      ../_images/um_response_metadata_size_example.png
  • URL Sampled. It is used to check that there was no redirect during the request execution, and the URL remained the same.
    1. Select the type of condition:

      • Equals. The assertion is successful if the entire URL matches the specified string completely. Case-sensitive.

      • Not equals. The assertion is successful if the URL doesn’t match the specified string. Case-sensitive.

      • Not substring. The assertion is successful if the URL doesn’t contain the specified string. Case-sensitive.

      • Regexp contains. The assertion is successful if the URL contains a string that matches the regular expression pattern.

      • Regexp matches. The assertion is successful if the entire URL fully matches the regular expression pattern.

      • Regexp not contains. The assertion is successful if the URL doesn’t contain a string that matches the regular expression pattern.

      • Regexp not matches. The assertion is successful if the entire URL doesn’t match the regular expression pattern.

      • Substring. The assertion is successful if the URL contains the specified string. Case-sensitive.

    2. Specify a string or regular expression.

    For example, let’s check that the URL is a link to a product in an online store:

    ../_images/um_url_sampled_example.png

To delete a setting, click delete_button.

Timers#

../_images/um_grpc_timers.en.png

The deadline is the maximum time clients will have to wait for an RPC to be completed. Change it, if needed. Specified in seconds.

To add a timer, select the value from the drop-down list:

  • Constant. The delay before sending the request by Virtual Users. Specified in seconds.

  • Random. Before each attempt to send a request, PFLB Platform calculates a random delay time. Enter a range of numbers within which a random delay time is selected. Specified in seconds.

By default, a default timer is enabled for all test requests. You can change or turn off the default timer. The default timer is always displayed, even if it is turned off. For more information, see Configure timers.

To delete the timer, click delete_button.