In case of an error, our WeatherException should be returned inside the soap:Fault/detail – whatever the error might be. So we´ll have to implement this requirement to provide a specification-compliant SOAP endpoint. ![]() Such standards are well known from “enterprise WSDLs”. Our specification states that the element WeatherException and its children should be put beneath the soap:Fault element, which resides inside the detail tag. But because we want to provoke an error, we´ll change the root tag to GetCityForecastByZIPfoo and send it against our endpoint: Actually our SOAP request´s root element has to be spelled as GetCityForecastByZIP according to the weather-general.xsd, which is imported into our WSDL. This time we´ll send a request against our endpoint that doesn´t comply to our XML schema. In case of an error, Apache CXF reacts in form of a standard SOAP fault. All the web service specifications define not if, but the terms how to react. Instead we should shift our focus to the reaction onto a validation error. Just fire a non-valid XML request against our endpoint (which we´ll do in a minute). And funnily enough, XML schema validation is already activated in our setup with Spring Boot and CXF. But the configuration of the XML schema validation isn´t our real problem. And even worse, the examples provided nearly all show up with Spring XML configuration, which we left behind already. You´ll find thousands of different variants to activate XML schema validation in Apache CXF. Once our SOAP endpoint is up and running (check ), we send a valid request against it with SoapUI :ġ 2 3 4 5 true 6 Deutschland 7 Weimar 8 Weimar 9 10 11 T17:17:06.903+02:00 12 0 13 weather forecast Weimar 14 15 0° 16 90° 17 18 19 5000% 20 22% 21 22 23 24 25 26 27 Standard SOAP faultsĪpproaching the topic for the first time, one could google something like “configure XML schema validation Apache CXF” or the like. □Īs a starting point we´ll use the preceding part´s project for now and fire up the SimpleBootCxfApplication with the help of a “Run as…”. As usual, there is a new GitHub project waiting in our tutorial repository – if you want to give it a try. We only have to follow this blog series first part´s guidelines and generate the Java classes from our WSDL and XSDs. Given a request that could be processed successfully, our response will always be 100% XML schema compliant. ![]() at the BiPro specs) that require our SOAP endpoint to react with a 100% XML schema compliant response in every situation – even when somebody sends bad XML requests which generate errors inside Apache CXF´s XML processing. There are some big web service specifications out there (look e.g. Now we want to look at a more particular case. ![]() In the preceding parts we learned how a SOAP web service is configured and tested in detail with Spring Boot and Apache CXF. Part 1: Spring Boot & Apache CXF – How to SOAP in 2016 Part 2: Spring Boot & Apache CXF – Testing SOAP web services Part 3: Spring Boot & Apache CXF – XML validation and custom SOAP faults Part 4: Spring Boot & Apache CXF – Logging & Monitoring with Logback, Elasticsearch, Logstash & Kibana Part 5: Spring Boot & Apache CXF – SOAP on steroids fueled by cxf-spring-boot-starter But how does this work with Spring Boot and Apache CXF? What about the reaction to the validation´s outcome? Most of the time, we have to tailor this response and build a custom SOAP fault. What about XML? Can’t we validate our data with XML easily? Just take the XML schema and … erm.
0 Comments
Leave a Reply. |