If I understand your scenario correctly, it sounds like there is probably some consistent data in addition to the variable data? A trivial example might be if there is a userID field that is always there and then the "addresses" array that varies. You probably have more to your example than that, but hopefully that gives the basic idea.
If my assumption about that is correct, you have what amounts to a couple of distinct usages for the input(request) data. Namely:
1. Some of it is necessary for matching and provides a unique "signature" for a type of transaction (i.e. all VerifyUserDetails calls have some basic sub-set of fields that are consistent, even if the address fields vary).
2. Some of it helps determine the structure of the response (i.e. if three "addresses" came in the request, three should go out in the response)
3. Some of it helps populate the response (i.e. the zip code in address 1 in the request needs to go into the zip code field in address 1 in the response)
And, in particular, I suspect that you have this variability in the purpose of your input data specifically because the data you see at playback isn't the same as the data you captured during recording. i.e. you may have recorded 5 "example" VerifyUserDetail transactions, but you actually have 200 users in your test environment and want the VS to "work" for any of them you want to use in a given test.
This is important because it represents a philosophical difference between the historical guiding principles for the product and your current usage. Historically the product was designed under the assumption that you would record the exact scenario(s) that you want to play back, and then you'd just play them back, verbatim, N number of times. Obviously, if we see ALL of the permutations during recording, then these problems go away. We already have all the various "signatures" that will happen along with their data, magic strings, etc and you can just go straight to playback. Further, the assumption has been that these Virtual Services are "throw away" in the sense that if your scenarios change and the data we captured before no longer applies, you'll simply throw away that VS and record a new one for the updated regression suite.
I mention that for historical perspective, not to imply that one way is "right" or "wrong". We could probably have a very enjoyable and long debate about that if we wanted. But that wouldn't help you right now.
So the short answer is that you'll have to do some level of scripting because of that history. We didn't build any features into the product to specifically help with what you are doing. But perhaps by attempting to be a bit clever (reader gets to decide if I was successful in being clever), we could minimize how much scripting you need to do. And/or make it such that maintaining that scripting is as easy as possible.
Here is what I would do:
1. Use SOAP or XML DPH to create arguments out of all the XML elements.
2. Use the Request Data Copier DPH to copy all of the arguments into TestExec properties
3. Use Request Data Manager to "keep" only the items that uniquely identify the signature (i.e. #1 above)
Then, once the service is created, open the VSM and add a script step before the respond step. In that script I would:
1. Check to see if the transaction in flight is one of these "variable" ones. If so:
2. Count the number of "addresses" in the incoming request and
3. Dynamically build a response chunk for those "addresses" including adding in any property references that are appropriate (i.e those "magic strings" you saved into testExec with Request Data Copier).
4. Save that chunk of text into a testExec property with a known name (i.e. 'dynamicResponseChunk').
Then, in the SI, find the transaction in question and edit the response to put a reference to "{{dynamicResponseChunk}}" in the place where that dynamically generated chunk should go.
The "hardest" part to get both right and "maintainable" is going to be the script step. Specifically, how to dynamically build that chunk and copy in the appropriate property references. I do think it is possible to do dynamically and generically since you know how many addresses there are and the properties are named in a consistent manner with an appropriate index. You should be able to check if a property exists with the expected name, if so, add a reference, if not, insert dummy data, a string generator pattern, or whatever.
Once you've done those steps, the Respond step will (automatically) correctly resolve all the property references, string patterns, etc and build a complete, "correct" response to send back to the caller.
I hope that helps. And if you have specific ideas on how we could enhance the product to enable you to accomplish this use case easier, we'd love to have those in the "Ideas" section.
Daniel