Forum Discussion

hvo's avatar
hvo
New Contributor
6 years ago

How to loop row response from JDBC Request to send Soap Request

Hi, I am new of ReadyAPI. I have a JDBC Request to get data from table using 2 columns (IntA, IntB). I can put the variable to Soap request to get the first row in the table. But I want to loop all...
  • richie's avatar
    richie
    6 years ago

    Hi hvo 

     

    sorry about the delay - I thought I'd responded to this already.

     

    Ok - so you're extracting some values from a table and then passing them to a SOAP request within a looping test case and you want to pass each uniterated value pair extracted from the table to each subsequent request.  I gotcha.

     

    First thing and Im not picking holes here - but why are you trying to extract multiple values from a table when the SOAP request you're hitting appears to just add the 2 numeric values together?  It seems like a lot of work for little gain - especially as you want to iterate through the extracted db values which is going to be fiddly.

     

    Is there a reason you have hardcoded some values into a single file (using the Filetype Datasource) or multiple files (1 for each test using the Directorytype Datasource)?

     

    Back to the JDBC step. My question about whether the number of records returned in yoru resultset via your SQL is constant is cos you can cheat abit - there isn't any native functionality in ReadyAPI! that allows the user to loop through retrieved records iteratively - I've had this problem myself and seen multiple people post about it - especially with the additional complication of never knowing how many records are being returned or if there are many records returned.

    If you want to use the native funcntionality method - you would need to setup property transfers for each of the extracted data records - not elegant, nor efficient but entirely feasible if you just need say 10 or less records.  The problem is if many records are returned in yoru SQL query (so a bit of tedious work) and especially if the number of records returned is NOT constant.(you could setup say 10 property transfers - but you could end up with empty transfers if the SQL executes and only retrieves 8 rows for example).

     

    The best option is groovyscript - and I cannot help with that - one of the groovy scripters on the site could help with that.

    If accordinng to the screenshot of the excel page - you have maybe 8 tests?  If you still maintain extracting values from a database to generate the numerics for input on yoru SOAP requests - you can add a clause to your SQL to limit the number of records you retrieve - i.e. so you only ever retrieve 8 records.

    If you do this, then its feasible to add 8 property transfers to extract the records in one go to a grid and then use the grid as the datasource for the SOAP part of the test (as you appear to have setup)

     

    From your screenshot it looks like you're using mySQL RDBMS.  I've never used mySQL myself - but I had a quick search and to restrict the number of returned rows you can use the LIMIT function - yoru screenshot indicates your SQL is as follows:

    select IntA, IntB
    from calculator

    so just add in the limit operator (there are a couple of parameters - count and offset - but I think you can just add in the count value and this will specify the max number retrieved as follows:

     

    select IntA, IntB
    from calculator
    limit, 8

    see the link for info on mySQL's limit

     

    As I state above - for yoru scenario the far better, more efficient and elegant option is groovy  to parse your JDBC response - extract the values for later use.  I have a JDBC script assertion that Rao put together for me to extract the table column name and data values but this only works for a SINGLE record - so this won't help you.

     

    So - do you really need to extract the numerics from a table are can you use hardcoded files?

    If you still want to use the JDBC step - can you limit the number of records that are returned?

     

    Cheers,

     

    rich