Responder correlations determine which messages a Message Responder tool accepts and processes. Various messages sent to the virtual asset URL are routed to specific Message Responder tools (each of which handle different operations) based on the settings here. For example, one Message Responder tool might respond to customer registration messages, another might respond to payment messages, and another might function as a default "catch all" that is used when none of the others match.

Configuring Correlations

To configure responder correlations in CTP:

In the left pane, select the responder whose correlation you want to configure.
Use the controls in the Correlations area to specify which correlations you want applied. You can configure one type of correlation, multiple types of correlation, or no correlations. If no correlations are configured, everything in the message will be processed. Correlation types are described below.

Transport Correlation

Transport correlations allow you to specify HTTP Headers, JMS message properties, or MQ message fields within the message that will determine whether or not the message is processed by this particular responder.

To configure a transport correlation:

Select the Transport headers check box.
Click the Add button. A new entry row displays.
Enter the Name and Value of the transport correlation you would like to specify. If you want to match all messages that include this header name (no matter what value it is are set to), use [*].

Request Body Correlation

Request body correlations allow you to specify XPaths within the message that will determine whether or not the message is processed.

To configure request body correlations:

Select the Request body check box.
Click the Add button. A new entry row displays and the XPath builder opens.
Provide an XPath expression to indicate the request body that you want to match. You can specify XPaths using the XPath builder (described in Specifying XPaths), or by directly entering the XPath in the XPath text field using the standard XPath 1.0 standard by W3C.
Repeat steps 2 and 3 as needed until all XPaths that you want to match are specified.

URL Path Correlation

URL path correlations allow you to specify URL paths that will determine whether or not the message is processed. URL path correlations apply to virtual assets that will be accessed over HTTP/HTTPS.

To configure a URL path correlation:

Select the URL path check box.
Specify the path you want to use for correlation.

For example, assume that a virtual asset is deployed under the path http://myvirtserver:9080/MyAsset/MyPath and the path /segment1/segment2/** is specified in the responder correlation.

The following URLs will match this correlation criteria:

http://myvirtserver:9080/MyAsset/MyPath/segment1/segment2
http://myvirtserver:9080/MyAsset/MyPath/segment1/segment2/
http://myvirtserver:9080/MyAsset/MyPath/segment1/segment2/segment3?param1=value1&param2=value2

The following URLs will NOT match:

http://myvirtserver:9080/MyAsset/MyPath/segment1/
http://myvirtserver:9080/MyAsset/MyPath/segment3/segment1/segment2

Ant-style wildcards can be used, where * matches zero or more characters and ** matches zero or more directories. Using this format:

