Best Of

Update to Video https://customerportal.parasoft.com/lightningportal/s/videodetail?id=a3A4P0000047JbVUAU

Add a XML or JSON Data Bank (depending on payload format), and extract the root element of the payload.

The XPath you are using in your Data Bank for "field_B" is likely configured incorrectly. My guess is that it is likely extracting text nodes which do not exist the third and fifth row. You can try using the string() function instead of text(). So, if your XPath looks something like "/results/resultSet/rows/row/field_B/text()" then try changing it to "/results/resultSet/rows/row/field_B/string()".

You have a few options:

1. Define appropriate environment variables and then configure the payload to reference them. Use the -environmentConfig CLI option to pass the specific variable values that you want to use from the Jenkins job. See https://docs.parasoft.com/display/SOA20201/CLI+Options
2. Define a CSV data source with a single row of data and configure the payload to use values from it. Configure the Jenkins job to rewrite the CSV file used by the data source before running the test.
3. Define appropriate test variables in the .tst file, and configure the payload to use them. Create an Extension Tool at the start of the test scenario that reads the appropriate values from some external file and sets the values of the test variables.

All three of these options require the Jenkins job to write the values into a file that then gets processed by SOAtest - an XML file for -enviornmentConfig, a CSV file for the data source, or whatever format you would like for the test variables.

There should be no problem with installing SOAtest into a newer version of Eclipse. Note that SOAtest 2020.2 when it is released later this year will ship with Eclipse 2020-06.

Problem:
You are data driving an API with your SOAtest test and you have data validation requirements on an array of data the API returns. This can be problematic because depending on the request parameters, which you've externalized into a data source, you will receive varying length arrays coming back in the API response. Since traditional data sources are two-dimensional (columns and rows), there is a problem because you have to account for a third dimension. Instead of hitting your head against the wall wondering how to construct multiple data source sheets to manage this hierarchy, there is a nice application of XPath that makes this problem easier to overcome.

Solution:
Let's first take a look at how your data source can be constructed. This will also help to visualize the desired data validation described in the problem.

Here you can see I'm using a delimiting character '|' to separate the variable length accountIds I am expecting to see in my response depending on which data source row is being executed. Next, let's look at how the JSON Assertor in my SOAtest Test needs to be configured.

You can see the expected value is set to the Excel column that contains the delimiter we used. The magic that makes this validation possible is a customized XPath using the XPath function "string-join()".

Notice the string-join() function has two parameters. An XPath, and our delimiter String. You will want to start off with an XPath that locates all the accountIds in the response payload, and then use the string-join() function that will append your delimiting character in-between each node the XPath selects. If you want to learn more about the string-join() XPath function, see: https://www.w3schools.com/xml/xsl_functions.asp

And that's all it takes!