0% found this document useful (0 votes)
51 views

DIY Exercise 9-1 - Use Validators To Validate Response Schemas

1) The document describes a DIY exercise to add validation of REST and SOAP response schemas and filter retrieved data from multiple concurrent requests. 2) Students are asked to add JSON and XML validation of responses from accounts and flights services respectively. 3) The exercise then tests the validators, introduces invalid schemas, and concurrently processes both requests, filtering empty responses and combining valid data.

Uploaded by

surendra54
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
51 views

DIY Exercise 9-1 - Use Validators To Validate Response Schemas

1) The document describes a DIY exercise to add validation of REST and SOAP response schemas and filter retrieved data from multiple concurrent requests. 2) Students are asked to add JSON and XML validation of responses from accounts and flights services respectively. 3) The exercise then tests the validators, introduces invalid schemas, and concurrently processes both requests, filtering empty responses and combining valid data.

Uploaded by

surendra54
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

DIY Exercise 9-1: Use validators to validate response schemas

Time estimate: 2 hours

Objectives
In this exercise, you control message flow using validators. You will:
• Validate REST response schemas.
• Validate SOAP response schemas.
• Retrieve data concurrently.
• Filter retrieved data.

Scenario
You are tasked with adding some new functionality to an existing project that involves retrieving
data from different sources concurrently. The new requirement is to validate the responses
returned from each individual data source and filter the final payload if the payload does meet
certain criteria.

Import the starting project


Import /files/module09/route-mod09-starter.jar (in the MUFundamentals4.x DIY Files zip that
you can download from the Course Resources) into Anypoint Studio.

Validate the Accounts REST response schema


In the implementation.xml file’s accounts flow, add the JSON module and use the Validate
schema operation to validate the REST response returned to the HTTP Request. Use the
schema src/main/resources/schema/accountsSchema.json to validate against the REST
request.

Validate the Flights SOAP response schema


In the implementation.xml file’s flights flow, add the XML module and use the Validate schema
operation to validate the SOAP response from the web service. Use the schema
src/main/resources/schema/flightsSchema.xsd to validate against the SOAP request.

Test the validators


Test the validators by making requests to the following URLs:
http://locahost:8081/accounts
http://localhost:8081/flights
Change the validation rules so the response fails validation
Edit the accountsSchema.json file and the flightsSchema.xsd file to introduce a validation rule
that is not met by the accounts and flights calls. For example, modify the XSD Schema file by
changing the key name to something different than what is actually returned by the Delta SOAP
service response:
<xs:sequence>
<xs:element name="airlineName-BAD" form="unqualified" type="xs:NCName"/>

For the JSON schema file, change a key name in the required array value:
"required": ["salesID-BAD","id","firstName", …]
After you verify the validation fails for accounts and flights, change the schemas back to the
correct schemas.

Concurrently process both requests


In the main.xml file, create a new flow listening on the HTTP endpoint /flights_accounts to
concurrently retrieve data from the accounts flow and the flights flow in implementation.xml.

Filter the retrieved data


Add a Choice router to filter out any empty data returned from either the flights flow or the
accounts flow. There are three possible empty data scenarios:
• flights is empty
• accounts is empty
• flights and accounts are both empty
Return a message to the client that states that the payload returned from flights, accounts, or
both are empty.
Hint: If there are no values returned from the SOAP service, the key listAllFlightsResponse will
contain the value null.

Combine data
In the same Choice router, add another branch to return the flights and accounts data as a new
JSON data structure to the client if flights and accounts are not empty.

Here is what the new JSON data structure should look like:
{
accounts: {
attributes: { … },
payload: { … }
},
flights: {
attributes: { … },
payload: { … }
}

Verify your solution


Load the solution /files/module09/route-mod09-solution.jar (in the MUFundamentals4.x DIY
Files zip that you can download from the Course Resources) and compare your solution.

You might also like