There is no configurable setting for this, but it is possible to do. There are several approaches and your choice could depend on factors not provided in your question. For sake of example, let's make some assumptions:
- 30% of the time, the VSI response is associated with transaction "A",
- 20% of the time, the VSI response is associated with transaction "B",
- 50% of the time, the VSI response is associated with transaction "C".
- The operation for the 30/20/50 scenario is:
GET /someThing
- And, the incoming request parameters on the VSI signature are: firstName, lastName and id.
The key to enabling the above type of requirement is to enable the addition of new information into the incoming request. To do this, we need one more assumption:
- The VSI can make a response determination using additional values (i.e., a fourth incoming request argument) that is/are not present in the original incoming request.
Steps (Abbreviated):
- Edit the VSI in Workstation, locate the GET /someThing operation, and add a new incoming request argument. This argument will be populated by a Scriptable DPH (see below) for each incoming request transaction.
- Next, set up two specific response transactions. One response contains the response for 20% of the time, and the other will contain the response for 30% of the time. Place the 50% of the time response in META's response. Set the Comparison Operator accordingly. In this example, the VSI only cares about the value of the 20, 30, and 50 so the other arguments are set to "anything".
Now, we need to install some algorithm in the VSM to calculate and set this new argument value so the VSI can select according to the percentage.
For this example, let's generate a random number between 1 and 100. Any value less than 21 equates to the 20% number. Any value between 21 and 50 (inclusive) represents the 30% and any value 51 to 100 represents the 50% response. Note: The greater the number of input transactions, the closer the response distribution will fall in mathematical terms for a true 20, 30, 50 split. It's like flipping a coin. (e.g., 1,000 flips of a coin will come closer to an exact 50/50 heads vs tails response than 10 flips of a coin do)
- In the VSM, LISTEN Step, add a Scriptable DPH. In this DPH, add code to generate the random number and add this number to the incoming request Argument List.
%beanshell%
import com.itko.util.ParameterList;
import java.util.*;
// only add this new argument to the desired operation
if ( ! "GET /someThing".equals( lisa_vse_request.getOperation() ) ) {
return;
}
// Place the incoming request Args in a list so we can add a new arg to it
ParameterList args = lisa_vse_request.getArguments();
// Generate a random number
int iRcdId = (new Random()).nextInt(101);
String sRandId;
// Any random value > 50 represents the 50% response
if ( iRcdId > 50 ) sRandId = "50";
else if ( iRcdId > 20 ) sRandId = "30"; // 30% responses here
else iRcdId = "20"; // 20% responses here
// Temporarily display a message in Event Log - remove before deploying
_logger.info("The Random Value is: {}", sRandId);
// add the new argument into the incoming request list for
// the GET /someThing operation.
args.addParameters("devtest_responseNum=" + sRandId);
lisa_vse_request.setArguments( args );
Try the above on a sample virtual service. Run the VSM in ITR mode. Use a tool to send a transaction to the endpoint. Watch the ITR Properties and Events to see how the selection occurs to see if you are satisfied with the results.