Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Use of Aggregate Data Sources in SOAtest: MAX nr of fields combined?

dgoedh
dgoedh Posts: 63 ✭
in SOAtest

Hi,

Currently I am building a project in SOAtest (9.1.0.6) in which I would like to combine some internal table data sources into an aggregate DS for use in XML Assertors to validate the contents of several DB tables. I have a project with several tst's underneath. I declare the DS on project level (not as Global DS!)
Constructing the Aggregate DS is not the problem. With Show Columns I can see all the fields of the separate tables, having unique labels. OK.
However when I attach the aggregate DS to an XML assertor to parametrize the expected value, I only get up to 3 combined tables, also after refreshing the tst and project. Having a 4th table added to the aggregate the expected value dropdown does not show all the variables.
So I wonder is there a MAX on either the number of fields in the expected value dropdown or in the combining of an aggregate DS.

Will Excel DS work better in this case?

Or might this be a performance issue, that it takes a long time to have the aggregate process and handle all the fields of the separate tables?

Thanks in advance.

Regards ,

Daniel

Tagged:

Comments

  • jakubiak
    jakubiak Posts: 813 admin

    How many columns total do you have in the 4 tables?

  • dgoedh
    dgoedh Posts: 63 ✭

    Hi Jakublak,

    Thanks for the reply. Already tracked down the source of the problem. Because I was still busy building the framework, the 'troublesome' table did not contain any data in it, except for the headers I was trying to address. Like I said: in the Aggregate the columns are shown, but for them to be incorporated in a dropdown SOAtest needs to have some data in them, apperently.
    I am wondering whether this behaviour is a worked as designed or we have a point of improvement at the horizon.

    Cheers,

    Daniel

  • jakubiak
    jakubiak Posts: 813 admin

    SOAtest is behaving as expected in this case. You will notice that if you try to use the data source without data directly outside of the aggregate data source, in that case also you will not see the columns for the data source in the dropdown. Once you add data, the columns will appear in the dropdown.

  • dgoedh
    dgoedh Posts: 63 ✭

    That's exactly the behaviour I come across.
    But what about Writable datasources, how can the data be accessed that has been written to them? Because when I try to parametrize a SOAPclient from a writable DS, I do not see the columns in the dropdown. How shoud that work?
    Cheers,
    Daniel

  • dgoedh
    dgoedh Posts: 63 ✭

    Hi,
    I just did another test, but now I added the writable DS WITHIN the Test Suite and then I can access the columns to parametize the SOAPclient. However when hooking up a writable DS from a higher level, outside the test suite, its columns are hidden, while for a static DS you can access these columns.

    Is this expected behaviour for a writable DS?

    Cheers,

    Daniel

  • jakubiak
    jakubiak Posts: 813 admin

    I am able to access columns for writable data sources at any level, whether the writable data source is global (outside the .tst), in a parent test suite, or within the same test suite as the client. However, for all cases, the column needs to have data in it - so I needed to add a value to the column before I was able to see the column in the dropdown. In other words, the writable is behaving the same way as all other data sources in that regard.

Categories

Tagged