Service Virtualization

Hi!

We would like to use DevTest in scenario where we don't have the client ready yet (prototyping style). The wsdl is agreed and has 8 optional elements, and we would like to generate a response for each possible combination of the optional fields. We end up with rather many combinations, and we would like to make life as easy as possible.

What is the suggested method to handle optional elements?

I saw a demo of CA TDM last week where they were doing exactly this. They wrote out the messages with all the combinations of requests & responses so they could be read directly by CA SV (generate from request response pairs), and would also be usable as data messages & response validations for a Web Services test step in CA SV.

This approach allows SV to do what it's great at (date shifting at runtime, automatic correlation of request and response elements, responding with required delays on requested ports, deployments into multiple environments, etc) and allows TDM to do what it's great at (management of test data, synthesis of data elements, ensuring 100% coverage, etc)

Sent from my iPhone. Please excuse typos

As Rick mentions TDM can do some (but not all) of this.

after that, you are stuck with either generating messages by hand, or with some tool.

we have a few apis in the same state, and were never able to generate the rr pairs in a way that made sense. and the built in matching wasn't flexible enough. and the darned apis keep changing..(amaziing what happens when users start to exercise at the spec level.. ours change significantly 5 times). imagine the impact of moving a body field to the url and the impact on every match (it was in an array of structures each containing an array of structures, both different structures with optional fields) both arrays with a max size of 50

I ended up creating a generic service, like the newer Data Driven service model, that runs all the data and operations from a spreadsheet tab ( ours can handle multiple tabs per file).

Data Driven also doesn't address the optional field problem, however.

to get around the matching for not present optional fields (where DT requires the name of all variables present in each match pattern), we used the schema checking to handle message structure/content validation,

then used structure match (not text) to compare documents.. and we added wildcard support to allow fields and or structures to be accepted regardless of their contents (where DT only supports fields, after structure & array flattening)

we started with rest/json, but now the need for soap/xml is getting more focus, and I just completed migrating the generic service over to soap/xml too. the hardest part was getting a decent document compare (nodes in different orders), that was easy in json.

I would love to have TDM, and it will be a task for later this year..

you might want to read about my travails with optional fields in a recent post here how do deal with apis with large numbers of array elements containing structures with variable arrays (of structures), with optional fields

see Daniels answer