Incoming messages are delegated through a chain of correlation logic to route messages to the proper response message. The multi-layered approach to correlating incoming messages to response messages provides flexibility and power in modeling dynamic and realistic virtual assets that behave in the same way as the real assets and do so in a manner than scales well.

When an incoming message is received, the following occurs:

1. Virtual asset selection: A deployed virtual asset is selected to respond to the message based on the HTTP path, JMS/MQ queue names, or other extension/custom criteria that is configured in each virtual asset configuration. A virtual asset corresponds to a .pva, so this step effectively determines which .pva file will be used to respond to that message. If no virtual asset is found to respond to that message, then an error message is returned to the requester. If two virtual assets are deployed on the same HTTP path, Virtualize will choose one that has a responder with matching correlation criteria.
   • For HTTP and HTTPS, the path is matched against the defined prefix. 
   • For JMS and MQ, messages are always picked up off the queue. 
   • For Custom Transports, listener settings are sent to the user’s code.
   • If no virtual assets correlate to the incoming request, an error message is returned.
     
     
2. Responder selection: A responder is selected among the responders in the responder suite of the virtual asset’s .pva file. Responders are evaluated sequentially, in a depth-first search pattern within the virtual asset. Once a Responder Correlation criteria matches the incoming message (see Responder Correlation Tab), this responder will be used to respond to the message and the correlation moves on to the next step.
   • Responders are checked in order (from top to bottom). 
   • Responder Correlation is used to determine if a responder should be used. 
   • If no responders correlate to the incoming request, an error message is returned. 
   • Responders with no correlation configured will always match – these can be used as ‘catch-all’ or ‘default’ responders.
     
     
3. Response: The response is built and populated using data source correlations. 

• • Values in the incoming message are compared (matched literally or with an expression) to values in a data source and the responder uses the matching row data to create a response message. 
  • If no data source row matching the specified incoming message value is found, then (with the default failover settings) Virtualize will continue searching the responder suite for a responder with matching responder correlation. An error will be reported if no responders meet the responder correlation criteria.
  • Any time that a data source correlation fails for a responder whose failover option is disabled, an error will be reported immediately and Virtualize will stop searching for matching responders. 
  • When an error is returned to the requester, an error event is also logged into the Event Messages view (if monitoring of the virtual asset is enabled).
  • If using Multiple Responses mode, the specified conditions are used to select a response message is selected from the list of responses. Select request message fields are evaluated against the matching criteria of each response within the Multiple Responses mode response message list and the first matching one is returned. If no matching message is found then an error message is returned to the requestor, and an error is logged to the Event Details view (if monitoring of the virtual asset is enabled as described in Gaining Visibility into Server Events).
  • Otherwise, the response is built and populated using Data Source Correlation (if parameterized via data source correlation) or with static values (if not parameterized). When data source correlation is used (see Data Source Correlation Tab), values in the incoming message are compared (matched literally or with an expression) to values in a data source and the responder uses the matching row data to create a response message. If no data source row is found matching the specified incoming message value, then (with the default failover settings) Virtualize will continue searching the responder suite for a responder with matching responder correlation. An error will be reported if no responders meet the responder correlation criteria. Moreover, any time that a data source correlation fails for a responder whose failover option is disabled, an error will be reported immediately and Virtualize will stop searching for matching responders. When an error is returned to the requester, an error event is also logged into the Event Details view (if monitoring of the virtual asset is enabled as described in Gaining Visibility into Server Events).
  • In the case of a SQL Responder, the incoming query is matched to a template and the corresponding parameter values (See Creating SQL Responders from a Database Recording for details).
  • Virtualize treats body content sent in form URL encoded POST requests as URL parameters, rather than putting them into the request body. This enables greater flexibility to create correlations based on individual parameters.