/**/abc matches /abc or /this/that/abc
/abc/** matches /abc or /abc/this/that/theother
/ab** DOES NOT match /abc/d (it is interpreted as if you used a single asterisk /ab*); it does match /absolutely
/**bc DOES NOT match /0/abc (it is interpreted as if you used a single asterisk /*bc); it does match /abc

Example 1: **/service/*

Matches	Does Not Match
service/Repository org/web/service/Entries org/something/else/tools/stiff/service/Entries	org/web/service/foo/bar/Entries

Example 2: org/parasoft/virtualize/**

Matches	Does Not Match
org/parasoft/virtualize/tools/service org/parasoft/virtualize/stuff	org/parasoft/somethingelse

Example 3: org/parasoft/**/EM/*

Matches	Does Not Match
org/parasoft/EM/Entries org/parasoft/virtualize/soatest/tools/EM/Entries	org/parasoft/EM/foo/bar/Entries

URL Parameter Correlation

URL parameter correlations allow you to specify URL parameters that will determine whether or not the message is processed. URL parameters can be repeated (you can have the same parameter set to different values). Any request that contains listed parameters as well as other parameters will correlate. A message that lacks one of the specified parameters will not match. URL parameter correlations apply to virtual assets that will be accessed over HTTP/HTTPS.

To configure a URL parameters correlation:

Select the URL parameter check box.
Click the Add button. A new entry row displays.
Enter the parameter name and value that this responder should match. If you want to match all messages that include this parameter name (no matter what value it is are set to), use [*].
Repeat steps 2 and 3 as needed until all parameter values that you want to match are specified.

For example, assume that an asset is deployed under the path http://myvirtserver:9080/MyAsset/MyPath and the following URL Parameters are specified in a responder:

Parameter Name	Value
param1	value1
param2	value2

The following request URLs will match this correlation criteria:

http://myvirtserver:9080/MyAsset/MyPath?param1=value1&m2=value2
http://myvirtserver:9080/MyAsset/MyPath?param1=value1&m2=value2&m3=value3
http://myvirtserver:9080/MyAsset/MyPath?param2=value2&m1=value1&m3=value3

The following URLs will NOT map to this responder:

http://myvirtserver:9080/MyAsset/MyPath?param1=value1&m2=someothervalue&m3=value3
http://myvirtserver:9080/MyAsset/MyPath?param1=value1&m3=value3

HTTP Method Correlation

HTTP method correlations allow you to specify HTTP methods that will determine whether or not the message is processed. HTTP path correlations apply to virtual assets that will be accessed over HTTP/HTTPS.

To configure an HTTP method correlation:

Select the HTTP method check box.
Specify the HTTP methods you want to use for correlation.

For example, if GET, POST, and PUT are checked, the responder will match HTTP requests with the method GET, POST, or PUT. HTTP requests with CONNECT, DELETE, HEAD, etc. will not match.

Data Source Correlation

After the above responder correlations are processed, 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.

For example, the following configures a correlation between the loanAmount value in incoming messages and the Amount column within the ApprovalLists data source:

SOAtest and Virtualize with CTP 2021.1 > Configuring Responder Correlations > image2016-7-1 17:40:10.png

For each incoming request, the loanAmount value will be matched to one of the rows in the Amount column. The response will then be parameterized with values from other columns for that same row.

When you’re configuring correlations, note that you can enter the name of a data source column, or select from the list of columns available in the data source associated with this tool (selected in the Data Source column at the top of the configuration area).

This shows the selected data source:

SOAtest and Virtualize with CTP 2021.1 > Configuring Responder Correlations > image2016-7-1 17:41:6.png

This shows the columns available in that data source:

SOAtest and Virtualize with CTP 2021.1 > Configuring Responder Correlations > image2016-7-1 17:40:52.png

Failover Options

When data source correlation is enabled, Virtualize uses the criteria specified in the data source correlations area to try to match values in the incoming message with data source values. If no data source row matches the specified incoming message value, this is considered to be a data source correlation failure.

When Continue searching for a matching responder if data source correlation fails is enabled (the default setting) and data source correlation fails for this responder, Virtualize will continue searching the responder suite for a responder with matching responder correlation. An error will be reported only if:

No responders meet the responder correlation criteria, or
Another responder in the responder suite matches the responder correlation, but its data source correlation fails and its data source correlation failover option is disabled.

If Continue searching for a matching responder if data source correlation fails is disabled and the data source correlation for this responder fails, an error will be reported immediately and Virtualize will stop searching for matching responders.

Request Body

This area allows you to specify one or more XPaths to run on the incoming messages in order to extract one or more values. The extracted values will be matched with values from the mapped data source columns.

You can enter XPaths directly in the XPath field, or add them using the XPath builder, which is described in Specifying XPaths.

URL Parameters

This area applies to assets that are accessed over HTTP/HTTPS. Specify one or more URL parameters to look for in the request URL. The parameter values will be matched with values from the mapped data source columns.

If multiple columns are used for the correlation, the values for each column row must all be either decoded or encoded. If all values are encoded, they must all be encoded in the same way—using either the plus sign or “%20” for spaces, but not both.

Data source correlations can correlate on the absence of a field in the request. For details, see the Virtualize User’s Guide.

URL Paths

This area applies to assets that are accessed over HTTP/HTTPS. You can configure data source value mappings based on path segment indexes.

For example, assume that:

The asset is deployed on the path http://myvirtserver:9080/MyAsset/MyPath
Incoming requests have the pattern http://myvirtserver:9080/MyAsset/MyPath/[somedynamicvalue]/B/C

If you want to take the value under the [somedynamicvalue] segment and match it with a data source column, then specify 2 for the URL Path Index. The counting is inclusive of the path segments that are used in the asset deployment path and start from zero.

If you want to match a dynamic value from the URL http://myvirtserver:9080/MyAsset/MyPath/A/[somedynamicvalue]/C, then use the path index value 3.

If multiple columns are used for the correlation, the values for each column row must all be either decoded or encoded. If all values are encoded, they must all be encoded in the same way—using either the plus sign or “%20” for spaces, but not both.