A perhaps simple question (then you please simply point me to a suitable article...). We're running a serviceV project to provide mock responses for loadtesting. The responses (soap XML) will be saved in a database for 30 services.
Right now I have a Database defined and resusing that in the DataSource defined in the service. The service has a value property, and a prepared property for ssn (key). The SQL Query uses the prepared property. All seems to work fine.
The dispatch style is script and my idea (perhaps wrongly) is that in the script I will extract the key from the request, set that as the prepared property, and then "execute" the Datasource and get the response.
In this a good strategy, or is there any other better way?
a) How do a set the prepared property ("ssn", in my DataSource GETPERSON) from groovy??
b) How do I execute and get the property "value" from my Datasource GETPERSON)
> We're running a serviceV project to provide mock responses for loadtesting.
I am not sure I completely understood your scenario...
Are you going to run a load test against the service virtualized in ServiceV ?
What is the reason for such test? What are you going to get as a result of it?
Service virtualization is just a dynamic mocking. Generally speaking, the location of the virtualized service is different from the same of the real service and virtualized service does not implement required business logic in all details.
We push load on the SUT (tweaking it, changing parameters in its configuration), and to make sure that we only notice the effect of the changes (and not the underlying systems) we mock the surrounding.
Quick note: I still think that *load* test against virtual service will not provide useful results. *Performance* test might work, but not load one.
Based on the description from https://support.smartbear.com/readyapi/docs/servicev/configure/datasources.html#how-it-works, I got it that the data query is executed on service start and returned dataset is static.
As you need dynamic dataset, the only idea that I have at the moment is to use ADO to get data from the database. Depending on the size of the database, I see two options for the implementation.
a) If the database is small, you can extract all data from the database and filter them later.
In order to do this, create MockRunListener.onMockRunnerStart event (https://support.smartbear.com/readyapi/docs/testing/handling-events.html#available-events) and add code that creates ADO.Recordset instance and fills it with the data from the database. (I know that in order to preserve resources, the obtained recordset can be disconnected from the database in VBScript code. Disconnection is not possible with JScript and I am not sure about Groovy - needs to be checked.) Obtained recordset should be preserved into (assigned to) the project global property (say, GetPerson). Then, in the response dispatch script, you should get the value of the SSN and filter the recordset (by setting its .Filter property to the SSN value). Use returned filtered value to craft the contents of the response.
b) If the database is large, then it may be too expensive to keep all data in the memory-based recordset. In this case in the MockRunListener.onMockRunnerStart event you may just open the connection to the database, attach this connection to the empty dataset and preserve the dataset in the public property. Then, within the response dispatch script you should provide this empty template dataset with the proper SQL statement and execute it to get the data.
Thanks for your help.
I have landed in a short term solution (that seems to work during my local tests), where I in the MockRunListener.onMockRunnerStart event create the connection to the database (releasing it in the MockRunnerStop event) and saves it in the contect.
Then in the response script I execute the sql query
* I fetch data from db for each request
=> I have abonded the datasource since I didn't get it to work.
=> I have to manually write the select sqls in the differents services
Do you see any apperent disadvantages with this approach?
> Do you see any apperent disadvantages with this approach?
No, I don't. Approach seems to be fine and, actually, it coincides with what I meant under option b) in my reply.
I don't see any really better way at the moment as the Datasource functionality seems to be of a 'static' nature.
The only thing that I can suggest now is to address Support directly via the https://support.smartbear.com/message/?prod=ReadyAPI form ans ask them if they can suggest something better. (I would appreciate it if you update this thread with the whatever result you'll get in this case.)