In this section:

Introduction

Message Responders are tools that determine which response a should be sent when a the virtual asset receives a request. Virtual assets can host several several Message Responders. You can configure responders to send specific messages to specific requests based on a set of correlation criteria. You can manually configure different request/response use cases or automate them based on data sources, error conditions, delays, and so forth.

The Virtualize desktop supports a variety of Message Responder types (see Virtualization Tools), but CTP currently supports Literal Message Responders.  This functionality is intended to provide a fast way to create new Message Responders that can be configured by specifying a literal message, such as a sample message you paste in and adapt. For more advanced functionality, open the related .pva in Virtualize Desktop.

Adding a Message Responder

To add a new Message Responder tool:

1. Choose a .pva or responder suite where you want to add the new Message Responder.
2. Choose Add Literal Message Responder from the action menu.
    
3. (Optional) Modify the name of the newly-created tool.
4. Configure the tool as described below.
5. Save the new tool configuration.

The new responder will be added at the end of the selected responder suite.

Configuring a Message Responder

1. If the virtual asset is associated with multiple data sources, choose the data source you to use for your responses from the Data source drop-down menu. Data sources has the data used to parameterize the responder. Refer to Parameterizing with Data Source and Data Bank Values for information about data sources.
   
2. (Optional) Configure the response code and message. By default, a 200 code and OK message are used, but you can click in either field and enter a new message. 
   • The Message field will automatically populate with standard messages when common response codes are entered into the status field.
     
   • You can override the pre-populated message.
     
   • The default 200 status code will be used if the value of the Status field is deleted. The Message field is not required.
3. (Optional) Add HTTP headers in the Response area.
   1. Click Add.
   2. Specify a header name (this is case insensitive) and value. You can enter values in either table mode or literal mode.
      
      Literal example:
      
      Table example:
      
4. Set the appropriate payload format and media type (in the Content type and MIME type boxes).
   

5. Specify the payload in literal text editor, the JSON editor, or the XML editor (see Editing JSON Messages and Editing XML Messages for details and tips).
   
   
   
   

   Using Variables

   If you’re familiar with Virtualize or SOAtest, you can use the standard ${var_name} notation to reference variables and data source values that are defined for the responder suite. Start typing a dollar sign and curly brace (${) into field and the available variables will appear in a tooltip.

   

   See Working with Variables for additional information.

   JSON fields require a special notation for parameterizing a number or boolean field: 

   ${number:<value>} or ${boolean:<value>}

   For example, to parameterize a number field with the column Count, you would use ${number:Count}.

6. Configure correlations as described in Configuring Responder Correlations.

7. (Optional) Specify a request URL template. Enter a URL that is typical/representative of the URLs that the application under test would serve (and the responder should simulate). If the responder is created through the traffic wizard, this field will be populated with the URL from one of the requests in the traffic corresponding to this responder. 

   The value specified here will be used to configure URL Paths and URL Parameters correlation settings for responder correlations and data source correlations.

8. (Optional) Specify a request message template. This template will be used to automatically populate the expected response when generating XPath parameters in Virtualize (e.g. in the message request XPath dialogs for data source correlation and responder correlation or in the multiple response XPath dialog).

• • When a Message Responder is created from traffic logs, the Request Message Template is generated automatically. The largest request message identified in the Traffic Log is used for this purpose.
  • When a Message Responder is NOT created from traffic logs, the template will be empty. In this case, you can manually modify the Request Message Template through the Literal Editor or XML Editor (e.g., by copying in a sample request message that correlates with the response message you’re configuring). See Editing XML Messages for details and tips.
  • If the request message template is empty, it will be updated when you first select a value from the XPath builder (described in Specifying XPaths).
  • The completed Request Message Template is used to populate the views in the Edit XPath Function dialogs available from the Message Responder in Virtualize desktop. The XML Data Bank and XML Transformer output in Virtualize desktop will also use the template if it is attached to the Message Responder as a Request output.