question

Glad this was helpful.  Response mapping is, arguably, the most challenging area of iTest -- but once you develop the expertise, it can pay big dividends. 

I'm attaching two files.  The first is a test case.  The first step is an "eval puts" step that simulates your step that produces the multi-table response.  This step has an analysis rule that uses a regular expression to extract just the top table out of the response and stores it into a variable.  The next step is an "eval puts" step that dumps out just that table, so that we can apply a response map to it.  The second attachment is the response map file that will extract the data from that top table. 

 

Put both files into any iTest folder in your workspace.  Then run the test case and you'll be able to see the results.  If you select the second eval step, you'll see that all of the data is nicely "blue-boxed".

 

Let me know if there's anything you don't understand here.

There is feature coming soon called "response filtering" that will be a big help here.  This feature will let you define a portion(s) of the response that you want to explicitly include or exclude in the final response to be analyzed.  In this case, you would be able to write a simple regex that would filter out everything other than the section you need, and then can use a simpler map to deal with just that portion.

 

In the meantime, I recall that dclaar elsewhere in the forum provided a very tricky way of dealing with a situation like this.  You can use a simple response map (pattern) that pulls out the section of the response you need and will store it in a variable, say var1.  Then on the next step, you can use "eval puts $var1" and can apply a response map to that step that operates only on the section that you need.  Effectively this does the response filtering "manually" that you need to deal with this kind of ugly situation.

 

Having said that, we've been talking for a while about creating an enhancement to our table mapper that can deal with these tables where one row in a table includes multiple lines -- as in this example you have here.  I think we should add that capability.  If we do, then the logic would try to detect the multiple lines per table row, and would concatenate the contents for each cell from all of the contents from the corresponding portions of those rows.  (Don't wait for it, though.  It might not be coming right away!)

 

Let me know if the solution suggested above seems daunting.  I might be able to put together an example for you.

I have seen a response something similar to this in the forum.. Please find it attached here.

Check if this helps to you. In this, they use one tabular map.