An approach I have used in the past is to add a Use Case description to each transaction so developers and testers could quickly identify their response scenarios.
It is up to you to decide whether or not this approach is viable given your specific requirements. For example, if you need to use learning mode, the approach may not be viable because Live Systems do not contain the argument, explained below, in the Live Response.
When a transaction enters a VSM, most services immediately parse the incoming transaction to construct a set of arguments used in the response selection process. We can extend this concept by adding an argument whose sole purpose is to provide a description of the Use Case scenario for those individuals that need to look at a VSI to determine response Use Cases.
1) Add an additional argument to the request.
- Add a Scriptable DPH, typically as the last Filter in the list
- Place a use case description of your choosing into the arg list. The VSI is going to override the value of the argument you add, so we don't care what the description value is at this point.
import com.itko.util.ParameterList;
ParameterList argList = lisa_vse_request.getArguments();
argList.addParameters("DevTestUseCase=someDescription"); // the new argument is called 'DevTestUseCase' but can be anything
lisa_vse_request.setArguments( argList );
You can add logic such as 'If the operation is "XYZ", add the argument, else skip adding the argument" to achieve your specific requirements.
2) Now you have an argument (key/value pair) added to each incoming request
If recording, add the Scriptable in the Recorder when you set up your DPHs and your Service Image picks up the additional argument at Record time
If an existing service,
Add the DPH,
Open the VSI
Manually add the argument to each operation.
Just take care to ensure that you use the exact same argument name in your VSI as your Scriptable adds. (In this example, DevTestUseCase.)
3) In the VSI, set your argument for each operation to compare on ANYTHING so the argument does not participate in any comparisons. You can use the Mass Change process to do this after adding the argument to each Operation's META.
4) Edit the Value associated with your argument to reflect the Use Case that each specific response applies to. Your value is freeform so as the Use Cases change, so can the description.
Now, the response Use Case is easily identifiable for each transaction in the VSI.
Here is an example VSI. The associated VSM has the Scriptable DPH to add the argument called DevTestUseCase using the code above.