Hi, nmrao. That's a nice example of reading headers in the dispatch script. But your project doesn't have any code injected directly in the response, and that's where we're not able to use the kind of code you're using in the dispatch script to access the request headers.
This does give me the idea that we could generate every combination of responses in a different hardcoded response file and choose one of them using the dispatch script. Right now it's just two boolean values, so there are four combinations, but that's likely to increase soon and create a maintenance problem.
On the topic of load tests - the SmartBear documentation does suggest doing a load test. We didn't need a heavy load to demonstrate the problem, just 2 or 3 concurrent threads, so we used only the minimum load necessary.
Hi, nmrao. I watched the video, and he is injecting properties into the response in a similar way that we're doing it. I believe his code has a similar vulnerability that we have - it's possible for two clients to get the same value in a response from his virtual service, but his intention was for each response to be random.
This is not working when I use this as a response:
mode="${=def clientId = mockRequest.getRequestHeaders().get("myClientId").get(0); context.expand("#MockService#" + clientId + "-mode")}'"The problem is that "mockRequest" is not made available to code that is injected in a response like this (only in code in the script pane). Is there any way to read the request headers from code in the response?
We have some code in another response that modifies dates - this is working fine.
Other ideas on how to maintain state for multiple users of the virtual service is welcome. That state will affect the content of the responses.
