TMenasco
11 years agoOccasional Contributor
JSON to XML translation working inconsistently
Entered this yesterday in a new topic on the SoapUI general board under a different userID, before finding the appropriate userID for Pro users.
We are using REST/JSON for our solution, so all get requests have the HTTP header of "Accept | application/json". We have a fooList object being returned which has a collection of fooDetails for each Foo. Have Xquery assertions for each test step to specify "//*:Response/*:success" = Y.
Now, on some of the responses, the JSON is properly translated into XML that is used by the Xquery, but some not, even though the JSON response looks identical in structure (i.e. the JSON tags are the same for each). Have looked at the JSON, and see no violation of XML tag standards. Examples below, not the full payloads but enough I think to present this problem with context.
Response 1 JSON:
{
"metadata": {
"request": "getFoo",
"user": "ba808d19-ba24-4a1c-a554-157424d776c4",
"version": "v1"
},
"id": null,
"success": "Y",
"resultCode": 1,
"message": null,
"errors": [],
"data": {"fooList": [{"fooDetail": {
"status": "ACTIVE",
"dateCreated": 1401214098304,
"dateUpdated": 1401214098304,
"userCreated": "ba808d19-ba24-4a1c-a554-157424d776c4",
"userUpdated": "ba808d19-ba24-4a1c-a554-157424d776c4",
"version": 1,
"compositeId": "5a7f0d2d-c2b3-46bf-b6e4-3dd65f9e5375#1392398806730#1392403599248#1392744390077#902e084e-73aa-4089-804f-848374c69554",
"projectId": "5a7f0d2d-c2b3-46bf-b6e4-3dd65f9e5375",
"ownerId": "ba808d19-ba24-4a1c-a554-157424d776c4",
"createDate": null,
"type": "S",
"description": null,
blah blah more fooDetail instances… clipped at this point.
Response 2 JSON:
{
"metadata": {
"request": "getFoo",
"user": "ba808d19-ba24-4a1c-a554-157424d776c4",
"version": "v1"
},
"id": null,
"success": "Y",
"resultCode": 1,
"message": null,
"errors": [],
"data": {"fooList": [
{"fooDetail": {
"status": "ACTIVE",
"dateCreated": 1400464639749,
"dateUpdated": 1400464639749,
"userCreated": "ba808d19-ba24-4a1c-a554-157424d776c4",
"userUpdated": "ba808d19-ba24-4a1c-a554-157424d776c4",
"version": 1,
"compositeId": "5a7f0d2d-c2b3-46bf-b6e4-3dd65f9e5375#1392744390059#a4d60838-d15d-4d5c-8ed3-7fba754a482d",
"projectId": "5a7f0d2d-c2b3-46bf-b6e4-3dd65f9e5375",
"ownerId": "ba808d19-ba24-4a1c-a554-157424d776c4",
"createDate": null,
"type": "S",
"description": null,
blah blah more fooDetail instances...
Response 1 XML translation as seen on the test step:
<data>
<fooList>
<e>
<fooDetail>
<compositeId>5a7f0d2d-c2b3-46bf-b6e4-3dd65f9e5375#1392744390059#a4d60838-d15d-4d5c-8ed3-7fba754a482d</compositeId>
<createDate null="true"/>
<dateCreated>1400464639749</dateCreated>
<dateUpdated>1400464639749</dateUpdated>
<description null="true"/>
blah blah more fooDetail instances...
Response 2 XML translation as seen on the test step:
<xml/>
That's it, that's all. To me, I see not difference between the JSON responses other than different tokens and Id's. Has anyone else reported this? Is it a feature with priority? Any clues would be appreciated, because as it stands I cannot confirm success of my multi-step test cases, which is a must do.
Thanks for any help.
We are using REST/JSON for our solution, so all get requests have the HTTP header of "Accept | application/json". We have a fooList object being returned which has a collection of fooDetails for each Foo. Have Xquery assertions for each test step to specify "//*:Response/*:success" = Y.
Now, on some of the responses, the JSON is properly translated into XML that is used by the Xquery, but some not, even though the JSON response looks identical in structure (i.e. the JSON tags are the same for each). Have looked at the JSON, and see no violation of XML tag standards. Examples below, not the full payloads but enough I think to present this problem with context.
Response 1 JSON:
{
"metadata": {
"request": "getFoo",
"user": "ba808d19-ba24-4a1c-a554-157424d776c4",
"version": "v1"
},
"id": null,
"success": "Y",
"resultCode": 1,
"message": null,
"errors": [],
"data": {"fooList": [{"fooDetail": {
"status": "ACTIVE",
"dateCreated": 1401214098304,
"dateUpdated": 1401214098304,
"userCreated": "ba808d19-ba24-4a1c-a554-157424d776c4",
"userUpdated": "ba808d19-ba24-4a1c-a554-157424d776c4",
"version": 1,
"compositeId": "5a7f0d2d-c2b3-46bf-b6e4-3dd65f9e5375#1392398806730#1392403599248#1392744390077#902e084e-73aa-4089-804f-848374c69554",
"projectId": "5a7f0d2d-c2b3-46bf-b6e4-3dd65f9e5375",
"ownerId": "ba808d19-ba24-4a1c-a554-157424d776c4",
"createDate": null,
"type": "S",
"description": null,
blah blah more fooDetail instances… clipped at this point.
Response 2 JSON:
{
"metadata": {
"request": "getFoo",
"user": "ba808d19-ba24-4a1c-a554-157424d776c4",
"version": "v1"
},
"id": null,
"success": "Y",
"resultCode": 1,
"message": null,
"errors": [],
"data": {"fooList": [
{"fooDetail": {
"status": "ACTIVE",
"dateCreated": 1400464639749,
"dateUpdated": 1400464639749,
"userCreated": "ba808d19-ba24-4a1c-a554-157424d776c4",
"userUpdated": "ba808d19-ba24-4a1c-a554-157424d776c4",
"version": 1,
"compositeId": "5a7f0d2d-c2b3-46bf-b6e4-3dd65f9e5375#1392744390059#a4d60838-d15d-4d5c-8ed3-7fba754a482d",
"projectId": "5a7f0d2d-c2b3-46bf-b6e4-3dd65f9e5375",
"ownerId": "ba808d19-ba24-4a1c-a554-157424d776c4",
"createDate": null,
"type": "S",
"description": null,
blah blah more fooDetail instances...
Response 1 XML translation as seen on the test step:
<data>
<fooList>
<e>
<fooDetail>
<compositeId>5a7f0d2d-c2b3-46bf-b6e4-3dd65f9e5375#1392744390059#a4d60838-d15d-4d5c-8ed3-7fba754a482d</compositeId>
<createDate null="true"/>
<dateCreated>1400464639749</dateCreated>
<dateUpdated>1400464639749</dateUpdated>
<description null="true"/>
blah blah more fooDetail instances...
Response 2 XML translation as seen on the test step:
<xml/>
That's it, that's all. To me, I see not difference between the JSON responses other than different tokens and Id's. Has anyone else reported this? Is it a feature with priority? Any clues would be appreciated, because as it stands I cannot confirm success of my multi-step test cases, which is a must do.
Thanks for any help.