I've tried to create VS from rrpairs. On my first attempt, request file was wrong :
GET gest/v1/au/app/id?id=1285311217 HTTP/1.1
The / is missing after GET. At the end of the creation, I saved a .vrs file, which contained :
I saw my error, and made a second attempt, with a good request file :
GET /gest/v1/au/app/id?id=1285311217 HTTP/1.1
And using the .vrs file in order to load all properties used previously.
But the basePath properties was not updated using the value found in new request file.
In the .vsm file, the basepath value was still gest/v1.
Is this behaviour the good one ? Or should the .vrs file/basepath be updated as we receive a new request file ?
Tested with workstation 10.1 / 10.3.
To me this is working as expected: saving your input into the wizard at the end of the recording is just that, it saves these values even if they are functionally not correct. If you recall them later from a .vrs file for a new recording they are placed there as you saved them. Apparently if there is a value in basepath (coming from .vrs) then the recording-wizard doesn’t put a new default basepath.
It could have been your choice (for whatever reason) to make the basepath shorter than the original value at recording – example “/” – the wizard should not try to correct your choice.
Yes, but when creating VS from rrpairs, the basepath is automaticaly build from rrpairs. The user cannot update it.
So, in other words, I'm create VS from rrpairs, and saved my parameters in .vrs file. But, oups, I made a mistake in request file : the base path is bad.
I have to recreate VS from rrpairs, and I cannot use .vrs file because of its content (the bad basepath saved in vrs file). So I have to re-specify all parameters... And my vrs file is useless...
That's why I'm not sure it is working as expected.
You have a point there, I was not focusing on the fact that you were creating from rrpairs, but even now after some rummaging around I am wondering if my memory is failing me because I could have sworn that at some point in time the basepath window also showed when creating from rrpairs (???). As said, I was more zooming in on whether or not the .vrs file should get updated automatically.
Anyways, yes, this may warrant a support issue, I don’t think the wizard should overwrite a basepath coming from a .vrs file. So, no automatic overwrite of an existing basepath value (coming from a .vrs file) but at least the basepath window should always show so that you can control the value.
Where you might not want an automatic overwrite is when you are merging .vsi files; the new set that you are adding with your current recording might have a more specific basepath which would make the resulting .vsm unsuited for the already existing transactions in the to-be-merged .vsi.
Now, even with the current behavior of not being able to adapt the basepath there are a few work-arounds other than respecifying all parameters.
Edit the .vrs file and correct the basepath in there
Edit the created .vsm and adapt the basepath in the Listen step
Thanks for your answer. And you're right for the work-around (we just have to remember about this behaviour, because it can puzzle the first time).
Case 01206950 opened for improvement.
And forgot to mention: if you start from a .vrs and you update something, eg. a basepath, or added a RequestDataManager, or… than don’t forget to save (and overwrite) your old .vrs file again before you close the recording wizard. Because as you noticed already, .vrs files don’t get updated automatically.